External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-08-05 00:13:48 +00:00
Code Issues Packages Projects Releases Wiki Activity
4b43da0bff
libvirt/tests/qemuxml2argvdata/memory-hotplug-virtio-mem.x86_64-latest.args

43 lines
2.3 KiB
Plaintext
Raw Normal View History

qemu: Build command line for virtio-mem Nothing special is happening here. All important changes were done when for 'virtio-pmem' (adjusting the code to put virtio memory on PCI bus, generating alias using qemuDomainDeviceAliasIndex(). The only bit that might look suspicious is no prealloc for virtio-mem. But if you think about it, the whole purpose of this device is to change amount of memory exposed to guest on the fly. There is no point in locking the whole backend in memory. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-19 09:16:55 +00:00
LC_ALL=C \
PATH=/bin \
HOME=/tmp/lib/domain--1-QEMUGuest1 \
USER=test \
LOGNAME=test \
XDG_DATA_HOME=/tmp/lib/domain--1-QEMUGuest1/.local/share \
XDG_CACHE_HOME=/tmp/lib/domain--1-QEMUGuest1/.cache \
XDG_CONFIG_HOME=/tmp/lib/domain--1-QEMUGuest1/.config \
qemuxml2argvdata: Use proper arch and emulator for x86 real capability tests Upcoming patches will modify how we populate the capability cache in tests to be more saner. This also means that the emulator binary and architecture used in the test files using real capabilities must match what the real capabilities have. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-01-04 15:36:46 +00:00
/usr/bin/qemu-system-x86_64 \
qemu: Build command line for virtio-mem Nothing special is happening here. All important changes were done when for 'virtio-pmem' (adjusting the code to put virtio memory on PCI bus, generating alias using qemuDomainDeviceAliasIndex(). The only bit that might look suspicious is no prealloc for virtio-mem. But if you think about it, the whole purpose of this device is to change amount of memory exposed to guest on the fly. There is no point in locking the whole backend in memory. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-19 09:16:55 +00:00
-name guest=QEMUGuest1,debug-threads=on \
-S \
-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/tmp/lib/domain--1-QEMUGuest1/master-key.aes"}' \
qemu: Switch to -accel We currently use -machine accel=XXX which is just a syntax sugar for -accel XXX. The former doesn't allow specifying arguments for accelerator, because all arguments passed to -machine are treated as arguments of machine itself. The -accel argument was introduced in QEMU commit v2.9.0-rc0~70^2~19 and since our minimum required version is newer (2.11.0) we can safely assume its existence and use it without any capability. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/233 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Tested-by: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-11-05 08:38:10 +00:00
-machine pc,usb=off,dump-guest-core=off \
-accel kvm \
qemu: Build command line for virtio-mem Nothing special is happening here. All important changes were done when for 'virtio-pmem' (adjusting the code to put virtio memory on PCI bus, generating alias using qemuDomainDeviceAliasIndex(). The only bit that might look suspicious is no prealloc for virtio-mem. But if you think about it, the whole purpose of this device is to change amount of memory exposed to guest on the fly. There is no point in locking the whole backend in memory. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-19 09:16:55 +00:00
-cpu qemu64 \
-m size=2095104k,slots=16,maxmem=1099511627776k \
-overcommit mem-lock=off \
-smp 2,sockets=2,dies=1,cores=1,threads=1 \
-object '{"qom-type":"memory-backend-ram","id":"ram-node0","size":2145386496}' \
-numa node,nodeid=0,cpus=0-1,memdev=ram-node0 \
-object '{"qom-type":"memory-backend-ram","id":"memvirtiomem0","reserve":false,"size":1073741824}' \
qemu: capabilities: Re-enable JSON syntax for -device Now that qemu fixed device unplug when JSON syntax is used with -device we can re-enable the feature. Since the old capability string representation is condemned by suggesting filtering it as a workaround we must introduce a new string. To achieve this the original capability position is renamed to X_QEMU_CAPS_DEVICE_JSON_BROKEN_HOTPLUG and a new position with the original name QEMU_CAPS_DEVICE_JSON is introduced to prevent us having to change the rest of the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-01-13 15:59:56 +00:00
-device '{"driver":"virtio-mem-pci","node":0,"block-size":2097152,"requested-size":536870912,"memdev":"memvirtiomem0","id":"virtiomem0","bus":"pci.0","addr":"0x2"}' \
qemu: Build command line for virtio-mem Nothing special is happening here. All important changes were done when for 'virtio-pmem' (adjusting the code to put virtio memory on PCI bus, generating alias using qemuDomainDeviceAliasIndex(). The only bit that might look suspicious is no prealloc for virtio-mem. But if you think about it, the whole purpose of this device is to change amount of memory exposed to guest on the fly. There is no point in locking the whole backend in memory. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-19 09:16:55 +00:00
-object '{"qom-type":"memory-backend-file","id":"memvirtiomem1","mem-path":"/dev/hugepages2M/libvirt/qemu/-1-QEMUGuest1","reserve":false,"size":2147483648,"host-nodes":[1,2,3],"policy":"bind"}' \
qemu: Allow prealloc for virtio-mem-pci There are a some scenarios in which we want to prealloc guest memory (e.g. when requested in domain XML, when using hugepages, etc.). With 'regular' <memory/> models (like 'dimm', 'nvdimm' or 'virtio-pmem') or regular guest memory it is corresponding memory-backend-* object that ends up with .prealloc attribute set. And that's desired because neither of those devices can change its size on the fly. However, with virtio-mem model things are a bit different. While one can set .prealloc attribute on corresponding memory-backend-* object it doesn't make much sense, because virtio-mem can inflate/deflate on the fly, i.e. change how big of a portion of the memory-backend-* object is exposed to the guest. For instance, from a say 4GiB module only a half can be exposed to the guest. Therefore, it doesn't make much sense to preallocate whole 4GiB and keep them allocated. But we still want the part exposed to the guest preallocated (when conditions described at the beginning are met). Having said that, with new enough QEMU the virtio-mem-pci device gained new attribute ".prealloc" which instructs the device to talk to the memory backend object and allocate only the requested portion of memory. Now, that our algorithm for setting .prealloc was isolated in a single function, the function can be called when constructing cmd line for virtio-mem-pci device. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-11-30 17:16:00 +00:00
-device '{"driver":"virtio-mem-pci","node":0,"block-size":2097152,"requested-size":1073741824,"memdev":"memvirtiomem1","prealloc":true,"id":"virtiomem1","bus":"pci.0","addr":"0x3"}' \
qemu: Build command line for virtio-mem Nothing special is happening here. All important changes were done when for 'virtio-pmem' (adjusting the code to put virtio memory on PCI bus, generating alias using qemuDomainDeviceAliasIndex(). The only bit that might look suspicious is no prealloc for virtio-mem. But if you think about it, the whole purpose of this device is to change amount of memory exposed to guest on the fly. There is no point in locking the whole backend in memory. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-19 09:16:55 +00:00
-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \
-display none \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc \
-no-shutdown \
-no-acpi \
-boot strict=on \
qemu: capabilities: Re-enable JSON syntax for -device Now that qemu fixed device unplug when JSON syntax is used with -device we can re-enable the feature. Since the old capability string representation is condemned by suggesting filtering it as a workaround we must introduce a new string. To achieve this the original capability position is renamed to X_QEMU_CAPS_DEVICE_JSON_BROKEN_HOTPLUG and a new position with the original name QEMU_CAPS_DEVICE_JSON is introduced to prevent us having to change the rest of the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-01-13 15:59:56 +00:00
-device '{"driver":"piix3-usb-uhci","id":"usb","bus":"pci.0","addr":"0x1.0x2"}' \
qemu: Build command line for virtio-mem Nothing special is happening here. All important changes were done when for 'virtio-pmem' (adjusting the code to put virtio memory on PCI bus, generating alias using qemuDomainDeviceAliasIndex(). The only bit that might look suspicious is no prealloc for virtio-mem. But if you think about it, the whole purpose of this device is to change amount of memory exposed to guest on the fly. There is no point in locking the whole backend in memory. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-19 09:16:55 +00:00
-blockdev '{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"raw","file":"libvirt-1-storage"}' \
qemu: capabilities: Re-enable JSON syntax for -device Now that qemu fixed device unplug when JSON syntax is used with -device we can re-enable the feature. Since the old capability string representation is condemned by suggesting filtering it as a workaround we must introduce a new string. To achieve this the original capability position is renamed to X_QEMU_CAPS_DEVICE_JSON_BROKEN_HOTPLUG and a new position with the original name QEMU_CAPS_DEVICE_JSON is introduced to prevent us having to change the rest of the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-01-13 15:59:56 +00:00
-device '{"driver":"ide-hd","bus":"ide.0","unit":0,"drive":"libvirt-1-format","id":"ide0-0-0","bootindex":1}' \
qemu: command: Use JSON for parameters of -audiodev '-audiodev' as a modern implementation based on QAPI already takes JSON as the argument. Convert our code to use it directly. The declaration of the QAPI types can be found in 'qemu.git/qapi/audio.json'. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-11-09 15:58:22 +00:00
-audiodev '{"id":"audio1","driver":"none"}' \
qemu: capabilities: Re-enable JSON syntax for -device Now that qemu fixed device unplug when JSON syntax is used with -device we can re-enable the feature. Since the old capability string representation is condemned by suggesting filtering it as a workaround we must introduce a new string. To achieve this the original capability position is renamed to X_QEMU_CAPS_DEVICE_JSON_BROKEN_HOTPLUG and a new position with the original name QEMU_CAPS_DEVICE_JSON is introduced to prevent us having to change the rest of the code. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2022-01-13 15:59:56 +00:00
-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.0","addr":"0x4"}' \
qemu: Build command line for virtio-mem Nothing special is happening here. All important changes were done when for 'virtio-pmem' (adjusting the code to put virtio memory on PCI bus, generating alias using qemuDomainDeviceAliasIndex(). The only bit that might look suspicious is no prealloc for virtio-mem. But if you think about it, the whole purpose of this device is to change amount of memory exposed to guest on the fly. There is no point in locking the whole backend in memory. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2021-01-19 09:16:55 +00:00
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
Reference in New Issue Copy Permalink