January 2024 - Devel - libvirt List Archives

[Libvir] Hang with virt-install graphic=no on FC 6 6.93/F7 RC2
by libvirtuser 23 Dec '25

23 Dec '25

I had this problem and another user confirmed the same behavior on his machine: http://pastie.caboo.se/65417 Haven't tried it with *2925.10* yet. Also, is there a way to get more verbose info about what calls are causing the "configuration file syntax error" errors? Thanks. virt-install How large would you like the disk () to be (in gigabytes)? 4 ERROR: Must provide a file, not a directory for the disk What would you like to use as the disk (path)? /xen/images/x6.img Would you like to enable graphics support? (yes or no) no What is the install location? http://mirror.anl.gov/pub/fedora-linux-core/test/6.93/Fedora/i386/os/ Starting install... libvir: Xen Daemon error : GET operation failed: libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name Retrieving Fedora... 276 kB 00:01 Retrieving vmlinuz... 100% |=========================| 2.1 MB 00:16 Retrieving initrd.img... 100% |=========================| 5.4 MB 00:28 libvir: Xen Daemon error : GET operation failed: libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name libvir: error : configuration file syntax error: expecting a name Creating domain... 0 B 00:06 Linux version 2.6.20-2925.5.fc7xen (brewbuilder(a)ls20-bc1-14.build.redhat.com) (gcc version 4.1.2 20070317 (Red Hat 4.1.2-5)) #1 SMP Thu Mar 22 13:51:38 EDT 2007 BIOS-provided physical RAM map: sanitize start sanitize bail 0 copy_e820_map() start: 0000000000000000 size: 0000000020800000 end: 0000000020800000 type: 1 Xen: 0000000000000000 - 0000000020800000 (usable) 0MB HIGHMEM available. 520MB LOWMEM available. Using x86 segment limits to approximate NX protection Zone PFN ranges: DMA 0 -> 133120 Normal 133120 -> 133120 HighMem 133120 -> 133120 early_node_map[1] active PFN ranges 0: 0 -> 133120 ACPI in unprivileged domain disabled Built 1 zonelists. Total pages: 132080 Kernel command line: method=http://mirror.anl.gov/pub/fedora-linux-core/test/6.93/Fedora/i386/os/ Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c135f000 soft=c133f000 PID hash table entries: 4096 (order: 12, 16384 bytes) Xen reported: 1694.994 MHz processor. Console: colour dummy device 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS: 2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1064 kB per task-struct memory footprint: 1200 bytes Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: e1000000-f4ffe000, maxmem 2d7fe000 Memory: 503936k/532480k available (2030k kernel code, 19948k reserved, 1079k data, 180k init, 0k highmem) virtual kernel memory layout: fixmap : 0xf5315000 - 0xf57fe000 (5028 kB) pkmap : 0xf5000000 - 0xf5200000 (2048 kB) vmalloc : 0xe1000000 - 0xf4ffe000 ( 319 MB) lowmem : 0xc0000000 - 0xe0800000 ( 520 MB) .init : 0xc130e000 - 0xc133b000 ( 180 kB) .data : 0xc11fb9d9 - 0xc1309714 (1079 kB) .text : 0xc1000000 - 0xc11fb9d9 (2030 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4262.67 BogoMIPS (lpj=8525343) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 256K Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 11k freed Brought up 1 CPUs Grant table initialized NET: Registered protocol family 16 Brought up 1 CPUs PCI: Fatal: No config space access function found PCI: setting up Xen PCI frontend stub Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled xen_mem: Initialising balloon driver. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: System does not support PCI PCI: System does not support PCI NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 9, 2097152 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered checking if image is initramfs... it is Freeing initrd memory: 7256k freed IA-32 Microcode Update Driver: v1.14-xen <tigran(a)veritas.com> audit: initializing netlink socket (disabled) audit(1180379657.981:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 BUG: at kernel/fork.c:994 copy_process() [<c1005d9a>] show_trace_log_lvl+0x1a/0x2f [<c1006343>] show_trace+0x12/0x14 [<c10063be>] dump_stack+0x16/0x18 [<c101d044>] copy_process+0x195/0x1245 [<c101e144>] do_fork+0x50/0x117 [<c1003351>] kernel_thread+0x8e/0x96 [<c102c701>] __call_usermodehelper+0x2d/0x46 [<c102cd4f>] run_workqueue+0x89/0x145 [<c102d711>] worker_thread+0xd5/0x102 [<c102ff27>] kthread+0xb3/0xdc [<c10058db>] kernel_thread_helper+0x7/0x10 ======================= rtc: IRQ 8 is not free. Non-volatile memory driver v1.2 Linux agpgart interface v0.101 (c) Dave Jones RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize input: Macintosh mouse button emulation as /class/input/input0 Xen virtual console successfully installed as xvc0 Event-channel device installed. usbcore: registered new interface driver libusual usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver PNP: No PS/2 controller found. Probing ports directly. i8042.c: No controller found. mice: PS/2 mouse device common for all mice TCP bic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 Using IPI No-Shortcut mode XENBUS: Device with no driver: device/vbd/51712 XENBUS: Device with no driver: device/vif/0 Freeing unused kernel memory: 180k freed Write protecting the kernel read-only data: 762k ^[Domain installation still in progress. You can reconnect

2 1

[ PATCH vf-token 0/8] Introduce vf-token when using userspace PF
by Vivek Kashyap 23 Dec '25

23 Dec '25

The VFIO PCI ABI has been extended to require userspace PF driver to set a VF token to a known value. The VF drivers are then required to provide this token to access the VF device. The vf-token is set by the PF driver before VF drivers can access the device. The kernel provides no means to retrieve the token in use; but there is no specification describing the distribution or level of confidentiality of the token. Qemu has been extended to require the vf-token when vf device is used. An important point to note is that the vf-token is required only when both the PF and VF are used in userspace. This patch series adds support to provide the vf-token (uuid format) in the domain XML and to generate the qemu commandline including the vf-token. To support vf-token the new element will be used as follows: <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x0' slot='0x00' function='0x1'> <vf-token uuid='00112233-4455-6677-8899-aabbccddeeff'/> </address> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </hostdev> The generated commandline will include the following: -device {"driver":"vfio-pci","host":"0000:00:0.1", "vf-token":"00112233-4455-6677-8899-aabbccddeeff", "id":"hostdev0","bus":"pci.0","addr":"0x1"} Changes since initial RFC based on review comments received: 1. Added documentation 2. Added test cases and ran successful test suite after each patch commit 3. fixed spaces, coding sytle, and uuid string format 4. Used S:vftoken in virJSONValueObjectAdd instead of a conditional Vivek Kashyap (8): Define the vf-token extension for PCI device Introduce the vf-token qemu capability This patch introduces the PCI address extension flag for vf-token This patch introduces new XML parser/formatter functions for parsing the vf-token Introduce a validation function for vf-token support in qemu and generate vf-token device attribute in qemu command line Provide information about the vf-token flag Add tests for the vf-token flag to the qemuxml2argv and qemuxml2xml test suites Update news about vf-token NEWS.rst | 8 +++ docs/formatdomain.rst | 3 ++ src/conf/device_conf.c | 49 ++++++++++++++++--- src/conf/domain_addr.h | 1 + src/conf/domain_conf.c | 8 +++ src/conf/schemas/basictypes.rng | 7 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 3 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 8 +++ src/qemu/qemu_domain_address.c | 3 ++ src/qemu/qemu_validate.c | 20 ++++++++ src/util/virpci.c | 7 +++ src/util/virpci.h | 10 ++++ .../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 1 + .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.xml | 1 + .../hostdev-vfio-vf-token.x86_64-latest.args | 34 +++++++++++++ .../hostdev-vfio-vf-token.xml | 22 +++++++++ tests/qemuxml2argvtest.c | 1 + .../hostdev-vfio-vf-token.x86_64-latest.xml | 40 +++++++++++++++ tests/qemuxml2xmltest.c | 1 + 22 files changed, 223 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-vf-token.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-vf-token.x86_64-latest.xml -- 2.33.8

3 19

[libvirt] [PATCH] Fix python error reporting for some storage operations
by Cole Robinson 07 Mar '25

07 Mar '25

In the python bindings, all vir* classes expect to be passed a virConnect object when instantiated. Before the storage stuff, these classes were only instantiated in virConnect methods, so the generator is hardcoded to pass 'self' as the connection instance to these classes. Problem is there are some methods that return pool or vol instances which aren't called from virConnect: you can lookup a storage volume's associated pool, and can lookup volumes from a pool. In these cases passing 'self' doesn't give the vir* instance a connection, so when it comes time to raise an exception crap hits the fan. Rather than rework the generator to accomodate this edge case, I just fixed the init functions for virStorage* to pull the associated connection out of the passed value if it's not a virConnect instance. Thanks, Cole diff --git a/python/generator.py b/python/generator.py index 01a17da..c706b19 100755 --- a/python/generator.py +++ b/python/generator.py @@ -962,8 +962,12 @@ def buildWrappers(): list = reference_keepers[classname] for ref in list: classes.write(" self.%s = None\n" % ref[1]) - if classname in [ "virDomain", "virNetwork", "virStoragePool", "virStorageVol" ]: + if classname in [ "virDomain", "virNetwork" ]: classes.write(" self._conn = conn\n") + elif classname in [ "virStorageVol", "virStoragePool" ]: + classes.write(" self._conn = conn\n" + \ + " if not isinstance(conn, virConnect):\n" + \ + " self._conn = conn._conn\n") classes.write(" if _obj != None:self._o = _obj;return\n") classes.write(" self._o = None\n\n"); destruct=None

4 3

[libvirt PATCH] qemu_snapshot: allow reverting to external disk only snapshot
by Pavel Hrdina 29 Jan '25

29 Jan '25

