[PATCH v2 0/6] add post parse pSeries mem align, when ABI_UPDATE
Daniel Henrique Barboza
danielhb413 at gmail.com
Thu Dec 3 20:04:10 UTC 2020
On 12/3/20 11:37 AM, Andrea Bolognani wrote:
> On Wed, 2020-12-02 at 15:08 +0100, Andrea Bolognani wrote:
>> On Wed, 2020-12-02 at 09:14 -0300, Daniel Henrique Barboza wrote:
>>> Andrea/Peter, do you want to take a look again to see if there's
>>> something that I missed?
>>
>> Yeah, sorry for not being very responsive, and thanks a lot Michal
>> for picking up the slack! I'll try to give it at least a quick look
>> by the end of the day.
>
> Sorry I didn't managed to get back to you yesterday but, given that
> we managed to get this at least partially wrong in every previous
> iteration, you'll hopefully forgive me for being perhaps a bit
> overcautious O:-)
Always good to try to minimize error :)
>
> As mentioned elsewhere, in the process of trying to convince myself
> that these changes are in fact correct I found it useful be able to
> make a direct comparison between the ABI_UPDATE case and the vanilla
> one, and to facilitate that I've produced a couple of simple
> patches[1] that I'm hoping you'll agree to rebase your work on top
> of. I have actually already done that locally, so feel free to simply
> pick up the corresponding branch[2].
That's what I'll end up doing. I'll probably push patches 1, 2 and 4
first, since they got the R-bs and aren't affected by this rebase,
then I'll make more adjustments based on your review and post a v3.
>
> Anyway, assuming you're working from that branch, here are the
> differences that are introduced by using ABI_UPDATE:
>
> $ diff -Naru tests/qemuxml2xmloutdata/memory-hotplug-ppc64-nonuma.xml tests/qemuxml2xmloutdata/memory-hotplug-ppc64-nonuma-abi-update.xml
> --- tests/qemuxml2xmloutdata/memory-hotplug-ppc64-nonuma.xml 2020-12-03 14:19:21.486145577 +0100
> +++ tests/qemuxml2xmloutdata/memory-hotplug-ppc64-nonuma-abi-update.xml 2020-12-03 14:57:09.857621727 +0100
> @@ -24,13 +24,13 @@
> <panic model='pseries'/>
> <memory model='dimm'>
> <target>
> - <size unit='KiB'>523264</size>
> + <size unit='KiB'>524288</size>
> </target>
> <address type='dimm' slot='0'/>
> </memory>
> <memory model='dimm'>
> <target>
> - <size unit='KiB'>524287</size>
> + <size unit='KiB'>524288</size>
> </target>
> <address type='dimm' slot='1'/>
> </memory>
> $ diff -Naru tests/qemuxml2argvdata/memory-hotplug-ppc64-nonuma.args tests/qemuxml2argvdata/memory-hotplug-ppc64-nonuma-abi-update.args
> --- tests/qemuxml2argvdata/memory-hotplug-ppc64-nonuma.args 2020-12-03 14:19:21.486145577 +0100
> +++ tests/qemuxml2argvdata/memory-hotplug-ppc64-nonuma-abi-update.args 2020-12-03 14:57:09.857621727 +0100
> @@ -11,7 +11,7 @@
> -name QEMUGuest1 \
> -S \
> -machine pseries,accel=kvm,usb=off,dump-guest-core=off \
> --m size=1310720k,slots=16,maxmem=4194304k \
> +-m size=1048576k,slots=16,maxmem=4194304k \
> -realtime mlock=off \
> -smp 1,sockets=1,cores=1,threads=1 \
> -object memory-backend-ram,id=memdimm0,size=536870912 \
> $
>
> You explain very well the command line change in the commit message
> for patch 6/6, and the output XML now reflects the aligned size for
> DIMMs that was used on the command line even before your changes, so
> this all looks good.
>
> $ diff -Naru tests/qemuxml2xmloutdata/memory-hotplug-nvdimm-ppc64.xml tests/qemuxml2xmloutdata/memory-hotplug-nvdimm-ppc64-abi-update.xml
> --- tests/qemuxml2xmloutdata/memory-hotplug-nvdimm-ppc64.xml 2020-12-03 14:57:09.857621727 +0100
> +++ tests/qemuxml2xmloutdata/memory-hotplug-nvdimm-ppc64-abi-update.xml 2020-12-03 14:57:09.857621727 +0100
> @@ -2,7 +2,7 @@
> <name>QEMUGuest1</name>
> <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
> <maxMemory slots='16' unit='KiB'>1099511627776</maxMemory>
> - <memory unit='KiB'>1267710</memory>
> + <memory unit='KiB'>1572992</memory>
> <currentMemory unit='KiB'>1267710</currentMemory>
> <vcpu placement='static' cpuset='0-1'>2</vcpu>
> <os>
> @@ -34,7 +34,7 @@
> <path>/tmp/nvdimm</path>
> </source>
> <target>
> - <size unit='KiB'>550000</size>
> + <size unit='KiB'>524416</size>
> <node>0</node>
> <label>
> <size unit='KiB'>128</size>
> $ diff -Naru tests/qemuxml2argvdata/memory-hotplug-nvdimm-ppc64.args tests/qemuxml2argvdata/memory-hotplug-nvdimm-ppc64-abi-update.args
> $
>
> 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>.
Thanks,
DHB
>
> Sorry again for all the questions and for delaying your work. I'm
> just trying to make sure we don't have to come back to it again in a
> couple of months O:-)
>
>
> [1] https://www.redhat.com/archives/libvir-list/2020-December/msg00244.html
> [2] https://gitlab.com/abologna/libvirt/-/tree/ppc64-memalign
>
More information about the libvir-list
mailing list