- Devel - libvirt List Archives

[PATCH] libxl: Improve reporting of die_id in capabilities
by Jim Fehlig 14 Sep '21

14 Sep '21

On Xen, libvirt runs in a VM (typically dom0) and does not have an accurate picture of numa and cpu topology of the underlying physical machine using the "usual" mechanisms. numa info and cpu toplogy are retrieved from libxl and used to populate the libvirt conterparts. Commit 7b79ee2f78b introduced support for reporting die_id in capabilities, but did not account for special handling of numa and cpu topology in libxl. Currently, Xen does not report die_id in the libxl_cputopology structure. In the meantime, set die_id to 0, which was suggested by the Xen developers and is slightly better than random garbage such as <cpu id='1' socket_id='0' die_id='-1073069552' core_id='0' siblings='0-1'/> Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/libxl/libxl_capabilities.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/libxl/libxl_capabilities.c b/src/libxl/libxl_capabilities.c index b4bd1d7e62..4afed71436 100644 --- a/src/libxl/libxl_capabilities.c +++ b/src/libxl/libxl_capabilities.c @@ -292,6 +292,8 @@ libxlCapsInitNuma(libxl_ctx *ctx, virCaps *caps) cpus[node][nr_cpus_node[node]-1].id = i; cpus[node][nr_cpus_node[node]-1].socket_id = cpu_topo[i].socket; cpus[node][nr_cpus_node[node]-1].core_id = cpu_topo[i].core; + /* Until Xen reports die_id, 0 is better than random garbage */ + cpus[node][nr_cpus_node[node]-1].die_id = 0; /* Allocate the siblings maps. We will be filling them later */ cpus[node][nr_cpus_node[node]-1].siblings = virBitmapNew(nr_cpus); } -- 2.33.0

2 1

[PATCH v4 for v7.6.0 00/14] Introduce virtio-mem <memory/> model
by Michal Privoznik 13 Sep '21

13 Sep '21

v4 of: https://listman.redhat.com/archives/libvir-list/2021-April/msg01138.html diff to v3: - Rebased code on the top of master - Tried to work in all Peter's review suggestions - Fixed a bug where adjusting <requested/> was viewed as hotplug of new <memory/> by XML validator and thus if <maxMemory/> was close enough to <currentMemory/> the validator reported an error (this was reported by David). You can also find these patches on my branch: https://gitlab.com/MichalPrivoznik/libvirt/-/tree/virtio_mem_v4 Michal Prívozník (14): virhostmem: Introduce virHostMemGetTHPSize() qemu_capabilities: Introduce QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI conf: Introduce virtio-mem <memory/> model qemu: Build command line for virtio-mem qemu: Wire up <memory/> live update Introduce <actual/> property to virtio-mem conf: Introduce virDomainMemoryFindByDeviceAlias() qemu: Wire up MEMORY_DEVICE_SIZE_CHANGE event qemu: Refresh the actual size of virtio-mem on monitor reconnect qemu: Account for both memballoon and virtio-mem qemuDomainSetMemoryFlags: Take virtio-mem into consideration virsh: Introduce update-memory-device command news: document recent virtio memory addition kbase: Document virtio-mem NEWS.rst | 12 + docs/formatdomain.rst | 45 +++- docs/kbase/index.rst | 4 + docs/kbase/memorydevices.rst | 150 +++++++++++ docs/kbase/meson.build | 1 + docs/manpages/virsh.rst | 30 +++ docs/schemas/domaincommon.rng | 16 ++ examples/c/misc/event-test.c | 17 ++ include/libvirt/libvirt-domain.h | 23 ++ src/conf/domain_conf.c | 118 ++++++++- src/conf/domain_conf.h | 15 ++ src/conf/domain_event.c | 84 ++++++ src/conf/domain_event.h | 10 + src/conf/domain_validate.c | 39 +++ src/libvirt_private.syms | 5 + src/qemu/qemu_alias.c | 10 +- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 13 +- src/qemu/qemu_domain.c | 33 ++- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_domain_address.c | 38 ++- src/qemu/qemu_driver.c | 240 +++++++++++++++++- src/qemu/qemu_hotplug.c | 18 ++ src/qemu/qemu_hotplug.h | 5 + src/qemu/qemu_monitor.c | 37 +++ src/qemu/qemu_monitor.h | 28 ++ src/qemu/qemu_monitor_json.c | 97 +++++-- src/qemu/qemu_monitor_json.h | 5 + src/qemu/qemu_process.c | 72 ++++++ src/qemu/qemu_validate.c | 8 + src/remote/remote_daemon_dispatch.c | 30 +++ src/remote/remote_driver.c | 32 +++ src/remote/remote_protocol.x | 14 +- src/remote_protocol-structs | 7 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 2 + src/security/security_selinux.c | 2 + src/util/virhostmem.c | 54 ++++ src/util/virhostmem.h | 3 + tests/domaincapsmock.c | 9 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + ...mory-hotplug-virtio-mem.x86_64-latest.args | 41 +++ .../memory-hotplug-virtio-mem.xml | 67 +++++ tests/qemuxml2argvtest.c | 1 + ...emory-hotplug-virtio-mem.x86_64-latest.xml | 1 + tests/qemuxml2xmltest.c | 1 + tools/virsh-domain.c | 169 ++++++++++++ 51 files changed, 1562 insertions(+), 53 deletions(-) create mode 100644 docs/kbase/memorydevices.rst create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-mem.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-mem.xml create mode 120000 tests/qemuxml2xmloutdata/memory-hotplug-virtio-mem.x86_64-latest.xml -- 2.31.1

