[libvirt] [PATCH] qemu: Fix typo in __QEMU_CAPSPRIV_H_ALLOW__
by Andrea Bolognani
---
Pushed as trivial.
src/qemu/qemu_capabilities.c | 2 +-
src/qemu/qemu_capspriv.h | 2 +-
tests/cputest.c | 4 ++--
tests/qemucapabilitiestest.c | 2 +-
tests/qemucapsprobe.c | 2 +-
tests/qemucpumock.c | 4 ++--
tests/qemuxml2argvtest.c | 4 ++--
tests/testutilsqemu.c | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 60ed31e..8bd39c7 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -44,7 +44,7 @@
#include "virstring.h"
#include "qemu_hostdev.h"
#include "qemu_domain.h"
-#define __QEMU_CAPSRIV_H_ALLOW__
+#define __QEMU_CAPSPRIV_H_ALLOW__
#include "qemu_capspriv.h"
#include <fcntl.h>
diff --git a/src/qemu/qemu_capspriv.h b/src/qemu/qemu_capspriv.h
index ee29b8b..61ccd45 100644
--- a/src/qemu/qemu_capspriv.h
+++ b/src/qemu/qemu_capspriv.h
@@ -21,7 +21,7 @@
* Author: Pavel Fedin <p.fedin(a)samsung.com>
*/
-#ifndef __QEMU_CAPSRIV_H_ALLOW__
+#ifndef __QEMU_CAPSPRIV_H_ALLOW__
# error "qemu_capspriv.h may only be included by qemu_capabilities.c or test suites"
#endif
diff --git a/tests/cputest.c b/tests/cputest.c
index 5e205c5..917b1a3 100644
--- a/tests/cputest.c
+++ b/tests/cputest.c
@@ -43,9 +43,9 @@
#if WITH_QEMU && WITH_YAJL
# include "testutilsqemu.h"
# include "qemumonitortestutils.h"
-# define __QEMU_CAPSRIV_H_ALLOW__
+# define __QEMU_CAPSPRIV_H_ALLOW__
# include "qemu/qemu_capspriv.h"
-# undef __QEMU_CAPSRIV_H_ALLOW__
+# undef __QEMU_CAPSPRIV_H_ALLOW__
#endif
#define VIR_FROM_THIS VIR_FROM_CPU
diff --git a/tests/qemucapabilitiestest.c b/tests/qemucapabilitiestest.c
index 2152e80..2918ff4 100644
--- a/tests/qemucapabilitiestest.c
+++ b/tests/qemucapabilitiestest.c
@@ -22,7 +22,7 @@
#include "testutils.h"
#include "testutilsqemu.h"
#include "qemumonitortestutils.h"
-#define __QEMU_CAPSRIV_H_ALLOW__
+#define __QEMU_CAPSPRIV_H_ALLOW__
#include "qemu/qemu_capspriv.h"
#define VIR_FROM_THIS VIR_FROM_NONE
diff --git a/tests/qemucapsprobe.c b/tests/qemucapsprobe.c
index fb9f3e9..561c5d7 100644
--- a/tests/qemucapsprobe.c
+++ b/tests/qemucapsprobe.c
@@ -24,7 +24,7 @@
#include "internal.h"
#include "virthread.h"
#include "qemu/qemu_capabilities.h"
-#define __QEMU_CAPSRIV_H_ALLOW__ 1
+#define __QEMU_CAPSPRIV_H_ALLOW__ 1
#include "qemu/qemu_capspriv.h"
#define VIR_FROM_THIS VIR_FROM_NONE
diff --git a/tests/qemucpumock.c b/tests/qemucpumock.c
index 2c1d24d..f0a113f 100644
--- a/tests/qemucpumock.c
+++ b/tests/qemucpumock.c
@@ -18,9 +18,9 @@
#include "internal.h"
#include "qemu/qemu_capabilities.h"
-#define __QEMU_CAPSRIV_H_ALLOW__
+#define __QEMU_CAPSPRIV_H_ALLOW__
#include "qemu/qemu_capspriv.h"
-#undef __QEMU_CAPSRIV_H_ALLOW__
+#undef __QEMU_CAPSPRIV_H_ALLOW__
virCPUDefPtr
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 64e14af..ec73ac7 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -27,9 +27,9 @@
# include "storage/storage_driver.h"
# include "virmock.h"
-# define __QEMU_CAPSRIV_H_ALLOW__
+# define __QEMU_CAPSPRIV_H_ALLOW__
# include "qemu/qemu_capspriv.h"
-# undef __QEMU_CAPSRIV_H_ALLOW__
+# undef __QEMU_CAPSPRIV_H_ALLOW__
# include "testutilsqemu.h"
diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c
index 026b73e..4cc482d 100644
--- a/tests/testutilsqemu.c
+++ b/tests/testutilsqemu.c
@@ -8,7 +8,7 @@
# include "cpu_conf.h"
# include "qemu/qemu_driver.h"
# include "qemu/qemu_domain.h"
-# define __QEMU_CAPSRIV_H_ALLOW__
+# define __QEMU_CAPSPRIV_H_ALLOW__
# include "qemu/qemu_capspriv.h"
# include "virstring.h"
--
2.7.4
7 years, 8 months
[libvirt] [PATCH] qemu: forbid migration with an IOMMU device
by Ján Tomko
https://bugzilla.redhat.com/show_bug.cgi?id=1433994
---
src/qemu/qemu_migration.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index f5711bc..15ed830 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2359,6 +2359,12 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver,
_("migration with shmem device is not supported"));
return false;
}
+
+ if (vm->def->iommu) {
+ virReportError(VIR_ERR_OPERATION_INVALID, "%s",
+ _("migration with iommu device is not supported"));
+ return false;
+ }
}
return true;
--
2.10.2
7 years, 8 months
[libvirt] [PATCH v3 0/7] Add TLS support for migration
by John Ferlan
v2: http://www.redhat.com/archives/libvir-list/2017-February/msg01374.html
NB: Parts of the original series were split out, patches posted, ACK'd,
and committed separately, see:
http://www.redhat.com/archives/libvir-list/2017-March/msg00037.html
Changes since v2:
First and foremost after some gentle encouragement and lots of hours cursing
at no one in particular, I was finally able to configure a couple of nested
host guests, create a guest on each, and actually migrate that guest without
TLS back and forth between the two nested hosts. Suffice to say there are
dribs and drabs of "howto"'s that help, but it is quite a confusing setup
and I was certainly left wondering how customers do this. OK beyond paying
someone set things up for them!
Now that I had the basics, the next task was creating the TLS environment.
MANY more curse words uttered, including some I didn't know I knew, but I
was actually able to test the changes in my environment. Suffice to say it's
"somewhat confusing" because the TLS environment that QEMU expects (ok, the
filenames) differ slightly than those that a libvirt TLS environment would
expects. What really got frustrating is that all I'd get back is the
following error message after 'migrate' started on the client and after
the server was essentially waiting for the migration:
error: operation failed: migration job: unexpectedly failed
Turns out that I was missing the '/etc/pki/qemu/client-cert.pem' and
'/etc/pki/qemu/client-key.pem' files, but got no message. Of course I
did have something in my /etc/pki/libvirt directory, but of course those
weren't being used. Still my brain wasn't exactly telling me that. The
other piece I was missing was the "details" about when "tls-hostname"
must be provided. In the previous patches, I would search on "fd" or
"spec" in spec->dest.host.protocol; however, that wasn't quite right.
What I needed to search on was MIGRATION_DEST_CONNECT_HOST or
MIGRATION_DEST_FD in spec->destType (and _CONNECT_HOST only because it
turns into _FD 'eventually').
Anyway, so happy days are here again and I can now liberally celebrate
St Patrick's Day (not that I wasn't going to before, but now moreso!).
Beyond the above description from my testing the real "key" behind all
of this is ensuring that the 'right' QEMU bits are installed by fetching
the "tls-creds" via qemuMonitorGetMigrationParams and as long as *something*
is returned, then we are assured that we can proceed. This relates to QEMU
commit '4af245dc3' (after v2.9.0-rc0) which sets a default for tls-creds
and more importantly for our purposes allows us to "clear" the tls-creds
and tls-hostname migration parameters by passing a "" (empty string).
With that in place the rest of the logic falls into place with regard
to qemuMigrationCheckSetupTLS ensuring that TLS for migration is available
for libvirt to use.
Once we know we can use TLS, we'll use qemuMigrationAddTLSObjects to
add the "secret" and "tls-creds-x509" objects to the domain for either
server (target) or client (source). Doing this also required an adjustment
to the existing code to allow the Async monitor usage.
Once those objects are created, we'll set the "tls-creds" and "tls-hostname"
parameters appropriate. If TLS isn't being used, we'll be sure to clear
them. This is only made tricky by needing to ensure the qemu that's running
can support setting them to "", hence the qemuMigrationCheckTLSCreds prior
to that clearing. If this wasn't done, older QEMU would be less than pleased
to find "" in tls-creds and tls-hostname.
Finally when the migration is successful, call qemuMigrationDeconstructTLS
(naming credit goes to my wife!). Failures will call just qemuMigrationResetTLS
in order to achieve the same call; however, for those paths we do not still
have the original 'tlsAlias' and 'secAlias' available, so we have to recreate
it on the fly'
Have I won the prize for the longest cover letter yet?
John Ferlan (7):
qemu: Create #define for TLS configuration setup.
conf: Introduce migrate_tls_x509_cert_dir
Add new migration flag VIR_MIGRATE_TLS
qemu: Add TLS params to _qemuMonitorMigrationParams
qemu: Add job for qemuDomain{Add|Del}TLSObjects
qemu: Set up the migrate TLS objects for target
qemu: Set up the migration TLS objects for source
include/libvirt/libvirt-domain.h | 8 +
src/qemu/libvirtd_qemu.aug | 5 +
src/qemu/qemu.conf | 37 ++++
src/qemu/qemu_conf.c | 45 ++--
src/qemu/qemu_conf.h | 4 +
src/qemu/qemu_domain.c | 7 +-
src/qemu/qemu_domain.h | 91 ++++----
src/qemu/qemu_driver.c | 4 +-
src/qemu/qemu_hotplug.c | 24 ++-
src/qemu/qemu_hotplug.h | 2 +
src/qemu/qemu_migration.c | 423 ++++++++++++++++++++++++++++++++++++-
src/qemu/qemu_migration.h | 9 +-
src/qemu/qemu_monitor.c | 11 +-
src/qemu/qemu_monitor.h | 3 +
src/qemu/qemu_monitor_json.c | 28 +++
src/qemu/test_libvirtd_qemu.aug.in | 3 +
tests/qemumonitorjsontest.c | 25 ++-
tools/virsh-domain.c | 7 +
18 files changed, 668 insertions(+), 68 deletions(-)
--
2.9.3
7 years, 8 months
[libvirt] [PATCH] util: fix build on non-Linux
by Roman Bogorodskiy
Decorate unused arguments of the virNetDevGetMaster() stub
with ATTRIBUTE_UNUSED to fix build on systems where this
stub is used.
---
Pushed as a build-breaker.
src/util/virnetdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c
index 6805d32..455239a 100644
--- a/src/util/virnetdev.c
+++ b/src/util/virnetdev.c
@@ -1017,7 +1017,8 @@ virNetDevGetMaster(const char *ifname, char **master)
int
-virNetDevGetMaster(const char *ifname, char **master)
+virNetDevGetMaster(const char *ifname ATTRIBUTE_UNUSED,
+ char **master ATTRIBUTE_UNUSED)
{
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
_("Unable to get device master from netlink on this platform"));
--
2.7.4
7 years, 8 months
[libvirt] [PATCH 1/1] qemu: snapshot: Forbid internal snapshots with OVMF firmware
by Peter Krempa
QEMU does not snapshot the pflash drive when doing a 'savevm' thus
internal snapshots with OVMF would be incomplete.
Forbid such snapshot so that we can avoid problems.
---
CC: lersek(a)redhat.com
There might be slight regression potential. While this did not work as expected
I did not encounter any error while doing a savevm, thus users might actually
think that this worked before.
src/qemu/qemu_driver.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 0e065081d..344917451 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -13873,6 +13873,16 @@ qemuDomainSnapshotPrepare(virConnectPtr conn,
goto cleanup;
}
+ /* Internal snapshots don't work with VMs with OVMF loader since qemu does
+ * not snapshot the variable store */
+ if (found_internal &&
+ vm->def->os.loader->type == VIR_DOMAIN_LOADER_TYPE_PFLASH) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("internal snapshots of a VM with pflash based "
+ "firmware are not supported by QEMU"));
+ goto cleanup;
+ }
+
/* Alter flags to let later users know what we learned. */
if (external && !active)
*flags |= VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY;
--
2.12.1
7 years, 8 months
[libvirt] [PATCH 0/3] allow fixing tap-bridge connections when network is restarted
by Laine Stump
It's been a long-standing problem that when you stop and restart a
libvirt network, the guest tap devices are no longer connected to the
network. Until now the only way to recover from this was to either
shutdown and restart all the affected guests, or to detach and then
re-attach all affected guest network devices.
These patches permit the situation to be remedied by just restarting
libvirtd - when the hypervisor drivers are notifying the network
drivers of each connection, the network can retrieve the current
"master" for the tap device and compare it to the network's bridge
device. If they don't match, then it disconnects the tap from any
incorrect bridge and connects to the correct bridge.
***
For now, that's as far as we go - *semi*-automated (since you need to
restart libvirtd for it to happen). My intent is for this to be
completely automated, but the logic to do that is a bit "convoluted"
so I've deferred trying to implement it until I've given it more
thought - a few different trains of thought have led to dead-ends, and
so far only one seems reasonably doable:
* add a networkStartCallback list to the network driver state object.
* as each hypervisor driver that uses the network driver is
initialized, it will call an internal-only function in the network
driver to register a callback.
* whenever a network is started, it will call all the registered
callback functions (sending the name of the network being started,
and some HV-specific context pointer).
* Each hypervisor's callback function will look through all of its
active domains for interfaces that are using the given network, and
for each such interface, will call networkNotifyActualDevice() (the
function that has been updated in Patch 3/3 to reconnect taps to
bridges).
The "convoluted" part here is that we need to make sure there is
enough (but not too much!) locking/refcounting both when adding items
to the callback list (which should only be done single threaded, since
it happens during the driver initializations) and when the
networkStart() function (in some state of lockedness/refcountedness)
calls over to some e.g. qemu function that will then need to do some
amount of locking (at least on each domain as it is processed) and
then calls back into the network driver (which will need "some amount"
of locking/refcounting). Since we're calling from network driver into
qemu into network driver, while the normal nesting is just calling
from qemu into network, I want to be sure there is no possibility for
a deadlock. (Also, I want to avoid making the list of callbacks any
more complicated than absolutely necessary - the "in" thing to do
these days seems to be to allocate a hash table, but there's a lot of
extra code required for that (see util/virclosecallbacks.[hc]) which
seems like overkill for a list of maximum 4-5 items that will *never*
change after the driver initialization - if anyone has ideas/opinions
about that, please speak up.
Laine Stump (2):
util: new function virNetDevGetMaster()
util: new function virNetDevTapAttachBridge()
root (1):
network: reconnect tap devices during networkNotifyActualDevice
src/libvirt_private.syms | 2 +
src/network/bridge_driver.c | 30 +++++++++++-
src/util/virnetdev.c | 49 +++++++++++++++++++
src/util/virnetdev.h | 3 ++
src/util/virnetdevtap.c | 111 +++++++++++++++++++++++++++++---------------
src/util/virnetdevtap.h | 12 +++++
6 files changed, 169 insertions(+), 38 deletions(-)
--
2.9.3
7 years, 8 months
[libvirt] [PATCH 00/22] Resolve Coverity and build issues
by John Ferlan
Hopefully the quantity doesn't scare anyone off... These are mostly
innocuous, but separated each out to appease the masses.
The first patch fixes a recently uncovered Coverity warning regarding
FORWARD_NULL of the 'formatStr'... According to an IRC response from
pkrempa the format should be set up properly in qemuDomainSnapshotPrepare
Patches 2-22 resolve various different build issues in the Coverity
environment that sets "lv_cv_static_analysis=yes" during the build.
This is 'reproducible' if one sets that as part of their autogen.sh
processing - something that we should probably do in the CI build
environment so we can get all those ATTRIBUTE_NONNULL checks to be
run on a daily basis.
John Ferlan (22):
qemu: Always format formatStr for blockdev-snapshot-sync
util: Remove NONNULL(1) for virNetDevGetName
conf: Remove NONNULL(2) for virNetDevBandwidthParse
conf: Remove NONNULL(1,2) for virNetDevBandwidthFormat
conf: Remove NONNULL(1) for virDomainNumaGetNodeCount
network: Remove null newBandwidth check from networkBandwidthUpdate
qemu: Remove non null 'vm' check from qemuMonitorOpen
qemu: Remove NONNULL(1) for qemu_monitor prototypes
util: Change return argument for virBitmapParseUnlimited
util: Remove NONNULL(1) for virBitmapParseUnlimited
util: Remove NONNULL(2,3) for virHostdevReAttachPCIDevices
util: Remove NONNULL(2,3) for virHostdevReAttachUSBDevices
util: Remove NONNULL(2,3) for virHostdevReAttachSCSIVHostDevices
util: Remove NONNULL(1) for virHostdevPrepareDomainDevices
util: Remove NONNULL(1) for virHostdevReAttachDomainDevices
util: Remove NONNULL(1) for virNetDevOpenvswitchSetMigrateData
util: Remove NONNULL(1,3,4) from virTypedParamsFilter
util: Remove NONNULL(2) for virNetDevBandwidthPlug
util: Remove NONNULL(1) for virNetDevOpenvswitchGetVhostuserIfname
util: Remove NONNULL's for
virNetDevVPortProfile[Associate|Disassociate]
util: Remove NONNULL(1) for virNetDevMacVLanDeleteWithVPortProfile
cpu: Remove NONNULL(1) for cpuBaseline
src/conf/netdev_bandwidth_conf.c | 2 +-
src/conf/netdev_bandwidth_conf.h | 5 ++---
src/conf/numa_conf.h | 4 ++--
src/cpu/cpu.h | 3 +--
src/network/bridge_driver.c | 2 +-
src/qemu/qemu_driver.c | 3 +--
src/qemu/qemu_monitor.c | 3 +--
src/qemu/qemu_monitor.h | 8 ++++----
src/util/virbitmap.c | 28 +++++++++++++---------------
src/util/virbitmap.h | 6 ++----
src/util/virhostdev.c | 9 ++++++---
src/util/virhostdev.h | 10 +++++-----
src/util/virnetdev.h | 2 +-
src/util/virnetdevbandwidth.h | 3 +--
src/util/virnetdevmacvlan.h | 2 +-
src/util/virnetdevopenvswitch.h | 4 ++--
src/util/virnetdevvportprofile.h | 10 ++++------
src/util/virtypedparam.h | 3 +--
tests/testutils.c | 2 +-
tests/virbitmaptest.c | 2 +-
20 files changed, 51 insertions(+), 60 deletions(-)
--
2.9.3
7 years, 8 months
[libvirt] [PATCH 0/3] Three random small patches
by Laine Stump
I found these while trying out some other code I decided not to use (I
was going to add more attributes to the <link> element,
virNetDevIfLink, and virNetDevGetLinkInfo(), but then decided not to
for now (in case Michal has a different idea of the meaning of "link"
than, e.g., iproute's "ip link" command).
The first two taken together actually have a very positive impact -
they make the output of "virsh nodedev-dumpxml" much more informative
when run as non-root.
Laine Stump (3):
util: use AF_UNIX family (not AF_PACKET) for ioctl sockets
util: allow retrieving ethtool features when unprivileged
network: remove unused typedef for networkDnsmasqLeaseFileNameFunc
src/network/bridge_driver.h | 2 --
src/util/virnetdev.c | 8 +-------
src/util/virnetdevip.c | 2 +-
3 files changed, 2 insertions(+), 10 deletions(-)
--
2.9.3
7 years, 8 months
[libvirt] [PATCH v3 00/15] Introduce vGPU mdev framework to libvirt
by Erik Skultety
since v1:
- new <hostdev> attribute model introduced which tells libvirt which device API
should be considered when auto-assigning guest address
- device_api is properly checked, thus taking the 'model' attribute only as a
hint to assign "some" address
- new address type 'mdev' is introduced rather than using plain <uuid> element,
since the address element is more conveniently extendable.
- the emulated mtty driver now works as well out of the box, so no HW needed to
review this series --> let's try it :)
- fixed all the nits from v1
since v2:
- dropped the patch introducing new address type 'mdev' since I added by
mistake and only after that realized that the device address type enum is used
for guest addresses only
--> the mdevs are still identified by address element containing an 'uuid'
attribute, I just dropped the enum
- resolved the driver hostdev list race condition raised by Pavel in his review
--> the device API is now checked every time our internal mdev object is
created as opposed to the previous version where because of the model being
checked separately, the locking issues arose.
- rewrote the docs, reflecting the mdev address type drop change
- squashed all security related stuff into 1 patch, also added app-armor bits
- as Pavel suggested, moved most of the mdev-related functions out of
virhostdev.c to virmdev.c
- added a few more test cases
I also created a new branch 'mdev-next' (more suitable name than a strict
version number) on https://github.com/eskultety/libvirt/commits/mdev-next
Erik
Erik Skultety (15):
conf: hostdev: Enforce enum-in-switch compile-time checks
conf: hostdev: Introduce virDomainHostdevSubsysSCSIClear
conf: Introduce virDomainHostdevDefPostParse
conf: Introduce new hostdev device type mdev
conf: Add post parse code for mdevs to virDomainHostdevDefPostParse
security: Enable labeling of vfio mediated devices
conf: Enable cold-plug of a mediated device
qemu: Assign PCI addresses for mediated devices as well
hostdev: Maintain a driver list of active mediated devices
qemu: cgroup: Adjust cgroups' logic to allow mediated devices
qemu: Bump the memory locking limit for mdevs as well
qemu: Format mdevs on qemu command line
test: Add some test cases for our test suite regarding the mdevs
docs: Document the new hostdev and address type 'mdev'
news: Update the NEWS.xml about the new mdev feature
docs/formatdomain.html.in | 46 +-
docs/news.xml | 10 +
docs/schemas/domaincommon.rng | 22 +
po/POTFILES.in | 1 +
src/Makefile.am | 1 +
src/conf/domain_conf.c | 225 ++++++++--
src/conf/domain_conf.h | 9 +
src/libvirt_private.syms | 25 ++
src/qemu/qemu_command.c | 45 ++
src/qemu/qemu_command.h | 5 +
src/qemu/qemu_domain.c | 24 +-
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_domain_address.c | 14 +-
src/qemu/qemu_hostdev.c | 56 +++
src/qemu/qemu_hostdev.h | 10 +
src/qemu/qemu_hotplug.c | 2 +
src/security/security_apparmor.c | 22 +
src/security/security_dac.c | 43 ++
src/security/security_selinux.c | 45 ++
src/util/virhostdev.c | 165 ++++++-
src/util/virhostdev.h | 23 +
src/util/virmdev.c | 487 +++++++++++++++++++++
src/util/virmdev.h | 123 ++++++
tests/domaincapsschemadata/full.xml | 1 +
...ml2argv-hostdev-mdev-invalid-target-address.xml | 33 ++
...muxml2argv-hostdev-mdev-src-address-invalid.xml | 35 ++
.../qemuxml2argv-hostdev-mdev-unmanaged.args | 25 ++
.../qemuxml2argv-hostdev-mdev-unmanaged.xml | 35 ++
tests/qemuxml2argvtest.c | 9 +
.../qemuxml2xmlout-hostdev-mdev-unmanaged.xml | 40 ++
tests/qemuxml2xmltest.c | 1 +
31 files changed, 1528 insertions(+), 55 deletions(-)
create mode 100644 src/util/virmdev.c
create mode 100644 src/util/virmdev.h
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-mdev-invalid-target-address.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-mdev-src-address-invalid.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-mdev-unmanaged.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-mdev-unmanaged.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-hostdev-mdev-unmanaged.xml
--
2.12.0
7 years, 8 months
[libvirt] [BUG] mlock support breakage
by Luiz Capitulino
Libvirt commit c2e60ad0e51 added a new check to the XML validation
logic where XMLs containing <memoryBacking><mlocked/> must also
contain <memtune><hard_limit>. This causes two breakages where
working guests won't start anymore:
1. Systems where mlock limit was set in /etc/security/limits.conf
2. Guests using hugeTLB pages. In this case, guests were relying
on the fact that libvirt automagically increases mlock
limit to 1GB
While it's true that <memoryBacking><mlocked/> documentation
says that <memtune><hard_limit> is required, this is actually
an extremely bad request because:
A. <memtune><hard_limit> own documention strongly recommends
NOT using it
B. <memtune><hard_limit> does more than setting memory locking
limit
C. <memtune><hard_limit> does not support infinity, so you have
to guess a limit
D. If <memtune><hard_limit> is less than 1GB, it will lower
VFIO's automatic limit of "guest memory + 1GB"
Here's two possible solutions to fix this all:
1. Drop change c2e60ad0e51 and drop automatic increases. Let
users configure limits in /etc/security/limits.conf
pros: this is the most correct way to do it, and how
it should be done originally IMHO
cons: will break working VFIO setups, so probably undoable
2. Drop change c2e60ad0e51 and automtically increase memory
locking limit to infinity when seeing <memoryBacking><locked/>
pros: make all cases work, no more <hard_limit> requirement
cons: allows guests with <locked/> to lock all memory
assigned to them plus QEMU allocations. While this seems
undesirable or even a security issue, using <hard_limit>
will have the same effect
Lastly, <locked/> doesn't belong to <memoryBacking>, it should
be in <memtune>. I recommend deprecating it from <memoryBacking>
and adding it where it belongs.
7 years, 8 months
