- Devel - libvirt List Archives

[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

[PATCH] qemu: warn on pausing of guest due to watchdog or io error
by Michal Privoznik 21 Mar '24

21 Mar '24

From: Lennart Fricke <lennart.fricke(a)drehpunkt.com> Change the log level for pauses of guests due to watchdog timeouts or io errors from debug to warn to enhance the visibility of such events. Signed-off-by: Lennart Fricke <lennart.fricke(a)drehpunkt.com> Reviewed-by: Michal Privoznik <mprivozn(a)redhat.com> --- Here's a commit from MR 339 [1] I've merged. 1: https://gitlab.com/libvirt/libvirt/-/merge_requests/339 src/qemu/qemu_process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 8e35d0a73f..8145205fa8 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -790,7 +790,7 @@ qemuProcessHandleWatchdog(qemuMonitor *mon G_GNUC_UNUSED, if (action == VIR_DOMAIN_EVENT_WATCHDOG_PAUSE && virDomainObjGetState(vm, NULL) == VIR_DOMAIN_RUNNING) { qemuDomainObjPrivate *priv = vm->privateData; - VIR_DEBUG("Transitioned guest %s to paused state due to watchdog", vm->def->name); + VIR_WARN("Transitioned guest %s to paused state due to watchdog", vm->def->name); virDomainObjSetState(vm, VIR_DOMAIN_PAUSED, VIR_DOMAIN_PAUSED_WATCHDOG); lifecycleEvent = virDomainEventLifecycleNewFromObj(vm, @@ -860,7 +860,7 @@ qemuProcessHandleIOError(qemuMonitor *mon G_GNUC_UNUSED, if (action == VIR_DOMAIN_EVENT_IO_ERROR_PAUSE && virDomainObjGetState(vm, NULL) == VIR_DOMAIN_RUNNING) { qemuDomainObjPrivate *priv = vm->privateData; - VIR_DEBUG("Transitioned guest %s to paused state due to IO error", vm->def->name); + VIR_WARN("Transitioned guest %s to paused state due to IO error", vm->def->name); if (priv->signalIOError) virDomainObjBroadcast(vm); -- 2.43.2

1 0

[libvirt PATCH V4 0/4] add loongarch support for libvirt
by Xianglai Li 21 Mar '24

21 Mar '24

Hello, Everyone: This patch series adds libvirt support for loongarch. After three times of code review and modification, our patch has come to the 4th version. We would like to thank Andrea very much for his comments and help us improve patch. You can get the full patch from the link below: https://gitlab.com/lixianglai/libvirt branch: loongarch Since the patch associated with loongarch has not yet been submitted to the virt-manager community, we are providing a temporary patch with loongarch for the time being patch's virt-manager, the open source work of virt-manager adding loongarch will be followed up later or synchronized with the open source libvirt. You can get the virt-manager code with loongarch patch from the link below: https://github.com/lixianglai/virt-manager branch: loongarch loongarch's virtual machine bios is not yet available in qemu,So you need to compile loongarch UEFI yourself, you can refer to the following link to compile UEFI: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Loongson/L… Here we provide compiled UEFI for ease of testing,you can get it from the following link: https://github.com/lixianglai/LoongarchVirtFirmware (Note: You should clone the repository using git instead of downloading the file via wget or you'll get xml) We named the bios QEMU_EFI.fd, QEMU_VARS.fd is used to store pflash images of non-volatile variables. After installing qemu-system-loongarch64,You can install the loongarch bios by executing the script install-loongarch-virt-firmware.sh Since there is no fedora operating system that supports the loongarch architecture, you can find an iso that supports loongarch at the link below for testing purposes: https://github.com/fedora-remix-loongarch/releases-info The operating system provided above may have minor problems of one kind or another, but you can also find out from the following link that openEuler's operating system supports loongarch: https://muug.ca/mirror/openeuler/openEuler-22.03-LTS/ISO/loongarch64/ Well, if you have completed the above steps I think you can now install loongarch virtual machine, you can install it through the virt-manager graphical interface, or install it through vrit-install, here is an example of installing it using virt-install: virt-install \ --virt-type=qemu \ --name loongarch-test \ --memory 4096 \ --vcpus=4 \ --arch=loongarch64 \ --boot cdrom \ --disk device=cdrom,bus=scsi,path=/root/livecd-fedora-mate-4.loongarch64.iso \ --disk path=/var/lib/libvirt/images/debian12-loongarch64.qcow2,size=10,format=qcow2,bus=scsi \ --network network=default \ --osinfo archlinux \ --video=virtio \ --graphics=vnc,listen=0.0.0.0 CHANGES V3->V4: 1.Rebase according to the latest master code, making appropriate adjustments for relevant changes. 2.Modify the default scsi controller model. 3.Add firmware test cases. 4.Remove unnecessary acpi functional flags from test cases. V2->V3: 1.Delete redundant header files in cpu_loongarch.c 2.Fixed code formatting issues 3.Modify the commit message of [PATCH 2/4] 4.Remove useless test cases for loongarch, Rebuild loongarch's test case based on the latest code. V1->V2: 1.Modify the link addresses of virtu-manager and firmeware in the cover letter. Please obtain the code and firmware from the latest link address. 2.Rename the bios name. Delete the loongarch bios name from libvirt and use the json file to obtain the bios path. 3.Refer to riscv64 to simplify the implementation of loongarch cpu driver.And fix some code style errors. 4.Delete unnecessary or redundant device enablement.Such as USB NEC. 5.Add some test cases for loongarch. Xianglai Li (4): Add loongarch cpu support Support for loongarch64 in the QEMU driver Implement the method of getting host info for loongarch Add test script for loongarch src/conf/schemas/basictypes.rng | 1 + src/cpu/cpu.c | 2 + src/cpu/cpu_loongarch.c | 58 + src/cpu/cpu_loongarch.h | 25 + src/cpu/meson.build | 1 + src/qemu/qemu_capabilities.c | 16 +- src/qemu/qemu_command.c | 6 +- src/qemu/qemu_domain.c | 42 +- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_validate.c | 1 + src/util/virarch.c | 13 +- src/util/virarch.h | 13 +- src/util/virhostcpu.c | 7 +- src/util/virsysinfo.c | 3 +- .../qemu_8.2.0-tcg-virt.loongarch64.xml | 165 + .../qemu_8.2.0-virt.loongarch64.xml | 169 + tests/domaincapstest.c | 4 +- .../caps_8.2.0_loongarch64.replies | 30121 ++++++++++++++++ .../caps_8.2.0_loongarch64.xml | 177 + .../qemucaps2xmloutdata/caps.loongarch64.xml | 28 + tests/qemufirmwaretest.c | 2 +- ...o-type-loongarch64.loongarch64-latest.args | 34 + ...eo-type-loongarch64.loongarch64-latest.xml | 45 + .../default-video-type-loongarch64.xml | 18 + ...garch64.loongarch64-latest.abi-update.args | 35 + ...ngarch64.loongarch64-latest.abi-update.xml | 34 + ...to-efi-loongarch64.loongarch64-latest.args | 35 + ...uto-efi-loongarch64.loongarch64-latest.xml | 34 + .../firmware-auto-efi-loongarch64.xml | 17 + ...-models.loongarch64-latest.abi-update.args | 43 + ...t-models.loongarch64-latest.abi-update.xml | 72 + ...irt-default-models.loongarch64-latest.args | 43 + ...virt-default-models.loongarch64-latest.xml | 72 + .../loongarch64-virt-default-models.xml | 21 + ...ch64-virt-graphics.loongarch64-latest.args | 56 + ...rch64-virt-graphics.loongarch64-latest.xml | 116 + .../loongarch64-virt-graphics.xml | 48 + ...ch64-virt-headless.loongarch64-latest.args | 52 + ...rch64-virt-headless.loongarch64-latest.xml | 102 + .../loongarch64-virt-headless.xml | 42 + ...minimal.loongarch64-latest.abi-update.args | 31 + ...-minimal.loongarch64-latest.abi-update.xml | 23 + ...rch64-virt-minimal.loongarch64-latest.args | 31 + ...arch64-virt-minimal.loongarch64-latest.xml | 23 + .../loongarch64-virt-minimal.xml | 12 + tests/qemuxmlconftest.c | 9 + tests/testutilshostcpus.h | 10 + 47 files changed, 31885 insertions(+), 28 deletions(-) create mode 100644 src/cpu/cpu_loongarch.c create mode 100644 src/cpu/cpu_loongarch.h create mode 100644 tests/domaincapsdata/qemu_8.2.0-tcg-virt.loongarch64.xml create mode 100644 tests/domaincapsdata/qemu_8.2.0-virt.loongarch64.xml create mode 100644 tests/qemucapabilitiesdata/caps_8.2.0_loongarch64.replies create mode 100644 tests/qemucapabilitiesdata/caps_8.2.0_loongarch64.xml create mode 100644 tests/qemucaps2xmloutdata/caps.loongarch64.xml create mode 100644 tests/qemuxmlconfdata/default-video-type-loongarch64.loongarch64-latest.args create mode 100644 tests/qemuxmlconfdata/default-video-type-loongarch64.loongarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/default-video-type-loongarch64.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-loongarch64.loongarch64-latest.abi-update.args create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-loongarch64.loongarch64-latest.abi-update.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-loongarch64.loongarch64-latest.args create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-loongarch64.loongarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-loongarch64.xml create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-default-models.loongarch64-latest.abi-update.args create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-default-models.loongarch64-latest.abi-update.xml create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-default-models.loongarch64-latest.args create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-default-models.loongarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-default-models.xml create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-graphics.loongarch64-latest.args create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-graphics.loongarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-graphics.xml create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-headless.loongarch64-latest.args create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-headless.loongarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-headless.xml create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-minimal.loongarch64-latest.abi-update.args create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-minimal.loongarch64-latest.abi-update.xml create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-minimal.loongarch64-latest.args create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-minimal.loongarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/loongarch64-virt-minimal.xml -- 2.39.1

2 5

[PATCH] remote: check for negative array lengths before allocation
by Daniel P. Berrangé 21 Mar '24

21 Mar '24

While the C API entry points will validate non-negative lengths for various parameters, the RPC server de-serialization code will need to allocate memory for arrays before entering the C API. These allocations will thus happen before the non-negative length check is performed. Passing a negative length to the g_new0 function will usually result in a crash due to the negative length being treated as a huge positive number. This was found and diagnosed by ALT Linux Team with AFLplusplus. CVE-2024-2494 Found-by: Alexandr Shashkin <dutyrok(a)altlinux.org> Co-developed-by: Alexander Kuznetsov <kuznetsovam(a)altlinux.org> Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/remote/remote_daemon_dispatch.c | 65 +++++++++++++++++++++++++++++ src/rpc/gendispatch.pl | 5 +++ 2 files changed, 70 insertions(+) diff --git a/src/remote/remote_daemon_dispatch.c b/src/remote/remote_daemon_dispatch.c index aaabd1e56c..01dcac4b12 100644 --- a/src/remote/remote_daemon_dispatch.c +++ b/src/remote/remote_daemon_dispatch.c @@ -2291,6 +2291,10 @@ remoteDispatchDomainGetSchedulerParameters(virNetServer *server G_GNUC_UNUSED, if (!conn) goto cleanup; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_DOMAIN_SCHEDULER_PARAMETERS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; @@ -2339,6 +2343,10 @@ remoteDispatchDomainGetSchedulerParametersFlags(virNetServer *server G_GNUC_UNUS if (!conn) goto cleanup; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_DOMAIN_SCHEDULER_PARAMETERS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; @@ -2497,6 +2505,10 @@ remoteDispatchDomainBlockStatsFlags(virNetServer *server G_GNUC_UNUSED, goto cleanup; flags = args->flags; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_DOMAIN_BLOCK_STATS_PARAMETERS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; @@ -2717,6 +2729,14 @@ remoteDispatchDomainGetVcpuPinInfo(virNetServer *server G_GNUC_UNUSED, if (!(dom = get_nonnull_domain(conn, args->dom))) goto cleanup; + if (args->ncpumaps < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("ncpumaps must be non-negative")); + goto cleanup; + } + if (args->maplen < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("maplen must be non-negative")); + goto cleanup; + } if (args->ncpumaps > REMOTE_VCPUINFO_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("ncpumaps > REMOTE_VCPUINFO_MAX")); goto cleanup; @@ -2811,6 +2831,11 @@ remoteDispatchDomainGetEmulatorPinInfo(virNetServer *server G_GNUC_UNUSED, if (!(dom = get_nonnull_domain(conn, args->dom))) goto cleanup; + if (args->maplen < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("maplen must be non-negative")); + goto cleanup; + } + /* Allocate buffers to take the results */ if (args->maplen > 0) cpumaps = g_new0(unsigned char, args->maplen); @@ -2858,6 +2883,14 @@ remoteDispatchDomainGetVcpus(virNetServer *server G_GNUC_UNUSED, if (!(dom = get_nonnull_domain(conn, args->dom))) goto cleanup; + if (args->maxinfo < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("maxinfo must be non-negative")); + goto cleanup; + } + if (args->maplen < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("maxinfo must be non-negative")); + goto cleanup; + } if (args->maxinfo > REMOTE_VCPUINFO_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("maxinfo > REMOTE_VCPUINFO_MAX")); goto cleanup; @@ -3096,6 +3129,10 @@ remoteDispatchDomainGetMemoryParameters(virNetServer *server G_GNUC_UNUSED, flags = args->flags; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_DOMAIN_MEMORY_PARAMETERS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; @@ -3156,6 +3193,10 @@ remoteDispatchDomainGetNumaParameters(virNetServer *server G_GNUC_UNUSED, flags = args->flags; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_DOMAIN_NUMA_PARAMETERS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; @@ -3216,6 +3257,10 @@ remoteDispatchDomainGetBlkioParameters(virNetServer *server G_GNUC_UNUSED, flags = args->flags; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_DOMAIN_BLKIO_PARAMETERS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; @@ -3277,6 +3322,10 @@ remoteDispatchNodeGetCPUStats(virNetServer *server G_GNUC_UNUSED, flags = args->flags; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_NODE_CPU_STATS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; @@ -3339,6 +3388,10 @@ remoteDispatchNodeGetMemoryStats(virNetServer *server G_GNUC_UNUSED, flags = args->flags; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_NODE_MEMORY_STATS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; @@ -3514,6 +3567,10 @@ remoteDispatchDomainGetBlockIoTune(virNetServer *server G_GNUC_UNUSED, if (!conn) goto cleanup; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_DOMAIN_BLOCK_IO_TUNE_PARAMETERS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; @@ -5081,6 +5138,10 @@ remoteDispatchDomainGetInterfaceParameters(virNetServer *server G_GNUC_UNUSED, flags = args->flags; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_DOMAIN_INTERFACE_PARAMETERS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; @@ -5301,6 +5362,10 @@ remoteDispatchNodeGetMemoryParameters(virNetServer *server G_GNUC_UNUSED, flags = args->flags; + if (args->nparams < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams must be non-negative")); + goto cleanup; + } if (args->nparams > REMOTE_NODE_MEMORY_PARAMETERS_MAX) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("nparams too large")); goto cleanup; diff --git a/src/rpc/gendispatch.pl b/src/rpc/gendispatch.pl index 5ce988c5ae..c5842dc796 100755 --- a/src/rpc/gendispatch.pl +++ b/src/rpc/gendispatch.pl @@ -1070,6 +1070,11 @@ elsif ($mode eq "server") { print "\n"; if ($single_ret_as_list) { + print " if (args->$single_ret_list_max_var < 0) {\n"; + print " virReportError(VIR_ERR_RPC,\n"; + print " \"%s\", _(\"max$single_ret_list_name must be non-negative\"));\n"; + print " goto cleanup;\n"; + print " }\n"; print " if (args->$single_ret_list_max_var > $single_ret_list_max_define) {\n"; print " virReportError(VIR_ERR_RPC,\n"; print " \"%s\", _(\"max$single_ret_list_name > $single_ret_list_max_define\"));\n"; -- 2.43.0

2 1

[PATCH-for-9.0 0/2] target/monitor: Deprecate 'info tlb/mem' in favor of 'info mmu'
by Philippe Mathieu-Daudé 20 Mar '24

20 Mar '24

'info tlb' and 'info mem' commands don't scale in heterogeneous emulation. They will be reworked after the next release, hidden behind the 'info mmu' command. It is not too late to deprecate commands, so add the 'info mmu' command as wrapper to the other ones, but already deprecate them. Philippe Mathieu-Daudé (2): target/monitor: Introduce 'info mmu' command target/monitor: Deprecate 'info tlb' and 'info mem' commands docs/about/deprecated.rst | 10 ++++++++ include/monitor/hmp-target.h | 3 +++ monitor/hmp-cmds-target.c | 49 ++++++++++++++++++++++++++++++++++++ target/i386/monitor.c | 4 +-- target/m68k/monitor.c | 2 +- target/nios2/monitor.c | 2 +- target/ppc/ppc-qmp-cmds.c | 2 +- target/riscv/monitor.c | 2 +- target/sh4/monitor.c | 2 +- target/sparc/monitor.c | 2 +- target/xtensa/monitor.c | 2 +- hmp-commands-info.hx | 22 +++++++++++++--- 12 files changed, 89 insertions(+), 13 deletions(-) -- 2.41.0

3 6