On 9/15/20 11:59 AM, Daniel P. Berrangé wrote:
On Tue, Sep 15, 2020 at 11:53:56AM +0200, Igor Mammedov wrote:On Tue, 15 Sep 2020 10:54:46 +0200 Michal Privoznik <mprivozn@xxxxxxxxxx> wrote:On 9/8/20 3:55 PM, Ján Tomko wrote:On a Tuesday in 2020, Michal Privoznik wrote:diff --git a/tests/qemuxml2argvdata/memfd-memory-default-hugepage.x86_64-latest.args b/tests/qemuxml2argvdata/memfd-memory-default-hugepage.x86_64-latest.args index 5d256c42bc..b43e7d9c3c 100644 --- a/tests/qemuxml2argvdata/memfd-memory-default-hugepage.x86_64-latest.args +++ b/tests/qemuxml2argvdata/memfd-memory-default-hugepage.x86_64-latest.args @@ -12,14 +12,16 @@ QEMU_AUDIO_DRV=none \ -S \ -object secret,id=masterKey0,format=raw,\ file=/tmp/lib/domain--1-instance-00000092/master-key.aes \ --machine pc-i440fx-2.3,accel=kvm,usb=off,dump-guest-core=off \ +-machine pc-i440fx-2.3,accel=kvm,usb=off,dump-guest-core=off,\ +memory-backend=pc.ram \ -cpu qemu64 \ -m 14336 \ --mem-prealloc \ +-object memory-backend-memfd,id=pc.ram,hugetlb=yes,hugetlbsize=2097152,\ +share=yes,prealloc=yes,size=15032385536 \ -overcommit mem-lock=off \ -smp 8,sockets=1,dies=1,cores=8,threads=1 \ -object memory-backend-memfd,id=ram-node0,hugetlb=yes,hugetlbsize=2097152,\ -share=yes,size=15032385536,host-nodes=3,policy=preferred \ +share=yes,prealloc=yes,size=15032385536,host-nodes=3,policy=preferred \ -numa node,nodeid=0,cpus=0-7,memdev=ram-node0 \ -uuid 126f2720-6f8e-45ab-a886-ec9277079a67 \ -display none \Should we format all the fields twice in these cases?Ah, good question. Honestly, I don't remember, it was slightly longer ago that I've written these patches. Igor, do you perhaps remember whether libvirt needs to specify both: -machine memory-backend=$id and -object memory-backend-*,id=$id?the later defines backend and the former uses it, short answer is yes. you do not need --mem-prealloc if you explicitly set "prealloc=yes" on backend. I'd prefer if libvirt stopped using old -mem-prealloc and -mem-path in favor of explicit properties on backend, so QEMU could deprecate it and drop aliasing code which uses global properties hack.IIRC, we tried todo that in the past and the change to use a backend impacted migration ABI compatibility.
Yes, but the problem there was that the memory IDs were not the same. That is: -m + -mem-path would create a memory-backend-file equivalent and set its ID to pc.ram (assuming this is x86 - hence default-ram-id exposure and tracking). But libvirt did generate different ID back then which was incompatible.
Michal
