- Devel - libvirt List Archives

[libvirt] [PATCHv2] QEMU: Modify qemuParseCommandLinePCI() to parsee '-device vfio-pci'
by Olivia Yin 09 Jun '14

09 Jun '14

Signed-off-by: Olivia Yin <Hong-Hua.Yin(a)freescale.com> Modify qemuParseCommandLinePCI() to support parsing '-device vfio-pci,host=bus:slot.func'. Add test case 'hostdev-vfio' into qemuargv2xmltest to validate this function. The case related to QEMU_CAPS_HOST_PCI_MULTIDOMAIN which uses '-device vfio-pci,host=domain:bus:slot.func' is not supported yet. --- src/qemu/qemu_command.c | 36 ++++++++++++++++++++++++++++++------ tests/qemuargv2xmltest.c | 2 +- 2 files changed, 31 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 3cf279e..ae7f94e 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -10193,7 +10193,7 @@ qemuParseCommandLineNet(virDomainXMLOptionPtr xmlopt, * Tries to parse a QEMU PCI device */ static virDomainHostdevDefPtr -qemuParseCommandLinePCI(const char *val) +qemuParseCommandLinePCI(const char *val, bool vfio) { int bus = 0, slot = 0, func = 0; const char *start; @@ -10222,10 +10222,20 @@ qemuParseCommandLinePCI(const char *val) goto error; } start = end + 1; - if (virStrToLong_i(start, NULL, 16, &func) < 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("cannot extract PCI device function '%s'"), val); - goto error; + + if (!vfio) { + if (virStrToLong_i(start, NULL, 16, &func) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("cannot extract PCI device function '%s'"), val); + goto error; + } + } else { + if (virStrToLong_i(start, &end, 16, &func) < 0 || *end != ',') { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("cannot extract PCI device function '%s'"), val); + goto error; + } else + def->source.subsys.u.pci.backend = VIR_DOMAIN_HOSTDEV_PCI_BACKEND_VFIO; } def->mode = VIR_DOMAIN_HOSTDEV_MODE_SUBSYS; @@ -11347,12 +11357,26 @@ qemuParseCommandLine(virCapsPtr qemuCaps, } else if (STREQ(arg, "-pcidevice")) { virDomainHostdevDefPtr hostdev; WANT_VALUE(); - if (!(hostdev = qemuParseCommandLinePCI(val))) + if (!(hostdev = qemuParseCommandLinePCI(val,0))) goto error; if (VIR_APPEND_ELEMENT(def->hostdevs, def->nhostdevs, hostdev) < 0) { virDomainHostdevDefFree(hostdev); goto error; } + } else if (STREQ(arg, "-device")) { + WANT_VALUE(); + if (STRPREFIX(val, "vfio-pci,")) { + const char *start; + start = val; + virDomainHostdevDefPtr hostdev; + start += strlen("vfio-pci,"); + if (!(hostdev = qemuParseCommandLinePCI(start,1))) + goto error; + if (VIR_APPEND_ELEMENT(def->hostdevs, def->nhostdevs, hostdev) < 0) { + virDomainHostdevDefFree(hostdev); + goto error; + } + } } else if (STREQ(arg, "-soundhw")) { const char *start; WANT_VALUE(); diff --git a/tests/qemuargv2xmltest.c b/tests/qemuargv2xmltest.c index 0fc9fcb..b4ba97a 100644 --- a/tests/qemuargv2xmltest.c +++ b/tests/qemuargv2xmltest.c @@ -251,8 +251,8 @@ mymain(void) DO_TEST("watchdog"); DO_TEST("hostdev-usb-address"); - DO_TEST("hostdev-pci-address"); + DO_TEST("hostdev-vfio"); DO_TEST("smp"); -- 1.8.5

2 1

[libvirt] [PATCH] parallels: Avoid possible leak of "cpu" from parallelsBuildCapabilities
by Peter Krempa 09 Jun '14

09 Jun '14

4d06af97d38c3648937eb8f732704379b3cd9e59 introduced a possible memory leak of the memory allocated into the "cpu" pointer in parallelsBuildCapabilities in the case "nodeGetInfo()" would fail right after the allocation. Rearrange the code to avoid the possibility of the leak. Found by Coverity. --- src/parallels/parallels_driver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/parallels/parallels_driver.c b/src/parallels/parallels_driver.c index 153961b..411527c 100644 --- a/src/parallels/parallels_driver.c +++ b/src/parallels/parallels_driver.c @@ -151,10 +151,10 @@ parallelsBuildCapabilities(void) "parallels", NULL, NULL, 0, NULL) == NULL) goto error; - if (VIR_ALLOC(cpu) < 0) + if (nodeGetInfo(&nodeinfo)) goto error; - if (nodeGetInfo(&nodeinfo)) + if (VIR_ALLOC(cpu) < 0) goto error; cpu->arch = caps->host.arch; -- 1.9.3

