- Devel - libvirt List Archives

[PATCH 0/6] Remove few useless syntax-checks
by Peter Krempa 31 Mar '21

31 Mar '21

Peter Krempa (6): syntax-check: Remove check for proper spelling of 'Red Hat' syntax-check: Clean up check for g_auto* syntax-check: Remove used header checks for gnulib modules syntax-check: Remove check for prohibited 'WITH_MBRTOWC' syntax-check: Remove unused header check for 'strings.h' syntax-check: Remove GFDL format check build-aux/syntax-check.mk | 134 +------------------------------------- 1 file changed, 1 insertion(+), 133 deletions(-) -- 2.29.2

2 7

[PATCH v2 00/12] libxl: bump LIBXL_API_VERSION
by Olaf Hering 31 Mar '21

31 Mar '21

Various changes to handle libxl API variants. Olaf v2: - adjust names of wrapper functions adjust indent adjust style of braces rename new header Olaf Hering (12): libxl: add API wrapper for libxl_domain_create_restore libxl: add API wrapper for libxl_retrieve_domain_configuration libxl: add API wrapper for libxl_domain_shutdown libxl: add API wrapper for libxl_domain_reboot libxl: add API wrapper for libxl_domain_pause libxl: add API wrapper for libxl_domain_unpause libxl: add API wrapper for libxl_domain_need_memory libxl: add API wrapper for libxl_get_free_memory libxl: add API wrapper for libxl_set_vcpuonline libxl: add API wrapper for libxl_send_trigger libxl: add API wrapper for libxl_set_memory_target libxl: use API 4.13 to support domUs with more than 4TB meson.build | 7 +- src/libxl/libxl_api_wrapper.h | 217 ++++++++++++++++++++++++++++++++++ src/libxl/libxl_conf.c | 5 +- src/libxl/libxl_domain.c | 27 +++-- src/libxl/libxl_driver.c | 25 ++-- src/libxl/libxl_migration.c | 3 +- tests/libxlmock.c | 7 +- 7 files changed, 261 insertions(+), 30 deletions(-) create mode 100644 src/libxl/libxl_api_wrapper.h

2 14

[PATCH-for-5.2] target/mips: Deprecate nanoMIPS ISA
by Philippe Mathieu-Daudé 30 Mar '21

30 Mar '21