4 21

[RFC REPOST 0/7] introduce support for live appid updates
by Pavel Hrdina 13 Sep '21

13 Sep '21

Rebased on top of current master. I'm posting this as an RFC mainly because I'm not sure how to model the new API. This patches introduce a new naive API that will change only the APPID and nothing else. Currently there are no other known features related to Fibre Channel resources so this non-extendable API will be sufficient, however the appid lives in <resource> element in the XML where we currently have root cgroup partition. Even though changing the partition will not be supported and we don't know about anything else that could be placed here it doesn't mean it will not happen in the future. In that case we would have to add new API as well. So I'm wondering if we should create a more generic API that would take typed parameters as arguments: int virDomainSetResource(virDomainPtr domain, virTypedParameterPtr params, int nparams, unsigned int flags) Any ideas? Pavel Hrdina (7): conf: extract appid validation to virDomainDefResourceAppidValidate cgroup: extract setting fibre channel appid into virCgroupSetFCAppid virCgroupSetFCAppid: properly handle when appid is NULL src: introduce virDomainSetFibreChannelAppid API remote: add RPC support for the virDomainSetFibreChannelAppid API qemu: implement virDomainSetFibreChannelAppid API tools: introduce virsh setappid command docs/manpages/virsh.rst | 14 ++++++ include/libvirt/libvirt-domain.h | 4 ++ src/conf/domain_validate.c | 42 ++++++++++-------- src/conf/domain_validate.h | 2 + src/driver-hypervisor.h | 6 +++ src/libvirt-domain.c | 44 +++++++++++++++++++ src/libvirt_private.syms | 2 + src/libvirt_public.syms | 1 + src/qemu/qemu_cgroup.c | 17 +------- src/qemu/qemu_driver.c | 75 ++++++++++++++++++++++++++++++++ src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 14 +++++- src/remote_protocol-structs | 6 +++ src/util/vircgroup.c | 24 ++++++++++ src/util/vircgroup.h | 3 ++ tools/virsh-domain.c | 65 +++++++++++++++++++++++++++ 16 files changed, 286 insertions(+), 34 deletions(-) -- 2.31.1

3 22

device-specific VFIO drivers
by Laine Stump 13 Sep '21

13 Sep '21

