- Devel - libvirt List Archives

[libvirt] [PATCH 0/2] SEV: Always format the <sev> element to the domcaps XML
by Erik Skultety 15 Jun '18

15 Jun '18

*** BLURB HERE *** Erik Skultety (2): schema: Fix the definition of SEV in domain capabilities schema conf: Fix formatting of <sev> element in domain capabilities XML docs/schemas/domaincaps.rng | 19 ++++++++++--------- src/conf/domain_capabilities.c | 20 ++++++++++++-------- tests/domaincapsschemadata/basic.xml | 1 + tests/domaincapsschemadata/bhyve_basic.x86_64.xml | 1 + tests/domaincapsschemadata/bhyve_fbuf.x86_64.xml | 1 + tests/domaincapsschemadata/bhyve_uefi.x86_64.xml | 1 + tests/domaincapsschemadata/full.xml | 1 + tests/domaincapsschemadata/libxl-xenfv-usb.xml | 1 + tests/domaincapsschemadata/libxl-xenfv.xml | 1 + tests/domaincapsschemadata/libxl-xenpv-usb.xml | 1 + tests/domaincapsschemadata/libxl-xenpv.xml | 1 + tests/domaincapsschemadata/qemu_1.7.0.x86_64.xml | 1 + .../qemu_2.12.0-virt.aarch64.xml | 1 + tests/domaincapsschemadata/qemu_2.12.0.ppc64.xml | 1 + tests/domaincapsschemadata/qemu_2.12.0.s390x.xml | 1 + tests/domaincapsschemadata/qemu_2.12.0.x86_64.xml | 1 + .../domaincapsschemadata/qemu_2.6.0-virt.aarch64.xml | 1 + tests/domaincapsschemadata/qemu_2.6.0.aarch64.xml | 1 + tests/domaincapsschemadata/qemu_2.6.0.ppc64.xml | 1 + tests/domaincapsschemadata/qemu_2.6.0.x86_64.xml | 1 + tests/domaincapsschemadata/qemu_2.7.0.s390x.xml | 1 + tests/domaincapsschemadata/qemu_2.8.0-tcg.x86_64.xml | 1 + tests/domaincapsschemadata/qemu_2.8.0.s390x.xml | 1 + tests/domaincapsschemadata/qemu_2.8.0.x86_64.xml | 1 + tests/domaincapsschemadata/qemu_2.9.0-q35.x86_64.xml | 1 + tests/domaincapsschemadata/qemu_2.9.0-tcg.x86_64.xml | 1 + tests/domaincapsschemadata/qemu_2.9.0.x86_64.xml | 1 + 27 files changed, 47 insertions(+), 17 deletions(-) -- 2.14.4

2 7

Re: [libvirt] [PATCH v4 3/3] hw/vfio/display: add ramfb support
by Alex Williamson 15 Jun '18

15 Jun '18

