- Devel - libvirt List Archives

[libvirt] [PATCH 0/5] qemu: support virtio console
by Cole Robinson 27 Jul '10

27 Jul '10

The following series adds virtio console XML and qemu driver support. The first 3 patches are just cleanups/improvements. Patch 4 adds XML support for more than 1 console device (not strictly required for virtio console, but it's a valid use case). Patch 5 actually adds virtio console support. Thanks, Cole Cole Robinson (5): docs: domain: Document virtio <channel> domain conf: Rename character prop targetType -> deviceType domain conf: char: Add an explicit targetType field domain conf: Support multiple <console> devices qemu: virtio console support docs/formatdomain.html.in | 31 +++- docs/schemas/domain.rng | 14 ++- src/conf/domain_conf.c | 192 ++++++++++++-------- src/conf/domain_conf.h | 26 ++- src/esx/esx_vmx.c | 4 +- src/libvirt_private.syms | 1 + src/lxc/lxc_driver.c | 8 +- src/qemu/qemu_conf.c | 48 +++++- src/qemu/qemu_driver.c | 3 +- src/uml/uml_conf.c | 4 +- src/uml/uml_driver.c | 6 +- src/vbox/vbox_tmpl.c | 4 +- src/xen/xend_internal.c | 16 ++- src/xen/xm_internal.c | 19 ++- .../qemuxml2argv-console-virtio.args | 1 + .../qemuxml2argv-console-virtio.xml | 30 +++ tests/qemuxml2argvtest.c | 2 + .../xml2sexprdata/xml2sexpr-pv-multi-console.sexpr | 1 + tests/xml2sexprdata/xml2sexpr-pv-multi-console.xml | 24 +++ tests/xml2sexprtest.c | 1 + 20 files changed, 324 insertions(+), 111 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-console-virtio.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-console-virtio.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-pv-multi-console.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-pv-multi-console.xml

2 16

[libvirt] [PATCH] Invert logic for checking for QEMU disk cache options
by Daniel P. Berrange 27 Jul '10

27 Jul '10

QEMU has had two different syntax for disk cache options Old: on|off New: writeback|writethrough|none QEMU recently added another 'unsafe' option which broke the libvirt check. We can avoid this & future breakage, if we do a negative check for the old syntax, instead of a positive check for the new syntax * src/qemu/qemu_conf.c: Invert cache option check --- src/qemu/qemu_conf.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 0dbab48..db60ca3 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -1170,7 +1170,8 @@ static unsigned long long qemudComputeCmdFlags(const char *help, flags |= QEMUD_CMD_FLAG_DOMID; if (strstr(help, "-drive")) { flags |= QEMUD_CMD_FLAG_DRIVE; - if (strstr(help, "cache=writethrough|writeback|none")) + if (strstr(help, "cache=") && + !strstr(help, "cache=on|off")) flags |= QEMUD_CMD_FLAG_DRIVE_CACHE_V2; if (strstr(help, "format=")) flags |= QEMUD_CMD_FLAG_DRIVE_FORMAT; -- 1.7.1.1

2 1

[libvirt] [PATCH 0/5] Fix compile and test errors in AppArmor related code
by Matthias Bolte 27 Jul '10

27 Jul '10

The recently added option to control the disk format probing has broken AppArmor related code and tests. This series fixes this. Matthias

5 22

[libvirt] [PATCH] Force FLR on for buggy SR-IOV devices.
by Chris Lalancette 26 Jul '10

26 Jul '10

Some buggy PCI devices actually support FLR, but forget to advertise that fact in their PCI config space. However, Virtual Functions on SR-IOV devices are *required* to support FLR by the spec, so force has_flr on if this is a virtual function. Signed-off-by: Chris Lalancette <clalance(a)redhat.com> --- src/util/pci.c | 48 ++++++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 44 insertions(+), 4 deletions(-) diff --git a/src/util/pci.c b/src/util/pci.c index c45b179..41e91af 100644 --- a/src/util/pci.c +++ b/src/util/pci.c @@ -183,6 +183,16 @@ pciOpenConfig(pciDevice *dev) return 0; } +static void +pciCloseConfig(pciDevice *dev) +{ + if (!dev) + return; + + if (dev->fd >= 0) + close(dev->fd); +} + static int pciRead(pciDevice *dev, unsigned pos, uint8_t *buf, unsigned buflen) { @@ -380,11 +390,16 @@ pciFindExtendedCapabilityOffset(pciDevice *dev, unsigned capability) return 0; } -static unsigned +/* detects whether this device has FLR. Returns 0 if the device does + * not have FLR, 1 if it does, and -1 on error + */ +static int pciDetectFunctionLevelReset(pciDevice *dev) { uint32_t caps; uint8_t pos; + char *path; + int found; /* The PCIe Function Level Reset capability allows * individual device functions to be reset without @@ -413,6 +428,25 @@ pciDetectFunctionLevelReset(pciDevice *dev) } } + /* there are some buggy devices that do support FLR, but forget to + * advertise that fact in their capabilities. However, FLR is *required* + * to be present for virtual functions (VFs), so if we see that this + * device is a VF, we just assume FLR works + */ + + if (virAsprintf(&path, PCI_SYSFS "devices/%s/physfn", dev->name) < 0) { + virReportOOMError(); + return -1; + } + + found = virFileExists(path); + VIR_FREE(path); + if (found) { + VIR_DEBUG("%s %s: buggy device didn't advertise FLR, but is a VF; forcing flr on", + dev->id, dev->name); + return 1; + } + VIR_DEBUG("%s %s: no FLR capability found", dev->id, dev->name); return 0; @@ -626,6 +660,8 @@ pciTryPowerManagementReset(pciDevice *dev) static int pciInitDevice(pciDevice *dev) { + int flr; + if (pciOpenConfig(dev) < 0) { virReportSystemError(errno, _("Failed to open config space file '%s'"), @@ -635,7 +671,12 @@ pciInitDevice(pciDevice *dev) dev->pcie_cap_pos = pciFindCapabilityOffset(dev, PCI_CAP_ID_EXP); dev->pci_pm_cap_pos = pciFindCapabilityOffset(dev, PCI_CAP_ID_PM); - dev->has_flr = pciDetectFunctionLevelReset(dev); + flr = pciDetectFunctionLevelReset(dev); + if (flr < 0) { + pciCloseConfig(dev); + return flr; + } + dev->has_flr = flr; dev->has_pm_reset = pciDetectPowerManagementReset(dev); dev->initted = 1; return 0; @@ -1098,8 +1139,7 @@ pciFreeDevice(pciDevice *dev) if (!dev) return; VIR_DEBUG("%s %s: freeing", dev->id, dev->name); - if (dev->fd >= 0) - close(dev->fd); + pciCloseConfig(dev); VIR_FREE(dev); } -- 1.7.1.1

2 2

[libvirt] [RFC PATCH 0/4] fix secondary bus reset with active devices logic
by Chris Wright 26 Jul '10

26 Jul '10

The current logic can allow libvirt to issue a secondary bus reset despite the host having devices on the same bus as a device that's being assigned to a guest. The following patches refactor the code a little and then update the secondary bus reset logic to properly deal with active devices. This has been lightly tested, testing is still incomplete, hence the RFC to get any style comments out of the way once testing verifies this is working as expected. The following scenarios have been successfully tested: - Do not issue a secondary bus reset: - start guest w/ domain conf including hostdev that shares bus w/ devices owned by host - use attach-device to dynamically add hostdev to guest, hostdev shares bus w/ devices owned by host - attempt to node-reset a device assigned to guest - Issue a secondary bus reset: - start guest w/ domain conf including all devices on bus[1] - use attach-device to dynamically add hostdev to guest, hostdev does not share bus with other devices Not yet tested: - Issue a secondary bus reset: - when shutting down domain - when detaching device from domain [1] guest did not succesfully start w/ these devices, unclear if this patch series is implicated. Chris Wright (4): qemuGetPciHostDeviceList take hostdev list directly Add helpers qemuPrepareHostdevPCIDevices and qemuDomainReAttachHostdevDevices qemudDomainAttachHostPciDevice refactor to use new helpers pciResetDevice: use inactive devices to determine safe reset src/qemu/qemu_driver.c | 87 ++++++++++++++++++++---------------------------- src/util/pci.c | 20 ++++++----- src/util/pci.h | 3 +- src/xen/xen_driver.c | 2 +- 4 files changed, 50 insertions(+), 62 deletions(-)

2 11

[libvirt] libvirt on x64
by Tavares, John 26 Jul '10

26 Jul '10

I just logged onto the first X64 based machine with libvirt (0.3.3-18.5) installed on it and I am only seeing the X64 based version of the shared library. Here is what I am seeing: $ rpm -qal libvirt | grep libvirt.so /usr/lib64/libvirt.so.0 /usr/lib64/libvirt.so.0.3.3 Is there any reason why the 32-bit version is not also installed?? My application is 32-bit based, so it will not work on this hardware because of this. Thanks. John

2 5

[libvirt] [PATCH] build: fix VPATH builds
by Eric Blake 26 Jul '10

26 Jul '10

After the recent libvirt-qemu library addition, VPATH builds fail with: CC libvirt_qemu_la-libvirt-qemu.lo In file included from ../../src/libvirt-qemu.c:29: ../../include/libvirt/libvirt-qemu.h:17:22: error: libvirt.h: No such file or directory ... CCLD libvirt-qmeu.la /usr/bin/ld: cannot open linker script file libvirt_qemu.syms: No such file or directory This fixes both issues (there are still some documentation VPATH issues, but those don't show up with 'make all'). * configure.ac (LIBVIRT_QEMU_SYMBOL_FILE): While libvirt.syms is generated and lives in $(builddir), libvirt_qemu.syms is static and lives in $(srcdir). * include/libvirt/libvirt-qemu.h (includes): Pull in libvirt.h via the public location, since this is a public header. --- Tested with both in-tree and VPATH builds. Should libvirt-qemu.h be using <libvirt/libvirt.h> instead of "libvirt/libvirt.h"? configure.ac | 2 +- include/libvirt/libvirt-qemu.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 08b7eb6..98d2f6e 100644 --- a/configure.ac +++ b/configure.ac @@ -1833,7 +1833,7 @@ CYGWIN_EXTRA_PYTHON_LIBADD= MINGW_EXTRA_LDFLAGS= WIN32_EXTRA_CFLAGS= LIBVIRT_SYMBOL_FILE=libvirt.syms -LIBVIRT_QEMU_SYMBOL_FILE=libvirt_qemu.syms +LIBVIRT_QEMU_SYMBOL_FILE='$(srcdir)/libvirt_qemu.syms' case "$host" in *-*-cygwin*) CYGWIN_EXTRA_LDFLAGS="-no-undefined" diff --git a/include/libvirt/libvirt-qemu.h b/include/libvirt/libvirt-qemu.h index d21fd92..9c191c7 100644 --- a/include/libvirt/libvirt-qemu.h +++ b/include/libvirt/libvirt-qemu.h @@ -14,7 +14,7 @@ #ifndef __VIR_QEMU_H__ # define __VIR_QEMU_H__ -# include "libvirt.h" +# include "libvirt/libvirt.h" # ifdef __cplusplus extern "C" { -- 1.7.1.1

2 2

[libvirt] [PATCH] Force FLR on for buggy SR-IOV devices.
by Chris Lalancette 26 Jul '10

26 Jul '10

Some buggy PCI devices actually support FLR, but forget to advertise that fact in their PCI config space. However, Virtual Functions on SR-IOV devices are *required* to support FLR by the spec, so force has_flr on if this is a virtual function. Signed-off-by: Chris Lalancette <clalance(a)redhat.com> --- src/util/pci.c | 22 ++++++++++++++++++++++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/src/util/pci.c b/src/util/pci.c index c45b179..4bfad2c 100644 --- a/src/util/pci.c +++ b/src/util/pci.c @@ -385,6 +385,7 @@ pciDetectFunctionLevelReset(pciDevice *dev) { uint32_t caps; uint8_t pos; + char *path; /* The PCIe Function Level Reset capability allows * individual device functions to be reset without @@ -413,6 +414,27 @@ pciDetectFunctionLevelReset(pciDevice *dev) } } + /* there are some buggy devices that do support FLR, but forget to + * advertise that fact in their capabilities. However, FLR is *required* + * to be present for virtual functions (VFs), so if we see that this + * device is a VF, we just assume FLR works + */ + + if (virAsprintf(&path, PCI_SYSFS "devices/%s/physfn", dev->name) < 0) { + VIR_ERROR("Failed to allocate memory when checking FLR for device %s", + dev->id); + return 0; + } + + if (virFileExists(path)) { + VIR_FREE(path); + VIR_DEBUG("%s %s: buggy device didn't advertise FLR, but is a VF; forcing flr on", + dev->id, dev->name); + return 1; + } + + VIR_FREE(path); + VIR_DEBUG("%s %s: no FLR capability found", dev->id, dev->name); return 0; -- 1.7.1.1

4 4

[libvirt] Parameters for macros in docs?
by Justin Clift 26 Jul '10

26 Jul '10

Hi all, The (autogenerated) docs aren't showing the parameters needed for the libvirt macros. For example, this is VIR_USE_CPU in the source: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ /** * VIR_USE_CPU: * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) (IN/OUT) * @cpu: the physical CPU number * * This macro is to be used in conjunction with virDomainPinVcpu() API. * USE_CPU macro set the bit (CPU usable) of the related cpu in cpumap. */ #define VIR_USE_CPU(cpumap,cpu) (cpumap[(cpu)/8] |= (1<<((cpu)%8))) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In the API docs on the website, this is shown: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ VIR_USE_CPU #define VIR_USE_CPU This macro is to be used in conjunction with virDomainPinVcpu() API. USE_CPU macro set the bit (CPU usable) of the related cpu in cpumap. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To me, it makess sense to show the parameters needed for each macro. The information is passed along by the Python doc generation script, but is disregarded in the final XSLT transformation to produce the html docs. Wondering if that's on purpose, or are we ok to display the macro parameters too? Regards and best wishes, Justin Clift

2 1

[libvirt] IO controller groups?
by Jon Masters 26 Jul '10

26 Jul '10

Folks, Anyone got any information about support in libvirt for automatic handling of IO controller throttling/IO limits with recent kernels? I'd love it if libvirt just supported assigning IO bandwidth automatically. :) Jon.

1 0