- Devel - libvirt List Archives

[PATCH-for-9.0] hw/i386/pc: Deprecate 64-bit CPUs on ISA-only PC machine
by Philippe Mathieu-Daudé 27 Mar '24

27 Mar '24

Per Daniel suggestion [*]: > isapc could arguably be restricted to just 32-bit CPU models, > because we should not need it to support any feature that didn't > exist prior to circa 1995. eg refuse to start with isapc, if 'lm' > is present in the CPU model for example. [*] https://lore.kernel.org/qemu-devel/ZgQkS4RPmSt5Xa08@redhat.com/ Suggested-by: Daniel P. Berrangé <berrange(a)redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> --- docs/about/deprecated.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7b548519b5..345c35507f 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -208,6 +208,13 @@ is no longer packaged in any distro making it harder to run the ``check-tcg`` tests. Unless we can improve the testing situation there is a chance the code will bitrot without anyone noticing. +64-bit (x86_64) CPUs on the ``isapc`` machine (since 9.0) +''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +The ``isapc`` machine aims to emulate old PC machine without PCI was +generalized, so hardware available around 1995, before 64-bit intel +CPUs were produced. + System emulator machines ------------------------ -- 2.41.0

2 1

[libvirt PATCH 0/2] correctly update metadata when deleting external snapshot
by Pavel Hrdina 27 Mar '24

27 Mar '24

Pavel Hrdina (2): qemu_snapshot: call qemuSnapshotDeleteUpdateDisks only for external snapshots qemu_snapshot: correctly update metadata when deleting external snapshot with multiple branches src/qemu/qemu_snapshot.c | 52 ++++++++++++++++++++++++---------------- 1 file changed, 31 insertions(+), 21 deletions(-) -- 2.43.2

2 4

[PATCH-for-9.1 00/18] hw/i386: Remove deprecated pc-i440fx-2.0 -> 2.3 machines
by Philippe Mathieu-Daudé 27 Mar '24

27 Mar '24

Kill legacy code, because we need to evolve. I ended there via dynamic machine -> ICH9 -> legacy ACPI... Based-on: <20240301185936.95175-1-philmd(a)linaro.org> "hw/i386/pc: Trivial cleanups" Philippe Mathieu-Daudé (18): hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine hw/usb/hcd-xhci: Enumerate xhci_flags setting values hw/usb/hcd-xhci: Remove XHCI_FLAG_FORCE_PCIE_ENDCAP flag hw/usb/hcd-xhci: Remove XHCI_FLAG_SS_FIRST flag hw/i386/acpi: Remove PCMachineClass::legacy_acpi_table_size hw/i386/pc: Remove deprecated pc-i440fx-2.1 machine target/i386/kvm: Remove x86_cpu_change_kvm_default() and 'kvm-cpu.h' hw/i386/pc: Remove PCMachineClass::smbios_uuid_encoded hw/i386/pc: Remove PCMachineClass::enforce_aligned_dimm hw/mem/pc-dimm: Remove legacy_align argument from pc_dimm_pre_plug() hw/mem/memory-device: Remove legacy_align from memory_device_pre_plug() hw/i386/pc: Remove deprecated pc-i440fx-2.2 machine hw/i386/pc: Remove PCMachineClass::resizable_acpi_blob hw/i386/pc: Remove PCMachineClass::rsdp_in_ram hw/i386/acpi: Remove AcpiBuildState::rsdp field hw/i386/pc: Remove deprecated pc-i440fx-2.3 machine target/i386: Remove X86CPU::kvm_no_smi_migration field hw/i386/pc: Replace PCMachineClass::acpi_data_size by PC_ACPI_DATA_SIZE docs/about/deprecated.rst | 7 --- docs/about/removed-features.rst | 2 +- hw/usb/hcd-xhci.h | 4 +- include/hw/i386/pc.h | 22 ------- include/hw/mem/memory-device.h | 2 +- include/hw/mem/pc-dimm.h | 3 +- target/i386/cpu.h | 3 - target/i386/kvm/kvm-cpu.h | 41 ------------ hw/arm/virt.c | 2 +- hw/i386/acpi-build.c | 94 +++------------------------- hw/i386/fw_cfg.c | 2 +- hw/i386/pc.c | 107 +++++--------------------------- hw/i386/pc_piix.c | 101 ------------------------------ hw/loongarch/virt.c | 2 +- hw/mem/memory-device.c | 12 ++-- hw/mem/pc-dimm.c | 6 +- hw/ppc/spapr.c | 2 +- hw/usb/hcd-xhci-nec.c | 4 -- hw/usb/hcd-xhci-pci.c | 4 +- hw/usb/hcd-xhci.c | 42 +++---------- hw/virtio/virtio-md-pci.c | 2 +- target/i386/cpu.c | 2 - target/i386/kvm/kvm-cpu.c | 3 +- target/i386/kvm/kvm.c | 6 -- 24 files changed, 48 insertions(+), 427 deletions(-) delete mode 100644 target/i386/kvm/kvm-cpu.h -- 2.41.0