On Wed, 13 Jun 2018 10:41:49 +0200 Gerd Hoffmann <kraxel(a)redhat.com> wrote: > So we have a boot display when using a vgpu as primary display. > > Use vfio-pci-ramfb instead of vfio-pci to enable it. Using a different device here seems like it almost guarantees a very complicated path to support under libvirt. What necessitates this versus a simple ramfb=on option to vfio-pci? I'm also not sure I understand the usage model, SeaBIOS and OVMF know how to write to this display, but it seems that the guest does not. I suppose in the UEFI case runtime services can be used to continue writing this display, but BIOS doesn't have such an option, unless we're somehow emulating VGA here. So for UEFI, I can imagine this covers us from power on through firmware boot and up to guest drivers initializing the GPU (assuming the vGPU supports a kernel mode driver, does NVIDIA?), but for BIOS it seems we likely still have a break from the bootloader to GPU driver initialization. For instance, what driver is used to draw the boot animation (or blue screen) on SeaBIOS Windows VM? I'm assuming that this display and the vGPU display are one in the same, so there's some cut from one to the other. Thanks, Alex > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> > --- > include/hw/vfio/vfio-common.h | 2 ++ > hw/vfio/display.c | 10 ++++++++++ > hw/vfio/pci.c | 15 +++++++++++++++ > 3 files changed, 27 insertions(+) > > diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h > index a9036929b2..a58d7e7e77 100644 > --- a/include/hw/vfio/vfio-common.h > +++ b/include/hw/vfio/vfio-common.h > @@ -26,6 +26,7 @@ > #include "qemu/queue.h" > #include "qemu/notify.h" > #include "ui/console.h" > +#include "hw/display/ramfb.h" > #ifdef CONFIG_LINUX > #include <linux/vfio.h> > #endif > @@ -143,6 +144,7 @@ typedef struct VFIODMABuf { > > typedef struct VFIODisplay { > QemuConsole *con; > + RAMFBState *ramfb; > struct { > VFIORegion buffer; > DisplaySurface *surface; > diff --git a/hw/vfio/display.c b/hw/vfio/display.c > index 59c0e5d1d7..409d5a2e3a 100644 > --- a/hw/vfio/display.c > +++ b/hw/vfio/display.c > @@ -124,6 +124,9 @@ static void vfio_display_dmabuf_update(void *opaque) > > primary = vfio_display_get_dmabuf(vdev, DRM_PLANE_TYPE_PRIMARY); > if (primary == NULL) { > + if (dpy->ramfb) { > + ramfb_display_update(dpy->con, dpy->ramfb); > + } > return; > } > > @@ -181,6 +184,8 @@ static int vfio_display_dmabuf_init(VFIOPCIDevice *vdev, Error **errp) > vdev->dpy->con = graphic_console_init(DEVICE(vdev), 0, > &vfio_display_dmabuf_ops, > vdev); > + if (strcmp(object_get_typename(OBJECT(vdev)), "vfio-pci-ramfb") == 0) > + vdev->dpy->ramfb = ramfb_setup(errp); > return 0; > } > > @@ -228,6 +233,9 @@ static void vfio_display_region_update(void *opaque) > return; > } > if (!plane.drm_format || !plane.size) { > + if (dpy->ramfb) { > + ramfb_display_update(dpy->con, dpy->ramfb); > + } > return; > } > format = qemu_drm_format_to_pixman(plane.drm_format); > @@ -300,6 +308,8 @@ static int vfio_display_region_init(VFIOPCIDevice *vdev, Error **errp) > vdev->dpy->con = graphic_console_init(DEVICE(vdev), 0, > &vfio_display_region_ops, > vdev); > + if (strcmp(object_get_typename(OBJECT(vdev)), "vfio-pci-ramfb") == 0) > + vdev->dpy->ramfb = ramfb_setup(errp); > return 0; > } > > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c > index 18c493b49e..6a2b42a595 100644 > --- a/hw/vfio/pci.c > +++ b/hw/vfio/pci.c > @@ -3234,9 +3234,24 @@ static const TypeInfo vfio_pci_dev_info = { > }, > }; > > +static void vfio_pci_ramfb_dev_class_init(ObjectClass *klass, void *data) > +{ > + DeviceClass *dc = DEVICE_CLASS(klass); > + > + dc->hotpluggable = false; > +} > + > +static const TypeInfo vfio_pci_ramfb_dev_info = { > + .name = "vfio-pci-ramfb", > + .parent = "vfio-pci", > + .instance_size = sizeof(VFIOPCIDevice), > + .class_init = vfio_pci_ramfb_dev_class_init, > +}; > + > static void register_vfio_pci_dev_type(void) > { > type_register_static(&vfio_pci_dev_info); > + type_register_static(&vfio_pci_ramfb_dev_info); > } > > type_init(register_vfio_pci_dev_type)

4 4

[libvirt] [dbus PATCH v2 00/17] StorageVolume APIs
by Katerina Koukiou 15 Jun '18

15 Jun '18

