[libvirt] [PATCH 00/19] Fix saving/setting/restoring SR-IOV VF MAC address
by Laine Stump
There are multiple bugs filed against both libvirt and the kernel
related to incorrect restoration of MAC addresses for SR-IOV VFs, both
when used via VFIO device assignment and when used for macvtap
passthrough mode
https://bugzilla.redhat.com/1415609 - libvirt
https://bugzilla.redhat.com/1341248 - kernel (igb)
https://bugzilla.redhat.com/1415609 - kernel (ixgbe)
https://bugzilla.redhat.com/1302166 - kernel (mlx, fixed)
Beyond that, there are other problems with incorrect setting and
restoration of VF MAC addresses that don't have their own bug reports
(although they may be partially described in the comments of the BZes
mentioned above). This patch series attempts (and I hope succeeds!) to
fix all of these problems, which can be summarized in these three
points:
* The VF's own MAC address was not being set prior to using it for
macvtap passthrough mode. Instead, due to serious misconception on
my part, the "admin MAC" for that VF was set in the PF. The problem
is that the admin MAC isn't put into use on the VF immediately;
rather it is unused until the next time the VF driver is initialized
(on either the host or in a guest) so setting it had no practical
effect, meaning that the macvtap device's MAC didn't match the MAC
of the VF device it was attached to - this meant that traffic
wouldn't pass unless the device was in promiscuous mode (and
apparently it was back when the code was changed to behave this
way?).
* The VF's own MAC address was never restored after it had been used
(for both VFIO device assignment and for macvtap passthrough mode).
Only the "admin MAC" address (which, again, won't take effect
until/unless the VF driver is reloaded/reinitialized) was restored.
* If the original admin MAC was 00:00:00:00:00:00, libvirt would save
that, then attempt to restore it when the guest was finished with
the device, but for some/many SRIOV-capable net drivers, an all 0
MAC is not allowed to be set (even though that is its initial
value). This would result in the MAC not being changed (of course,
since this is the admin MAC, that didn't actually matter, but the
combination of the error message and the VF's own MAC still being
set to the value used by the guest, users mistakenly believed this
was the source of networking problems (e.g. when the guest moved to
another host, but the old host still had an interface showing its
MAC address).
There are lots of details in the patches. 01 - 07 just clean up and
slightly modify some existing utility functions. 08 - 11 define some
functions to save/restore netdev MAC/vlan settings, and 12-14 change
the existing setup/teardown code for macvtap and hostdev to use the
new functions, then 15 and 17-19 modify their behavior further, while
16 just removes functions that are no longer used.
In the end, the VF's own MAC *and* admin MAC are saved for all SRIOV
VFs when we begin using a VF, and the VF's MAC is restored when
finished. Since the admin MAC doesn't actually have any immediate
practical effect, we don't concern ourselves with assuring it is
restored in all cases (in particular, when use use the VF for VFIO
assignment, we only restore the VF's MAC, but not the admin MAC during
teardown, and when using the VF for macvtap passthrough we avoid
restoring the admin MAC because that would unnecessarily turn on the
"administratively set" flag in the PF driver (described in the commit
log for one of these patches). I might decide to fix the former later,
but for now it just unnecessarily complicates the code for no real
gain).
Laine Stump (19):
util: permit querying a VF MAC address or VLAN tag by itself
util: remove unused args from virNetDevSetVfConfig()
util: use cleanup label consistently in virHostdevNetConfigReplace()
util: eliminate useless local variable
util: make virMacAddrParse more versatile
util: change virPCIGetNetName() to not return error if device has no
net name
util: make virPCIGetDeviceAddressFromSysfsLink() public
util: new function virPCIDeviceRebind()
util: new internal function to permit silent failure of
virNetDevSetMAC()
util: new function virNetDevPFGetVF()
util: new functions virNetDev(Save|Read|Set)NetConfig()
util: use new virNetDev*NetConfig() functions for macvtap
setup/teardown
util: use new virNetDev*NetConfig() functions for hostdev
setup/teardown
util: replace virHostdevNetConfigReplace with ...(Save|Set)NetConfig()
util: save hostdev network device config before unbinding from host
driver
util: after hostdev assignment, restore VF MAC address via setting
admin MAC
util: remove unused functions from virnetdev.c
util: if setting admin MAC to 00:00:00:00:00:00 fails, try
02:00:00:00:00:00
util: try *really* hard to set the MAC address of an SRIOV VF
src/libvirt_private.syms | 10 +-
src/util/virhostdev.c | 171 ++++++--
src/util/virmacaddr.c | 2 +-
src/util/virnetdev.c | 937 +++++++++++++++++++++++++++++++-------------
src/util/virnetdev.h | 25 ++
src/util/virnetdevmacvlan.c | 45 ++-
src/util/virpci.c | 65 ++-
src/util/virpci.h | 4 +
8 files changed, 933 insertions(+), 326 deletions(-)
--
2.9.3
8 years
[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
8 years
[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
8 years
[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
8 years
[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
8 years
[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
8 years
[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
8 years
[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
8 years
[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
8 years
[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
8 years