3 39

[RFC] virsysinfo: Try reading DMI table
by brett.holman＠canonical.com 26 Mar '24

26 Mar '24

This patch intends to add DMI support to libvirt for RISC-V and mips. This change is based on commit ec6ce6363, which added ARM support. This is not tested on the target arches, as I've been unable to find hardware to test this on. src/util/virsysinfo.c | 2 ++ 1 file changed, 2 insertions(+) Cheers, Brett Holman PS: This is my first post on this mailing list. I believe that I've followed the documented steps, but if I've missed anything please let me know.

2 5

[PATCH 00/28] vsh: Fix handling of commands and help - part 2 (unwanted positional parsing of optional arguments)
by Peter Krempa 25 Mar '24

25 Mar '24

Part 2 was supposed to be the refactor of the parser, but it turns out that our annotations of arguments and quirks of the parser itself resulted with basically every optional argument with value being also considered for positional parisng. This series explains where this happens and annotates all cases. Peter Krempa (28): vshCmddefHelp: Drop empty line at the end virsh: cmdDomdisplayReload: Require option name for --type vshCmddefCheckInternals: Improve some checks virsh: Inline VIRSH_COMMON_OPT_DOMAIN_OT_STRING macro virsh: Inline VIRSH_COMMON_OPT_FILE_FULL macro virsh: Inline VIRSH_COMMON_OPT_NETWORK_OT_STRING macro vsh: Introduce tool to find unwanted positional arguments to 'self-test' vsh: Introduce annotation for vsh options which are unexpectedly parsed positionally virsh: Annotate '--diskspec' _ARGV options as unwanted positional virsh: Annotate rest of _ARGV arguments as positional vsh: Fix option formatting for 'VHS_OT_ARGV' options virsh: Require option flags for 'blkdeviotune' arguments virsh: Fix "positional" argument annotations for 'migrate' command virsh: Require option flags for all optional arguments of 'attach-disk' virsh-checkpoint: Make 'checkpointname' positional and required vsh: Allow one optional positional argument vsh: Make the only argument of 'connect', 'cd', and 'help' commands positional virsh: snapshot: Make 'snapshotname' argument positional virsh: Make '(snapshot|checkpoint)-create' 'xmlfile' argument positional virsh-backup: Fix argument annotations of 'backup-begin' command virsh: Annotate some optional arguments as positional virsh: volume: Mark optional 'pool' argument as 'positional' virsh: Annotate "unwanted_positional" arguments for 'pool-(define|create)-as' commands virsh: Annodate 'unwanted_positional' arguments virt-admin: Annodate 'unwanted_positional' arguments vsh: Make positional parsing of arguments opt-in vsh: Replace 'VSH_OFLAG_EMPTY_OK' bitwise flag with a separate struct member vshCmdOptDef: Remove unused 'flags' member tools/virsh-backup.c | 3 +- tools/virsh-checkpoint.c | 26 ++++--- tools/virsh-domain-event.c | 10 ++- tools/virsh-domain-monitor.c | 11 +-- tools/virsh-domain.c | 134 ++++++++++++++++++++++++++++------- tools/virsh-host.c | 33 +++++++-- tools/virsh-interface.c | 2 +- tools/virsh-network.c | 28 ++++---- tools/virsh-nodedev.c | 6 +- tools/virsh-nwfilter.c | 2 - tools/virsh-pool.c | 31 ++++++-- tools/virsh-secret.c | 6 +- tools/virsh-snapshot.c | 13 +++- tools/virsh-volume.c | 12 +++- tools/virsh.c | 3 +- tools/virsh.h | 20 +----- tools/virt-admin.c | 15 ++-- tools/vsh.c | 64 +++++++++++++---- tools/vsh.h | 18 +++-- 19 files changed, 316 insertions(+), 121 deletions(-) -- 2.44.0