The nanoMIPS ISA has been announced in 2018 for various projects: GCC: https://gcc.gnu.org/legacy-ml/gcc/2018-05/msg00012.html Linux: https://lwn.net/Articles/753605/ QEMU: https://www.mail-archive.com/qemu-devel@nongnu.org/msg530721.html Unfortunately the links referenced doesn't work anymore (www.mips.com) >From this Wayback machine link [1] we can get to a working place to download a toolchain (a more recent release than the one referenced in the announcement mails): http://codescape.mips.com/components/toolchain/nanomips/2018.04-02/download… The toolchain page mention LLVM but simply links http://llvm.org/ where there is no reference on nanoMIPS. The only reference in the GCC mailing list, is the nanoMIPS announcement: https://gcc.gnu.org/pipermail/gcc/2018-May.txt The developer who authored the announcements have been emailed [2] to ask for more information but all their emails are now bouncing: - Your message to Stefan.Markovic(a)mips.com couldn't be delivered. - Your message to smarkovic(a)wavecomp.com couldn't be delivered. - Couldn't deliver the message to the following recipients: Robert.Suchanek(a)mips.com, matthew.fortune(a)mips.com, marcin.nowakowski(a)mips.com Our deprecation policy do not allow feature removal before 2 release, therefore declare the nanoMIPS ISA code deprecated as of QEMU 5.2. This gives time to developers to update the QEMU community, or interested parties to step in to maintain this code. [1] https://web.archive.org/web/20180904044530/https://www.mips.com/develop/too… [2] https://www.mail-archive.com/qemu-devel@nongnu.org/msg756392.html Signed-off-by: Philippe Mathieu-Daudé <f4bug(a)amsat.org> --- docs/system/deprecated.rst | 23 +++++++++++++++++++++++ MAINTAINERS | 6 +++++- 2 files changed, 28 insertions(+), 1 deletion(-) diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst index 32a0e620dbb..a26af200c73 100644 --- a/docs/system/deprecated.rst +++ b/docs/system/deprecated.rst @@ -310,6 +310,13 @@ to build binaries for it. ``Icelake-Client`` CPU Models are deprecated. Use ``Icelake-Server`` CPU Models instead. +MIPS ``I7200`` CPU Model (since 5.2) +'''''''''''''''''''''''''''''''''''' + +The ``I7200`` guest CPU relies on the nanoMIPS ISA, which is deprecated +(the ISA has never been upstreamed to a compiler toolchain). Therefore +this CPU is also deprecated. + System emulator devices ----------------------- @@ -413,6 +420,13 @@ The ``ppc64abi32`` architecture has a number of issues which regularly trip up our CI testing and is suspected to be quite broken. For that reason the maintainers strongly suspect no one actually uses it. +MIPS ``I7200`` CPU (since 5.2) +'''''''''''''''''''''''''''''' + +The ``I7200`` guest CPU relies on the nanoMIPS ISA, which is deprecated +(the ISA has never been upstreamed to a compiler toolchain). Therefore +this CPU is also deprecated. + Related binaries ---------------- @@ -477,6 +491,15 @@ versions, aliases will point to newer CPU model versions depending on the machine type, so management software must resolve CPU model aliases before starting a virtual machine. +Guest Emulator ISAs +------------------- + +nanoMIPS ISA +'''''''''''' + +The ``nanoMIPS`` ISA has never been upstreamed to any compiler toolchain. +As it is hard to generate binaries for it, declare it deprecated. + Recently removed features ========================= diff --git a/MAINTAINERS b/MAINTAINERS index 2c22bbca5ac..4f701012eea 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -227,7 +227,7 @@ R: Aleksandar Rikalo <aleksandar.rikalo(a)syrmia.com> S: Odd Fixes F: target/mips/ F: default-configs/*mips* -F: disas/*mips* +F: disas/mips.c F: docs/system/cpu-models-mips.rst.inc F: hw/intc/mips_gic.c F: hw/mips/ @@ -240,6 +240,10 @@ F: include/hw/timer/mips_gictimer.h F: tests/tcg/mips/ K: ^Subject:.*(?i)mips +MIPS TCG CPUs (nanoMIPS ISA) +S: Orphan +F: disas/nanomips.* + Moxie TCG CPUs M: Anthony Green <green(a)moxielogic.com> S: Maintained -- 2.26.2

3 4

[PATCH] vm : forbid to start a removing vm
by Hogan Wang 30 Mar '21

30 Mar '21

From: Zhuang Shengen <zhuangshengen(a)huawei.com> When a vm is doing migration phase confirm, and then start it concurrently, it will lead to the vm out of libvirtd control. Cause Analysis: 1. thread1 migrate vm out. 2. thread2 start the migrating vm. 3. thread1 remove vm from domain list after migrate success. 4. thread2 acquired the vm job success and start the vm. 5. cannot find the vm any more by 'virsh list' command. Actually, the started vm is not exist in the domain list. Solution: Check the vm->removing state before start. Signed-off-by: Zhuang Shengen <zhuangshengen(a)huawei.com> Reviewed-by: Hogan Wang <hogan.wang(a)huawei.com> --- src/qemu/qemu_driver.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index d1a3659774..a5dfea94cb 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6637,6 +6637,12 @@ qemuDomainCreateWithFlags(virDomainPtr dom, unsigned int flags) goto endjob; } + if (vm->removing) { + virReportError(VIR_ERR_OPERATION_INVALID, + "%s", _("domain is already removing")); + goto endjob; + } + if (qemuDomainObjStart(dom->conn, driver, vm, flags, QEMU_ASYNC_JOB_START) < 0) goto endjob; -- 2.23.0

2 4

Ways to deal with broken machine types
by Igor Mammedov 30 Mar '21

30 Mar '21