2 2

Re: [libvirt] [Qemu-devel] Question about how to distinguish a usb device in usb pass-through feature
by Gonglei (Arei) 09 Jun '14

09 Jun '14

Hi, Qemu has supported 3rd method for USB passthrough except two ways that you have pointed: hostbus+hostport -- match for a specific physical port in the host, any device which is plugged in there gets passed to the guest. The method can resolve your all problems. AFAICT, libvirt do not support this way at present. Any Plan? CC'ing libvirt developer mailist. Best regards, -Gonglei From: qemu-devel-bounces+arei.gonglei=huawei.com(a)nongnu.org [mailto:qemu-devel-bounces+arei.gonglei=huawei.com@nongnu.org] On Behalf Of Yuanjing (D) Sent: Monday, June 09, 2014 11:37 AM To: qemu-devel(a)nongnu.org Cc: Liuji (Jeremy) Subject: [Qemu-devel] Question about how to distinguish a usb device in usb pass-through feature Hi, I want to provide feature that pass-through host's usb device to guest os in Openstack. I have question about how to distinguish a usb device. I have read some introductions and made some tests. I think qemu supports two ways to identify a host usb device: (1)host:bus.addr (2)host:vendor_id:product_id I think they both have restriction on some use cases: (1) 'host:bus.addr' is not appropriate if more than one usb devices with the same 'host:bus.addr' in a host. (2) The addr(device number) may change every time unplug/plug usb device of a host. One this happen the guest may reboot failed with wrong host:bus.addr. I noticed that Vmware supports technology 'autoconnection', they pass-through usb device by using usb path of the device on the host(physical topology and port location). Once unplug usb device and plug usb device again with the same usb path, the new device appears and is connected to the guest. I am not a qemu/system programmer and I apologize if I am missing something very obvious. Hope somebody can help me to find the best way to distinguish a usb device? Thanks in advance

1 0

[libvirt] [PATCH] m4: bhyve: Fix check for the required bhyve programs
by Peter Krempa 09 Jun '14

09 Jun '14