2 34

RE: join running core dump job
by Thanos Makatos 22 Mar '24

22 Mar '24

> -----Original Message----- > From: Thanos Makatos <thanos.makatos(a)nutanix.com> > Sent: Friday, March 8, 2024 2:21 PM > To: devel(a)lists.libvirt.org > Cc: Michal Privoznik <mprivozn(a)redhat.com> > Subject: RE: join running core dump job > > > -----Original Message----- > > From: Thanos Makatos <thanos.makatos(a)nutanix.com> > > Sent: Monday, March 4, 2024 9:45 PM > > To: Thanos Makatos <thanos.makatos(a)nutanix.com>; > devel(a)lists.libvirt.org > > Subject: RE: join running core dump job > > > > > -----Original Message----- > > > From: Thanos Makatos <thanos.makatos(a)nutanix.com> > > > Sent: Monday, March 4, 2024 5:24 PM > > > To: devel(a)lists.libvirt.org > > > Subject: join running core dump job > > > > > > Is there a way to programmatically wait for a previously initiated > > > virDomainCoreDumpWithFormat() where the process that started it died? > > I'm > > > looking at the API and don't seem to find anything relevant. I suppose I > > could > > > poll via virDomainGetJobStats(), but, ideally, I'd like a function that would > > join > > > the dump job and return when the dump job finishes. > > > _______________________________________________ > > > Devel mailing list -- devel(a)lists.libvirt.org > > > To unsubscribe send an email to devel-leave(a)lists.libvirt.org > > > > I see there's qemuDumpWaitForCompletion(), looks promising. > > I've made some progress (added a > virHypervisorDriver.domainCoreDumpWait and the relevant scaffolding to > make 'virsh dump --wait' work), calling qemuDumpWaitForCompletion() is all > that's needed. > > However, it doesn't seem trivial to implement this in the test_driver. > First, IIUC testDomainCoreDumpWithFormat() gets an exclusive lock on the > domain (haven't tested anything yet), so calling domainCoreDumpWait() > would block for the wrong reason. Is making > testDomainCoreDumpWithFormat() using asynchronous jobs internally > unavoidable? > Second, I want to test behaviour in my application where (1) it calls > domainCoreDump(), (2) crashes before domainCoreDump() finishes, (3) then > my application starts again and looks for a pending dump job and (4) joins it > using domainCoreDumpWait(). I can't see an easy wait of faking a dump job > in the test_driver when it starts. How about adding persistent tasks, which I > can pre-populate before starting my application, or fake jobs via an > environment variable, so that when the test_driver starts it can internally > continue them? E.g. we can specify how long to run the job for and > domainCoreDumpWait() add a sleep for that long. I ended up using and environment variable in the test_driver to fake jobs, so the application under test doesn't need to know anything. Would something like that be accepted? > > I'm open to suggestions. I have managed to implement a PoC by introducing virDomainJobWait(), which checks the job type and if it's a dump it calls qemuDumpWaitForCompletion(), purely because it's the easiest thing to do (it fails with VIR_ERR_OPERATION_INVALID for all other operations). We'd like to implement this for all other job types and I'm looking for some pointers, is virCondWaitUntil(&priv->job.asyncCond, &obj->parent.lock) all that's required? (And return priv->job.error?) Also, as I explained earlier, I want to implement joining a potentially existing dump job. In my specific use case, I want to either join an ongoing dump job if it exists, otherwise start a new one. I do this by calling virDomainGetJobStats(), but I'm thinking whether we could add a new, optional dump flag, e.g. 'join' which would make virDomainCoreDumpWithFormat do all this internally. Would something like that be accepted upstream.

