On Tue, 15 Sep 2020 10:59:04 +0100 Daniel P. Berrangé <berrange@redhat.com> 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@redhat.com> 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.
for new machine types, that shouldn't happen as they use memory-backend internally (assuming CLI isn't messed up). old machine types should cope with switch too, the only thing we were not able to convert "-numa node,mem" => "-numa memdev" due to odd sizes 'mem' allowed, that's why "-numa node,mem" were preserved for old machine types.
Regards, Daniel