[libvirt] [PATCH] pci: add support for VMD domains
by Jon Derrick
VMD domains start at 0x10000, so expand dev->name to fit at least this
many characters.
Signed-off-by: Jon Derrick <jonathan.derrick(a)intel.com>
---
src/util/virpci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virpci.c b/src/util/virpci.c
index 2c1b758..b3afefe 100644
--- a/src/util/virpci.c
+++ b/src/util/virpci.c
@@ -50,7 +50,7 @@ VIR_LOG_INIT("util.pci");
#define PCI_SYSFS "/sys/bus/pci/"
#define PCI_ID_LEN 10 /* "XXXX XXXX" */
-#define PCI_ADDR_LEN 13 /* "XXXX:XX:XX.X" */
+#define PCI_ADDR_LEN 14 /* "XXXXX:XX:XX.X" */
VIR_ENUM_IMPL(virPCIELinkSpeed, VIR_PCIE_LINK_SPEED_LAST,
"", "2.5", "5", "8", "16")
--
2.9.3
7 years, 4 months
[libvirt] [PATCH 00/10] conf: Clean up virDomain*Def creation
by Andrea Bolognani
This series is required to solve a known limitation in the
current incarnation of device isolation support[1], namely
the inability to isolate host devices coming from IOMMU
group 0.
The issue lies in the fact that virDomainDeviceInfo, and
all virDomain*Def that embed it, are usually allocated
through VIR_ALLOC(), which result in all their fields being
initialized to zero.
That's worked out just fine so far, because zero was a
sensible default value for all existing fields; however,
when implementing isolation groups, we add a new
virDomainDeviceInfo::isolationGroup field which we need
to be initialized to -1 instead so that it doesn't overlap
with IOMMU group 0 mentioned above.
Solving the issue involves creating twenty or so
virDomain*DefNew() functions and using them instead of
VIR_ALLOC() every time a virDomain*Def needs to be created,
which is arguably a pretty good idea regardless.
The series could probably be organized so that eg. the
patch order makes more sense, but honestly I'm pretty
tired right now and I just don't have it in me. Moreover,
the goal of the series and its implementation are both
straighforward enough that I feel reviewers will have no
problem following along.
My main concern with this series is that, while converting
from VIR_ALLOC() to virDomain*DefNew(), I might simply have
missed some instances. That would not cause any issue right
away, but once we introduce isolation groups it would lead
to suboptimal PCI addresses being allocated at best, and to
perfectly legitimate hotplug requests being denied at worst.
The fact that the test suite[2] passes gives me a lot of
confidence that I haven't overlooked anything, but if
anyone has clever ideas on how to be actually sure rather
than merely confident please do let me know.
[1] https://www.redhat.com/archives/libvir-list/2017-June/msg01018.html
[2] That is, the version of it where the default isolation
group being initialized correctly actually matters
Andrea Bolognani (10):
conf: Make virDomainDeviceGetInfo() private
conf: Rename virDomainHostdevDefAlloc() to virDomainHostdevDefNew()
conf: Clean up virDomainHostdevDefNew()
conf: Clean up virDomain{Memory,Shmem}DefParseXML()
conf: Move some virDomainDeviceInfo functions
conf: Introduce virDomainDeviceInfoNew()
conf: Clean up virDomainDeviceInfo functions
conf, qemu: Use virDomainDeviceInfoNew()
conf: Provide missing virDomain*DefNew() functions
conf: Call virDomainDeviceInfoClear() in virDomain*DefNew()
src/bhyve/bhyve_parse_command.c | 4 +-
src/conf/device_conf.c | 146 ++++++++++++
src/conf/device_conf.h | 9 +
src/conf/domain_addr.c | 6 +-
src/conf/domain_conf.c | 486 ++++++++++++++++++++++++----------------
src/conf/domain_conf.h | 25 ++-
src/libvirt_private.syms | 19 +-
src/lxc/lxc_native.c | 2 +-
src/openvz/openvz_conf.c | 2 +-
src/qemu/qemu_command.c | 12 +-
src/qemu/qemu_domain.c | 11 +-
src/qemu/qemu_domain_address.c | 31 +--
src/qemu/qemu_hotplug.c | 5 +-
src/qemu/qemu_parse_command.c | 31 +--
src/vbox/vbox_common.c | 14 +-
src/vmx/vmx.c | 2 +-
src/vz/vz_sdk.c | 6 +-
src/xen/xen_driver.c | 2 +-
src/xenapi/xenapi_driver.c | 2 +-
src/xenconfig/xen_common.c | 4 +-
src/xenconfig/xen_sxpr.c | 10 +-
src/xenconfig/xen_xl.c | 4 +-
src/xenconfig/xen_xm.c | 2 +-
tests/virhostdevtest.c | 2 +-
24 files changed, 561 insertions(+), 276 deletions(-)
--
2.7.5
7 years, 4 months
[libvirt] [PATCH] qemu: Don't update CPU when checking ABI stability
by Jiri Denemark
When checking ABI stability between two domain definitions, we first
make migratable copies of them. However, we also asked for the guest CPU
to be updated, even though the updated CPU is supposed to be already
included in the original definitions. Moreover, if we do this on the
destination host during migration, we're potentially updating the
definition with according to an incompatible host CPU.
While updating the CPU when checking ABI stability doesn't make any
sense, it actually just worked because updating the CPU doesn't do
anything for custom CPUs (only host-model CPUs are affected) and we
updated both definitions in the same way.
Less then a year ago commit v2.3.0-rc1~42 stopped updating the CPU in
the definition we got internally and only the user supplied definition
was updated. However, the same commit started updating host-model CPUs
to custom CPUs which are not affected by the request to update the CPU.
So it still seemed to work right, unless a user upgraded libvirt 2.2.0
to a newer version while there were some domains with host-model CPUs
running on the host. Such domains couldn't be migrated with a user
supplied XML since libvirt would complain:
Target CPU mode custom does not match source host-model
The fix is pretty straightforward, we just need to stop updating the CPU
when checking ABI stability.
https://bugzilla.redhat.com/show_bug.cgi?id=1463957
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/qemu/qemu_domain.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 8e7404da6..d9357f20c 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -5926,7 +5926,6 @@ qemuDomainMigratableDefCheckABIStability(virQEMUDriverPtr driver,
#define COPY_FLAGS (VIR_DOMAIN_XML_SECURE | \
- VIR_DOMAIN_XML_UPDATE_CPU | \
VIR_DOMAIN_XML_MIGRATABLE)
bool
--
2.13.2
7 years, 4 months
[libvirt] [PATCH 0/3] Add setting CPU features (CPUID) with libxenlight driver.
by Marek Marczykowski-Górecki
Marek Marczykowski-Górecki (3):
cpu: define sub-leaf 0 for leaf 7 in cpu_map.xml
libxl: add support for CPUID features policy
tests: check domain XML to libxl structures conversion
src/cpu/cpu_map.xml | 58 +++++------
src/libxl/libxl_conf.c | 139 ++++++++++++++++++++-----
src/libxl/libxl_conf.h | 1 +-
tests/Makefile.am | 8 +-
tests/libxlxmltest.c | 232 ++++++++++++++++++++++++++++++++++++++++++-
5 files changed, 383 insertions(+), 55 deletions(-)
create mode 100644 tests/libxlxmltest.c
base-commit: f914b3f2d24d05615095e5ab5b0c91560c4dc903
--
git-series 0.9.1
7 years, 4 months
[libvirt] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host
by Michael Roth
Hi everyone. Hoping to get some feedback on this approach, or some
alternatives proposed below, to the following issue:
Currently libvirt immediately attempts to rebind a managed device back to the
host driver when it receives a DEVICE_DELETED event from QEMU. This is
problematic for 2 reasons:
1) If multiple devices from a group are attached to a guest, this can move
the group into a "non-viable" state where some devices are assigned to
the host and some to the guest.
2) When QEMU emits the DEVICE_DELETED event, there's still a "finalize" phase
where additional cleanup occurs. In most cases libvirt can ignore this
cleanup, but in the case of VFIO devices this is where closing of a VFIO
group FD occurs, and failing to wait before rebinding the device to the
host driver can result in unexpected behavior. In the case of powernv
hosts at least, this can lead to a host driver crashing due to the default
DMA windows not having been fully-restored yet. The window between this is
and the initial DEVICE_DELETED seems to be ~6 seconds in practice. We've
seen host dumps with Mellanox CX4 VFs being rebound to host driver during
this period (on powernv hosts).
Patches 1-4 address 1) by deferring rebinding of a hostdev to the host driver
until all the devices in the group have been detached, at which point all
the hostdevs are rebound as a group. Until that point, the devices are traced
by the drvManager's inactiveList in a similar manner to hostdevs that are
assigned to VFIO via the nodedev-detach interface.
Patch 5 addresses 2) by adding an additional check that, when the last device
from a group is detached, polls /proc for open FDs referencing the VFIO group
path in /dev/vfio/<iommu_group> and waiting for the FD to be closed. If we
time out, we abandon rebinding the hostdevs back to the host.
There are a couple alternatives to Patch 5 that might be worth considering:
a) Add a DEVICE_FINALIZED event to QEMU and wait for that instead of
DEVICE_DELETED. Paired with patches 1-4 this would let us drop patch 5 in
favor of minimal changes to libvirt's event handlers.
The downsides are:
- that we'd incur some latency for all device-detach calls, but it's not
apparent to me whether this delay is significant for anything outside
of VFIO.
- there may be cases where finalization after DEVICE_DELETE/unparent are
is not guaranteed, and I'm not sure QOM would encourage such
expectations even if that's currently the case.
b) Add a GROUP_DELETED event to VFIO's finalize callback. This is the most
direct solution. With this we could completely separate out the handling
of rebinding to host driver based on receival of this event.
The downsides are:
- this would only work for newer versions of QEMU, though we could use
the poll-wait in patch 5 as a fallback.
- synchronizing sync/async device-detach threads with sync/async
handlers for this would be a bit hairy, but I have a WIP in progress
that seems *fairly reasonable*
c) Take the approach in Patch 5, either as a precursor to implementing b) or
something else, or just sticking with that for now.
d) ???
Personally I'm leaning toward c), but I'm wondering if that's "good enough"
for now, or if we should pursue something more robust from the start, or
perhaps something else entirely?
Any feedback is greatly appreciated!
src/libvirt_private.syms | 5 ++
src/qemu/qemu_hostdev.c | 16 +++++
src/qemu/qemu_hostdev.h | 4 ++
src/qemu/qemu_hotplug.c | 56 ++++++++++++++----
src/util/virfile.c | 52 +++++++++++++++++
src/util/virfile.h | 1 +
src/util/virhostdev.c | 173 ++++++++++++++++++++++++++++++++++++++++++++++++++-----
src/util/virhostdev.h | 16 +++++
src/util/virpci.c | 69 ++++++++++++++++++----
src/util/virpci.h | 4 ++
10 files changed, 360 insertions(+), 36 deletions(-)
7 years, 4 months
[libvirt] [PATCH] conf: Move virDomainPCIAddressBusIsFullyReserved()
by Andrea Bolognani
This function was private to the QEMU driver and was,
accordingly, called qemuDomainPCIBusFullyReserved().
However, since it's really not QEMU-specific at all,
it makes a lot of sense to have it closer to the
virDomainPCIAddressBus struct it operates on; even more
so considering we're going to introduce a complementary
virDomainPCIAddressBusIsEmpty() function later on.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
src/conf/domain_addr.c | 14 ++++++++++++++
src/conf/domain_addr.h | 3 +++
src/libvirt_private.syms | 1 +
src/qemu/qemu_domain_address.c | 15 +--------------
4 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
index 639168e..0ae1ed9 100644
--- a/src/conf/domain_addr.c
+++ b/src/conf/domain_addr.c
@@ -355,6 +355,20 @@ virDomainPCIAddressBusSetModel(virDomainPCIAddressBusPtr bus,
}
+bool
+virDomainPCIAddressBusIsFullyReserved(virDomainPCIAddressBusPtr bus)
+{
+ size_t i;
+
+ for (i = bus->minSlot; i <= bus->maxSlot; i++) {
+ if (!bus->slot[i].functions)
+ return false;
+ }
+
+ return true;
+}
+
+
/* Ensure addr fits in the address set, by expanding it if needed
*
* Return value:
diff --git a/src/conf/domain_addr.h b/src/conf/domain_addr.h
index f884b8a..c90a335 100644
--- a/src/conf/domain_addr.h
+++ b/src/conf/domain_addr.h
@@ -141,6 +141,9 @@ int virDomainPCIAddressBusSetModel(virDomainPCIAddressBusPtr bus,
virDomainControllerModelPCI model)
ATTRIBUTE_NONNULL(1);
+bool virDomainPCIAddressBusIsFullyReserved(virDomainPCIAddressBusPtr bus)
+ ATTRIBUTE_NONNULL(1);
+
bool virDomainPCIAddressSlotInUse(virDomainPCIAddressSetPtr addrs,
virPCIDeviceAddressPtr addr)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2);
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 888412a..d76c1a7 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -106,6 +106,7 @@ virDomainCCWAddressSetFree;
virDomainCCWAddressValidate;
virDomainGetBlkioParametersAssignFromDef;
virDomainPCIAddressAsString;
+virDomainPCIAddressBusIsFullyReserved;
virDomainPCIAddressBusSetModel;
virDomainPCIAddressEnsureAddr;
virDomainPCIAddressFlagsCompatible;
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index b5b863f..efc698d 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -1499,19 +1499,6 @@ qemuDomainValidateDevicePCISlotsChipsets(virDomainDefPtr def,
}
-static bool
-qemuDomainPCIBusFullyReserved(virDomainPCIAddressBusPtr bus)
-{
- size_t i;
-
- for (i = bus->minSlot; i <= bus->maxSlot; i++)
- if (!bus->slot[i].functions)
- return false;
-
- return true;
-}
-
-
/*
* This assigns static PCI slots to all configured devices.
* The ordering here is chosen to match the ordering used
@@ -2043,7 +2030,7 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
bool buses_reserved = true;
for (i = 0; i < addrs->nbuses; i++) {
- if (!qemuDomainPCIBusFullyReserved(&addrs->buses[i])) {
+ if (!virDomainPCIAddressBusIsFullyReserved(&addrs->buses[i])) {
buses_reserved = false;
break;
}
--
2.7.5
7 years, 4 months
[libvirt] libvirt-2.0.0 build error (hidden symbol libvirt_event_poll_update_handle_semaphore)
by longguang.yue
Hi, all:
i back port a patch which makes qemu depends on util directory.
so i correct its dependency by applying a patch. but another error occur.
the patch is http://libvirt.org/git/?p=libvirt.git;a=commit;h=57b5e27d3d74f8dbb77ac909...
the patch fix dependency :
--- libvirt-2.0.0/src/Makefile.am 2016-06-27 22:12:20.523191076 +0800
+++ libvirt-2.0.0-ok/src/Makefile.am 2017-06-22 12:25:17.512000000 +0800
@@ -1362,6 +1362,7 @@
-I$(srcdir)/access \
-I$(srcdir)/conf \
-I$(srcdir)/secret \
+ -I$(srcdir)/util \
$(AM_CFLAGS)
libvirt_driver_qemu_impl_la_LDFLAGS = $(AM_LDFLAGS)
libvirt_driver_qemu_impl_la_LIBADD = $(CAPNG_LIBS) \
@@ -1369,6 +1370,7 @@
$(LIBNL_LIBS) \
$(LIBXML_LIBS) \
libvirt_secret.la \
+ libvirt_util.la \
$(NULL)
libvirt_driver_qemu_impl_la_SOURCES = $(QEMU_DRIVER_SOURCES)
---------
BUILD ERROR:
CCLD qemucapsprobe
/bin/ld: .libs/qemucapsprobe: hidden symbol `libvirt_event_poll_update_handle_semaphore' in ../src/libvirt_probes.o is referenced by DSO
/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make[1]: *** [qemucapsprobe] Error 1
make[1]: Leaving directory `/root/libvirt-2.0/BUILD/libvirt-2.0.0/tests'
make: *** [check-am] Error 2
+ cat test-suite.log
cat: test-suite.log: No such file or directory
+ true
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.ZVbGSv (%check)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.ZVbGSv (%check)
-------------
7 years, 4 months
[libvirt] [PATCH v2 0/2] vz: fix vz driver compilation
by Mikhail Feoktistov
Mikhail Feoktistov (2):
vz: add argument xmlopt for virDomainDefCheckABIStability call
vz: nseclabels member is moved to virDomainChrSourceDef struct
src/vz/vz_driver.c | 2 +-
src/vz/vz_sdk.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
1.8.3.1
7 years, 4 months
[libvirt] [PATCH] docs: Document bhyve's vgaconf support
by Roman Bogorodskiy
- Add a news entry
- Update driver's page with information about the new
vgaconf attribute and provide usage example; while here,
fix a grammar mistake
Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com>
---
docs/drvbhyve.html.in | 28 +++++++++++++++++++++++++++-
docs/news.xml | 12 ++++++++++++
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in
index dd6620d..f083db9 100644
--- a/docs/drvbhyve.html.in
+++ b/docs/drvbhyve.html.in
@@ -351,10 +351,36 @@ FreeBSD port.</p>
<p>This way, VNC will be accessible on <code>127.0.0.1:5904</code>.</p>
-<p>Please note that the tablet device requires to have an USB controller
+<p>Please note that the tablet device requires to have a USB controller
of the <code>nec-xhci</code> model. Currently, only a single controller of this
type and a single tablet are supported per domain.</p>
+<p><span class="since">Since 3.5.0</span>, it's possible to configure how the video device is exposed
+to the guest using the <code>vgaconf</code> attribute:</p>
+
+<pre>
+<domain type='bhyve'>
+ <devices>
+ ...
+ <graphics type='vnc' port='5904'>
+ <listen type='address' address='127.0.0.1'/>
+ </graphics>
+ <video>
+ <driver vgaconf='on'/>
+ <model type='gop' heads='1' primary='yes'/>
+ </video>
+ ...
+ </devices>
+ ...
+</domain>
+</pre>
+
+<p>If not specified, bhyve's default mode for <code>vgaconf</code>
+will be used. Please refer to the
+<a href="https://www.freebsd.org/cgi/man.cgi?query=bhyve&sektion=8&manpath...">bhyve(8)</a>
+manual page and the <a href="https://wiki.freebsd.org/bhyve">bhyve wiki</a> for more details on using
+the <code>vgaconf</code> option.</p>
+
<h3><a name="clockconfig">Clock configuration</a></h3>
<p>Originally bhyve supported only localtime for RTC. Support for UTC time was introduced in
diff --git a/docs/news.xml b/docs/news.xml
index 27562e1..d320965 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -46,6 +46,18 @@
select a boot entry.
</description>
</change>
+ <change>
+ <summary>
+ Support controlling how video devices are exposed to the bhyve guests
+ </summary>
+ <description>
+ The <code>vgaconf</code> attribute was added to <code>video</code>'s
+ <code>driver</code> element. Possible values are: <code>on</code>,
+ <code>off</code>, and <code>io</code>. It controlls the way how
+ bhyve exposes video devices to its guests; various guest OSes might
+ require different settings to boot properly.
+ </description>
+ </change>
</section>
<section title="Improvements">
</section>
--
2.7.4
7 years, 4 months
[libvirt] [PATCH 0/2] Really check for TLS dir if specified in qemu.conf
by John Ferlan
The qemu.conf indicates that for the various *_tls_x509_cert_dir settings
that "If the provided path does not exist then the default_tls_x509_cert_dir
path will be used."; however, the code didn't quite do that.
The default for each was set during virQEMUDriverConfigNew; however, that
was overwritten if the various config settings were used, but whether the
directory actually existed and falling back to the default action of using
the default configuration was not done.
So that's what these patches do.
John Ferlan (2):
qemu: Clean up long lines in virQEMUDriverConfigLoadFile
qemu: Check for existence of provided *_tls_x509_cert_dir
src/qemu/qemu.conf | 9 +++-
src/qemu/qemu_conf.c | 123 +++++++++++++++++++++++++++++++++++++--------------
2 files changed, 98 insertions(+), 34 deletions(-)
--
2.9.4
7 years, 4 months