1 0

[PATCH] qemuDomainChangeNet: Error when boot index changes in live XML
by Adam Julis 22 Mar '24

22 Mar '24

If the original code detected a missing or null boot index in the new XML, it automatically added the current value. This autocompletion was incorrect because it was impossible to distinguish between user intent and user error - changing the boot order itself is forbidden and should always be an error. Resolves: https://issues.redhat.com/browse/RHEL-23416 Fixies: Commit hash aa3e07caec6179dfa6479deab14a21a493637d53 Signed-off-by: Adam Julis <ajulis(a)redhat.com> --- src/qemu/qemu_hotplug.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index b9c502613c..62dc879ed4 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -3847,8 +3847,6 @@ qemuDomainChangeNet(virQEMUDriver *driver, goto cleanup; } - if (newdev->info.bootIndex == 0) - newdev->info.bootIndex = olddev->info.bootIndex; if (olddev->info.bootIndex != newdev->info.bootIndex) { virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", _("cannot modify network device boot index setting")); -- 2.44.0

3 2

[PATCH v3 00/12] Improve versioned CPU support in libvirt
by Jonathon Jongsma 22 Mar '24

22 Mar '24

For SEV-SNP support we will need to be able to specify versioned CPU models that are not yet available in libvirt. Rather than just adding a versioned CPU or two that would satisfy that immediate need, I decided to try to add versioned CPUs in a more standard way. This series generates CPU definitions for all cpu versions that are defined in upstream qemu (at least for recent Intel and AMD CPUs). libvirt already provides a select subset of these versions as configurable CPU models. But we only include the ones that have defined aliases in qemu, such as EPYC-IBPB. After this patchset, all verisioned cpu models supported by qemu will be available in libvirt. In addition to adding these new versioned models, based on feedback from Daniel Berrange, I've also translated all CPU model aliases to a specific version when specifying a CPU model to qemu. This means that we will no longer specify e.g. '-cpu EPYC' to qemu, but will rather specify '-cpu EPYC-v1' Changes in v3: - handle unversioned aliases Changes in v2: - don't make any changes to existing CPU models - drop concept of aliases from libvirt and only provide new versioned models that aren't already available via their qemu alias. Jonathon Jongsma (12): cpu_map: update script to handle versioned CPUs cpu_map: add canonical names to existing CPU models cpu: parse the canonical name from the cpu model qemu: use canonical name for CPU models cpu_map: Add versioned EPYC CPUs cpu_map: Add versioned Intel Skylake CPUs cpu_map: Add versioned Intel Cascadelake CPUs cpu_map: Add versioned Intel Icelake CPUs cpu_map: Add versioned Intel Cooperlake CPUs cpu_map: Add versioned Intel Snowridge CPUs cpu_map: Add versioned Intel SapphireRapids CPUs cpu_map: Add versioned Dhyana CPUs src/conf/cpu_conf.c | 3 + src/conf/cpu_conf.h | 1 + src/cpu/cpu_x86.c | 24 ++++ src/cpu_map/index.xml | 22 +++ src/cpu_map/meson.build | 22 +++ src/cpu_map/sync_qemu_models_i386.py | 42 ++++-- src/cpu_map/x86_Broadwell-IBRS.xml | 1 + src/cpu_map/x86_Broadwell-noTSX-IBRS.xml | 1 + src/cpu_map/x86_Broadwell-noTSX.xml | 1 + src/cpu_map/x86_Broadwell.xml | 1 + src/cpu_map/x86_Cascadelake-Server-noTSX.xml | 1 + src/cpu_map/x86_Cascadelake-Server-v2.xml | 93 +++++++++++++ src/cpu_map/x86_Cascadelake-Server-v4.xml | 91 +++++++++++++ src/cpu_map/x86_Cascadelake-Server-v5.xml | 92 +++++++++++++ src/cpu_map/x86_Cascadelake-Server.xml | 1 + src/cpu_map/x86_Cooperlake-v2.xml | 98 ++++++++++++++ src/cpu_map/x86_Cooperlake.xml | 1 + src/cpu_map/x86_Dhyana-v2.xml | 81 ++++++++++++ src/cpu_map/x86_Dhyana.xml | 1 + src/cpu_map/x86_EPYC-IBPB.xml | 1 + src/cpu_map/x86_EPYC-Milan-v2.xml | 108 +++++++++++++++ src/cpu_map/x86_EPYC-Milan.xml | 1 + src/cpu_map/x86_EPYC-Rome-v2.xml | 93 +++++++++++++ src/cpu_map/x86_EPYC-Rome-v3.xml | 95 +++++++++++++ src/cpu_map/x86_EPYC-Rome-v4.xml | 94 +++++++++++++ src/cpu_map/x86_EPYC-Rome.xml | 1 + src/cpu_map/x86_EPYC-v3.xml | 87 ++++++++++++ src/cpu_map/x86_EPYC-v4.xml | 88 ++++++++++++ src/cpu_map/x86_EPYC.xml | 1 + src/cpu_map/x86_Haswell-IBRS.xml | 1 + src/cpu_map/x86_Haswell-noTSX-IBRS.xml | 1 + src/cpu_map/x86_Haswell-noTSX.xml | 1 + src/cpu_map/x86_Haswell.xml | 1 + src/cpu_map/x86_Icelake-Server-noTSX.xml | 1 + src/cpu_map/x86_Icelake-Server-v3.xml | 103 +++++++++++++++ src/cpu_map/x86_Icelake-Server-v4.xml | 108 +++++++++++++++ src/cpu_map/x86_Icelake-Server-v5.xml | 109 +++++++++++++++ src/cpu_map/x86_Icelake-Server-v6.xml | 109 +++++++++++++++ src/cpu_map/x86_Icelake-Server.xml | 1 + src/cpu_map/x86_IvyBridge-IBRS.xml | 1 + src/cpu_map/x86_IvyBridge.xml | 1 + src/cpu_map/x86_Nehalem-IBRS.xml | 1 + src/cpu_map/x86_Nehalem.xml | 1 + src/cpu_map/x86_SandyBridge-IBRS.xml | 1 + src/cpu_map/x86_SandyBridge.xml | 1 + src/cpu_map/x86_SapphireRapids-v2.xml | 125 ++++++++++++++++++ src/cpu_map/x86_SapphireRapids.xml | 1 + src/cpu_map/x86_Skylake-Client-IBRS.xml | 1 + src/cpu_map/x86_Skylake-Client-noTSX-IBRS.xml | 1 + src/cpu_map/x86_Skylake-Client-v4.xml | 77 +++++++++++ src/cpu_map/x86_Skylake-Client.xml | 1 + src/cpu_map/x86_Skylake-Server-IBRS.xml | 1 + src/cpu_map/x86_Skylake-Server-noTSX-IBRS.xml | 1 + src/cpu_map/x86_Skylake-Server-v4.xml | 83 ++++++++++++ src/cpu_map/x86_Skylake-Server-v5.xml | 85 ++++++++++++ src/cpu_map/x86_Skylake-Server.xml | 1 + src/cpu_map/x86_Snowridge-v2.xml | 78 +++++++++++ src/cpu_map/x86_Snowridge-v3.xml | 80 +++++++++++ src/cpu_map/x86_Snowridge-v4.xml | 78 +++++++++++ src/cpu_map/x86_Snowridge.xml | 1 + src/cpu_map/x86_Westmere-IBRS.xml | 1 + src/cpu_map/x86_Westmere.xml | 1 + src/qemu/qemu_command.c | 5 +- .../x86_64-cpuid-Atom-P5362-guest.xml | 3 +- .../x86_64-cpuid-Atom-P5362-json.xml | 3 +- .../x86_64-cpuid-Cooperlake-host.xml | 3 +- .../x86_64-cpuid-EPYC-7502-32-Core-host.xml | 5 +- .../x86_64-cpuid-EPYC-7601-32-Core-guest.xml | 9 +- ...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml | 8 +- ..._64-cpuid-Hygon-C86-7185-32-core-guest.xml | 5 +- ...6_64-cpuid-Hygon-C86-7185-32-core-host.xml | 5 +- ...6_64-cpuid-Hygon-C86-7185-32-core-json.xml | 6 +- ...4-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-8268-guest.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-8268-host.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-9242-guest.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-9242-host.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-9242-json.xml | 9 +- ..._64-cpuid-baseline-Cascadelake+Icelake.xml | 9 +- ...-cpuid-baseline-Cooperlake+Cascadelake.xml | 9 +- ...6_64-cpuid-baseline-Cooperlake+Icelake.xml | 9 +- .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 2 + .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 4 + .../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 4 + tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 4 + .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 7 + .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 7 + tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 7 + .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 7 + .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 7 + tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 7 + .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 8 ++ .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 8 ++ tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 8 ++ .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 15 +++ .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 15 +++ tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 15 +++ .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 16 +++ .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 16 +++ tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 16 +++ .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 17 +++ .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 17 +++ tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 17 +++ .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 17 +++ .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 17 +++ tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 17 +++ .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 17 +++ .../qemu_7.2.0-tcg.x86_64+hvf.xml | 17 +++ .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 17 +++ tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 17 +++ .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 17 +++ .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 17 +++ tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 17 +++ .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 27 +++- .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 22 +++ tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 27 +++- .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 27 +++- .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 22 +++ tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 27 +++- .../cpu-Haswell-noTSX.x86_64-latest.args | 2 +- .../cpu-Haswell.x86_64-latest.args | 2 +- .../cpu-Haswell2.x86_64-latest.args | 2 +- .../cpu-Haswell3.x86_64-latest.args | 2 +- ...-Icelake-Server-pconfig.x86_64-latest.args | 2 +- .../cpu-cache-disable3.x86_64-latest.args | 2 +- ...u-check-default-partial.x86_64-latest.args | 2 +- .../cpu-fallback.x86_64-5.2.0.args | 2 +- .../cpu-fallback.x86_64-8.0.0.args | 2 +- .../cpu-host-model-cmt.x86_64-latest.args | 2 +- ...-host-model-fallback-kvm.x86_64-4.2.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-5.0.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-5.1.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-5.2.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-6.0.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-6.1.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-6.2.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-7.0.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-7.1.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-7.2.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-8.0.0.args | 2 +- ...-host-model-fallback-kvm.x86_64-8.1.0.args | 2 +- ...host-model-fallback-kvm.x86_64-latest.args | 2 +- ...-host-model-fallback-tcg.x86_64-7.2.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-8.0.0.args | 2 +- ...-host-model-fallback-tcg.x86_64-8.1.0.args | 2 +- ...host-model-fallback-tcg.x86_64-latest.args | 2 +- .../cpu-host-model-kvm.x86_64-4.2.0.args | 2 +- .../cpu-host-model-kvm.x86_64-5.0.0.args | 2 +- .../cpu-host-model-kvm.x86_64-5.1.0.args | 2 +- .../cpu-host-model-kvm.x86_64-5.2.0.args | 2 +- .../cpu-host-model-kvm.x86_64-6.0.0.args | 2 +- .../cpu-host-model-kvm.x86_64-6.1.0.args | 2 +- .../cpu-host-model-kvm.x86_64-6.2.0.args | 2 +- .../cpu-host-model-kvm.x86_64-7.0.0.args | 2 +- .../cpu-host-model-kvm.x86_64-7.1.0.args | 2 +- .../cpu-host-model-kvm.x86_64-7.2.0.args | 2 +- .../cpu-host-model-kvm.x86_64-8.0.0.args | 2 +- .../cpu-host-model-kvm.x86_64-8.1.0.args | 2 +- .../cpu-host-model-kvm.x86_64-latest.args | 2 +- ...ost-model-nofallback-kvm.x86_64-4.2.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-5.0.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-5.1.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-5.2.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-6.0.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-6.1.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-6.2.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-7.0.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-7.1.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-7.2.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-8.0.0.args | 2 +- ...ost-model-nofallback-kvm.x86_64-8.1.0.args | 2 +- ...st-model-nofallback-kvm.x86_64-latest.args | 2 +- ...ost-model-nofallback-tcg.x86_64-7.2.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-8.0.0.args | 2 +- ...ost-model-nofallback-tcg.x86_64-8.1.0.args | 2 +- ...st-model-nofallback-tcg.x86_64-latest.args | 2 +- .../cpu-host-model-tcg.x86_64-7.2.0.args | 2 +- .../cpu-host-model-tcg.x86_64-8.0.0.args | 2 +- .../cpu-host-model-tcg.x86_64-8.1.0.args | 2 +- .../cpu-host-model-tcg.x86_64-latest.args | 2 +- .../cpu-host-model-vendor.x86_64-latest.args | 2 +- .../cpu-minimum1.x86_64-latest.args | 2 +- .../cpu-minimum2.x86_64-latest.args | 2 +- .../cpu-nofallback.x86_64-8.0.0.args | 2 +- .../cpu-phys-bits-emulate2.x86_64-latest.args | 2 +- .../cpu-strict1.x86_64-latest.args | 2 +- .../cpu-translation.x86_64-latest.args | 2 +- .../cpu-tsc-frequency.x86_64-latest.args | 2 +- 190 files changed, 2837 insertions(+), 187 deletions(-) create mode 100644 src/cpu_map/x86_Cascadelake-Server-v2.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v4.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v5.xml create mode 100644 src/cpu_map/x86_Cooperlake-v2.xml create mode 100644 src/cpu_map/x86_Dhyana-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Milan-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v3.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v4.xml create mode 100644 src/cpu_map/x86_EPYC-v3.xml create mode 100644 src/cpu_map/x86_EPYC-v4.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v3.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v4.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v5.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v6.xml create mode 100644 src/cpu_map/x86_SapphireRapids-v2.xml create mode 100644 src/cpu_map/x86_Skylake-Client-v4.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v4.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v5.xml create mode 100644 src/cpu_map/x86_Snowridge-v2.xml create mode 100644 src/cpu_map/x86_Snowridge-v3.xml create mode 100644 src/cpu_map/x86_Snowridge-v4.xml -- 2.41.0