The Linux kernel has recently added support for device-specific VFIO drivers to be used (instead of the current generic, one-size-fits-all vfio_pci driver) when assigning a device to a guest with VFIO. The intent of this is to (for example) support APIs for device-specific setup that needs to be done before the device is handed over to the guest, and to support migration of guests using these devices. More details can be found in the comments of the patch emails here: https://lore.kernel.org/kvm/20210826103912.128972-1-yishaih@nvidia.com/ There are a couple of issues that need to be resolved before that will work well with libvirt-managed guests: 1) Although they've outlined a system for determining the best / most specific driver for a device by extending the existing modules aliases, the kernel people have left it up to userspace to actually parse the module.aliases info to determine the best driver for a device. They've even "thrown us a bone" in the form of an example python script to do just that: https://github.com/maxgurtovoy/linux_tools/blob/main/vfio/bind_vfio_pci_dri… Currently, if a device is assigned to a guest with <hostdev managed='yes'> (the default) then libvirt will unbind the device from whatever host driver its bound to, and bind it to the vfio_pci driver (since, up to now, that has been the only driver available). In the future, if we want to be able to take advantage of the extended capabilities provided by the device-specific vfio drivers, we will need to figure out which driver to load. I personally don't like the idea of embedding the logic from the above example program into libvirt - this really seems to me like something that should be implemented in one place for use by many consumers (libvirt being one of the consumers). One suggestion made by Alex Williamson (in a private discussion, not on a mailing list) was that possibly we could get the driverctl utility to add this functionality, and then call driverctl to learn the name of the best-fit vfio driver for a device. I haven't yet looked at it, but I've been told that driverctl is a bash script :-O. If we decide that's a good route, perhaps we could also convince someone to convert drivertctl to rust, similar to what jjongsma did with mdevctl (nudge nudge, hint hint). Or maybe I'm making it into a bigger deal than it needs to be, and we should just implement the logic of the python script up above directly in libvirt. Does anyone have an opinion? (NB: If a device is assigned to a guest by libvirt with <hostdev managed='no'> then libvirt will just blindly assume that it is already bound to the correct driver, so until we get internal support for using the device-specific drivers, users can still get the same functionality by binding their devices to the device-specific vfio driver externally to libvirt). ===== 2) There may be cases where, in spite of a device-specific driver being available, the user prefers to use the generic vfio_pci driver. To support that we will need to have a place in our config to set the driver name. We already have a <driver> subelement of <hostdev> that was originally added to allow choosing between VFIO device assignment and legacy KVM device assignment: <driver name='vfio|kvm'/> All support for KVM device assignment was removed a few years ago, so in practice the driver name is always "vfio". The most natural looking way to support device-specific drivers would be to use this name attribute to specify the driver name, e.g. if you wanted to let libvirt select the best driver, you would use: <driver name='vfio'/> (what it's currently set to in everyone's configs). But if you wanted to force use of the generic driver, you'd use: <driver name='vfio_pci'/> or if you wanted to force use of another driver that wasn't the 'best fit' according to the module aliases, you could use, e.g.: <driver name='vfio_pci_xyzzy'/> I'm uncomfortable with the fact that we're effectively "re-using" the name attribute for a new purpose though - up until now it has been "which device assignment method?", but this changes it to "which vfio driver should be loaded?". So maybe we need a new element. I'm not sure what to call it though. How about this? <driver name='vfio' modname='vfio_pci'/> Does anyone have a better idea for the name?

2 1

[PATH v2 0/2] qemu: don't change ownership of cache directory
by Peng Liang 13 Sep '21

13 Sep '21

See path 2 for detail. v1 -> v2: - Add commit message for path1 [Peter] Peng Liang (2): qemu: move temp file of screenshot and memorypeek to autoDumpPath qemu: don't change ownership of cache directory src/qemu/qemu_driver.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) -- 2.31.1

2 4

[PATCH] docs: Fix dimm example
by Michal Privoznik 13 Sep '21

13 Sep '21

In the example for <memory model='dimm'/> we show how to configure hugepages as backend. In the example we show 4MiB hugepages which are non-standard and thus at the first glance may mislead users thinking that a regular sized pages (4K) will be used. Use 2MiB as the value instead. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/formatdomain.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 67cb934881..7dc93d6abe 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -7745,7 +7745,7 @@ Example: usage of the memory devices </memory> <memory model='dimm'> <source> - <pagesize unit='KiB'>4096</pagesize> + <pagesize unit='KiB'>2048</pagesize> <nodemask>1-3</nodemask> </source> <target> -- 2.32.0

