- Devel - libvirt List Archives

[PATCH v4 0/4] introduce support for acpi-bridge-hotplug feature
by Ani Sinha 30 Sep '21

30 Sep '21

changelog: v4: split the original series into two - pci-root controller specific one (https://www.mail-archive.com/libvir-list@redhat.com/msg221645.html) and this one specific to pci bridges. The conf xml has been introduced as per suggestion by Berrange here: https://patchew.org/Libvirt/20210912032631.2853520-1-ani@anisinha.ca Changes has been introduced to parse and validate the xml accordingly as well as to add backend qemu commandline option. v3: reorganized the patches as per Laine's suggestion. Added more details in commit messages. Added conf description in formatdomain.rst. Added changelog for next release. v2: fixed bugs and added additional missing unit tests. v1: initial implementation. Had some bugs and missed some unit tests This change introduces a new libvirt sub-element <pci> under <features> that can be used to configure all pci related features. Currently the only sub-sub element supported by this sub-element is 'acpi-bridge-hotplug' as shown below: <features> <pci> <acpi-bridge-hotplug state='on|off'/> </pci> </features> The above option is only available for qemu driver and that too for x86 guests only. It is a global option. 'acpi-bridge-hotplug' option enables or disables ACPI hotplug support for cold-plugged pci bridges. Examples of bridges include PCI-PCI bridge (pci-bridge controller) or PCIe-PCI bridges for pc machines and pcie-root-port controller for q35 machines. Being global option, no other bridge specific option are required. For pc machine type in x86, this option is available in qemu for a long time, from version 2.1. Please see the following changes in qemu repo: 9e047b982452c6 ("piix4: add acpi pci hotplug support") 133a2da488062e ("pc: acpi: generate AML only for PCI0 devices if PCI bridge hotplug is disabled") For q35 machine type, this was introduced in qemu 6.1 with the following changes in qemu repo: (a) c0e427d6eb5fef ("hw/acpi/ich9: Enable ACPI PCI hot-plug") (b) 17858a16950860 ("hw/acpi/ich9: Set ACPI PCI hot-plug as default on Q35") The reasons for enabling ACPI based hotplug for PCIe (q35) based machines (as opposed to native hotplug) are outlined in (b). There are use cases where users would still want to use native hotplug. Therefore, this config option enables users to choose either ACPI based hotplug or native hotplug for bridges (for example for pcie root port controller in q35 machines). Ani Sinha (4): qemu: capablities: detect presence of acpi-pci-hotplug-with-bridge-support conf: introduce support for acpi-bridge-hotplug feature qemu: command: add support for acpi-bridge-hotplug feature NEWS: add new acpi pci hotplug config option in the release note for next release NEWS.rst | 7 ++ docs/formatdomain.rst | 11 +++ docs/schemas/domaincommon.rng | 15 ++++ src/conf/domain_conf.c | 89 ++++++++++++++++++- src/conf/domain_conf.h | 9 ++ src/qemu/qemu_capabilities.c | 6 ++ src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_command.c | 14 +++ src/qemu/qemu_validate.c | 46 ++++++++++ .../caps_2.11.0.x86_64.xml | 1 + .../caps_2.12.0.x86_64.xml | 1 + .../caps_3.0.0.x86_64.xml | 1 + .../caps_3.1.0.x86_64.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 2 + .../aarch64-acpi-hotplug-bridge-disable.err | 1 + .../aarch64-acpi-hotplug-bridge-disable.xml | 33 +++++++ ...pc-i440fx-acpi-hotplug-bridge-disable.args | 31 +++++++ .../pc-i440fx-acpi-hotplug-bridge-disable.err | 1 + .../pc-i440fx-acpi-hotplug-bridge-disable.xml | 33 +++++++ .../pc-i440fx-acpi-hotplug-bridge-enable.xml | 33 +++++++ .../q35-acpi-hotplug-bridge-disable.args | 33 +++++++ .../q35-acpi-hotplug-bridge-disable.err | 1 + .../q35-acpi-hotplug-bridge-disable.xml | 47 ++++++++++ .../q35-acpi-hotplug-bridge-enable.xml | 47 ++++++++++ tests/qemuxml2argvtest.c | 16 ++++ .../pc-i440fx-acpi-hotplug-bridge-disable.xml | 1 + .../pc-i440fx-acpi-hotplug-bridge-enable.xml | 1 + .../q35-acpi-hotplug-bridge-disable.xml | 1 + .../q35-acpi-hotplug-bridge-enable.xml | 1 + tests/qemuxml2xmltest.c | 14 +++ 37 files changed, 507 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/aarch64-acpi-hotplug-bridge-disable.err create mode 100644 tests/qemuxml2argvdata/aarch64-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.args create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.err create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-hotplug-bridge-enable.xml create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.args create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.err create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-disable.xml create mode 100644 tests/qemuxml2argvdata/q35-acpi-hotplug-bridge-enable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-hotplug-bridge-disable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-hotplug-bridge-enable.xml create mode 120000 tests/qemuxml2xmloutdata/q35-acpi-hotplug-bridge-disable.xml create mode 120000 tests/qemuxml2xmloutdata/q35-acpi-hotplug-bridge-enable.xml -- 2.25.1

1 4

Entering freeze for libvirt-7.8.0
by Jiri Denemark 29 Sep '21

29 Sep '21

I have just tagged v7.8.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

[libvirt PATCH] scripts: include function versions in API definition
by Daniel P. Berrangé 28 Sep '21

28 Sep '21

In order to auto-generate more of the language binding code, it is desirable to know what libvirt version an API was introduced in. We can extract this information from the .syms files and expose it in the API description eg instead of <function name='virNodeNumOfDevices' file='libvirt-nodedev' module='libvirt-nodedev'> we now have <function name='virNodeNumOfDevices' file='libvirt-nodedev' module='libvirt-nodedev' version='0.5.0'> This will benefit this proposal: https://gitlab.com/libvirt/libvirt-go-module/-/merge_requests/7 Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- scripts/apibuild.py | 68 +++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 62 insertions(+), 6 deletions(-) diff --git a/scripts/apibuild.py b/scripts/apibuild.py index 9b29466e1d..bdd3077c48 100755 --- a/scripts/apibuild.py +++ b/scripts/apibuild.py @@ -2030,8 +2030,9 @@ class CParser: class docBuilder: """A documentation builder""" - def __init__(self, name, path='.', directories=['.'], includes=[]): + def __init__(self, name, syms, path='.', directories=['.'], includes=[]): self.name = name + self.syms = syms self.path = path self.directories = directories if name == "libvirt": @@ -2044,6 +2045,7 @@ class docBuilder: self.includes = includes + list(admin_included_files.keys()) self.modules = {} self.headers = {} + self.versions = {} self.idx = index() self.xref = {} self.index = {} @@ -2114,6 +2116,44 @@ class docBuilder: self.modules[module] = idx self.idx.merge_public(idx) + def scanVersions(self): + prefix = self.name.upper().replace("-", "_") + "_" + + version = None + prevversion = None + with open(self.syms, "r") as syms: + while True: + line = syms.readline() + if not line: + break + line = line.strip() + if line.startswith("#"): + continue + if line == "": + continue + + if line.startswith(prefix) and line.endswith(" {"): + version = line[len(prefix):-2] + elif line == "global:": + continue + elif line == "local:": + continue + elif line.startswith("}"): + if prevversion is None: + if line != "};": + raise Exception("Unexpected closing version") + else: + if line != ("} %s%s;" % (prefix, prevversion)): + raise Exception("Unexpected end of version '%s': %s'" % (line, "} " + prefix + version)) + + prevversion = version + version = None + elif line.endswith(";") and version is not None: + func = line[:-1] + self.versions[func] = version + else: + raise Exception("Unexpected line in syms file: %s" % line) + def scan(self): for directory in self.directories: files = glob.glob(directory + "/*.c") @@ -2136,6 +2176,7 @@ class docBuilder: self.headers[file] = None self.scanHeaders() self.scanModules() + self.scanVersions() def modulename_file(self, file): module = os.path.basename(file) @@ -2275,9 +2316,17 @@ class docBuilder: print("=>", id) # NB: this is consumed by a regex in 'getAPIFilenames' in hvsupport.pl - output.write(" <%s name='%s' file='%s' module='%s'>\n" % (id.type, - name, self.modulename_file(id.header), - self.modulename_file(id.module))) + if id.type == "function": + ver = self.versions[name] + if ver is None: + raise Exception("Missing version for '%s'" % name) + output.write(" <function name='%s' file='%s' module='%s' version='%s'>\n" % ( + name, self.modulename_file(id.header), + self.modulename_file(id.module), self.versions[name])) + else: + output.write(" <functype name='%s' file='%s' module='%s'>\n" % ( + name, self.modulename_file(id.header), + self.modulename_file(id.module))) # # Processing of conditionals modified by Bill 1/1/05 # @@ -2406,9 +2455,16 @@ class app: print(msg) def rebuild(self, name, srcdir, builddir): - if name not in ["libvirt", "libvirt-qemu", "libvirt-lxc", "libvirt-admin"]: + syms = { + "libvirt": srcdir + "/../src/libvirt_public.syms", + "libvirt-qemu": srcdir + "/../src/libvirt_qemu.syms", + "libvirt-lxc": srcdir + "/../src/libvirt_lxc.syms", + "libvirt-admin": srcdir + "/../src/admin/libvirt_admin_public.syms", + } + if name not in syms: self.warning("rebuild() failed, unknown module %s" % name) return None + builder = None if glob.glob(srcdir + "/../src/libvirt.c") != []: if not quiet: @@ -2418,7 +2474,7 @@ class app: srcdir + "/../src/util", srcdir + "/../include/libvirt", builddir + "/../include/libvirt"] - builder = docBuilder(name, builddir, dirs, []) + builder = docBuilder(name, syms[name], builddir, dirs, []) else: self.warning("rebuild() failed, unable to guess the module") return None -- 2.31.1

3 4

[PATCH v6 0/4] Add support to enable/disable hotplug on pci-root controller
by Ani Sinha 28 Sep '21

28 Sep '21

changelog: v6: incorporated Jan's suggestions. v5: incorporated suggestions from Laine for patches #2 and #3. The qemu command line is now added in a new function and called from qemuBuildControllersByTypeCommandLine(). Output xmls are now symlinked to input xmls for unit tests. v4: split the original patchset into a pci-root controller specific patch series. also the libvirt conf is now a sub-element of the pci-root controller as was suggested by Dan Berrange. Please see discussion here: https://listman.redhat.com/archives/libvir-list/2021-September/msg00839.html v3: reorganized the patches as per Laine's suggestion. Added more details in commit messages. Added conf description in formatdomain.rst. Added changelog for next release. v2: fixed bugs and added additional missing unit tests. v1: initial implementation. Had some bugs and missed some unit tests This patchset introduces libvirt xml support to enable/disable hotplug on the pci-root controller. It adds a 'target' subelement for the pci-root controller with a 'hotplug' property. This property can be used to enable or disable hotplug for the pci-root controller. For example, in order to disable hotplug on the pci-root controller, one has to use set '<target hotplug='off'>' as shown below: <controller type='pci' model='pci-root'> <target hotplug='off'/> </controller> '<target hotplug='on'>' option would enable hotplug for pci-root controller. This is also the default value. This option is only available for pc machine types and is applicable for qemu only/kvm accelerator onlt.This feature was introduced from qemu version 5.2 with the following change in qemu repository: 3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus") The above qemu commit describes some reasons why users might to disable hotplug on PCI root buses [1]. The corresponding commandline option to qemu for x86 guests is: -global PIIX4_PM.acpi-root-pci-hotplug=<off/on> Notes: 1. The use case scenario described by Laine in https://listman.redhat.com/archives/libvir-list/2020-February/msg00110.html intentionally does not discuss i440fx and focusses solely on q35. I do realize that redhat has moved on from i440fx and currently efforts for new features are concentrated on q35 machines only. We have had some hard debates on this on the qemu mailing list before. The fact of the matter is that i440fx is not at 1-1 parity with q35. There are many users who are currenly using i440fx and are simply not ready to move to q35 without sacrificing some existing features they support today. For example https://wiki.qemu.org/images/4/4e/Q35.pdf lists some of q35 limitations. https://www.linux-kvm.org/images/0/06/2012-forum-Q35.pdf provides more information on the differences. Hence we need to solve the issue Laine has described in the above email for i440fx without adding additional bridges. Further, in Daniel Berrange's words from : https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03012.html "From the upstream POV, there's been no decision / agreement to phase out PIIX, this is purely a RHEL downstream decision & plan. If other distros / users have a different POV, and find the feature useful, we should accept the patch if it meets the normal QEMU patch requirements. " Also to be noted that I have already experimented this qemu commandline option using libvirt passthrough feature as has been documented in http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html This was only meant to be a short term solution until libvirt started supporting this natively. Supporting this option through libvirt would simplify their use case as well as add capability validations and graceful failure scenarios in case qemu did not support the option. Ani Sinha (4): qemu: capablities: detect presence of acpi-root-pci-hotplug for i440fx machines conf: introduce option to enable/disable pci hotplug on pci-root controller qemu: command: add support to enable/disable hotplug on pci-root controller NEWS: release note the new hotplug enable/disable option on pci-root controller NEWS.rst | 6 ++++ docs/formatdomain.rst | 12 ++++--- src/qemu/qemu_capabilities.c | 4 +++ src/qemu/qemu_capabilities.h | 3 ++ src/qemu/qemu_command.c | 17 ++++++++++ src/qemu/qemu_validate.c | 9 +++++- .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + .../pc-i440fx-acpi-root-hotplug-disable.args | 31 +++++++++++++++++++ .../pc-i440fx-acpi-root-hotplug-disable.err | 1 + .../pc-i440fx-acpi-root-hotplug-disable.xml | 30 ++++++++++++++++++ .../pc-i440fx-acpi-root-hotplug-enable.xml | 30 ++++++++++++++++++ tests/qemuxml2argvtest.c | 3 ++ .../pc-i440fx-acpi-root-hotplug-disable.xml | 1 + .../pc-i440fx-acpi-root-hotplug-enable.xml | 1 + tests/qemuxml2xmltest.c | 4 +++ 17 files changed, 149 insertions(+), 6 deletions(-) create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.args create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.err create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-enable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-disable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-enable.xml -- 2.25.1

2 5

[libvirt PATCH] vshCmddefCheckInternals: Fix typo
by Tim Wiederhake 27 Sep '21

27 Sep '21

Signed-off-by: Tim Wiederhake <twiederh(a)redhat.com> --- tools/vsh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/vsh.c b/tools/vsh.c index 189c452f73..7b77acad34 100644 --- a/tools/vsh.c +++ b/tools/vsh.c @@ -279,7 +279,7 @@ vshCmddefCheckInternals(vshControl *ctl, } if (!(alias = vshCmddefSearch(cmd->alias))) { - vshError(ctl, _("command alias '%s' is pointing to a non-existant command '%s'"), + vshError(ctl, _("command alias '%s' is pointing to a non-existent command '%s'"), cmd->name, cmd->alias); return -1; } -- 2.31.1

2 1

[PATCH v5 0/4] Add support to enable/disable hotplug on pci-root controller
by Ani Sinha 27 Sep '21

27 Sep '21

changelog: v5: incorporated suggestions from Laine for patches #2 and #3. The qemu command line is now added in a new function and called from qemuBuildControllersByTypeCommandLine(). Output xmls are now symlinked to input xmls for unit tests. v4: split the original patchset into a pci-root controller specific patch series. also the libvirt conf is now a sub-element of the pci-root controller as was suggested by Dan Berrange. Please see discussion here: https://listman.redhat.com/archives/libvir-list/2021-September/msg00839.html v3: reorganized the patches as per Laine's suggestion. Added more details in commit messages. Added conf description in formatdomain.rst. Added changelog for next release. v2: fixed bugs and added additional missing unit tests. v1: initial implementation. Had some bugs and missed some unit tests This patchset introduces libvirt xml support to enable/disable hotplug on the pci-root controller. It adds a 'target' subelement for the pci-root controller with a 'hotplug' property. This property can be used to enable or disable hotplug for the pci-root controller. For example, in order to disable hotplug on the pci-root controller, one has to use set '<target hotplug='off'>' as shown below: <controller type='pci' model='pci-root'> <target hotplug='off'/> </controller> '<target hotplug='on'>' option would enable hotplug for pci-root controller. This is also the default value. This option is only available for pc machine types and is applicable for qemu only/kvm accelerator onlt.This feature was introduced from qemu version 5.2 with the following change in qemu repository: 3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus") The above qemu commit describes some reasons why users might to disable hotplug on PCI root buses [1]. The corresponding commandline option to qemu for x86 guests is: -global PIIX4_PM.acpi-root-pci-hotplug=<off/on> Notes: 1. The use case scenario described by Laine in https://listman.redhat.com/archives/libvir-list/2020-February/msg00110.html intentionally does not discuss i440fx and focusses solely on q35. I do realize that redhat has moved on from i440fx and currently efforts for new features are concentrated on q35 machines only. We have had some hard debates on this on the qemu mailing list before. The fact of the matter is that i440fx is not at 1-1 parity with q35. There are many users who are currenly using i440fx and are simply not ready to move to q35 without sacrificing some existing features they support today. For example https://wiki.qemu.org/images/4/4e/Q35.pdf lists some of q35 limitations. https://www.linux-kvm.org/images/0/06/2012-forum-Q35.pdf provides more information on the differences. Hence we need to solve the issue Laine has described in the above email for i440fx without adding additional bridges. Further, in Daniel Berrange's words from : https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03012.html "From the upstream POV, there's been no decision / agreement to phase out PIIX, this is purely a RHEL downstream decision & plan. If other distros / users have a different POV, and find the feature useful, we should accept the patch if it meets the normal QEMU patch requirements. " Also to be noted that I have already experimented this qemu commandline option using libvirt passthrough feature as has been documented in http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html This was only meant to be a short term solution until libvirt started supporting this natively. Supporting this option through libvirt would simplify their use case as well as add capability validations and graceful failure scenarios in case qemu did not support the option. Ani Sinha (4): qemu: capablities: detect presence of acpi-root-pci-hotplug for i440fx machines conf: introduce option to enable/disable pci hotplug on pci-root controller qemu: command: add support to enable/disable hotplug on pci-root controller NEWS: release note the new hotplug enable/disable option on pci-root controller NEWS.rst | 6 ++++ docs/formatdomain.rst | 12 ++++--- src/qemu/qemu_capabilities.c | 4 +++ src/qemu/qemu_capabilities.h | 3 ++ src/qemu/qemu_command.c | 17 ++++++++++ src/qemu/qemu_validate.c | 9 +++++- .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + .../pc-i440fx-acpi-root-hotplug-disable.args | 31 +++++++++++++++++++ .../pc-i440fx-acpi-root-hotplug-disable.err | 1 + .../pc-i440fx-acpi-root-hotplug-disable.xml | 30 ++++++++++++++++++ .../pc-i440fx-acpi-root-hotplug-enable.xml | 30 ++++++++++++++++++ tests/qemuxml2argvtest.c | 3 ++ .../pc-i440fx-acpi-root-hotplug-disable.xml | 1 + .../pc-i440fx-acpi-root-hotplug-enable.xml | 1 + tests/qemuxml2xmltest.c | 4 +++ 17 files changed, 149 insertions(+), 6 deletions(-) create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.args create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.err create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-enable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-disable.xml create mode 120000 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-enable.xml -- 2.25.1

3 10

[PATCH v4 0/4] Add support to enable/disable hotplug on pci-root controller
by Ani Sinha 27 Sep '21

27 Sep '21

changelog: v4: split the original patchset into a pci-root controller specific patch series. also the libvirt conf is now a sub-element of the pci-root controller as was suggested by Dan Berrange. Please see discussion here: https://listman.redhat.com/archives/libvir-list/2021-September/msg00839.html v3: reorganized the patches as per Laine's suggestion. Added more details in commit messages. Added conf description in formatdomain.rst. Added changelog for next release. v2: fixed bugs and added additional missing unit tests. v1: initial implementation. Had some bugs and missed some unit tests This patchset introduces libvirt xml support to enable/disable hotplug on the pci-root controller. It adds a 'target' subelement for the pci-root controller with a 'hotplug' property. This property can be used to enable or disable hotplug for the pci-root controller. For example, in order to disable hotplug on the pci-root controller, one has to use set '<target hotplug='off'>' as shown below: <controller type='pci' model='pci-root'> <target hotplug='off'/> </controller> '<target hotplug='on'>' option would enable hotplug for pci-root controller. This is also the default value. This option is only available for pc machine types and is applicable for qemu only/kvm accelerator onlt.This feature was introduced from qemu version 5.2 with the following change in qemu repository: 3d7e78aa7777f ("Introduce a new flag for i440fx to disable PCI hotplug on the root bus") The above qemu commit describes some reasons why users might to disable hotplug on PCI root buses [1]. The corresponding commandline option to qemu for x86 guests is: -global PIIX4_PM.acpi-root-pci-hotplug=<off/on> Notes: 1. The use case scenario described by Laine in https://listman.redhat.com/archives/libvir-list/2020-February/msg00110.html intentionally does not discuss i440fx and focusses solely on q35. I do realize that redhat has moved on from i440fx and currently efforts for new features are concentrated on q35 machines only. We have had some hard debates on this on the qemu mailing list before. The fact of the matter is that i440fx is not at 1-1 parity with q35. There are many users who are currenly using i440fx and are simply not ready to move to q35 without sacrificing some existing features they support today. For example https://wiki.qemu.org/images/4/4e/Q35.pdf lists some of q35 limitations. https://www.linux-kvm.org/images/0/06/2012-forum-Q35.pdf provides more information on the differences. Hence we need to solve the issue Laine has described in the above email for i440fx without adding additional bridges. Further, in Daniel Berrange's words from : https://lists.gnu.org/archive/html/qemu-devel/2020-04/msg03012.html "From the upstream POV, there's been no decision / agreement to phase out PIIX, this is purely a RHEL downstream decision & plan. If other distros / users have a different POV, and find the feature useful, we should accept the patch if it meets the normal QEMU patch requirements. " Also to be noted that I have already experimented this qemu commandline option using libvirt passthrough feature as has been documented in http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html This was only meant to be a short term solution until libvirt started supporting this natively. Supporting this option through libvirt would simplify their use case as well as add capability validations and graceful failure scenarios in case qemu did not support the option. Ani Sinha (4): qemu: capablities: detect presence of acpi-root-pci-hotplug for i440fx machines conf: introduce option to enable/disable pci hotplug on pci-root controller qemu: command: add support to enable/disable hotplug on pci-root controller NEWS: release note the new hotplug enable/disable option on pci-root controller NEWS.rst | 6 ++++ docs/formatdomain.rst | 12 ++++--- docs/schemas/domaincommon.rng | 10 ++++++ src/qemu/qemu_capabilities.c | 4 +++ src/qemu/qemu_capabilities.h | 3 ++ src/qemu/qemu_command.c | 12 +++++++ src/qemu/qemu_validate.c | 9 +++++- .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + .../pc-i440fx-acpi-root-hotplug-disable.args | 31 +++++++++++++++++++ .../pc-i440fx-acpi-root-hotplug-disable.xml | 17 ++++++++++ .../pc-i440fx-acpi-root-hotplug-enable.err | 1 + .../pc-i440fx-acpi-root-hotplug-enable.xml | 17 ++++++++++ tests/qemuxml2argvtest.c | 6 ++++ .../pc-i440fx-acpi-root-hotplug-disable.xml | 30 ++++++++++++++++++ tests/qemuxml2xmltest.c | 2 ++ 17 files changed, 157 insertions(+), 6 deletions(-) create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.args create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-disable.xml create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-enable.err create mode 100644 tests/qemuxml2argvdata/pc-i440fx-acpi-root-hotplug-enable.xml create mode 100644 tests/qemuxml2xmloutdata/pc-i440fx-acpi-root-hotplug-disable.xml -- 2.25.1

2 9

[PATCH] qemu: ingore the transient domain state in fake reboot
by Zhenzhong Duan 27 Sep '21

27 Sep '21

When action for 'on_poweroff' is set to 'restart', 'fake reboot' is triggered and qemu shutdown state is transient. Domain state need not to be changed and events not sent in this case. Fixes:4ffc807214cb80086d57e1d3e7b60959a41d2874 Signed-off-by: Zhenzhong Duan <zhenzhong.duan(a)intel.com> --- src/qemu/qemu_process.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 632cb817b9..fcdda4ffe1 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -612,7 +612,7 @@ qemuProcessHandleShutdown(qemuMonitor *mon G_GNUC_UNUSED, /* In case of fake reboot qemu shutdown state is transient so don't * change domain state nor send events. */ - if (!priv->fakeReboot || + if (!priv->fakeReboot && vm->def->onPoweroff != VIR_DOMAIN_LIFECYCLE_ACTION_RESTART) { VIR_DEBUG("Transitioned guest %s to shutdown state", vm->def->name); -- 2.25.1

2 1

[libvirt PATCH 0/4] qemu: deprecate more capabilities
by Ján Tomko 25 Sep '21

25 Sep '21

Applies on top of my seccomp sandbox series. Ján Tomko (4): qemu: assume QEMU_CAPS_MACHINE_KERNEL_IRQCHIP qemu: Deprecate QEMU_CAPS_MACHINE_KERNEL_IRQCHIP qemu: assume QEMU_CAPS_FSDEV_CREATEMODE qemu: deprecate QEMU_CAPS_FSDEV_CREATEMODE src/qemu/qemu_capabilities.c | 6 ++---- src/qemu/qemu_capabilities.h | 4 ++-- src/qemu/qemu_validate.c | 12 ------------ tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 2 -- tests/qemucapabilitiesdata/caps_2.11.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 2 -- tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 2 -- tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 2 -- tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 2 -- tests/qemucapabilitiesdata/caps_3.0.0.riscv32.xml | 2 -- tests/qemucapabilitiesdata/caps_3.0.0.riscv64.xml | 2 -- tests/qemucapabilitiesdata/caps_3.0.0.s390x.xml | 2 -- tests/qemucapabilitiesdata/caps_3.0.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 2 -- tests/qemucapabilitiesdata/caps_3.1.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml | 2 -- tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 2 -- tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml | 2 -- tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml | 2 -- tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 2 -- tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml | 2 -- tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 2 -- tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml | 2 -- tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 2 -- tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 2 -- tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 2 -- tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml | 2 -- tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml | 2 -- tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 2 -- tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml | 2 -- tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml | 2 -- tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml | 2 -- tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml | 2 -- tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml | 2 -- tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml | 2 -- 42 files changed, 4 insertions(+), 96 deletions(-) -- 2.31.1

2 5

[libvirt PATCH 0/5] qemu: simplify seccomp sandbox
by Ján Tomko 25 Sep '21

25 Sep '21

Inspired by Peter's q-c-l-o cleanups. Ján Tomko (5): qemu: always assume QEMU_CAPS_SECCOMP_BLACKLIST qemu: conf: simplify seccomp_sandbox comment qemu: seccomp: remove dead code qemu: capabilities: deprecate QEMU_CAPS_SECCOMP_BLACKLIST qemu: capabilities: do not look at parameters for sandbox src/qemu/qemu.conf | 11 +++++------ src/qemu/qemu_capabilities.c | 5 ++--- src/qemu/qemu_capabilities.h | 2 +- src/qemu/qemu_command.c | 7 +------ tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 - tests/qemucapabilitiesdata/caps_2.11.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 - tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 1 - tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 1 - tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 1 - tests/qemucapabilitiesdata/caps_3.0.0.riscv32.xml | 1 - tests/qemucapabilitiesdata/caps_3.0.0.riscv64.xml | 1 - tests/qemucapabilitiesdata/caps_3.0.0.s390x.xml | 1 - tests/qemucapabilitiesdata/caps_3.0.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 1 - tests/qemucapabilitiesdata/caps_3.1.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml | 1 - tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 - tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml | 1 - tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml | 1 - tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 - tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_4.1.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml | 1 - tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 - tests/qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 - tests/qemucapabilitiesdata/caps_4.2.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 1 - tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 - tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 1 - tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 - tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml | 1 - tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 - tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml | 1 - tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 - tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml | 1 - tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 - tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml | 1 - tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml | 1 - 43 files changed, 9 insertions(+), 55 deletions(-) -- 2.31.1

2 6