When snapshot is created with disk-only flag it is always external snapshot without memory state. Historically when there was not support to revert external snapshots this produced error message. error: Failed to revert snapshot s1 error: internal error: Invalid target domain state 'disk-snapshot'. Refusing snapshot reversion Now we can simply consider this as reverting to offline snapshot as the possible damage to file system is already done at the point of snapshot creation. Resolves: https://issues.redhat.com/browse/RHEL-21549 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_snapshot.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index 0cac0c4146..7964f70553 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -2606,6 +2606,7 @@ qemuSnapshotRevert(virDomainObj *vm, case VIR_DOMAIN_SNAPSHOT_SHUTDOWN: case VIR_DOMAIN_SNAPSHOT_SHUTOFF: case VIR_DOMAIN_SNAPSHOT_CRASHED: + case VIR_DOMAIN_SNAPSHOT_DISK_SNAPSHOT: ret = qemuSnapshotRevertInactive(vm, snapshot, snap, driver, cfg, &inactiveConfig, @@ -2617,8 +2618,6 @@ qemuSnapshotRevert(virDomainObj *vm, _("qemu doesn't support reversion of snapshot taken in PMSUSPENDED state")); goto endjob; - case VIR_DOMAIN_SNAPSHOT_DISK_SNAPSHOT: - /* Rejected earlier as an external snapshot */ case VIR_DOMAIN_SNAPSHOT_NOSTATE: case VIR_DOMAIN_SNAPSHOT_BLOCKED: case VIR_DOMAIN_SNAPSHOT_LAST: -- 2.43.0

2 1

[libvirt PATCH 00/28] native support for nftables in virtual network driver
by Laine Stump 12 Jun '24

12 Jun '24

