Re: [libvirt] [Qemu-devel] Question about how to distinguish a usb device in usb pass-through feature
by Gonglei (Arei)
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
10 years, 5 months
[libvirt] [PATCH] m4: bhyve: Fix check for the required bhyve programs
by Peter Krempa
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
10 years, 5 months
[libvirt] [PATCH] vmx: Relax virtualHW.version check
by Matthias Bolte
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
10 years, 5 months
[libvirt] QMP fallback race in libvirt
by Ron
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
10 years, 5 months
[libvirt] libvirt, libxl and <channels>
by Dave Scott
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
10 years, 5 months
[libvirt] [PATCH] Fix virbitmaptest on 32-bit
by Ján Tomko
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
10 years, 5 months
[libvirt] [PATCH] nodedev: Export NUMA node locality for PCI devices
by Michal Privoznik
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
10 years, 5 months
[libvirt] [PATCH 0/6] Print cpu maps in human readable form
by Ján Tomko
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
10 years, 5 months
[libvirt] [PATCH 0/3] Parallels: patch set
by Alexander Burluka
From: A.Burluka <aburluka(a)parallels.com>
I've fixed my previous patches after Libvirt community reviews
(thanks to Eric Blake and Daniel P. Berrange).
Parallels team continues working on Libvirt Parallels driver integration
with OpenStack.
A.Burluka (3):
Parallels: add domainGetVcpus().
Parallels: add connectBaselineCPU().
Parallels: Include CPU info in the capabilities XML
10 years, 5 months
[libvirt] [PATCH] Remove ssp buffer size setting
by Ján Tomko
This option only makes sense with -fstack-protector.
With -fstack-protector-all, even functions with buffers
smaller than this are protected.
https://bugzilla.redhat.com/show_bug.cgi?id=1105456
---
m4/virt-compile-warnings.m4 | 8 --------
1 file changed, 8 deletions(-)
diff --git a/m4/virt-compile-warnings.m4 b/m4/virt-compile-warnings.m4
index 574fbc4..ebc931d 100644
--- a/m4/virt-compile-warnings.m4
+++ b/m4/virt-compile-warnings.m4
@@ -171,14 +171,6 @@ AC_DEFUN([LIBVIRT_COMPILE_WARNINGS],[
dnl be great overhead in adding -fstack-protector-all instead
dnl wantwarn="$wantwarn -fstack-protector"
wantwarn="$wantwarn -fstack-protector-all"
- wantwarn="$wantwarn --param=ssp-buffer-size=4"
- dnl Even though it supports it, clang complains about
- dnl use of --param=ssp-buffer-size=4 unless used with
- dnl the -c arg. It doesn't like it when used with args
- dnl that just link together .o files. Unfortunately
- dnl we can't avoid that with automake, so we must turn
- dnl off the following clang specific warning
- wantwarn="$wantwarn -Wno-unused-command-line-argument"
;;
*-*-freebsd*)
dnl FreeBSD ships old gcc 4.2.1 which doesn't handle
--
1.8.3.2
10 years, 5 months
