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
