[libvirt] [PATCH] Force FLR on for buggy SR-IOV devices.
by Chris Lalancette
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
14 years, 9 months
[libvirt] [RFC PATCH 0/4] fix secondary bus reset with active devices logic
by Chris Wright
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(-)
14 years, 9 months
[libvirt] libvirt on x64
by Tavares, John
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
14 years, 9 months
[libvirt] [PATCH] build: fix VPATH builds
by Eric Blake
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
14 years, 9 months
[libvirt] [PATCH] Force FLR on for buggy SR-IOV devices.
by Chris Lalancette
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
14 years, 9 months
[libvirt] Parameters for macros in docs?
by Justin Clift
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
14 years, 9 months
[libvirt] IO controller groups?
by Jon Masters
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.
14 years, 9 months
[libvirt] [PATCH] esx: Support vSphere 4.1
by Matthias Bolte
Also accept version > 4.1, but output a warning.
---
src/esx/esx_driver.c | 12 ++++++++----
src/esx/esx_vi.c | 27 ++++++++++++++++++++++++---
src/esx/esx_vi.h | 10 ++++++++--
src/esx/esx_vmx.c | 9 +++++++++
4 files changed, 49 insertions(+), 9 deletions(-)
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
index 5922cb6..e33976c 100644
--- a/src/esx/esx_driver.c
+++ b/src/esx/esx_driver.c
@@ -353,9 +353,11 @@ esxConnectToHost(esxPrivate *priv, virConnectAuthPtr auth,
if (expectedProductVersion == esxVI_ProductVersion_ESX) {
if (priv->host->productVersion != esxVI_ProductVersion_ESX35 &&
- priv->host->productVersion != esxVI_ProductVersion_ESX40) {
+ priv->host->productVersion != esxVI_ProductVersion_ESX40 &&
+ priv->host->productVersion != esxVI_ProductVersion_ESX41 &&
+ priv->host->productVersion != esxVI_ProductVersion_ESX4x) {
ESX_ERROR(VIR_ERR_INTERNAL_ERROR,
- _("%s is neither an ESX 3.5 host nor an ESX 4.0 host"),
+ _("%s is neither an ESX 3.5 host nor an ESX 4.x host"),
hostname);
goto cleanup;
}
@@ -462,10 +464,12 @@ esxConnectToVCenter(esxPrivate *priv, virConnectAuthPtr auth,
}
if (priv->vCenter->productVersion != esxVI_ProductVersion_VPX25 &&
- priv->vCenter->productVersion != esxVI_ProductVersion_VPX40) {
+ priv->vCenter->productVersion != esxVI_ProductVersion_VPX40 &&
+ priv->vCenter->productVersion != esxVI_ProductVersion_VPX41 &&
+ priv->vCenter->productVersion != esxVI_ProductVersion_VPX4x) {
ESX_ERROR(VIR_ERR_INTERNAL_ERROR,
_("%s is neither a vCenter 2.5 server nor a vCenter "
- "4.0 server"), hostname);
+ "4.x server"), hostname);
goto cleanup;
}
diff --git a/src/esx/esx_vi.c b/src/esx/esx_vi.c
index 8c43d67..69ba7a9 100644
--- a/src/esx/esx_vi.c
+++ b/src/esx/esx_vi.c
@@ -378,9 +378,16 @@ esxVI_Context_Connect(esxVI_Context *ctx, const char *url,
ctx->apiVersion = esxVI_APIVersion_25;
} else if (STRPREFIX(ctx->service->about->apiVersion, "4.0")) {
ctx->apiVersion = esxVI_APIVersion_40;
+ } else if (STRPREFIX(ctx->service->about->apiVersion, "4.1")) {
+ ctx->apiVersion = esxVI_APIVersion_41;
+ } else if (STRPREFIX(ctx->service->about->apiVersion, "4.")) {
+ ctx->apiVersion = esxVI_APIVersion_4x;
+
+ VIR_WARN("Found untested VI API major/minor version '%s'",
+ ctx->service->about->apiVersion);
} else {
ESX_VI_ERROR(VIR_ERR_INTERNAL_ERROR,
- _("Expecting VI API major/minor version '2.5' or '4.0' "
+ _("Expecting VI API major/minor version '2.5' or '4.x' "
"but found '%s'"), ctx->service->about->apiVersion);
goto cleanup;
}
@@ -400,10 +407,17 @@ esxVI_Context_Connect(esxVI_Context *ctx, const char *url,
ctx->productVersion = esxVI_ProductVersion_ESX35;
} else if (STRPREFIX(ctx->service->about->version, "4.0")) {
ctx->productVersion = esxVI_ProductVersion_ESX40;
+ } else if (STRPREFIX(ctx->service->about->version, "4.1")) {
+ ctx->productVersion = esxVI_ProductVersion_ESX41;
+ } else if (STRPREFIX(ctx->service->about->version, "4.")) {
+ ctx->productVersion = esxVI_ProductVersion_ESX4x;
+
+ VIR_WARN("Found untested ESX major/minor version '%s'",
+ ctx->service->about->version);
} else {
ESX_VI_ERROR(VIR_ERR_INTERNAL_ERROR,
_("Expecting ESX major/minor version '3.5' or "
- "'4.0' but found '%s'"),
+ "'4.x' but found '%s'"),
ctx->service->about->version);
goto cleanup;
}
@@ -412,9 +426,16 @@ esxVI_Context_Connect(esxVI_Context *ctx, const char *url,
ctx->productVersion = esxVI_ProductVersion_VPX25;
} else if (STRPREFIX(ctx->service->about->version, "4.0")) {
ctx->productVersion = esxVI_ProductVersion_VPX40;
+ } else if (STRPREFIX(ctx->service->about->version, "4.1")) {
+ ctx->productVersion = esxVI_ProductVersion_VPX41;
+ } else if (STRPREFIX(ctx->service->about->version, "4.")) {
+ ctx->productVersion = esxVI_ProductVersion_VPX4x;
+
+ VIR_WARN("Found untested VPX major/minor version '%s'",
+ ctx->service->about->version);
} else {
ESX_VI_ERROR(VIR_ERR_INTERNAL_ERROR,
- _("Expecting VPX major/minor version '2.5' or '4.0' "
+ _("Expecting VPX major/minor version '2.5' or '4.x' "
"but found '%s'"), ctx->service->about->version);
goto cleanup;
}
diff --git a/src/esx/esx_vi.h b/src/esx/esx_vi.h
index f5e89e9..9eb5094 100644
--- a/src/esx/esx_vi.h
+++ b/src/esx/esx_vi.h
@@ -94,7 +94,9 @@ enum _esxVI_APIVersion {
esxVI_APIVersion_Undefined = 0,
esxVI_APIVersion_Unknown,
esxVI_APIVersion_25,
- esxVI_APIVersion_40
+ esxVI_APIVersion_40,
+ esxVI_APIVersion_41,
+ esxVI_APIVersion_4x /* > 4.1 */
};
/*
@@ -110,10 +112,14 @@ enum _esxVI_ProductVersion {
esxVI_ProductVersion_ESX = (1 << 1) << 16,
esxVI_ProductVersion_ESX35 = esxVI_ProductVersion_ESX | 1,
esxVI_ProductVersion_ESX40 = esxVI_ProductVersion_ESX | 2,
+ esxVI_ProductVersion_ESX41 = esxVI_ProductVersion_ESX | 3,
+ esxVI_ProductVersion_ESX4x = esxVI_ProductVersion_ESX | 4, /* > 4.1 */
esxVI_ProductVersion_VPX = (1 << 2) << 16,
esxVI_ProductVersion_VPX25 = esxVI_ProductVersion_VPX | 1,
- esxVI_ProductVersion_VPX40 = esxVI_ProductVersion_VPX | 2
+ esxVI_ProductVersion_VPX40 = esxVI_ProductVersion_VPX | 2,
+ esxVI_ProductVersion_VPX41 = esxVI_ProductVersion_VPX | 3,
+ esxVI_ProductVersion_VPX4x = esxVI_ProductVersion_VPX | 4 /* > 4.1 */
};
enum _esxVI_Occurrence {
diff --git a/src/esx/esx_vmx.c b/src/esx/esx_vmx.c
index e075149..c63b159 100644
--- a/src/esx/esx_vmx.c
+++ b/src/esx/esx_vmx.c
@@ -1184,6 +1184,7 @@ esxVMX_ParseConfig(esxVI_Context *ctx, virCapsPtr caps, const char *vmx,
* 4 7 API
* ESX 3.5 + 2.5
* ESX 4.0 + + 4.0
+ * ESX 4.1 + + 4.1
* GSX 2.0 + + 2.5
*/
switch (productVersion) {
@@ -1201,7 +1202,9 @@ esxVMX_ParseConfig(esxVI_Context *ctx, virCapsPtr caps, const char *vmx,
case esxVI_ProductVersion_GSX20:
case esxVI_ProductVersion_ESX40:
+ case esxVI_ProductVersion_ESX41:
case esxVI_ProductVersion_VPX40:
+ case esxVI_ProductVersion_VPX41:
if (virtualHW_version != 4 && virtualHW_version != 7) {
ESX_ERROR(VIR_ERR_INTERNAL_ERROR,
_("Expecting VMX entry 'virtualHW.version' to be 4 or 7 "
@@ -1212,6 +1215,10 @@ esxVMX_ParseConfig(esxVI_Context *ctx, virCapsPtr caps, const char *vmx,
break;
+ case esxVI_ProductVersion_ESX4x:
+ case esxVI_ProductVersion_VPX4x:
+ break;
+
default:
ESX_ERROR(VIR_ERR_INTERNAL_ERROR, "%s",
_("Unexpected product version"));
@@ -2702,6 +2709,8 @@ esxVMX_FormatConfig(esxVI_Context *ctx, virCapsPtr caps, virDomainDefPtr def,
case esxVI_ProductVersion_GSX20:
case esxVI_ProductVersion_ESX40:
+ case esxVI_ProductVersion_ESX41:
+ case esxVI_ProductVersion_ESX4x:
virBufferAddLit(&buffer, "virtualHW.version = \"7\"\n");
break;
--
1.7.0.4
14 years, 9 months
[libvirt] [PATCH] esx: Don't ignore the vcenter query parameter
by Matthias Bolte
Since 070f61002f47b602c15d1e4950a122ac9edefe1b the vcenter query
parameter has been ignored, because the refactoring to use
esxUtil_ParseQuery was incomplete. This effectively broke migration,
because the vcenter query parameter is essential for a migration.
---
src/esx/esx_driver.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
index acf8908..33f421d 100644
--- a/src/esx/esx_driver.c
+++ b/src/esx/esx_driver.c
@@ -475,11 +475,18 @@ esxOpen(virConnectPtr conn, virConnectAuthPtr auth, int flags ATTRIBUTE_UNUSED)
}
/* Login to vCenter */
- if (vCenter != NULL) {
+ if (parsedQuery->vCenter != NULL) {
VIR_FREE(url);
VIR_FREE(password);
VIR_FREE(username);
+ vCenter = strdup(parsedQuery->vCenter);
+
+ if (vCenter == NULL) {
+ virReportOOMError();
+ goto cleanup;
+ }
+
/* If a vCenter is specified resolve the hostname */
if (STRNEQ(vCenter, "*") &&
esxUtil_ResolveHostname(vCenter, vCenterIpAddress,
--
1.7.0.4
14 years, 9 months