On Tue, 23 Mar 2021 16:04:11 +0100 Thomas Lamprecht <t.lamprecht(a)proxmox.com> wrote: > On 23.03.21 15:55, Vitaly Cheptsov wrote: > >> 23 марта 2021 г., в 17:48, Michael S. Tsirkin <mst(a)redhat.com> написал(а): > >> > >> The issue is with people who installed a VM using 5.1 qemu, > >> migrated to 5.2, booted there and set a config on a device > >> e.g. IP on a NIC. > >> They now have a 5.1 machine type but changing uid back > >> like we do will break these VMs. > >> > >> Unlikley to be common but let's at least create a way for these people > >> to used these VMs. > >> > > They can simply set the 5.2 VM version in such a case. I do not want to > let this legacy hack to be enabled in any modern QEMU VM version, as it violates ACPI specification and makes the life more difficult for various other software like bootloaders and operating systems. > > Yeah here I agree with Vitaly, if they already used 5.2 and made some configurations > for those "new" devices they can just keep using 5.2? > > If some of the devices got configured on 5.1 and some on 5.2 there's nothing we can > do anyway, from a QEMU POV - there the user always need to choose one machine version > and fix up the device configured while on the other machine. According to testing it appears that issue affects virtio drivers so it may lead to failure to boot guest (and there was at least 1 report about virtio-scsi being affected). Let me hijack this thread for beyond this case scope. I agree that for this particular bug we've done all we could, but there is broader issue to discuss here. We have machine versions to deal with hw compatibility issues and that covers most of the cases, but occasionally we notice problem well after release(s), so users may be stuck with broken VM and need to manually fix configuration (and/or VM). Figuring out what's wrong and how to fix it is far from trivial. So lets discuss if we can help to ease this pain, yes it will be late for first victims but it's still better than never. I'll try to sum up idea Michael suggested (here comes my unorganized brain-dump), 1. We can keep in VM's config QEMU version it was created on and as minimum warn user with a pointer to known issues if version in config mismatches version of actually used QEMU, with a knob to silence it for particular mismatch. When an issue becomes know and resolved we know for sure how and what changed and embed instructions on what options to use for fixing up VM's config to preserve old HW config depending on QEMU version VM was installed on. some more ideas: 2. let mgmt layer to keep fixup list and apply them to config if available (user would need to upgrade mgmt or update fixup list somehow) 3. let mgmt layer to pass VM's QEMU version to currently used QEMU, so that QEMU could maintain and apply fixups based on QEMU version + machine type. The user will have to upgrade to newer QEMU to get/use new fixups. In my opinion both would lead to explosion of 'possibly needed' properties for each change we introduce in hw/firmware(read ACPI) and very possibly a lot of conditional branches in QEMU code. And I'm afraid it will become hard to maintain QEMU => more bugs in future. Also it will lead to explosion of test matrix for downstreams who care about testing. If we proactively gate changes on properties, we can just update fixup lists in mgmt, without need to update QEMU (aka Insite rules) at a cost of complexity on QMEU side. Alternatively we can be conservative in spawning new properties, that means creating them only when issue is fixed and require users to update QEMU, so that fixups could be applied to VM. Feel free to shoot the messenger down or suggest ways how we can deal with the problem.

5 7

[PATCH] NEWS: Mention fix for exec-restart of virtlo(g|ck)d and 'object_add' improvements
by Peter Krempa 30 Mar '21

30 Mar '21

Mention that libvirt-7.2 will be needed to do stuff that executes 'object-add'/'object-del' QMP commands with the upcoming qemu-6.0 and that exec-restart of virtlockd and virtlogd was fixed. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 2142cbd21e..1c4186917e 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -35,8 +35,20 @@ v7.2.0 (unreleased) * **Improvements** + * qemu: Compatibility with ``qemu-6.0`` for certain hot-(un)-plug operations + + Libvirt ``7.2.0`` is required for compatibility with the upcoming + ``qemu-6.0`` release for hotplug and hotunplug of certain devices and + helpers, such as iothreads, chardevs, RNG devices, disks with secret, ... + * **Bug fixes** + * virtlogd|virtlockd: Fixed crash when upgrading the daemons in-place + + A bug preventing the in-place upgrade of ``virtlogd`` and ``virtlockd`` + daemons was fixed, so they can again be upgraded without dropping the log + file descriptors or locks on files. + v7.1.0 (2021-03-01) =================== -- 2.29.2

2 1

Entering freeze for libvirt-7.2.0
by Jiri Denemark 30 Mar '21

30 Mar '21

I have just tagged v7.2.0-rc1 in the repository and pushed signed tarballs and source RPMs to https://libvirt.org/sources/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Thanks, Jirka

1 1

[PATCH] qemu: don't reject virtiofs for qemu:///session
by Cole Robinson 29 Mar '21

29 Mar '21

