[PATCH v2 0/6] add post parse pSeries mem align, when ABI_UPDATE

[Andrea Bolognani]

On Thu, 2020-12-03 at 17:04 -0300, Daniel Henrique Barboza wrote:
> On 12/3/20 11:37 AM, Andrea Bolognani wrote:
> > This is where I'm a bit confused. IIUC the new value for <memory>,
> > 1572992 KiB, is exactly 1 GiB (initial NUMA memory) + 512 MiB (NVDIMM
> > guest area size) + 128 KiB (NVDIMM label size). Is that the value we
> > expect users to see in the XML? If the label size were not there I
> > would certainly say yes, but those extra 128 KiB make me pause. Then
> > again, the <target><size> for the <memory type='nvdimm'> element also
> > includes the label size, so perhaps it's all good? I just want to
> > make sure it is intentional :)
> 
> This is intentional. The target_size of the NVDIMM must contain the
> size of the guest visible area (256MB aligned) plus the label_size.
> 
> > The last bit of confusion is given by the fact that the
> > <currentMemory> element is not updated along with the <memory>
> > element. How will that work? Do I understand correctly that the guest
> > will actually get the full <memory> size, but if a memory balloon is
> > also present then the difference between <memory> and <currentMemory>
> > will be (temporarily) returned to the host using that mechanism?
> 
> Yes. <memory> is the max amount of memory the guest can have at boot
> time. For our case (pSeries) it consists of the base RAM + space for
> the DMA window for VFIO devices and PHBs and hotplug. This is what is
> being directly impacted by patch 06 and this series as a whole.
> 
> <currentMemory> is represented by our internal value of def->mem.cur_balloon.
> If there is a balloon device then <currentMemory> follows the lead
> of the device. If there is no RAM ballooning,
> def->mem.cur_balloon = <memory> = <currentMemory>.

Thank you for your explanation! It all sounds good :)

-- 
Andrea Bolognani / Red Hat / Virtualization