Changes from v1: - Fixes from reviews - And more: * tests: Moved all xml definitions for tests in separate file. * tests: Renamed all functions that are not supposed to be run as tests, so that they don't have test prefix. I found out that these were running as tests, when I added the new function for listing the volumes from the test driver. test driver doesn't offer any volumes, and the function failed. * tests: To get a test volume I created a pytest fixture, which I add in the setup of the tests that are manipulating with volumes. In this way, the get_test_storage_volume function remained same to the similar purpose functions as suggested in the previous review. Katerina Koukiou (17): Introduce StorageVol Interface Implement ListStorageVolumes for StoragePool Interface test: move XML definition of entities to seperate file tests: rename test_* functions which are not tests Implement StorageVolCreateXML method for StoragePool Interface Implement Name property for StorageVol Interface Implement Key property for StorageVol Interface Implement Path property for StorageVol Interface Implement GetXMLDesc method for StorageVol Interface Implement StorageVolLookupByKey method for Connect Interface Implement StorageVolLookupByName method for StoragePool Interface Implement StorageVolLookupByPath method for Connect Interface Implement Resize method for StorageVol Interface Implement Wipe method for StorageVol Interface Implement GetInfo method for StorageVol Interface Implement Delete method for StorageVol Interface Implement StorageVolCreateXMLFrom method for StoragePool Interface data/Makefile.am | 4 +- data/org.libvirt.Connect.xml | 12 ++ data/org.libvirt.StoragePool.xml | 28 ++++ data/org.libvirt.StorageVol.xml | 51 +++++++ src/Makefile.am | 4 +- src/connect.c | 66 +++++++++ src/connect.h | 1 + src/storagepool.c | 152 ++++++++++++++++++++ src/storagevol.c | 302 +++++++++++++++++++++++++++++++++++++++ src/storagevol.h | 9 ++ src/util.c | 35 +++++ src/util.h | 16 +++ tests/libvirttest.py | 37 ++++- tests/test_connect.py | 69 ++++----- tests/test_domain.py | 20 +-- tests/test_network.py | 14 +- tests/test_storage.py | 79 ++++++++-- tests/xmldata.py | 47 ++++++ 18 files changed, 871 insertions(+), 75 deletions(-) create mode 100644 data/org.libvirt.StorageVol.xml create mode 100644 src/storagevol.c create mode 100644 src/storagevol.h create mode 100644 tests/xmldata.py -- 2.15.0

2 21

[libvirt] [PATCH v2 0/6] travis: Various cleanups and fixes
by Andrea Bolognani 14 Jun '18

14 Jun '18

Changes from [v1]: * keep DOCKER_CMD around instead of removing it completely, which will help once we introduce MinGW builds; * the last two patches are new. [v1] https://www.redhat.com/archives/libvir-list/2018-June/msg00579.html Andrea Bolognani (6): travis: Skip macOS upgrade travis: Don't duplicate Docker invocation travis: Introduce MACOS_CMD travis: Rename DOCKER_CMD to LINUX_CMD travis: Fix error path travis: Skip first compilation for Linux builds .travis.yml | 74 ++++++++++++++++++++++++----------------------------- 1 file changed, 34 insertions(+), 40 deletions(-) -- 2.17.1

2 7

[libvirt] [PATCH 0/4] qemu: Allow concurrent access to monitor and guest agent
by Michal Privoznik 14 Jun '18

14 Jun '18

It is very easy to see these patches in action. Just apply the following diff: diff --git i/src/qemu/qemu_agent.c w/src/qemu/qemu_agent.c index 10c6ef09fa..dd48caecb7 100644 --- i/src/qemu/qemu_agent.c +++ w/src/qemu/qemu_agent.c @@ -1702,6 +1702,8 @@ qemuAgentGetTime(qemuAgentPtr mon, VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK) < 0) goto cleanup; + sleep(120); + if (virJSONValueObjectGetNumberUlong(reply, "return", &json_time) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("malformed return value")); This is to simulate a slow guest agent. Then all you need to do is run: 'virsh domtime $dom' and then 'virsh domstats $dom' from another terminal. Enjoy. Michal Privoznik (4): qemu: Introduce qemuDomainAgentJob qemu: Introduce APIs for manipulating qemuDomainAgentJob qemuDomainAgentJob: Introduce query and modify jobs qemu: Switch code to use new agent job APIs src/qemu/THREADS.txt | 62 ++++++++++++++++-- src/qemu/qemu_domain.c | 169 +++++++++++++++++++++++++++++++++++++++---------- src/qemu/qemu_domain.h | 29 +++++++++ src/qemu/qemu_driver.c | 91 ++++++++++++++++---------- 4 files changed, 281 insertions(+), 70 deletions(-) -- 2.16.4

2 15

[libvirt] [libvirt-go-xml PATCH 0/2] Add support for the AMD SEV feature
by Erik Skultety 14 Jun '18

14 Jun '18

*** BLURB HERE *** Erik Skultety (2): Add support for domain launch security Add support for SEV in domain capabilities XML domain.go | 135 ++++++++++++++++++++++++++++++++++++++++++++++++- domain_capabilities.go | 7 +++ 2 files changed, 141 insertions(+), 1 deletion(-) -- 2.14.4

2 5

[libvirt] [PATCH v4 0/2] Finish the conversion to virConfGetValue* functions
by Fabiano Fidêncio 14 Jun '18

14 Jun '18