Currently libvirt rejects attempts to use virtiofs with qemu:///session. Indeed virtiofs does not have a chance of working with typical session usage, because virtiofsd needs multiple linux capabilities to perform its job. The only way to do this with out of the box qemu packaging is to run virtiofsd as root, so libvirtd must run as root, so qemu:///system is required. But it's possible that a custom environment could setuid or set file capabilities on the virtiofsd binary. In this case qemu:///session would work fine. This may be an option for kubevirt to help them transition to using qemu:///session everywhere Drop the two pieces that block virtiofs for qemu:///session. Attempts to use virtiofs for stock qemu:///session will fail at qemu startup, though it's a bit opaque: error: Failed to start domain 'f32' error: internal error: qemu unexpectedly closed the monitor: 2021-03-26T16:26:12.459293Z qemu-system-x86_64: -device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=/foovirtiofs,bus=pci.10,addr=0x0: Failed to write msg. Wrote -1 instead of 12. 2021-03-26T16:26:12.459317Z qemu-system-x86_64: -device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=/foovirtiofs,bus=pci.10,addr=0x0: vhost_dev_init failed: Operation not permitted Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- The SetUID/SetGID bits don't seem to be necessary for qemu:///system usage AFAICT, but it's a bit tough to decode virSetUIDGIDWithCaps. virtiofsd is meticulous about managing its capability set though src/qemu/qemu_validate.c | 7 +------ src/qemu/qemu_virtiofs.c | 4 ---- 2 files changed, 1 insertion(+), 10 deletions(-) diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c index 6043f974ce..d4079f6b67 100644 --- a/src/qemu/qemu_validate.c +++ b/src/qemu/qemu_validate.c @@ -4053,7 +4053,7 @@ qemuValidateDomainDeviceDefGraphics(const virDomainGraphicsDef *graphics, static int qemuValidateDomainDeviceDefFS(virDomainFSDefPtr fs, const virDomainDef *def, - virQEMUDriverPtr driver, + virQEMUDriverPtr driver G_GNUC_UNUSED, virQEMUCapsPtr qemuCaps) { if (fs->type != VIR_DOMAIN_FS_TYPE_MOUNT) { @@ -4107,11 +4107,6 @@ qemuValidateDomainDeviceDefFS(virDomainFSDefPtr fs, _("virtiofs does not yet support read-only mode")); return -1; } - if (!driver->privileged) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("virtiofs is not yet supported in session mode")); - return -1; - } if (fs->accessmode != VIR_DOMAIN_FS_ACCESSMODE_PASSTHROUGH) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("virtiofs only supports passthrough accessmode")); diff --git a/src/qemu/qemu_virtiofs.c b/src/qemu/qemu_virtiofs.c index 2e239cad66..0bb4e3c0d1 100644 --- a/src/qemu/qemu_virtiofs.c +++ b/src/qemu/qemu_virtiofs.c @@ -214,10 +214,6 @@ qemuVirtioFSStart(virLogManagerPtr logManager, if (!(cmd = qemuVirtioFSBuildCommandLine(cfg, fs, &fd))) goto cleanup; - /* so far only running as root is supported */ - virCommandSetUID(cmd, 0); - virCommandSetGID(cmd, 0); - virCommandSetPidFile(cmd, pidfile); virCommandSetOutputFD(cmd, &logfd); virCommandSetErrorFD(cmd, &logfd); -- 2.30.2

3 3

[libvirt PATCH] conf: remove duplicated firmware type attribute
by Daniel P. Berrangé 29 Mar '21

29 Mar '21