2 1

[libvirt PATCH 0/4] qemu: replace -device sga with -M graphics=off
by Daniel P. Berrangé 13 Sep '21

13 Sep '21

SeaBIOS >= 1.11 / QEMU >= 2.11 no longer requires the 'sga' device for serial console output from the BIOS. It can be done directly with graphics=off machine option. This appears to be live migration compatible, despite changing the number of option ROMS loaded, though I need a little more testing to fully confirm this. Daniel P. Berrangé (4): qemu: prevent use of <bios useserial='yes'> on non-x86 arches qemu: tweak error message to be more general purpose qemu: switch to use -M graphics=off instead of -device sga qemu: stop probing for '-device sga' support src/qemu/qemu_capabilities.c | 3 +-- src/qemu/qemu_capabilities.h | 2 +- src/qemu/qemu_command.c | 25 ++++++++----------- src/qemu/qemu_validate.c | 15 ++++++++--- .../caps_2.11.0.x86_64.xml | 1 - .../caps_2.12.0.x86_64.xml | 1 - .../caps_3.0.0.x86_64.xml | 1 - .../caps_3.1.0.x86_64.xml | 1 - .../caps_4.0.0.x86_64.xml | 1 - .../caps_4.1.0.x86_64.xml | 1 - .../caps_4.2.0.x86_64.xml | 1 - .../caps_5.0.0.x86_64.xml | 1 - .../caps_5.1.0.x86_64.xml | 1 - .../caps_5.2.0.x86_64.xml | 1 - .../caps_6.0.0.x86_64.xml | 1 - .../caps_6.1.0.x86_64.xml | 1 - tests/qemuxml2argvdata/bios.args | 3 +-- tests/qemuxml2argvtest.c | 3 +-- 18 files changed, 25 insertions(+), 38 deletions(-) -- 2.31.1

3 7

[PATCH 0/2] qemu: don't change ownership of cache directory
by Peng Liang 13 Sep '21

13 Sep '21

See path 2 for detail. Peng Liang (2): qemu: move temp file of screenshot and memorypeek to autoDumpPath qemu: don't change ownership of cache directory src/qemu/qemu_driver.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) -- 2.31.1

2 3

Libvirt with Firecracker
by Puscasu, Felix 12 Sep '21

12 Sep '21

Hello Libvirt team, For the last couple of months, as an AWS intern I have been reading and learning how to use libvirt. I have been working on integrating Firecracker<https://github.com/firecracker-microvm/firecracker>, an open source virtual machine monitor into libvirt as a hypervisor driver, believing its design would be a great addition to the fleet of already existing drivers. One question I have is regarding testing, I couldn’t properly use the libvirt-test-API repository, and neither the libvirt-TCK one. I am now looking at the testing done In the libvirt repository itself and wanted to ask if integration-like tests would be achievable here, and if it is in line with the project’s direction. We would like to have tests to be as “end to end” as they can. Another mention is this contribution is more of a proof of concept than a production ready patch/series of patches as it doesn’t have (yet) tests in any way. It can be a starting point for future contributions (that can also be from the open source community). I wanted to check with you if this integration collides with any of your ongoing work and what would be some of your initial thoughts. Kind regards, Felix Puscasu Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005.

3 2

[PATCH v2 0/4] Add support for two i386 pm options which control acpi hotplug
by Ani Sinha 12 Sep '21

12 Sep '21

Hi: I added some negative xml2argv tests as well as new xml2xml tests. In the process, I also fixed a bug where I had not added appropriate code to generate the output xml correctly. The patch series is sent again as v2. Kindly, please provide inputs and review them. [PATCH v2 1/4] pm/i386: add support for two options that controls [PATCH v2 2/4] tests: add positive xml2argv tests to exercize pm acpi [PATCH v2 3/4] tests: add negative xml2argv tests to exercize pm acpi [PATCH v2 4/4] tests: add xml2xml tests to exercize pm acpi hotplug

2 8