This patch series enables libvirt to use nftables rules rather than iptables *when setting up virtual networks* (it does *not* add nftables support to the nwfilter driver). It accomplishes this by abstracting several iptables functions (from viriptables.[ch] called by the virtual network driver into a rudimentary "virNetfilter API" (in virnetfilter.[ch], having the virtual network driver call the virNetFilter API rather than calling the existing iptables functions directly, and then finally adding an equivalent virNftables backend that can be used instead of iptables (selected manually via a network.conf setting, or automatically if iptables isn't found on the host). A first look at the result may have you thinking that it's filled with a lot of bad decisions. While I would agree with that in many cases, I think that overall they are the "least bad" decisions, or at least "bad within acceptable limits / no worse than something else", and point out that it's been done in a way that minimizes (actually eliminates) the need for immediate changes to nwfilter (the other consumer of iptables, which *also* needs to be updated to use native nftables), and makes it much easier to change our mind about the details in the future. When I first started on this (long, protracted, repeatedly interrupted for extended periods - many of these patches are > a year old) task, I considered doing an all-at-once complete replacement of iptables with nftables, since all the Linux distros we support have had nftables for several years, and I'm pretty sure nobody has it disabled (not even sure if it's possible to disable nftables while still enabling iptables, since they both use xtables in the kernel). But due to libvirt's use of "-t mangle -j CHECKSUM --checksum-fill" (see commit fd5b15ff all the way back in July 2010 for details) which has no equivalent in nftables rules (and we don't *want* it to!!), and the desire to be able to easily switch back to iptables in case of an unforeseen regression, we decided that both iptables and nftables need to be supported (for now), with the default (for now) remaining as iptables. Just allowing for dual backends complicated matters, since it means that we have to have a config file, a setting, detection of which backends are available, and of course some sort of concept of an abstracted frontend that can use either backend based on the config setting (and/or auto-detection). Combining that with the fact that it would just be "too big" of a project to switch over nwfilter's iptables usage at the same time means that we have to keep around a lot of existing code for compatibility's sake rather than just wiping it all away and starting over. So, what I've ended up with is: 1) a network.conf file (didn't exist before) with a single setting "firewall_backend". If unset, the network driver tries to use iptables on the backend, and if that's missing, then tries to use nftables. 2) a new (internal-only, so transient!) virNetFilterXXX API that is used by the network driver in place of the iptablesXXX API, and calls either iptablesXXX or: 3) a virNftablesXXX API that exactly replicates the filtering rules of the existing iptablesXXX API (except in the custom "libvirt" base table rather than the system "filter" and "nat" tables). This means that: 4) when the nftables backend is used, the rules added are *exactly the same* (functionally speaking) as we currently add for iptables (except they are in the "libvirt" table). We had spent some time in IRC discussing different ways of using new functionality available in nftables to make a more efficient/performant implemention of the desired filtering, and there are some really great possibilities that need to be explored, but in the end there were too many details up in the air, and I decided that it would be more "accomplishable" (coined a new word there!) to first replicate existing behavior with nftables, but do it inside a framework that makes it easy to modify the details in the future (in particular making it painless to switch back and forth between builds with differing filter models at runtime) - this way we'll be able to separate the infrastructure work from the details of the rules (which we can then more easily work on and experiment with). (This implies that the main objective right now is "get rid of iptables dependencies", not "make the filtering faster and more efficient"). Notable features of this patchset: * allows switching between iptables/nftables backends without rebooting or restarting networks/guests. Because the commands required to remove a network's filter rules are now saved in the network status XML, each time libvirtd (or virtnetworkd) is restarted, it will execute exactly the commands needed to remove the filter rules that had been added by the previous libvirtd/virtnetworkd (rather than just making a guess, as we've always done up until now), and then add new rules using the current backend+binary's set of rules (while also saving the info needed for future removal of these new rules back into the network's status XML). * firewall_backend can be explicitly set in (new) /etc/libvirt/network.conf, but if it's not explicitly set, libvirt will default to the iptables backend if the iptables binary is found, and otherwise fall back to nftables as long as the nft binary is found; otherwise the first attempt to start a network will fail with an appropriate error. Things that seem ugly / that I would like to clean up / that I think are just fine as they are: * virFirewall does *not* provide a backend-agnostic interface [this is fine] * We need to maintain a backward-compatible API for virFirewall so that we don't have to touch nwfilter code. Trying to make its API backend-agnostic would require individually considering/changing every nwfilter use of virFirewall. * instead virFirewall objects are just a way to build a collection of commands to execute to build a firewall, then execute them while collecting info for and building a collection of commands that will tear down that firewall in the future. Do I want to "fix" this in the future by making virFirewall a higher level interface that accepts tokens describing the type of rule to add (rather than backend-specific arguments to a backend-specific command)? No. I think I like the way virFirewall works (as described in that previous bullet-point), instead I'm thinking that it is just slightly mis-named - I've lately been thinking of it as a "virNetFilterCmdList". Similarly, the virFirewallRules that it has a list of aren't really "rules", they are better described as commands or actions, so maybe they should be renamed to virNetfilterCmd or virNetfilterAction. But that is just cosmetic, so I didn't want to get into it in these patches (especially in case someone disagrees, or has a better idea for naming). * Speaking of renaming - I should probably rename all the "iptablesXXX" functions to "virIptablesXXX" to be consistent with so much of our other code. I lost the ambition to deal with it right now though, so I'm leaving that for later cleanup (or I could do it now if it really makes someone's day :-). * I could have chosen a higher place in the callchain to make the virNetfilter abstraction, e.g. at the level of "networkAddXXXFirewallRules()" rather than at the lower level of iptablesXXX(). That is actually probably what will happen in the future (since it will be necessary in order for an nftables-based firewall to be significantly different in structure from an iptables-based firewall). But that's the beauty of an API being private - we can freely add/remove things as needed. the important thing is that we now have the basic structure there. For now, the split is just above the existing iptablesXXX API (util/viriptables.[ch], which seems like a "narrow" enough place. Most iptablesXXX functions are written in terms of just 10 *other* iptablesXXX functions that add iptables-specific commands - I've just moved those functions into virnetfilter.[ch] (appropriately renamed), and changed them to call the 10 virNetfilterXXX functions that will in-turn call those 10 iptablesXXX (or equivalent virNftablesXXX) functions. * Some people may dislike that the 10 virNetfilterXXX functions are each written with a switch statement that has cases to directly call each backend, rather than each backend driver having a table of pointers to API functions, with the virNetfilter API function calling backends[fwBackend]->XXX() (ie the pattern for so many drivers in libvirt). But for just 2 backends, that really seemed like overkill and unnecessary obfuscation. * As implemented here, I am storing a "<fwRemoval>" element in the network status XML - it contains a serialized virFirewall object that directly contains the commands necessary to remove the firewall. I could instead just store "<firewall>", which would include all the commands that were used to *create* the firewall in addition to the commands needed to remove the firewall. The way it's done currently takes up less space; switching to storing the full firewall *might* be more informative to somebody, but on the other hand would make the network status XML *very* long. If anybody has an opinion about this, now is the time to bring it up - do you think it's worth having a separate list of all the commands that were used to create a network's firewall (keeping in mind that there is no public API to access it)? Or is it enough to just store what's needed to remove the firewall? * Several months ago Eric Garver posted patches for a pure firewalld backend, and I requested that they not be pushed because I wanted that to be integrated with my nftables backend support. Due to the fact that the firewalld backend is almost entirely implemented by putting the bridge into a new firewalld "zone", with no individual rules added, that won't happen as just another backend driver file in parallel to iptables and nftables; it will instead work by checking firewall_backend at a higher level in the network driver, thus avoiding the calls to virNetfilterXXX() entirely. I have locally merged Eric's patches over the top of these patches, and there are surprisingly few conflicts, but since his patches didn't account for a user-settable config (but instead just always used the firewalld backend if firewalld was active), some of the patches are going to require a bit of rework, which I'll take care of after getting these patches in. Laine Stump (28): util: add -w/--concurrent when applying the rule rather than when building it util: new virFirewallRuleGet*() APIs util: determine ignoreErrors value when creating rule, not when applying util: rename iptables helpers that will become the frontend for ip&nftables util: move backend-agnostic virNetfilter*() functions to their own file util: make netfilter action a proper typedefed (virFirewall) enum util: #define the names used for private packet filter chains util: move/rename virFirewallApplyRuleDirect to virIptablesApplyFirewallRule util/network: reintroduce virFirewallBackend, but different network: add (empty) network.conf file to distribution files network: allow setting firewallBackend from network.conf network: do not add DHCP checksum mangle rule unless using iptables network: call backend agnostic function to init private filter chains util: setup functions in virnetfilter which will call appropriate backend build: add nft to the list of binaries we attempt to locate util: add nftables backend to virnetfilter API used by network driver tests: test cases for nftables backend util: new functions to support adding individual rollback rules util: check for 0 args when applying iptables rule util: implement rollback rule autosave for iptables backend util: implement rollback rule autosave for nftables backend network: turn on auto-rollback for the rules added for virtual networks util: new function virFirewallNewFromRollback() util: new functions virFirewallParseXML() and virFirewallFormat() conf: add a virFirewall object to virNetworkObj network: use previously saved list of firewall rules when removing network: save network status when firewall rules are reloaded network: improve log message when reloading virtual network firewall rules libvirt.spec.in | 5 + meson.build | 1 + po/POTFILES | 2 + src/conf/virnetworkobj.c | 40 + src/conf/virnetworkobj.h | 11 + src/libvirt_private.syms | 68 +- src/network/bridge_driver.c | 40 +- src/network/bridge_driver_conf.c | 44 + src/network/bridge_driver_conf.h | 3 + src/network/bridge_driver_linux.c | 241 +++-- src/network/bridge_driver_nop.c | 6 +- src/network/bridge_driver_platform.h | 6 +- src/network/libvirtd_network.aug | 39 + src/network/meson.build | 11 + src/network/network.conf | 24 + src/network/test_libvirtd_network.aug.in | 5 + src/nwfilter/nwfilter_ebiptables_driver.c | 16 +- src/util/meson.build | 2 + src/util/virebtables.c | 4 +- src/util/virfirewall.c | 490 ++++++++-- src/util/virfirewall.h | 51 +- src/util/viriptables.c | 762 ++++----------- src/util/viriptables.h | 222 ++--- src/util/virnetfilter.c | 892 ++++++++++++++++++ src/util/virnetfilter.h | 159 ++++ src/util/virnftables.c | 698 ++++++++++++++ src/util/virnftables.h | 118 +++ .../{base.args => base.iptables} | 0 tests/networkxml2firewalldata/base.nftables | 256 +++++ ...-linux.args => nat-default-linux.iptables} | 0 .../nat-default-linux.nftables | 248 +++++ ...pv6-linux.args => nat-ipv6-linux.iptables} | 0 .../nat-ipv6-linux.nftables | 384 ++++++++ ...rgs => nat-ipv6-masquerade-linux.iptables} | 0 .../nat-ipv6-masquerade-linux.nftables | 456 +++++++++ ...linux.args => nat-many-ips-linux.iptables} | 0 .../nat-many-ips-linux.nftables | 472 +++++++++ ...-linux.args => nat-no-dhcp-linux.iptables} | 0 .../nat-no-dhcp-linux.nftables | 384 ++++++++ ...ftp-linux.args => nat-tftp-linux.iptables} | 0 .../nat-tftp-linux.nftables | 274 ++++++ ...inux.args => route-default-linux.iptables} | 0 .../route-default-linux.nftables | 162 ++++ tests/networkxml2firewalltest.c | 56 +- tests/virfirewalltest.c | 20 +- 45 files changed, 5718 insertions(+), 954 deletions(-) create mode 100644 src/network/libvirtd_network.aug create mode 100644 src/network/network.conf create mode 100644 src/network/test_libvirtd_network.aug.in create mode 100644 src/util/virnetfilter.c create mode 100644 src/util/virnetfilter.h create mode 100644 src/util/virnftables.c create mode 100644 src/util/virnftables.h rename tests/networkxml2firewalldata/{base.args => base.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/base.nftables rename tests/networkxml2firewalldata/{nat-default-linux.args => nat-default-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-default-linux.nftables rename tests/networkxml2firewalldata/{nat-ipv6-linux.args => nat-ipv6-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-ipv6-linux.nftables rename tests/networkxml2firewalldata/{nat-ipv6-masquerade-linux.args => nat-ipv6-masquerade-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-ipv6-masquerade-linux.nftables rename tests/networkxml2firewalldata/{nat-many-ips-linux.args => nat-many-ips-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-many-ips-linux.nftables rename tests/networkxml2firewalldata/{nat-no-dhcp-linux.args => nat-no-dhcp-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-no-dhcp-linux.nftables rename tests/networkxml2firewalldata/{nat-tftp-linux.args => nat-tftp-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/nat-tftp-linux.nftables rename tests/networkxml2firewalldata/{route-default-linux.args => route-default-linux.iptables} (100%) create mode 100644 tests/networkxml2firewalldata/route-default-linux.nftables -- 2.39.2

7 78

[PATCH] Extend libvirt-guests to shutdown only persistent VMs
by Benjamin Taubmann 04 Apr '24

04 Apr '24

At the moment, there is no configuration option for the libvirt-guests service that allows users to define that only persistent virtual machines should be shutdown on host shutdown. Currently, the service config allows to choose between two ON_SHUTDOWN actions that are executed on running virtual machines when the host goes down: shutdown, suspend. The ON_SHUTDOWN action should be orthogonal to the type of the virtual machine. However, the existing implementation, does not suspend transient virtual machines. This is the matrix of actions that is executed on virtual machines based on the configured ON_SHUTDOWN action and the type of a virtual machine. | persistent | transient shutdown | shutdown | shutdown (what we want to change) suspend | suspend | nothing Add config option PERSISTENT_ONLY to libvirt-guests config that allows users to define if the ON_SHUTDOWN action should be applied only on persistent virtual machines. PERSISTENT_ONLY can be set to true, false, default. The default option will implement the already existing logic. Case 1: PERSISTENT_ONLY=default | persistent | transient shutdown | shutdown | shutdown suspend | suspend | nothing Case 2: PERSISTENT_ONLY=true | persistent | transient shutdown | shutdown | nothing suspend | suspend | nothing Case 3: PERSISTENT_ONLY=false | persistent | transient shutdown | shutdown | shutdown suspend | suspend | suspend Change-Id: Ib03013d00b3ec60716287dad4743a038cf000763 --- tools/libvirt-guests.sh.in | 37 ++++++++++++++++++++++++++++++------- 1 file changed, 30 insertions(+), 7 deletions(-) diff --git a/tools/libvirt-guests.sh.in b/tools/libvirt-guests.sh.in index 344b54390a..c3c5954e17 100644 --- a/tools/libvirt-guests.sh.in +++ b/tools/libvirt-guests.sh.in @@ -38,6 +38,7 @@ PARALLEL_SHUTDOWN=0 START_DELAY=0 BYPASS_CACHE=0 SYNC_TIME=0 +PERSISTENT_ONLY="default" test -f "$initconfdir"/libvirt-guests && . "$initconfdir"/libvirt-guests @@ -438,14 +439,16 @@ shutdown_guests_parallel() # stop # Shutdown or save guests on the configured uris stop() { - local suspending="true" local uri= + local action="suspend" + local persistent_only="default" + # last stop was not followed by start [ -f "$LISTFILE" ] && return 0 if [ "x$ON_SHUTDOWN" = xshutdown ]; then - suspending="false" + action="shutdown" if [ $SHUTDOWN_TIMEOUT -lt 0 ]; then gettext "SHUTDOWN_TIMEOUT must be equal or greater than 0" echo @@ -454,6 +457,22 @@ stop() { fi fi + case "x$PERSISTENT_ONLY" in + xtrue) + persistent_only="true" + ;; + xfalse) + persistent_only="false" + ;; + *) + if [ "x$action" = xshutdown ]; then + persistent_only="false" + elif [ "x$action" = xsuspend ]; then + persistent_only="true" + fi + ;; + esac + : >"$LISTFILE" set -f for uri in $URIS; do @@ -478,7 +497,7 @@ stop() { echo fi - if "$suspending"; then + if "$persistent_only"; then local transient="$(list_guests "$uri" "--transient")" if [ $? -eq 0 ]; then local empty="true" @@ -486,7 +505,11 @@ stop() { for uuid in $transient; do if "$empty"; then - eval_gettext "Not suspending transient guests on URI: \$uri: " + if [ "x$action" = xsuspend ]; then + eval_gettext "Not suspending transient guests on URI: \$uri: " + else + eval_gettext "Not shutting down transient guests on URI: \$uri: " + fi empty="false" else printf ", " @@ -520,19 +543,19 @@ stop() { if [ -s "$LISTFILE" ]; then while read uri list; do - if "$suspending"; then + if [ "x$action" = xsuspend ]; then eval_gettext "Suspending guests on \$uri URI..."; echo else eval_gettext "Shutting down guests on \$uri URI..."; echo fi if [ "$PARALLEL_SHUTDOWN" -gt 1 ] && - ! "$suspending"; then + [ "x$action" = xshutdown ]; then shutdown_guests_parallel "$uri" "$list" else local guest= for guest in $list; do - if "$suspending"; then + if [ "x$action" = xsuspend ]; then suspend_guest "$uri" "$guest" else shutdown_guest "$uri" "$guest" -- 2.39.2

4 5

[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/7] qemu XML testing improvements, part 3 - xmlout->xmlout testing and fixes
by Peter Krempa 19 Mar '24

19 Mar '24

This series depends on the 'part 2' with cover letter's subject: [PATCH 00/23] qemu XML testing improvements, part 2 - enforcement of xml->xml testing both this along with the rebased prerequisite series can be fetched from: git fetch https://gitlab.com/pipo.sk/libvirt.git test-improvements-3 The main goal of part 3 is to add testing based on parsing of the libvirt-formatted files from tests/qemuxml2xmloutdata and formatting them back, and checking that they are identical. By adding this testing multiple problems in code auto-adding information was discovered. Peter Krempa (7): virDomainDefMaybeAddVirtioSerialController: Reformat hard to read linebreaks conf: domain: Insert auto-added controllers in same order as in XML parser virDomainAssignControllerIndexes: Ensure controller ordering after assigning indexes qemu: Move 'shmem' device size validation to qemu_validate qemuDomainAssignPCIAddresses: Assign extension addresses when auto-assigning PCI address virDomainDefAddConsoleCompat: Fix numbering of console targets after modification qemuxml2conftest: Test re-parsing of formatted XML src/conf/domain_conf.c | 26 ++++++++++--- src/conf/domain_postparse.c | 21 ++++++++++ src/qemu/qemu_command.c | 19 ---------- src/qemu/qemu_domain_address.c | 14 +++++-- src/qemu/qemu_validate.c | 9 +++++ .../autoindex.x86_64-latest.args | 4 +- .../channel-virtio-default.x86_64-latest.args | 2 +- .../channel-virtio-unix.x86_64-latest.args | 2 +- .../chardev-reconnect.x86_64-latest.args | 2 +- .../pci-autoadd-idx.x86_64-latest.args | 16 ++++---- .../pseries-many-buses-2.ppc64-latest.args | 4 +- .../shmem-invalid-size.x86_64-latest.err | 2 +- .../shmem-small-size.x86_64-latest.err | 2 +- .../aarch64-virt-graphics.aarch64-latest.xml | 6 +-- .../aarch64-virt-headless.aarch64-latest.xml | 6 +-- .../aarch64-virt-virtio.aarch64-4.2.0.xml | 6 +-- .../aarch64-virt-virtio.aarch64-latest.xml | 6 +-- ...rch64-virtio-pci-default.aarch64-4.2.0.xml | 6 +-- ...ch64-virtio-pci-default.aarch64-latest.xml | 6 +-- ...io-pci-manual-addresses.aarch64-latest.xml | 6 +-- .../arm-virt-virtio.aarch64-latest.xml | 6 +-- .../autoindex.x86_64-latest.xml | 12 +++--- .../channel-virtio-auto.x86_64-latest.xml | 2 +- .../channel-virtio-autoadd.x86_64-latest.xml | 2 +- .../channel-virtio-default.x86_64-latest.xml | 6 +-- .../channel-virtio-unix.x86_64-latest.xml | 6 +-- .../chardev-reconnect.x86_64-latest.xml | 6 +-- .../console-compat2.x86_64-latest.xml | 2 +- .../cpu-host-model-kvm.x86_64-4.2.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-5.0.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-5.1.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-5.2.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-6.0.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-6.1.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-6.2.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-7.0.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-7.1.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-7.2.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-8.0.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-8.1.0.xml | 12 +++--- .../cpu-host-model-kvm.x86_64-latest.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-4.2.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-5.0.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-5.1.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-5.2.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-6.0.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-6.1.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-6.2.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-7.0.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-7.1.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-7.2.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-8.0.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-8.1.0.xml | 12 +++--- .../cpu-host-model-tcg.x86_64-latest.xml | 12 +++--- .../disk-floppy-q35.x86_64-latest.xml | 8 ++-- ...dev-scsi-autogen-address.x86_64-latest.xml | 6 +-- ...tdev-vfio-zpci-boundaries.s390x-latest.xml | 4 +- ...f-aarch64-virt-headless.aarch64-latest.xml | 6 +-- .../hvf-x86_64-q35-headless.x86_64-latest.xml | 6 +-- ...ach-virt-console-virtio.aarch64-latest.xml | 6 +-- .../net-isolated-port.x86_64-latest.xml | 12 +++--- .../pci-autoadd-idx.x86_64-latest.xml | 22 +++++------ .../pcie-expander-bus.x86_64-latest.xml | 10 ++--- .../pcie-root.x86_64-latest.xml | 12 +++--- ...cie-switch-upstream-port.x86_64-latest.xml | 10 ++--- .../pcihole64-q35.x86_64-latest.xml | 12 +++--- .../pseries-many-buses-2.ppc64-latest.xml | 6 +-- ...eries-phb-default-missing.ppc64-latest.xml | 8 ++-- .../qemuxml2xmloutdata/q35.x86_64-latest.xml | 12 +++--- .../riscv64-virt-graphics.riscv64-latest.xml | 6 +-- .../riscv64-virt-headless.riscv64-latest.xml | 6 +-- .../shmem-invalid-size.x86_64-latest.xml | 34 ----------------- .../shmem-small-size.x86_64-latest.xml | 34 ----------------- .../user-aliases2.x86_64-latest.xml | 8 ++-- .../watchdog-q35-multiple.x86_64-latest.xml | 12 +++--- .../x86_64-q35-graphics.x86_64-latest.xml | 6 +-- .../x86_64-q35-headless.x86_64-latest.xml | 6 +-- tests/qemuxmlconftest.c | 38 ++++++++++++++++++- 78 files changed, 405 insertions(+), 404 deletions(-) delete mode 100644 tests/qemuxml2xmloutdata/shmem-invalid-size.x86_64-latest.xml delete mode 100644 tests/qemuxml2xmloutdata/shmem-small-size.x86_64-latest.xml -- 2.43.0

3 10

[libvirt PATCH 00/12] Add vmx-* features from qemu
by Tim Wiederhake 15 Mar '24

15 Mar '24

For rationale, see patch 3 (cpu_map: No longer ignore vmx- features in sync_qemu_features_i386.py). Adding features in bunches (one patch per msr index), as this series is adding ~100 features. This also adds cpu features "gds-no" and "amx-complex" and brings libvirt in sync with qemu commit ad6ef0a42e. Tim Wiederhake (12): cpu_map: Add missing feature "gds-no" cpu_map: Add missing feature "amx-complex" cpu_map: No longer ignore vmx- features in sync_qemu_features_i386.py cpu_map: Add missing vmx features from MSR 0x480 cpu_map: Add missing vmx features from MSR 0x485 cpu_map: Add missing vmx features from MSR 0x48B cpu_map: Add missing vmx features from MSR 0x48C cpu_map: Add missing vmx features from MSR 0x48D cpu_map: Add missing vmx features from MSR 0x48E cpu_map: Add missing vmx features from MSR 0x48F cpu_map: Add missing vmx features from MSR 0x490 cpu_map: Add missing vmx features from MSR 0x491 src/cpu_map/sync_qemu_features_i386.py | 2 +- src/cpu_map/x86_features.xml | 295 ++++++++++++++++++ .../x86_64-cpuid-Atom-P5362-enabled.xml | 9 + .../x86_64-cpuid-Atom-P5362-json.xml | 70 +++++ .../x86_64-cpuid-Cooperlake-enabled.xml | 9 + .../x86_64-cpuid-Cooperlake-json.xml | 71 +++++ .../x86_64-cpuid-Core-i7-8550U-enabled.xml | 9 + .../x86_64-cpuid-Core-i7-8550U-json.xml | 68 ++++ ...86_64-cpuid-Xeon-Platinum-9242-enabled.xml | 9 + .../x86_64-cpuid-Xeon-Platinum-9242-json.xml | 71 +++++ ...-cpuid-baseline-Cooperlake+Cascadelake.xml | 71 +++++ .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 68 ++++ tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 68 ++++ .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 68 ++++ tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 68 ++++ .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 1 + .../cpu-host-model.x86_64-4.2.0.args | 2 +- .../cpu-host-model.x86_64-5.0.0.args | 2 +- .../cpu-host-model.x86_64-latest.args | 2 +- 20 files changed, 960 insertions(+), 4 deletions(-) -- 2.39.2

3 19

[PATCH 0/5] multiple memory backend support for CPR Live Updates
by mgalaxy＠akamai.com 06 Mar '24

06 Mar '24

From: Michael Galaxy <mgalaxy(a)akamai.com> CPR-based support for whole-hypervisor kexec-based live updates is making progress on qemu-devel. In support of this, we need NUMA to be support in these kinds of environments. To do this we use a technology called PMEM (persistent memory), which underpin the ability for CPR Live Updates to work so that QEMU memory can remain in RAM and be recovered after the kexec has completed. Our systems are highly NUMA-aware, and so this patch series enables NUMA awareness for live update and also allows live migrations to work. Further, we make a small change that allows live migrations to work between *non* PMEM-based systems and PMEM-based systems (and vice-versa). This allows for seemless upgrades from non-live-compatible systems to live-update-compatible sytems without any downtime. Michael Galaxy (5): qemu.conf changes to support multiple memory backend directories Update cleanup routines to handle multiple memory backing paths instead of just one. Implement multiple memory backing paths Support live migration between file-backed memory and anonymous memory. Update unit test to support multiple memory backends src/qemu/qemu_command.c | 8 ++- src/qemu/qemu_conf.c | 140 ++++++++++++++++++++++++++++++++++++---- src/qemu/qemu_conf.h | 14 ++-- src/qemu/qemu_domain.c | 24 +++++-- src/qemu/qemu_driver.c | 31 +++++---- src/qemu/qemu_hotplug.c | 6 +- src/qemu/qemu_process.c | 45 +++++++------ src/qemu/qemu_process.h | 13 ++-- tests/testutilsqemu.c | 5 +- 9 files changed, 217 insertions(+), 69 deletions(-) -- 2.25.1

4 11

[PATCH 00/10] Subject: [PATCH 00/10] Code cleanup
by Artem Chernyshev 29 Feb '24

29 Feb '24

Several functions was modified to become invariant. Change their type to void and remove unnecessary checks of their return values. Found by Linux Verification Center (linuxtesting.org) with SVACE. Artem Chernyshev (10): conf: domain_conf: virDomainHostdevInsert/virDomainNetInsert to void libxl: libxlMakeDomainCapabilities to void virtime: virTimeMillisNowRaw to void conf: virDomainGraphicsListenAppendAddress() to void conf: virDomainDefMaybeAddInput() to void virbitmap: virBitmapToData() to void tools: cmdDomblkinfoGet() to void vireventglib: virEventRunDefaultImpl() to void vsh: vshCompleterFilter() to void vsh: vshInitDebug() to void examples/c/misc/event-test.c | 5 +- include/libvirt/libvirt-event.h | 2 +- src/ch/ch_monitor.c | 5 +- src/conf/domain_conf.c | 35 +++------- src/conf/domain_conf.h | 8 +-- src/conf/virdomainjob.c | 7 +- src/hypervisor/domain_driver.c | 5 +- src/libxl/libxl_capabilities.c | 40 ++++-------- src/libxl/libxl_capabilities.h | 2 +- src/libxl/libxl_domain.c | 16 ++--- src/libxl/libxl_domain.h | 2 +- src/libxl/libxl_driver.c | 17 ++--- src/libxl/xen_common.c | 25 +++---- src/libxl/xen_common.h | 2 +- src/libxl/xen_xl.c | 3 +- src/lxc/lxc_driver.c | 6 +- src/nwfilter/nwfilter_dhcpsnoop.c | 18 ++--- src/qemu/qemu_agent.c | 6 +- src/qemu/qemu_backup.c | 3 +- src/qemu/qemu_dbus.c | 3 +- src/qemu/qemu_domain.c | 35 ++++------ src/qemu/qemu_domainjob.c | 22 +++---- src/qemu/qemu_domainjob.h | 4 +- src/qemu/qemu_driver.c | 19 +++--- src/qemu/qemu_hotplug.c | 6 +- src/qemu/qemu_migration.c | 4 +- src/qemu/qemu_nbdkit.c | 3 +- src/qemu/qemu_process.c | 12 ++-- src/qemu/qemu_tpm.c | 3 +- src/rpc/virnetdaemon.c | 6 +- src/storage/storage_backend_iscsi_direct.c | 4 +- src/util/virbitmap.c | 6 +- src/util/virbitmap.h | 2 +- src/util/virevent.c | 7 +- src/util/vireventglib.c | 4 +- src/util/vireventglib.h | 2 +- src/util/virfdstream.c | 3 +- src/util/virhostcpu.c | 4 +- src/util/virhostuptime.c | 3 +- src/util/virtime.c | 48 ++++---------- src/util/virtime.h | 14 ++-- src/vbox/vbox_common.c | 4 +- src/vmx/vmx.c | 3 +- src/vz/vz_driver.c | 38 +++++------ src/vz/vz_sdk.c | 14 ++-- src/vz/vz_utils.c | 16 ++--- src/vz/vz_utils.h | 2 +- tests/domaincapstest.c | 3 +- tests/objecteventtest.c | 76 ++++++++++------------ tests/qemucapsprobe.c | 5 +- tests/qemumonitortestutils.c | 8 +-- tests/virbitmaptest.c | 3 +- tests/virnetsockettest.c | 3 +- tools/virsh-completer-domain.c | 6 +- tools/virsh-domain-monitor.c | 10 +-- tools/virsh-domain.c | 15 ++--- tools/vsh.c | 24 +++---- 57 files changed, 231 insertions(+), 420 deletions(-) -- 2.43.0

2 12

[PATCH 0/2] Introduce mshv Hypervisor type.
by Praveen K Paladugu 16 Feb '24

16 Feb '24

These patches introduce 'mshv' hypervisor type and check for the hypervisor device on host while starting ch guests. Praveen K Paladugu (2): conf: Introduce mshv hypervisor type ch: Check for hypervisor while starting guests src/ch/ch_conf.c | 2 ++ src/ch/ch_driver.c | 7 +++++++ src/ch/ch_process.c | 34 ++++++++++++++++++++++++++++++++++ src/conf/domain_conf.c | 1 + src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 1 + 6 files changed, 46 insertions(+) -- 2.43.0

3 11

[PATCH 1/3] qemu: add a 'chain' parameter to nbdkit start/stop
by Jonathon Jongsma 12 Feb '24

12 Feb '24

This will allow us to start or stop nbdkit for just a single disk source or for every source in the backing chain. This will be used in following patches. Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- src/qemu/qemu_extdevice.c | 8 +++--- src/qemu/qemu_hotplug.c | 6 ++--- src/qemu/qemu_nbdkit.c | 51 ++++++++++++++++++++++++++++++--------- src/qemu/qemu_nbdkit.h | 6 +++-- 4 files changed, 51 insertions(+), 20 deletions(-) diff --git a/src/qemu/qemu_extdevice.c b/src/qemu/qemu_extdevice.c index 3cf3867056..ed5976d1f7 100644 --- a/src/qemu/qemu_extdevice.c +++ b/src/qemu/qemu_extdevice.c @@ -234,12 +234,12 @@ qemuExtDevicesStart(virQEMUDriver *driver, for (i = 0; i < def->ndisks; i++) { virDomainDiskDef *disk = def->disks[i]; - if (qemuNbdkitStartStorageSource(driver, vm, disk->src) < 0) + if (qemuNbdkitStartStorageSource(driver, vm, disk->src, true) < 0) return -1; } if (def->os.loader && def->os.loader->nvram) { - if (qemuNbdkitStartStorageSource(driver, vm, def->os.loader->nvram) < 0) + if (qemuNbdkitStartStorageSource(driver, vm, def->os.loader->nvram, true) < 0) return -1; } @@ -297,11 +297,11 @@ qemuExtDevicesStop(virQEMUDriver *driver, for (i = 0; i < def->ndisks; i++) { virDomainDiskDef *disk = def->disks[i]; - qemuNbdkitStopStorageSource(disk->src, vm); + qemuNbdkitStopStorageSource(disk->src, vm, true); } if (def->os.loader && def->os.loader->nvram) - qemuNbdkitStopStorageSource(def->os.loader->nvram, vm); + qemuNbdkitStopStorageSource(def->os.loader->nvram, vm, true); } diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 31b00e05ca..e67673b762 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1018,7 +1018,7 @@ qemuDomainAttachDeviceDiskLiveInternal(virQEMUDriver *driver, if (qemuHotplugAttachManagedPR(vm, disk->src, VIR_ASYNC_JOB_NONE) < 0) goto cleanup; - if (qemuNbdkitStartStorageSource(driver, vm, disk->src) < 0) + if (qemuNbdkitStartStorageSource(driver, vm, disk->src, true) < 0) goto cleanup; } @@ -1045,7 +1045,7 @@ qemuDomainAttachDeviceDiskLiveInternal(virQEMUDriver *driver, if (virStorageSourceChainHasManagedPR(disk->src)) ignore_value(qemuHotplugRemoveManagedPR(vm, VIR_ASYNC_JOB_NONE)); - qemuNbdkitStopStorageSource(disk->src, vm); + qemuNbdkitStopStorageSource(disk->src, vm, true); } qemuDomainSecretDiskDestroy(disk); qemuDomainCleanupStorageSourceFD(disk->src); @@ -4562,7 +4562,7 @@ qemuDomainRemoveDiskDevice(virQEMUDriver *driver, qemuHotplugRemoveManagedPR(vm, VIR_ASYNC_JOB_NONE) < 0) goto cleanup; - qemuNbdkitStopStorageSource(disk->src, vm); + qemuNbdkitStopStorageSource(disk->src, vm, true); if (disk->transient) { VIR_DEBUG("Removing transient overlay '%s' of disk '%s'", diff --git a/src/qemu/qemu_nbdkit.c b/src/qemu/qemu_nbdkit.c index 1c72b6fe6a..39f9c58a48 100644 --- a/src/qemu/qemu_nbdkit.c +++ b/src/qemu/qemu_nbdkit.c @@ -893,18 +893,34 @@ qemuNbdkitInitStorageSource(qemuNbdkitCaps *caps WITHOUT_NBDKIT_UNUSED, } +static int +qemuNbdkitStartStorageSourceOne(virQEMUDriver *driver, + virDomainObj *vm, + virStorageSource *src) +{ + qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(src); + + if (priv && priv->nbdkitProcess && + qemuNbdkitProcessStart(priv->nbdkitProcess, vm, driver) < 0) + return -1; + + return 0; +} + + int qemuNbdkitStartStorageSource(virQEMUDriver *driver, virDomainObj *vm, - virStorageSource *src) + virStorageSource *src, + bool chain) { virStorageSource *backing; - for (backing = src; backing != NULL; backing = backing->backingStore) { - qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(backing); + if (!chain) + return qemuNbdkitStartStorageSourceOne(driver, vm, src); - if (priv && priv->nbdkitProcess && - qemuNbdkitProcessStart(priv->nbdkitProcess, vm, driver) < 0) + for (backing = src; backing != NULL; backing = backing->backingStore) { + if (qemuNbdkitStartStorageSourceOne(driver, vm, backing) < 0) return -1; } @@ -912,18 +928,31 @@ qemuNbdkitStartStorageSource(virQEMUDriver *driver, } +static void +qemuNbdkitStopStorageSourceOne(virStorageSource *src, + virDomainObj *vm) +{ + qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(src); + + if (priv && priv->nbdkitProcess && + qemuNbdkitProcessStop(priv->nbdkitProcess, vm) < 0) + VIR_WARN("Unable to stop nbdkit for storage source '%s'", + qemuBlockStorageSourceGetStorageNodename(src)); +} + + void qemuNbdkitStopStorageSource(virStorageSource *src, - virDomainObj *vm) + virDomainObj *vm, + bool chain) { virStorageSource *backing; - for (backing = src; backing != NULL; backing = backing->backingStore) { - qemuDomainStorageSourcePrivate *priv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(backing); + if (! chain) + return qemuNbdkitStopStorageSourceOne(src, vm); - if (priv && priv->nbdkitProcess && - qemuNbdkitProcessStop(priv->nbdkitProcess, vm) < 0) - VIR_WARN("Unable to stop nbdkit for storage source '%s'", qemuBlockStorageSourceGetStorageNodename(src)); + for (backing = src; backing != NULL; backing = backing->backingStore) { + qemuNbdkitStopStorageSourceOne(backing, vm); } } diff --git a/src/qemu/qemu_nbdkit.h b/src/qemu/qemu_nbdkit.h index 853b2cca6f..637bf962a7 100644 --- a/src/qemu/qemu_nbdkit.h +++ b/src/qemu/qemu_nbdkit.h @@ -63,11 +63,13 @@ qemuNbdkitReconnectStorageSource(virStorageSource *source, int qemuNbdkitStartStorageSource(virQEMUDriver *driver, virDomainObj *vm, - virStorageSource *src); + virStorageSource *src, + bool chain); void qemuNbdkitStopStorageSource(virStorageSource *src, - virDomainObj *vm); + virDomainObj *vm, + bool chain); int qemuNbdkitStorageSourceManageProcess(virStorageSource *src, -- 2.43.0

2 9

[PATCH v2 0/5] Initial network support in ch driver.
by Praveen K Paladugu 02 Feb '24

02 Feb '24

v2: * Refactor virSocketRecvHttpResponse to return responses without parsing http responses. * Use errno to report errors in virsocket.c * Address WIN32 build failure in virsocket.c * Fix code indentations Praveen K Paladugu (5): conf: Drop unused parameter hypervisor: Move domain interface mgmt methods util: Add util methods required by ch networking ch: Introduce version based cap for network support ch: Enable ETHERNET Network mode support po/POTFILES | 3 + src/ch/ch_capabilities.c | 9 + src/ch/ch_capabilities.h | 1 + src/ch/ch_conf.h | 4 + src/ch/ch_domain.c | 41 +++ src/ch/ch_domain.h | 3 + src/ch/ch_interface.c | 100 +++++++ src/ch/ch_interface.h | 35 +++ src/ch/ch_monitor.c | 213 +++++--------- src/ch/ch_monitor.h | 7 +- src/ch/ch_process.c | 166 ++++++++++- src/ch/meson.build | 2 + src/conf/domain_conf.c | 1 - src/conf/domain_conf.h | 3 +- src/hypervisor/domain_interface.c | 457 ++++++++++++++++++++++++++++++ src/hypervisor/domain_interface.h | 45 +++ src/hypervisor/meson.build | 1 + src/libvirt_private.syms | 11 + src/libxl/libxl_domain.c | 2 +- src/libxl/libxl_driver.c | 4 +- src/lxc/lxc_driver.c | 2 +- src/lxc/lxc_process.c | 4 +- src/qemu/qemu_command.c | 8 +- src/qemu/qemu_hotplug.c | 15 +- src/qemu/qemu_interface.c | 339 +--------------------- src/qemu/qemu_interface.h | 11 - src/qemu/qemu_process.c | 72 +---- src/util/virsocket.c | 116 ++++++++ src/util/virsocket.h | 3 + 29 files changed, 1107 insertions(+), 571 deletions(-) create mode 100644 src/ch/ch_interface.c create mode 100644 src/ch/ch_interface.h create mode 100644 src/hypervisor/domain_interface.c create mode 100644 src/hypervisor/domain_interface.h -- 2.43.0

4 11

[PATCH 00/11] nodedev state and update
by Boris Fiuczynski 01 Feb '24

01 Feb '24

The series add a dual state to the mdev node devices as these objects can be active and defined at the same time. These two states can become different. To be able to also introspect the persisted and transient nodedevs filtering is added. To be able to also dump the XML of an inactive state while the node device is active a new option is added. The last three patches add the capability to update a mdev node device. This can be done on the persisted state, on the active state or on both. To support this v1.3.0 of mdevctl is required. Boris Fiuczynski (11): virmdev: prepare type and attributes for dual state node_device: refactor mdev attributes handling node_device: remove unnecessary checks in virNodeDeviceDefFormat nodedev: add an active config to mdev tools: add option inactive to nodedev-dumpxml nodedev: add persisted and transient filter on list tools: add switches persisted and transient to nodedev-list virsh: doc fix on nodedev-list api: add virNodeDeviceUpdate() nodedev: Implement virNodeDeviceUpdateXML virsh: add nodedev-update docs/manpages/virsh.rst | 36 +- include/libvirt/libvirt-nodedev.h | 31 ++ libvirt.spec.in | 2 +- src/access/viraccessperm.c | 1 + src/access/viraccessperm.h | 6 + src/conf/node_device_conf.c | 76 ++-- src/conf/node_device_conf.h | 14 +- src/conf/virnodedeviceobj.c | 50 +++ src/conf/virnodedeviceobj.h | 3 + src/driver-nodedev.h | 6 + src/libvirt-nodedev.c | 47 ++- src/libvirt_private.syms | 1 + src/libvirt_public.syms | 5 + src/node_device/node_device_driver.c | 388 ++++++++++++++---- src/node_device/node_device_driver.h | 17 +- src/node_device/node_device_udev.c | 5 +- src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 17 +- src/remote_protocol-structs | 6 + src/test/test_driver.c | 6 +- src/util/virmdev.h | 6 + tests/nodedevmdevctldata/mdevctl-modify.argv | 19 + tests/nodedevmdevctltest.c | 68 ++- ...v_c60cc60c_c60c_c60c_c60c_c60cc60cc60c.xml | 14 + ...d_b7f0_4fea_b468_f1da537d301b_inactive.xml | 1 + ...v_c60cc60c_c60c_c60c_c60c_c60cc60cc60c.xml | 10 + ...c_c60c_c60c_c60c_c60cc60cc60c_inactive.xml | 9 + ...9_36ea_4111_8f0a_8c9a70e21366_inactive.xml | 1 + ...9_495e_4243_ad9f_beb3f14c23d9_inactive.xml | 1 + ...4_f554_4dc1_809d_b2a01e8e48ad_inactive.xml | 8 + ...6_1ca8_49ac_b176_871d16c13076_inactive.xml | 1 + tests/nodedevxml2xmltest.c | 59 ++- tools/virsh-nodedev.c | 137 ++++++- 33 files changed, 908 insertions(+), 144 deletions(-) create mode 100644 tests/nodedevmdevctldata/mdevctl-modify.argv create mode 100644 tests/nodedevschemadata/mdev_c60cc60c_c60c_c60c_c60c_c60cc60cc60c.xml create mode 120000 tests/nodedevxml2xmlout/mdev_3627463d_b7f0_4fea_b468_f1da537d301b_inactive.xml create mode 100644 tests/nodedevxml2xmlout/mdev_c60cc60c_c60c_c60c_c60c_c60cc60cc60c.xml create mode 100644 tests/nodedevxml2xmlout/mdev_c60cc60c_c60c_c60c_c60c_c60cc60cc60c_inactive.xml create mode 120000 tests/nodedevxml2xmlout/mdev_d069d019_36ea_4111_8f0a_8c9a70e21366_inactive.xml create mode 120000 tests/nodedevxml2xmlout/mdev_d2441d39_495e_4243_ad9f_beb3f14c23d9_inactive.xml create mode 100644 tests/nodedevxml2xmlout/mdev_ee0b88c4_f554_4dc1_809d_b2a01e8e48ad_inactive.xml create mode 120000 tests/nodedevxml2xmlout/mdev_fedc4916_1ca8_49ac_b176_871d16c13076_inactive.xml -- 2.42.0

2 28

[PATCH 00/10] tests: Introduce tool for qemu '.replies' files
by Peter Krempa 31 Jan '24

31 Jan '24

This a much improved version of my first attempt for this tool [1]. This: - replaces tests/qemucapabilitiesnumbering.c - including much simpler approach for programatic modification of the .replies files - adds 'dump' capability to simplify comparing two qemu versions or figuring out query strings for qmp schema [1]: [PATCH] scripts: QMP schema query string helper script Peter Krempa (10): tests: qemucaps: Make JSON output identical to python's 'json.dump' method syntax-check: Exclude 'scripts/*.py' from 'sc_prohibit_magic_number_exit' scripts: Add 'qemu-qmp-replies-tool' script for testing and modifying data for qemucapabilitiestest tests: Remove 'qemucapabilitiesnumbering' test util: json: Remove 'virJSONValueObjectReplaceValue' qemumonitortestutils: Unexport 'qemuMonitorTestProcessFileEntries' qemu-replies-tool: Add validation of known fields in 'query-qmp-schema' qemu-replies-tool: Add mode to dump all QMP schema query strings qemu-replies-tool: Dump 'qom-list-types' qemu-replies-tool: Dump 'device-list-properties' build-aux/syntax-check.mk | 3 + scripts/meson.build | 1 + scripts/qemu-replies-tool.py | 557 ++++++++++++++++++ src/libvirt_private.syms | 1 - src/util/virjson.c | 20 - src/util/virjson.h | 6 - tests/meson.build | 12 +- .../caps_4.2.0_aarch64.replies | 42 +- .../caps_4.2.0_ppc64.replies | 42 +- .../caps_4.2.0_s390x.replies | 297 ++++------ .../caps_4.2.0_x86_64.replies | 363 ++++-------- .../caps_5.0.0_aarch64.replies | 39 +- .../caps_5.0.0_ppc64.replies | 39 +- .../caps_5.0.0_riscv64.replies | 42 +- .../caps_5.0.0_x86_64.replies | 372 ++++-------- .../caps_5.1.0_sparc.replies | 42 +- .../caps_5.1.0_x86_64.replies | 291 +++------ .../caps_5.2.0_aarch64.replies | 39 +- .../caps_5.2.0_ppc64.replies | 39 +- .../caps_5.2.0_riscv64.replies | 42 +- .../caps_5.2.0_s390x.replies | 303 ++++------ .../caps_5.2.0_x86_64.replies | 291 +++------ .../caps_6.0.0_aarch64.replies | 39 +- .../caps_6.0.0_s390x.replies | 303 ++++------ .../caps_6.0.0_x86_64.replies | 291 +++------ .../caps_6.1.0_x86_64.replies | 297 ++++------ .../caps_6.2.0_aarch64.replies | 45 +- .../caps_6.2.0_ppc64.replies | 45 +- .../caps_6.2.0_x86_64.replies | 297 ++++------ .../caps_7.0.0_aarch64+hvf.replies | 45 +- .../caps_7.0.0_aarch64.replies | 45 +- .../caps_7.0.0_ppc64.replies | 45 +- .../caps_7.0.0_x86_64.replies | 297 ++++------ .../caps_7.1.0_ppc64.replies | 45 +- .../caps_7.1.0_x86_64.replies | 297 ++++------ .../caps_7.2.0_ppc.replies | 45 +- .../caps_7.2.0_x86_64+hvf.replies | 297 ++++------ .../caps_7.2.0_x86_64.replies | 297 ++++------ .../caps_8.0.0_riscv64.replies | 36 +- .../caps_8.0.0_x86_64.replies | 297 ++++------ .../caps_8.1.0_s390x.replies | 318 ++++------ .../caps_8.1.0_x86_64.replies | 285 +++------ .../caps_8.2.0_aarch64.replies | 48 +- .../caps_8.2.0_x86_64.replies | 288 +++------ .../caps_9.0.0_x86_64.replies | 288 +++------ tests/qemucapabilitiesnumbering.c | 245 -------- tests/qemucapsprobemock.c | 28 +- tests/qemumonitortestutils.c | 9 +- tests/qemumonitortestutils.h | 13 - 49 files changed, 2796 insertions(+), 4672 deletions(-) create mode 100755 scripts/qemu-replies-tool.py delete mode 100644 tests/qemucapabilitiesnumbering.c -- 2.43.0

3 36

[PATCH 0/3] qemu: Improvements related to MODEL_SCSI_AUTO
by Andrea Bolognani 31 Jan '24

31 Jan '24

Andrea Bolognani (3): tests: Add controller-scsi-auto qemu: Handle MODEL_SCSI_{AUTO,DEFAULT} appropriately qemu: Use virDomainControllerDefNew() more src/qemu/qemu_command.c | 4 +-- src/qemu/qemu_domain_address.c | 4 +-- src/qemu/qemu_hotplug.c | 4 +-- src/qemu/qemu_validate.c | 2 +- .../controller-scsi-auto.x86_64-latest.args | 32 +++++++++++++++++++ .../controller-scsi-auto.x86_64-latest.xml | 30 +++++++++++++++++ .../qemuxmlconfdata/controller-scsi-auto.xml | 15 +++++++++ tests/qemuxmlconftest.c | 1 + 8 files changed, 85 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxmlconfdata/controller-scsi-auto.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/controller-scsi-auto.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/controller-scsi-auto.xml -- 2.43.0

2 4

Re: Re: [PATCH] apparmor: Add user session path for PID and socket files used by passt
by Andrea Bolognani 31 Jan '24

31 Jan '24

On Tue, Jan 30, 2024 at 10:47:54AM -0800, Andrea Bolognani wrote: > On Tue, Jan 30, 2024 at 07:15:51PM +0100, Stefano Brivio wrote: > > Commit 7a39b04d683f ("apparmor: Enable passt support") grants > > passt(1) read-write access to /{,var/}run/libvirt/qemu/passt/* if > > started by the libvirt daemon. That's the path where passt creates > > PID and socket files only if the guest is started by the root user. > > > > If the guest is started by another user, though, the path is more > > commonly /var/run/user/$UID/libvirt/qemu/run/passt: add it as > > read-write location. Otherwise, passt won't be able to start, as > > reported by Andreas. > > > > While at it, replace /{,var/}run/ in the existing rule by its > > corresponding tunable variable, @{run}. > > > > Reported-by: Andreas B. Mundt <andi(a)debian.org> > > Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061678 > > Fixes: 7a39b04d683f ("apparmor: Enable passt support") > > Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> > > --- > > src/security/apparmor/libvirt-qemu.in | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/src/security/apparmor/libvirt-qemu.in b/src/security/apparmor/libvirt-qemu.in > > index f40f471891..8b92915281 100644 > > --- a/src/security/apparmor/libvirt-qemu.in > > +++ b/src/security/apparmor/libvirt-qemu.in > > @@ -196,7 +196,8 @@ > > signal (receive) set=("term") peer=libvirtd, > > signal (receive) set=("term") peer=virtqemud, > > > > - owner /{,var/}run/libvirt/qemu/passt/* rw, > > + owner @{run}/user/[0-9]*/libvirt/qemu/run/passt/* rw, > > + owner @{run}/libvirt/qemu/passt/* rw, > > Makes sense to me, so > > Reviewed-by: Andrea Bolognani <abologna(a)redhat.com> > > I'll give Jim and others a chance to take a look before pushing. I just realized that you sent the patch to the old mailing list address. We've migrated somewhat recently, so that's completely understandable :) I've adjusted the recipient now. I don't think it's necessary for you to post the patch again, as its contents are fully contained within the quoted part of this message. -- Andrea Bolognani / Red Hat / Virtualization

2 2

[PATCH 00/31] pci vpd: Fix broken XML formatter and refactor questionable error reporting
by Peter Krempa 31 Jan '24

31 Jan '24

The first part of the series fixes the XML formatter of nodedevs to not generate invalid XML if a PCI device custom field contains '>' which would be printed unescaped The rest fixes questionable and broken error reporting from the pci vpd device code which actually parses the above data. https://gitlab.com/pipo.sk/libvirt/-/pipelines/1157912774 Peter Krempa (31): virPCIVPDResourceIsValidTextValue: Adjust comment to reflect actual code util: pcivpd: Refactor virPCIVPDResourceIsValidTextValue virNodeDeviceCapVPDFormatCustom*: Escape unsanitized strings virNodeDeviceCapVPDFormat: Properly escape system-originated strings schema: nodedev: Adjust allowed characters in 'vpdFieldValueFormat' tests: Test the previously mishandled PCI VPD characters Don't overwrite error message from 'virXPathNodeSet' tests: virpcivpdtest: Remove 'testVirPCIVPDReadVPDBytes' case util: virpcivpd: Unexport 'virPCIVPDReadVPDBytes' util: pcivpd: Unexport virPCIVPDParseVPDLargeResourceFields tests: virpcivpd: Remove 'testVirPCIVPDParseVPDStringResource' case util: virpcivpd: Unexport 'virPCIVPDParseVPDLargeResourceString' virPCIVPDResourceGetKeywordPrefix: Fix logging util: virpcivpd: Remove return value from virPCIVPDResourceCustomUpsertValue conf: virNodeDeviceCapVPDParse*: Remove pointless NULL checks virpcivpdtest: testPCIVPDResourceBasic: Remove tests for uninitialized 'ro'/'rw' section util: virPCIVPDResourceUpdateKeyword: Remove impossible checks conf: node_device: Refactor 'virNodeDeviceCapVPDParseCustomFields' to fix error reporting virNodeDeviceCapVPDParseXML: Fix error reporting util: virpcivpd: Remove return value from virPCIVPDResourceUpdateKeyword virPCIDeviceHasVPD: Refactor "debug" messages virPCIDeviceGetVPD: Fix multiple error handling bugs virPCIDeviceGetVPD: Handle errors in callers virPCIVPDReadVPDBytes: Refactor error handling virPCIVPDParseVPDLargeResourceString: Properly report errors virPCIVPDParseVPDLargeResourceFields: Merge logic conditions virPCIVPDParseVPDLargeResourceFields: Remove impossible 'default' swithch case virPCIVPDParseVPDLargeResourceFields: Refactor processing of read data virPCIVPDParseVPDLargeResourceFields: Refactor return logic virPCIVPDParseVPDLargeResourceFields: Report proper errors virPCIVPDParse: Do reasonable error reporting src/conf/domain_conf.c | 78 +-- src/conf/network_conf.c | 80 +-- src/conf/node_device_conf.c | 177 +++---- src/conf/numa_conf.c | 15 +- src/conf/schemas/nodedev.rng | 2 +- src/cpu/cpu_ppc64.c | 5 +- src/libvirt_private.syms | 3 - src/qemu/qemu_capabilities.c | 30 +- src/qemu/qemu_domain.c | 23 +- src/qemu/qemu_migration_cookie.c | 5 +- src/qemu/qemu_nbdkit.c | 5 +- src/util/virpci.c | 34 +- src/util/virpcivpd.c | 454 ++++++++---------- src/util/virpcivpd.h | 8 +- src/util/virpcivpdpriv.h | 11 +- src/vz/vz_sdk.c | 5 +- .../pci_0000_42_00_0_vpd.xml | 4 +- tests/virpcimock.c | 4 +- tests/virpcitest.c | 3 +- tests/virpcivpdtest.c | 160 +----- 20 files changed, 386 insertions(+), 720 deletions(-) -- 2.43.0

2 39

[PATCH v2] meson: Adjust -fstack-protector use
by Andrea Bolognani 31 Jan '24

31 Jan '24

Back in 2014, -fstack-protector was reported not to work on aarch64, so fe881ae086ec disabled it on that target. OS-wise, its use is currently limited to just Linux, FreeBSD and Windows. Looking at the situation today, it seems that whatever issue was affecting aarch64 a decade ago has been resolved; moreover, macOS can also use the feature these days. I haven't checked any of the other BSDs, but since the feature works on FreeBSD it's pretty safe to the assume that they can use it too. If we get reports that it's not the case, we can always further restrict its usage accordingly. Best viewed with 'git show -w'. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/1157984478 Changes from [v1]: * drop alpha-specific exception. [v1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/R5C5… meson.build | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-) diff --git a/meson.build b/meson.build index 611cc582c0..e1c70fce92 100644 --- a/meson.build +++ b/meson.build @@ -442,22 +442,17 @@ supported_cc_flags = [] if get_option('warning_level') == '2' supported_cc_flags = cc.get_supported_arguments(cc_flags) - # on aarch64 error: -fstack-protector not supported for this target - if host_machine.cpu_family() != 'aarch64' - if host_machine.system() in [ 'linux', 'freebsd', 'windows' ] - # we prefer -fstack-protector-strong but fallback to -fstack-protector-all - fstack_cflags = cc.first_supported_argument([ - '-fstack-protector-strong', - '-fstack-protector-all', - ]) - supported_cc_flags += fstack_cflags - - # When building with mingw using -fstack-protector requires libssp library - # which is included by using -fstack-protector with linker. - if fstack_cflags.length() == 1 and host_machine.system() == 'windows' - add_project_link_arguments(fstack_cflags, language: 'c') - endif - endif + # we prefer -fstack-protector-strong but fallback to -fstack-protector-all + fstack_cflags = cc.first_supported_argument([ + '-fstack-protector-strong', + '-fstack-protector-all', + ]) + supported_cc_flags += fstack_cflags + + # When building with mingw using -fstack-protector requires libssp library + # which is included by using -fstack-protector with linker. + if fstack_cflags.length() == 1 and host_machine.system() == 'windows' + add_project_link_arguments(fstack_cflags, language: 'c') endif if supported_cc_flags.contains('-Wlogical-op') -- 2.43.0

2 1

[PATCH] scripts: Make check-symfile.py work on alpha
by Andrea Bolognani 30 Jan '24

30 Jan '24

The script expects each of the symbols that it looks for to be in one of three sections, which in nm(1) are described as follows: T - The symbol is in the text (code) section. B - The symbol is in the BSS data section. This section typically contains zero-initialized or uninitialized data, although the exact behavior is system dependent. D - The symbol is in the initialized data section. When building on alpha, however, some of the symbols show up in one of two additional sections, specifically: S - The symbol is in an uninitialized or zero-initialized data section for small objects. G - The symbol is in an initialized data section for small objects. In other words, S is the same as B and G is the same as D, except with some optimization for small objects that for some reason is applied on alpha but not on other architectures. I have confirmed that, for all the symbols that the script complained about being missing on alpha, the section is the expected one, that is, symbols that are reported as B on x86 are reported as S on alpha, and symbols that are reported as D on x86 are reported as G on alpha. Note that, while the B section doesn't seem to be used at all on alpha, at least in our case, the D section still is. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- scripts/check-symfile.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/check-symfile.py b/scripts/check-symfile.py index 0f6e780df0..c2ee405118 100755 --- a/scripts/check-symfile.py +++ b/scripts/check-symfile.py @@ -61,7 +61,7 @@ for elflib in elflibs: for line in nm: line = line.decode("utf-8") - symmatch = re.search(r'''^\S+\s(?:[TBD])\s(\S+)\s*$''', line) + symmatch = re.search(r'''^\S+\s(?:[TBSDG])\s(\S+)\s*$''', line) if symmatch is None: continue -- 2.43.0

4 10

[libvirt PATCH 0/2] don't require disk-only flag when creating external snapshots
by Pavel Hrdina 30 Jan '24

30 Jan '24

Pavel Hrdina (2): qemu_snapshot: create: refactor external snapshot detection qemu_snapshot: create: don't require disk-only flag for offline external snapshot src/qemu/qemu_snapshot.c | 44 ++++++++++++++++++++++++++++++++-------- 1 file changed, 35 insertions(+), 9 deletions(-) -- 2.43.0

2 4

[libvirt PATCH] qemu_snapshot: fix detection if non-leaf snapshot isn't in active chain
by Pavel Hrdina 30 Jan '24

30 Jan '24

The condition was completely wrong. As per the comment for function virDomainMomentIsAncestor() it checks that the first argument is descendant of the second argument. Consider the following snapshot tree for VM: s1 | +- s2 | | | +- s3 | +- s4 | +- s5 (current) When deleting s2 with the original code we checked if virDomainMomentIsAncestor(s2, s5) which would return false basically for any snapshot as s5 is leaf snapshot so no children. When deleting s2 with fixed code we check if virDomainMomentIsAncestor(s5, s2) which still returns false but when deleting s4 it will correctly return true. Resolves: https://issues.redhat.com/browse/RHEL-23212 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_snapshot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_snapshot.c b/src/qemu/qemu_snapshot.c index 73ff533827..af5f995b0d 100644 --- a/src/qemu/qemu_snapshot.c +++ b/src/qemu/qemu_snapshot.c @@ -3815,7 +3815,7 @@ qemuSnapshotDeleteValidate(virDomainObj *vm, } if (snap != current && snap->nchildren != 0 && - virDomainMomentIsAncestor(snap, current)) { + !virDomainMomentIsAncestor(current, snap)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("deletion of non-leaf external snapshot that is not in active chain is not supported")); return -1; -- 2.43.0

2 1

[PATCH] ch_driver: fix condition in virCHDomainRemoveInactive()
by Purna Pavan Chandra Aekkaladevi 30 Jan '24

30 Jan '24

Rectify the condition to remove a domain only if it is not persistent. Signed-off-by: Purna Pavan Chandra Aekkaladevi <paekkaladevi(a)linux.microsoft.com> --- src/ch/ch_domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ch/ch_domain.c b/src/ch/ch_domain.c index c0d6c75b1d..2f3fae6758 100644 --- a/src/ch/ch_domain.c +++ b/src/ch/ch_domain.c @@ -36,7 +36,7 @@ void virCHDomainRemoveInactive(virCHDriver *driver, virDomainObj *vm) { - if (vm->persistent) { + if (!vm->persistent) { virDomainObjListRemove(driver->domains, vm); } } -- 2.34.1

3 2

[libvirt PATCH V2 0/4] add loongarch support for libvirt
by Xianglai Li 30 Jan '24

30 Jan '24

Hello, Everyone: This patch series adds libvirt support for loongarch.Although the bios path and name has not been officially integrated into qemu and we think there are still many shortcomings, we try to push a version of patch to the community according to the opinions of the community, hoping to listen to everyone's opinions. Anyway we have a version of libvirt that supports loongarch. You can also get libvirt's 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 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 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 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 Config some capabilities for loongarch virt machine 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 | 80 + src/cpu/cpu_loongarch.h | 25 + src/cpu/meson.build | 1 + src/qemu/qemu_capabilities.c | 12 +- src/qemu/qemu_domain.c | 33 +- src/qemu/qemu_domain.h | 1 + src/util/virarch.c | 4 + src/util/virarch.h | 4 + src/util/virhostcpu.c | 7 +- src/util/virsysinfo.c | 3 +- .../qemu_8.2.0-tcg-virt.loongarch64.xml | 163 + .../qemu_8.2.0-virt.loongarch64.xml | 167 + tests/domaincapstest.c | 13 + .../caps_8.2.0_loongarch64.replies | 30140 ++++++++++++++++ .../caps_8.2.0_loongarch64.xml | 175 + .../qemucaps2xmloutdata/caps.loongarch64.xml | 28 + ...o-type-loongarch64.loongarch64-latest.args | 34 + .../default-video-type-loongarch64.xml | 18 + ...ch64-virt-graphics.loongarch64-latest.args | 56 + .../loongarch64-virt-graphics.xml | 48 + ...ch64-virt-headless.loongarch64-latest.args | 52 + .../loongarch64-virt-headless.xml | 42 + ...ongarch64-virt-pci.loongarch64-latest.args | 39 + .../qemuxml2argvdata/loongarch64-virt-pci.xml | 27 + .../loongarch64-virt.loongarch64-latest.args | 44 + tests/qemuxml2argvdata/loongarch64-virt.xml | 22 + tests/qemuxml2argvtest.c | 9 + ...eo-type-loongarch64.loongarch64-latest.xml | 45 + ...rch64-virt-graphics.loongarch64-latest.xml | 114 + ...rch64-virt-headless.loongarch64-latest.xml | 100 + ...oongarch64-virt-pci.loongarch64-latest.xml | 48 + .../loongarch64-virt.loongarch64-latest.xml | 66 + tests/qemuxml2xmltest.c | 6 + tests/testutilshostcpus.h | 10 + 36 files changed, 31633 insertions(+), 6 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/qemuxml2argvdata/default-video-type-loongarch64.loongarch64-latest.args create mode 100644 tests/qemuxml2argvdata/default-video-type-loongarch64.xml create mode 100644 tests/qemuxml2argvdata/loongarch64-virt-graphics.loongarch64-latest.args create mode 100644 tests/qemuxml2argvdata/loongarch64-virt-graphics.xml create mode 100644 tests/qemuxml2argvdata/loongarch64-virt-headless.loongarch64-latest.args create mode 100644 tests/qemuxml2argvdata/loongarch64-virt-headless.xml create mode 100644 tests/qemuxml2argvdata/loongarch64-virt-pci.loongarch64-latest.args create mode 100644 tests/qemuxml2argvdata/loongarch64-virt-pci.xml create mode 100644 tests/qemuxml2argvdata/loongarch64-virt.loongarch64-latest.args create mode 100644 tests/qemuxml2argvdata/loongarch64-virt.xml create mode 100644 tests/qemuxml2xmloutdata/default-video-type-loongarch64.loongarch64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/loongarch64-virt-graphics.loongarch64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/loongarch64-virt-headless.loongarch64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/loongarch64-virt-pci.loongarch64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/loongarch64-virt.loongarch64-latest.xml -- 2.39.1

4 25