The <os firmware='efi'> <firmware type='efi'> <feature enabled='no' name='enrolled-keys'/> </firmware> </os> repeats the firmware attribute twice. This has no functional benefit, as evidenced by fact that we use a single struct field to store both attributes, while needlessly introducing an error scenario. The XML can just be simplified to: <os firmware='efi'> <firmware> <feature enabled='no' name='enrolled-keys'/> </firmware> </os> which also means that we don't need to emit the empty element <firmware type='efi'/> for all existing configs too. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/formatdomain.rst | 8 ---- docs/schemas/domaincommon.rng | 10 +--- src/conf/domain_conf.c | 48 ++++++------------- .../os-firmware-efi-no-enrolled-keys.xml | 2 +- .../os-firmware-invalid-type.xml | 28 ----------- tests/qemuxml2argvtest.c | 1 - ...aarch64-os-firmware-efi.aarch64-latest.xml | 1 - .../os-firmware-bios.x86_64-latest.xml | 1 - .../os-firmware-efi-secboot.x86_64-latest.xml | 1 - .../os-firmware-efi.x86_64-latest.xml | 1 - tests/vmx2xmldata/vmx2xml-firmware-efi.xml | 1 - 11 files changed, 18 insertions(+), 84 deletions(-) delete mode 100644 tests/qemuxml2argvdata/os-firmware-invalid-type.xml diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 9392c80113..741130bf21 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -158,14 +158,6 @@ harddisk, cdrom, network) determining where to obtain/find the boot image. ``firmware`` :since:`Since 7.2.0 QEMU/KVM only` - When used together with ``firmware`` attribute of ``os`` element the ``type`` - attribute must have the same value. - - List of mandatory attributes: - - - ``type`` (accepted values are ``bios`` and ``efi``) same as the ``firmware`` - attribute of ``os`` element. - When using firmware auto-selection there are different features enabled in the firmwares. The list of features can be used to limit what firmware should be automatically selected for the VM. The list of features can be specified diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 1dbfc68f18..f5ced5b7a2 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -278,13 +278,7 @@ <ref name="ostypehvm"/> <optional> <element name="firmware"> - <attribute name="type"> - <choice> - <value>bios</value> - <value>efi</value> - </choice> - </attribute> - <zeroOrMore> + <oneOrMore> <element name="feature"> <attribute name="enabled"> <ref name="virYesNo"/> @@ -296,7 +290,7 @@ </choice> </attribute> </element> - </zeroOrMore> + </oneOrMore> </element> </optional> <optional> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index b0eba9f7bd..d050a519c6 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -19590,31 +19590,21 @@ virDomainDefParseBootFirmwareOptions(virDomainDefPtr def, xmlXPathContextPtr ctxt) { g_autofree char *firmware = virXPathString("string(./os/@firmware)", ctxt); - g_autofree char *type = virXPathString("string(./os/firmware/@type)", ctxt); g_autofree xmlNodePtr *nodes = NULL; g_autofree int *features = NULL; int fw = 0; int n = 0; size_t i; - if (!firmware && !type) + if (!firmware) return 0; - if (firmware && type && STRNEQ(firmware, type)) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("firmware attribute and firmware type has to be the same")); - return -1; - } - - if (!type) - type = g_steal_pointer(&firmware); - - fw = virDomainOsDefFirmwareTypeFromString(type); + fw = virDomainOsDefFirmwareTypeFromString(firmware); if (fw <= 0) { virReportError(VIR_ERR_XML_ERROR, _("unknown firmware value %s"), - type); + firmware); return -1; } @@ -29491,30 +29481,22 @@ virDomainDefFormatInternalSetRootName(virDomainDefPtr def, virBufferAsprintf(buf, ">%s</type>\n", virDomainOSTypeToString(def->os.type)); - if (def->os.firmware) { - virBufferAsprintf(buf, "<firmware type='%s'", - virDomainOsDefFirmwareTypeToString(def->os.firmware)); - - if (def->os.firmwareFeatures) { - virBufferAddLit(buf, ">\n"); - - virBufferAdjustIndent(buf, 2); + if (def->os.firmwareFeatures) { + virBufferAddLit(buf, "<firmware>\n"); + virBufferAdjustIndent(buf, 2); - for (i = 0; i < VIR_DOMAIN_OS_DEF_FIRMWARE_FEATURE_LAST; i++) { - if (def->os.firmwareFeatures[i] == VIR_TRISTATE_BOOL_ABSENT) - continue; + for (i = 0; i < VIR_DOMAIN_OS_DEF_FIRMWARE_FEATURE_LAST; i++) { + if (def->os.firmwareFeatures[i] == VIR_TRISTATE_BOOL_ABSENT) + continue; - virBufferAsprintf(buf, "<feature enabled='%s' name='%s'/>\n", - virTristateBoolTypeToString(def->os.firmwareFeatures[i]), - virDomainOsDefFirmwareFeatureTypeToString(i)); - } + virBufferAsprintf(buf, "<feature enabled='%s' name='%s'/>\n", + virTristateBoolTypeToString(def->os.firmwareFeatures[i]), + virDomainOsDefFirmwareFeatureTypeToString(i)); + } - virBufferAdjustIndent(buf, -2); + virBufferAdjustIndent(buf, -2); - virBufferAddLit(buf, "</firmware>\n"); - } else { - virBufferAddLit(buf, "/>\n"); - } + virBufferAddLit(buf, "</firmware>\n"); } virBufferEscapeString(buf, "<init>%s</init>\n", diff --git a/tests/qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml b/tests/qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml index 8944ce70bb..352908f745 100644 --- a/tests/qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml +++ b/tests/qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml @@ -6,7 +6,7 @@ <vcpu placement='static'>1</vcpu> <os firmware='efi'> <type arch='x86_64' machine='pc-q35-4.0'>hvm</type> - <firmware type='efi'> + <firmware> <feature enabled='no' name='enrolled-keys'/> </firmware> <boot dev='hd'/> diff --git a/tests/qemuxml2argvdata/os-firmware-invalid-type.xml b/tests/qemuxml2argvdata/os-firmware-invalid-type.xml deleted file mode 100644 index 41360df0f7..0000000000 --- a/tests/qemuxml2argvdata/os-firmware-invalid-type.xml +++ /dev/null @@ -1,28 +0,0 @@ -<domain type='kvm'> - <name>fedora</name> - <uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid> - <memory unit='KiB'>8192</memory> - <currentMemory unit='KiB'>8192</currentMemory> - <vcpu placement='static'>1</vcpu> - <os firmware='efi'> - <type arch='x86_64' machine='pc-q35-4.0'>hvm</type> - <firmware type='bios'/> - <loader secure='no'/> - <nvram>/var/lib/libvirt/qemu/nvram/fedora_VARS.fd</nvram> - <boot dev='hd'/> - <bootmenu enable='yes'/> - </os> - <features> - <acpi/> - <apic/> - <pae/> - </features> - <clock offset='utc'/> - <on_poweroff>destroy</on_poweroff> - <on_reboot>restart</on_reboot> - <on_crash>restart</on_crash> - <devices> - <emulator>/usr/bin/qemu-system-x86_64</emulator> - <memballoon model='none'/> - </devices> -</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 12c2b68fd7..3439f34ef1 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -3582,7 +3582,6 @@ mymain(void) DO_TEST_CAPS_LATEST("os-firmware-efi"); DO_TEST_CAPS_LATEST("os-firmware-efi-secboot"); DO_TEST_CAPS_LATEST("os-firmware-efi-no-enrolled-keys"); - DO_TEST_CAPS_LATEST_PARSE_ERROR("os-firmware-invalid-type"); DO_TEST_CAPS_ARCH_LATEST("aarch64-os-firmware-efi", "aarch64"); DO_TEST_CAPS_LATEST("vhost-user-vga"); diff --git a/tests/qemuxml2xmloutdata/aarch64-os-firmware-efi.aarch64-latest.xml b/tests/qemuxml2xmloutdata/aarch64-os-firmware-efi.aarch64-latest.xml index cb4f3ccfce..627e285ae1 100644 --- a/tests/qemuxml2xmloutdata/aarch64-os-firmware-efi.aarch64-latest.xml +++ b/tests/qemuxml2xmloutdata/aarch64-os-firmware-efi.aarch64-latest.xml @@ -6,7 +6,6 @@ <vcpu placement='static'>1</vcpu> <os firmware='efi'> <type arch='aarch64' machine='virt-4.0'>hvm</type> - <firmware type='efi'/> <kernel>/aarch64.kernel</kernel> <initrd>/aarch64.initrd</initrd> <cmdline>earlyprintk console=ttyAMA0,115200n8 rw root=/dev/vda rootwait</cmdline> diff --git a/tests/qemuxml2xmloutdata/os-firmware-bios.x86_64-latest.xml b/tests/qemuxml2xmloutdata/os-firmware-bios.x86_64-latest.xml index 016c5b863f..df6f61421a 100644 --- a/tests/qemuxml2xmloutdata/os-firmware-bios.x86_64-latest.xml +++ b/tests/qemuxml2xmloutdata/os-firmware-bios.x86_64-latest.xml @@ -6,7 +6,6 @@ <vcpu placement='static'>1</vcpu> <os firmware='bios'> <type arch='x86_64' machine='pc-q35-4.0'>hvm</type> - <firmware type='bios'/> <loader secure='no'/> <nvram>/var/lib/libvirt/qemu/nvram/fedora_VARS.fd</nvram> <boot dev='hd'/> diff --git a/tests/qemuxml2xmloutdata/os-firmware-efi-secboot.x86_64-latest.xml b/tests/qemuxml2xmloutdata/os-firmware-efi-secboot.x86_64-latest.xml index fa5eaa3148..c383546cc6 100644 --- a/tests/qemuxml2xmloutdata/os-firmware-efi-secboot.x86_64-latest.xml +++ b/tests/qemuxml2xmloutdata/os-firmware-efi-secboot.x86_64-latest.xml @@ -6,7 +6,6 @@ <vcpu placement='static'>1</vcpu> <os firmware='efi'> <type arch='x86_64' machine='pc-q35-4.0'>hvm</type> - <firmware type='efi'/> <loader secure='yes'/> <nvram>/var/lib/libvirt/qemu/nvram/fedora_VARS.fd</nvram> <boot dev='hd'/> diff --git a/tests/qemuxml2xmloutdata/os-firmware-efi.x86_64-latest.xml b/tests/qemuxml2xmloutdata/os-firmware-efi.x86_64-latest.xml index 382146c23b..04d57860e7 100644 --- a/tests/qemuxml2xmloutdata/os-firmware-efi.x86_64-latest.xml +++ b/tests/qemuxml2xmloutdata/os-firmware-efi.x86_64-latest.xml @@ -6,7 +6,6 @@ <vcpu placement='static'>1</vcpu> <os firmware='efi'> <type arch='x86_64' machine='pc-q35-4.0'>hvm</type> - <firmware type='efi'/> <loader secure='no'/> <nvram>/var/lib/libvirt/qemu/nvram/fedora_VARS.fd</nvram> <boot dev='hd'/> diff --git a/tests/vmx2xmldata/vmx2xml-firmware-efi.xml b/tests/vmx2xmldata/vmx2xml-firmware-efi.xml index fa10daf3a6..fee707fe71 100644 --- a/tests/vmx2xmldata/vmx2xml-firmware-efi.xml +++ b/tests/vmx2xmldata/vmx2xml-firmware-efi.xml @@ -6,7 +6,6 @@ <vcpu placement='static'>1</vcpu> <os firmware='efi'> <type arch='i686'>hvm</type> - <firmware type='efi'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> -- 2.30.2