bhyveload and bhyvectl wouldn't be checked otherwise as the configure script wouldn't execute one of the tests: checking for bhyve... /usr/local/sbin/bhyve checking for bhyvectl... /usr/local/sbin/bhyvectl checking for bhyveload... /usr/local/sbin/bhyveload ./configure: line 62602: test: too many arguments Fix the shell statement testing the 3 binaries. --- m4/virt-driver-bhyve.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/virt-driver-bhyve.m4 b/m4/virt-driver-bhyve.m4 index 9c0030b..c65b15d 100644 --- a/m4/virt-driver-bhyve.m4 +++ b/m4/virt-driver-bhyve.m4 @@ -28,7 +28,7 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_BHYVE],[ AC_PATH_PROG([BHYVECTL], [bhyvectl], [], [$PATH:/usr/sbin]) AC_PATH_PROG([BHYVELOAD], [bhyveload], [], [$PATH:/usr/sbin/]) - if test -z "$BHYVE" || test -z "$BHYVECTL" \ + if test -z "$BHYVE" || test -z "$BHYVECTL" || \ test -z "$BHYVELOAD" || test "$with_freebsd" = "no"; then if test "$with_bhyve" = "check"; then with_bhyve="no" -- 1.9.3

2 2

[libvirt] [PATCH] vmx: Relax virtualHW.version check
by Matthias Bolte 07 Jun '14

07 Jun '14

The original implementation of the VMX config parser assumed that the virtualHW.version would have more influence on the content of the VMX file than it actually seems to have. It started with accepting only version 4. Additonal versions were added later without any additional changes in the parser itself. This suggests that the influence of the virtualHW.version on the content and format of the VMX file is small or non-existent. The parser worked without any changes across several virtualHW and vSphere versions. So instead of adding new virtualHW.version values to the parser as they come along, or adding an extra flag to allow unknown virtualHW.version values just relax the check to require version 4 or later. --- This patch is meant as a alternative for this patch series: https://www.redhat.com/archives/libvir-list/2014-May/msg00122.html src/vmx/vmx.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c index 169440c..ce228d4 100644 --- a/src/vmx/vmx.c +++ b/src/vmx/vmx.c @@ -1316,12 +1316,10 @@ virVMXParseConfig(virVMXContext *ctx, goto cleanup; } - if (virtualHW_version != 4 && virtualHW_version != 7 && - virtualHW_version != 8 && virtualHW_version != 9 && - virtualHW_version != 10) { + if (virtualHW_version < 4) { virReportError(VIR_ERR_INTERNAL_ERROR, _("Expecting VMX entry 'virtualHW.version' to be " - "4, 7, 8, 9 or 10 but found %lld"), + "4 or higher but found %lld"), virtualHW_version); goto cleanup; } -- 1.8.1.2

2 2

[libvirt] QMP fallback race in libvirt
by Ron 07 Jun '14

07 Jun '14

Hi, Eric asked me to move this here from #virt so it doesn't get forgotten. I hit a weird bug in a new install of libvirt on Debian Jessie this week where a vm could not be configured to use any CPU type except passthrough. After much digging and headscratching, the immediate cause for that turns out to be one of the (three) files in the qemu/capabilities cache being generated wrongly the first time that libvirtd was started. Instead of being generated from the QMP queries, it appears to have fallen back to the old method of scraping 'qemu -cpu help', and since the output of that changed with qemu 2.0 it leads to things like: <cpu name='SandyBridge Intel Xeon E312xx (Sandy Bridge) '/> and hilarity then ensues when cpuModelIsAllowed() is called by x86Decode(). Since only one of the cache files there was corrupted like this, it would appear libvirt either didn't wait long enough, or didn't try hard enough, to get a connection to the monitor for the QMP query on what was probably also the very first time qemu had been started on this host machine. After nuking the cache files and restarting libvirtd they were then correctly regenerated, and things began to work as expected. This was all done on a new clean install of the host machine, so there was nothing around from any earlier versions to get tangled up with, and possibly means qemu had some first time init of its own to do which took some time before it was ready to be queried. I am also seeing bursts of several of these warnings in the logs: libvirtd[26475]: This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous Which I haven't confirmed as being related, but doesn't seem to be obviously unrelated either, and at worst is a separate bug. Cheers, Ron

1 0

[libvirt] libvirt, libxl and <channels>
by Dave Scott 06 Jun '14

06 Jun '14

Hi, Two of the applications I’d like to use with libvirt (cloudstack and oVirt) make use of “<channels>” in the domain XML, like this: <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/s-4-VM.agent'/> <target type='virtio' name='s-4-VM.vport'/> <address type='virtio-serial'/> </channel> I don’t believe these are currently supported by libvirt + libxl — I’d like to see what it would take to hook these up. I chatted with Daniel Berrange at the Xen hackathon last week, and if I understood correctly these channels are analogous to serial ports used for low-bandwidth communication to (e.g.) guest agents. Daniel suggested that the xen console mechanism ought to be adequate to power these things. The other option (if higher bandwidth was required) would be to use the Xen vchan protocol. I think the behaviour is: * bind a unix domain socket on the host (‘/var/lib/libvirt/qemu/…') * connect a bidirectional low-bandwidth channel to the guest * manifest the channel in the guest as a ‘/dev/vport/s-4-VM.vport’ device (?) So an application on the host can connect() to the host socket, an application in the guest can open() the guest device and they can talk privately. [Have I got this right?] I had a quick read of the libxl code and I think the consoles are considered an internal detail: there is a function libxl_console_get_tty to retrieve a console’s endpoint in dom0 but I couldn’t see a way to request additional consoles are created. The libxl_domain_config has disks, nics, pcidevs, vfbs, vkbs, and vtpms but no consoles. (Have I missed something?) Bypassing libxl I was able to manually create a /local/domain/%d/device/console/1 which was recognised by the VM as /dev/hvc1. As an aside, I notice that there are 2 console backends now: xenconsoled seems to only watch for the initial console, while a per-domain qemu process is used for all subsequent consoles, so any enhancements to the dom0 end would have to go into qemu? So to implement channels via consoles I would need to: 1. check if qemu when acting as a console server in dom0 is able to connect the console to a suitably named Unix domain socket in dom0 (signalled via xenstore in the usual way) 2. modify libxl to support consoles as configurable devices alongside disks, nics etc 3. add support to libvirt’s libxl driver 4. see if I can write something like a udev rule in the guest to notice the console, look up the ‘name’ from xenstore and make a suitably-named file? What do you think? Cheers, Dave