3 35

[PATCH 0/2] NEWS: Mention loongarch64 guest support
by Andrea Bolognani 22 Mar '24

22 Mar '24

Plus a random fix. Andrea Bolognani (2): NEWS: Fix spacing NEWS: Mention loongarch64 guest support NEWS.rst | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) -- 2.44.0

2 3

[PATCH 0/2] Add 'display' and 'ramfb' option for pci hostdevs
by Jonathon Jongsma 22 Mar '24

22 Mar '24

see https://issues.redhat.com/browse/RHEL-28808 Jonathon Jongsma (2): conf: allow display and ramfb for vfio pci hostdevs qemu: enable display/ramfb for vfio pci hostdevs docs/formatdomain.rst | 8 ++++ src/conf/domain_conf.c | 20 ++++++++- src/conf/domain_conf.h | 2 + src/conf/domain_validate.c | 21 +++++---- src/conf/schemas/domaincommon.rng | 25 ++++++----- src/qemu/qemu_command.c | 10 ++++- src/qemu/qemu_validate.c | 8 ++++ ...stdev-pci-display-ramfb.x86_64-latest.args | 33 ++++++++++++++ ...ostdev-pci-display-ramfb.x86_64-latest.xml | 44 +++++++++++++++++++ .../hostdev-pci-display-ramfb.xml | 33 ++++++++++++++ tests/qemuxmlconftest.c | 1 + 11 files changed, 185 insertions(+), 20 deletions(-) create mode 100644 tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/hostdev-pci-display-ramfb.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/hostdev-pci-display-ramfb.xml -- 2.44.0

3 5