2 2

[libvirt PATCH 0/9] improve firmware auto-selection
by Pavel Hrdina 29 Mar '21

29 Mar '21

Cleanup the parser code and implement firmware feature filtering support to allow users to modify firmware auto-selection behavior per VM. More details in PATCH 08. Pavel Hrdina (9): docs: improve description of secure attribute for loader element conf: introduce virDomainDefParseBootInitOptions conf: introduce virDomainDefParseBootKernelOptions conf: introduce virDomainDefParseBootFirmwareOptions conf: introduce virDomainDefParseBootLoaderOptions conf: introduce virDomainDefParseBootAcpiOptions conf: use switch in virDomainDefParseBootOptions conf: introduce support for firmware auto-selection feature filtering qemu: implement support for firmware auto-selection feature filtering docs/formatdomain.rst | 35 +- docs/schemas/domaincommon.rng | 23 + src/conf/domain_conf.c | 396 ++++++++++++------ src/conf/domain_conf.h | 10 + src/qemu/qemu_firmware.c | 40 ++ .../os-firmware-efi-invalid-type.xml | 28 ++ ...re-efi-no-enrolled-keys.x86_64-latest.args | 49 +++ .../os-firmware-efi-no-enrolled-keys.xml | 25 ++ ...os-firmware-invalid-type.x86_64-latest.err | 1 + .../os-firmware-invalid-type.xml | 28 ++ tests/qemuxml2argvtest.c | 2 + ...aarch64-os-firmware-efi.aarch64-latest.xml | 1 + .../os-firmware-bios.x86_64-latest.xml | 1 + ...are-efi-no-enrolled-keys.x86_64-latest.xml | 50 +++ .../os-firmware-efi-secboot.x86_64-latest.xml | 1 + .../os-firmware-efi.x86_64-latest.xml | 1 + tests/qemuxml2xmltest.c | 1 + tests/vmx2xmldata/vmx2xml-firmware-efi.xml | 1 + 18 files changed, 567 insertions(+), 126 deletions(-) create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-invalid-type.xml create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/os-firmware-efi-no-enrolled-keys.xml create mode 100644 tests/qemuxml2argvdata/os-firmware-invalid-type.x86_64-latest.err create mode 100644 tests/qemuxml2argvdata/os-firmware-invalid-type.xml create mode 100644 tests/qemuxml2xmloutdata/os-firmware-efi-no-enrolled-keys.x86_64-latest.xml -- 2.30.2

4 21