2 2

[libvirt] [PATCH] Fix virbitmaptest on 32-bit
by Ján Tomko 06 Jun '14

06 Jun '14

My commit 7d8afc4 was passing the incorrect size to virBitmapDataToString in the newly added test. --- Pushed as a trivial paper-bag build breaker fix. tests/virbitmaptest.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/virbitmaptest.c b/tests/virbitmaptest.c index 139b8e2..048946f 100644 --- a/tests/virbitmaptest.c +++ b/tests/virbitmaptest.c @@ -313,7 +313,7 @@ test5(const void *v ATTRIBUTE_UNUSED) if (STRNEQ(str, "0,9,34")) goto error; VIR_FREE(str); - if (!(str = virBitmapDataToString(data2, sizeof(data2)))) + if (!(str = virBitmapDataToString(data2, len2))) goto error; if (STRNEQ(str, "0,2,9,15,34")) goto error; -- 1.8.3.2

1 0

[libvirt] [PATCH] nodedev: Export NUMA node locality for PCI devices
by Michal Privoznik 06 Jun '14

06 Jun '14

A PCI device can be associated with a specific NUMA node. Later, when a guest is pinned to one NUMA node the PCI device can be assigned on different NUMA node. This makes DMA transfers travel across nodes and thus results in suboptimal performance. We should expose the NUMA node locality for PCI devices so management applications can make better decisions. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- The only difference to the previous round is, I'm sending it as standalone patch for easier review. docs/formatnode.html.in | 7 ++++ docs/schemas/nodedev.rng | 10 +++++ src/conf/node_device_conf.c | 44 ++++++++++++++++++++++ src/conf/node_device_conf.h | 1 + src/node_device/node_device_udev.c | 7 ++++ tests/nodedevschemadata/pci_1002_71c4.xml | 1 + tests/nodedevschemadata/pci_8086_10c9_sriov_pf.xml | 1 + 7 files changed, 71 insertions(+) diff --git a/docs/formatnode.html.in b/docs/formatnode.html.in index b424c96..76bf8af 100644 --- a/docs/formatnode.html.in +++ b/docs/formatnode.html.in @@ -110,6 +110,13 @@ have a list of <code>address</code> subelements, one for each VF on this PF. </dd> + <dt><code>numa</code></dt> + <dd> + This optional element contains information on the PCI device + with respect to NUMA. For example, the optional + <code>node</code> attribute tells which NUMA node is the PCI + device associated with. + </dd> </dl> </dd> <dt><code>usb_device</code></dt> diff --git a/docs/schemas/nodedev.rng b/docs/schemas/nodedev.rng index 81ab4d4..02d4106 100644 --- a/docs/schemas/nodedev.rng +++ b/docs/schemas/nodedev.rng @@ -158,6 +158,16 @@ </element> </optional> + <optional> + <element name='numa'> + <optional> + <attribute name='node'> + <data type='int'/> + </attribute> + </optional> + </element> + </optional> + </define> <define name='capusbdev'> diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c index e65b5e4..99fa448 100644 --- a/src/conf/node_device_conf.c +++ b/src/conf/node_device_conf.c @@ -346,6 +346,9 @@ char *virNodeDeviceDefFormat(const virNodeDeviceDef *def) virBufferAdjustIndent(&buf, -2); virBufferAddLit(&buf, "</iommuGroup>\n"); } + if (data->pci_dev.numa_node >= 0) + virBufferAsprintf(&buf, "<numa node='%d'/>\n", + data->pci_dev.numa_node); break; case VIR_NODE_DEV_CAP_USB_DEV: virBufferAsprintf(&buf, "<bus>%d</bus>\n", data->usb_dev.bus); @@ -520,6 +523,41 @@ char *virNodeDeviceDefFormat(const virNodeDeviceDef *def) return NULL; } +/** + * virNodeDevCapsDefParseIntOptional: + * @xpath: XPath to evaluate + * @ctxt: Context + * @value: Where to store parsed value + * @def: Node device which is parsed + * @invalid_error_fmt: error message to print on invalid format + * + * Returns: -1 on error (invalid int format under @xpath) + * 0 if @xpath was not found (@value is untouched) + * 1 on success + */ +static int +virNodeDevCapsDefParseIntOptional(const char *xpath, + xmlXPathContextPtr ctxt, + int *value, + virNodeDeviceDefPtr def, + const char *invalid_error_fmt) +{ + int ret; + int val; + + ret = virXPathInt(xpath, ctxt, &val); + if (ret < -1) { + virReportError(VIR_ERR_INTERNAL_ERROR, + invalid_error_fmt, + def->name); + return -1; + } else if (ret == -1) { + return 0; + } + *value = val; + return 1; +} + static int virNodeDevCapsDefParseULong(const char *xpath, xmlXPathContextPtr ctxt, @@ -1101,6 +1139,12 @@ virNodeDevCapPCIDevParseXML(xmlXPathContextPtr ctxt, goto out; } } + + if (virNodeDevCapsDefParseIntOptional("number(./numa[1]/@node)", ctxt, + &data->pci_dev.numa_node, def, + _("invalid NUMA node ID supplied for '%s'")) < 0) + goto out; + ret = 0; out: ctxt->node = orignode; diff --git a/src/conf/node_device_conf.h b/src/conf/node_device_conf.h index 50e6805..50ce4b3 100644 --- a/src/conf/node_device_conf.h +++ b/src/conf/node_device_conf.h @@ -115,6 +115,7 @@ struct _virNodeDevCapsDef { virPCIDeviceAddressPtr *iommuGroupDevices; size_t nIommuGroupDevices; unsigned int iommuGroupNumber; + int numa_node; } pci_dev; struct { unsigned int bus; diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 9a951d9..8e98ad2 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -493,6 +493,13 @@ static int udevProcessPCI(struct udev_device *device, goto out; } + if (udevGetIntSysfsAttr(device, + "numa_node", + &data->pci_dev.numa_node, + 10) == PROPERTY_ERROR) { + goto out; + } + if (!virPCIGetPhysicalFunction(syspath, &data->pci_dev.physical_function)) data->pci_dev.flags |= VIR_NODE_DEV_CAP_FLAG_PCI_PHYSICAL_FUNCTION; diff --git a/tests/nodedevschemadata/pci_1002_71c4.xml b/tests/nodedevschemadata/pci_1002_71c4.xml index 6de09c1..6d5d85b 100644 --- a/tests/nodedevschemadata/pci_1002_71c4.xml +++ b/tests/nodedevschemadata/pci_1002_71c4.xml @@ -8,5 +8,6 @@ <function>0</function> <product id='0x71c4'>M56GL [Mobility FireGL V5200]</product> <vendor id='0x1002'>ATI Technologies Inc</vendor> + <numa node='1'/> </capability> </device> diff --git a/tests/nodedevschemadata/pci_8086_10c9_sriov_pf.xml b/tests/nodedevschemadata/pci_8086_10c9_sriov_pf.xml index eff8932..6e1dc86 100644 --- a/tests/nodedevschemadata/pci_8086_10c9_sriov_pf.xml +++ b/tests/nodedevschemadata/pci_8086_10c9_sriov_pf.xml @@ -12,5 +12,6 @@ <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> <address domain='0x0000' bus='0x02' slot='0x00' function='0x1'/> </iommuGroup> + <numa node='0'/> </capability> </device> -- 2.0.0