This patchset finishes the conversion to virConfGetValue* functions, started by Daniel Berrange a few months ago. Please, mind that although we could make virConfGetValue* functions more generic in order to support numbers and booleans as strings, that doesn't seem the safest path to take. The side-effect of this is that we will have to live with some specific code doing that as part of vmx and xen_common. Once this patchset gets merged, https://wiki.libvirt.org/page/BiteSizedTasks#Finish_conversion_to_virConfGe… can be removed. - Changes since v1: All the "values" from virConfGetValueString() are freed - Changes since v2: All comments from Ján Tomko have been addressed; A few leaks were (possibly) found and they're addressed in the last patch of the series; - Changes since v3: All commentes from Ján Tomko have been addressed in order to lower the non-whitespace changes in the first patch; Fabiano Fidêncio (2): xen_common: Split per-Vif logic from xenParseVif() xen_common: convert to typesafe virConf acessors src/xenconfig/xen_common.c | 535 +++++++++++++++++++++++---------------------- 1 file changed, 273 insertions(+), 262 deletions(-) -- 2.14.3

2 4

[libvirt] [libvirt-python PATCH v2 0/2] Provide coverage for the AMD SEV APIs
by Erik Skultety 14 Jun '18

14 Jun '18

Add support for the recently introduced AMD SEV APIs. since v1: - fixed indentation issues - built against a refreshed master and fixed some compilation errors - added virNodeGetSEVInfo to the XML api override list Erik Skultety (2): Add support for virDomainGetLaunchSecurityInfo Add support for virNodeGetSEVInfo generator.py | 2 ++ libvirt-override-api.xml | 12 ++++++++ libvirt-override.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 88 insertions(+) -- 2.14.4

2 5

[libvirt] [PATCHv2] docs: schema: Add missing <interleave> element to input device
by Lily Zhu 14 Jun '18

14 Jun '18

For the 2 optional sub-elements - <alias> and <address> of input device, make the order of them interchangeable in the XML. Signed-off-by: Lily Zhu <lizhu(a)redhat.com> --- docs/schemas/domaincommon.rng | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 1d06a5e..7c7f956 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -4309,12 +4309,14 @@ </element> </group> </choice> - <optional> - <ref name="alias"/> - </optional> - <optional> - <ref name="address"/> - </optional> + <interleave> + <optional> + <ref name="alias"/> + </optional> + <optional> + <ref name="address"/> + </optional> + </interleave> </element> </define> <define name="hub"> -- 1.8.3.1

2 1

[libvirt] Call to virDomainIsActive hangs forever
by Mathieu Tarral 14 Jun '18

14 Jun '18

Hi ! I'm submitting my messages on this mailing list to request a bit of help on a case that I have where a Python application makes a call to virDomainIsActive, and the call never returns. I have tried to investigate, but as there are no debug symbols for libvirt on Debian Stretch, i can only have the following GDB backtrace: (gdb) bt #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007f49026f5b76 in virCondWait () from /usr/lib/libvirt.so.0 #2 0x00007f4902808bab in ?? () from /usr/lib/libvirt.so.0 #3 0x00007f490280a433 in virNetClientSendWithReply () from /usr/lib/libvirt.so.0 #4 0x00007f490280abe2 in virNetClientProgramCall () from /usr/lib/libvirt.so.0 #5 0x00007f49027e0ea4 in ?? () from /usr/lib/libvirt.so.0 #6 0x00007f49027ea1bb in ?? () from /usr/lib/libvirt.so.0 #7 0x00007f49027b0ef3 in virDomainIsActive () from /usr/lib/libvirt.so.0 #8 0x00007f4902b7fbd0 in libvirt_virDomainIsActive () from /usr/lib/python3/dist-packages/libvirtmod.cpython-35m-x86_64-linux-gnu.so #9 0x0000558eeec696df in PyCFunction_Call () at ../Objects/methodobject.c:109 The libvirt driver used is QEMU, and i have a specific monitoring in place using virtual machine introspection: https://github.com/KVM-VMI/kvm-vmi Now this specific monitoring somehow triggers this bug, and at this point, i don't know if it's a corner case in the libvirt QEMU driver or not. That's why i would like to have your lights on this. libvirt version: 3.0.0-4 -> Could you tell me where i should look in the code ? -> Do you have more information about this virCondWait ? Which condition is it waiting for ? -> How can i get the symbols without having the recompile libvirt and install it system wide, erasing the binaries installed by the package ? Best regards, -- Mathieu Tarral

5 11