2 2

[libvirt] [PATCH 0/6] Print cpu maps in human readable form
by Ján Tomko 06 Jun '14

06 Jun '14

Consistently report errors in virBitmapFormat and introduce a flag for vcpuinfo and nodecpumap for more readable cpu map outputs. Ján Tomko (6): Invert logic in cmdVcpuinfo Separate API calls and result printing in cmdVcpuinfo Format NULL bitmap as an empty string Always report an error if virBitmapFormat fails Introudce virBitmapDataToString Implement pretty flag for vcpuinfo and nodecpumap src/conf/capabilities.c | 4 +- src/conf/domain_conf.c | 19 ++-------- src/conf/network_conf.c | 2 +- src/libvirt_private.syms | 1 + src/libxl/libxl_driver.c | 3 +- src/lxc/lxc_cgroup.c | 11 +----- src/qemu/qemu_cgroup.c | 16 ++------ src/qemu/qemu_driver.c | 12 ++---- src/util/virbitmap.c | 32 +++++++++++++--- src/util/virbitmap.h | 7 +++- src/util/virstring.h | 1 - tests/virbitmaptest.c | 14 ++++++- tools/virsh-domain.c | 97 +++++++++++++++++++++++++----------------------- tools/virsh-host.c | 25 +++++++++++-- 14 files changed, 134 insertions(+), 110 deletions(-) -- 1.8.3.2

3 19