[libvirt] [PATCH] Fix compile error for stable 1.2.9
by Yang hongyang
Seems a backport miss. An extra member is passed to struct
virLXCBasicMountInfo.
Signed-off-by: Yang hongyang <hongyang.yang(a)easystack.cn>
---
src/lxc/lxc_container.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c
index 28dabec..1c65fa9 100644
--- a/src/lxc/lxc_container.c
+++ b/src/lxc/lxc_container.c
@@ -760,7 +760,7 @@ typedef struct {
static const virLXCBasicMountInfo lxcBasicMounts[] = {
{ "proc", "/proc", "proc", MS_NOSUID|MS_NOEXEC|MS_NODEV, false, false },
- { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false, false },
+ { "/proc/sys", "/proc/sys", NULL, MS_BIND|MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false },
{ "sysfs", "/sys", "sysfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, false, false },
{ "securityfs", "/sys/kernel/security", "securityfs", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_RDONLY, true, true },
#if WITH_SELINUX
--
1.7.1
1 year, 1 month
[libvirt] Supporting vhost-net and macvtap in libvirt for QEMU
by Anthony Liguori
Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd
people that are who can throw tomatoes at me for getting bits wrong :-)
I wanted to start a discussion about supporting vhost-net in libvirt.
vhost-net has not yet been merged into qemu but I expect it will be soon
so it's a good time to start this discussion.
There are two modes worth supporting for vhost-net in libvirt. The
first mode is where vhost-net backs to a tun/tap device. This is
behaves in very much the same way that -net tap behaves in qemu today.
Basically, the difference is that the virtio backend is in the kernel
instead of in qemu so there should be some performance improvement.
Current, libvirt invokes qemu with -net tap,fd=X where X is an already
open fd to a tun/tap device. I suspect that after we merge vhost-net,
libvirt could support vhost-net in this mode by just doing -net
vhost,fd=X. I think the only real question for libvirt is whether to
provide a user visible switch to use vhost or to just always use vhost
when it's available and it makes sense. Personally, I think the later
makes sense.
The more interesting invocation of vhost-net though is one where the
vhost-net device backs directly to a physical network card. In this
mode, vhost should get considerably better performance than the current
implementation. I don't know the syntax yet, but I think it's
reasonable to assume that it will look something like -net
tap,dev=eth0. The effect will be that eth0 is dedicated to the guest.
On most modern systems, there is a small number of network devices so
this model is not all that useful except when dealing with SR-IOV
adapters. In that case, each physical device can be exposed as many
virtual devices (VFs). There are a few restrictions here though. The
biggest is that currently, you can only change the number of VFs by
reloading a kernel module so it's really a parameter that must be set at
startup time.
I think there are a few ways libvirt could support vhost-net in this
second mode. The simplest would be to introduce a new tag similar to
<source network='br0'>. In fact, if you probed the device type for the
network parameter, you could probably do something like <source
network='eth0'> and have it Just Work.
Another model would be to have libvirt see an SR-IOV adapter as a
network pool whereas it handled all of the VF management. Considering
how inflexible SR-IOV is today, I'm not sure whether this is the best model.
Has anyone put any more thought into this problem or how this should be
modeled in libvirt? Michael, could you share your current thinking for
-net syntax?
--
Regards,
Anthony Liguori
1 year, 1 month
[libvirt] [PATCH 0/3] Fix ppc64 CPU configuration for QEMU 2.11+
by Jiri Denemark
The original fix was both incomplete and too general. It only fixed
domain startup, but libvirt would still report empty list of supported
CPU models with recent QEMU for ppc64. On the other hand, while ppc64
QEMU ignores case when looking up CPU model names, x86_64 QEMU does
case sensitive lookup.
Jiri Denemark (3):
Revert "domcaps: Treat host models as case-insensitive strings"
util: Introduce virStringListSearch
qemu: Adapt to changed ppc64 CPU model names
src/conf/domain_capabilities.c | 2 +-
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 28 +++++++++++++++++--
src/qemu/qemu_capabilities.h | 3 +-
src/qemu/qemu_process.c | 2 +-
src/util/virstring.c | 28 +++++++++++++++++++
src/util/virstring.h | 3 ++
.../qemu_2.12.0.ppc64.xml | 6 +++-
.../caps_2.12.0.ppc64.xml | 12 ++++----
9 files changed, 73 insertions(+), 12 deletions(-)
--
2.17.0
5 years, 2 months
[libvirt] [PATCH v4 0/8] Virtio-crypto device support
by Longpeng(Mike)
As virtio-crypto has been supported in QEMU 2.8 and the frontend
driver has been merged in linux 4.10, so it's necessary to support
virtio-crypto in libvirt.
---
Changes since v3:
- spilt the capabilities part into a separate patch. [Boris]
- include Boris's virtio-crypto ccw support(PATCH 6 & 8). [Boris]
- add the missing capabilities in caps_2.9.0.x86_64.xml. [Boris]
- fix Indentation and missing virDomainCryptoDefFree. [Marc]
Changes since v2:
- PATCH 1: modify docs as Martin & Boris's suggestion. [Martin & Boris]
- PATCH 2: add the missing 'ToString'. [Martin]
- PATCH 3: use virAsprintf instead of virBufferAsprintf. [Martin]
remove pointless virBufferCheckError. [Martin]
- rebase on master. [Longpeng]
Changes since v1:
- split patch [Martin]
- rebase on master [Martin]
- add docs/tests/schema [Martin]
- fix typos [Gonglei]
---
Boris Fiuczynski (2):
qemu: virtio-crypto: add ccw support
qemu: virtio-crypto: add test for ccw support
Longpeng(Mike) (6):
docs: schema: Add basic documentation for the virtual
docs: news: Add virtio-crypto devices
conf: Parse virtio-crypto in the domain XML
caps: Add qemu capabilities about virtio-crypto
qemu: Implement support for 'builtin' backend for virtio-crypto
tests: Add testcase for virtio-crypto parsing
docs/formatdomain.html.in | 61 ++++++
docs/news.xml | 10 +
docs/schemas/domaincommon.rng | 30 +++
src/conf/domain_conf.c | 213 ++++++++++++++++++++-
src/conf/domain_conf.h | 32 ++++
src/libvirt_private.syms | 5 +
src/qemu/qemu_alias.c | 20 ++
src/qemu/qemu_alias.h | 3 +
src/qemu/qemu_capabilities.c | 6 +
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_command.c | 130 +++++++++++++
src/qemu/qemu_command.h | 3 +
src/qemu/qemu_domain_address.c | 25 +++
src/qemu/qemu_driver.c | 6 +
src/qemu/qemu_hotplug.c | 1 +
tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 +
tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 2 +
tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 2 +
.../qemuxml2argv-virtio-crypto-builtin.xml | 26 +++
.../qemuxml2argv-virtio-crypto-ccw.args | 22 +++
.../qemuxml2argv-virtio-crypto-ccw.xml | 16 ++
.../qemuxml2argv-virtio-crypto.args | 22 +++
tests/qemuxml2argvtest.c | 6 +
.../qemuxml2xmlout-virtio-crypto-builtin.xml | 31 +++
tests/qemuxml2xmltest.c | 2 +
25 files changed, 679 insertions(+), 1 deletion(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-builtin.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-ccw.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto-ccw.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-crypto.args
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-virtio-crypto-builtin.xml
--
1.8.3.1
6 years
[libvirt] [PATCH 00/30] syntax: Remove spaces after casts
by Martin Kletzander
According to previous discussions it looks like this is the preferred way
of casting. One difference to the previous one is that this time I
tuned the regexp a bit so that it doesn't match some macros and
assignments and it also matches structs.
Feel free to require squashing of some small patches together.
Martin Kletzander (30):
examples/: Remove spaces after casts
access/: Remove spaces after casts
admin/: Remove spaces after casts
conf/: Remove spaces after casts
cpu/: Remove spaces after casts
esx/: Remove spaces after casts
hyperv/: Remove spaces after casts
libxl/: Remove spaces after casts
locking/: Remove spaces after casts
lxc/: Remove spaces after casts
network/: Remove spaces after casts
nwfilter/: Remove spaces after casts
phyp/: Remove spaces after casts
qemu/: Remove spaces after casts
remote/: Remove spaces after casts
rpc/: Remove spaces after casts
security/: Remove spaces after casts
storage/: Remove spaces after casts
test/: Remove spaces after casts
uml/: Remove spaces after casts
util/: Remove spaces after casts
vbox/: Remove spaces after casts
vmx/: Remove spaces after casts
vz/: Remove spaces after casts
xenapi/: Remove spaces after casts
xenconfig/: Remove spaces after casts
tests/: Remove spaces after casts
tools/: Remove spaces after casts
Remove spaces after casts in rest of the files
Prohibit space after cast
cfg.mk | 6 +
docs/hacking.html.in | 9 +
examples/object-events/event-test.c | 34 +-
src/access/viraccessdriverpolkit.c | 2 +-
src/admin/admin_remote.c | 54 +--
src/admin/admin_server_dispatch.c | 8 +-
src/conf/cpu_conf.c | 6 +-
src/conf/device_conf.c | 2 +-
src/conf/domain_audit.c | 4 +-
src/conf/domain_conf.c | 88 ++--
src/conf/interface_conf.c | 4 +-
src/conf/network_conf.c | 4 +-
src/conf/nwfilter_params.c | 4 +-
src/conf/storage_conf.c | 48 +-
src/conf/virchrdev.c | 4 +-
src/conf/virnodedeviceobj.c | 4 +-
src/conf/virsecretobj.c | 2 +-
src/conf/virstorageobj.c | 4 +-
src/cpu/cpu_ppc64.c | 4 +-
src/esx/esx_driver.c | 2 +-
src/hyperv/hyperv_driver.c | 8 +-
src/hyperv/hyperv_wmi.c | 24 +-
src/internal.h | 4 +-
src/libvirt-domain.c | 4 +-
src/libvirt-host.c | 2 +-
src/libvirt-lxc.c | 4 +-
src/libvirt-stream.c | 4 +-
src/libxl/libxl_conf.c | 4 +-
src/locking/lock_driver_sanlock.c | 28 +-
src/lxc/lxc_cgroup.c | 2 +-
src/lxc/lxc_controller.c | 4 +-
src/lxc/lxc_domain.c | 4 +-
src/lxc/lxc_driver.c | 4 +-
src/lxc/lxc_monitor.c | 2 +-
src/lxc/lxc_native.c | 4 +-
src/lxc/lxc_process.c | 4 +-
src/network/bridge_driver.c | 4 +-
src/nwfilter/nwfilter_dhcpsnoop.c | 6 +-
src/phyp/phyp_driver.c | 2 +-
src/qemu/qemu_agent.c | 4 +-
src/qemu/qemu_alias.c | 2 +-
src/qemu/qemu_block.c | 2 +-
src/qemu/qemu_capabilities.c | 20 +-
src/qemu/qemu_command.c | 18 +-
src/qemu/qemu_domain.c | 32 +-
src/qemu/qemu_domain_address.c | 12 +-
src/qemu/qemu_driver.c | 68 +--
src/qemu/qemu_hostdev.c | 2 +-
src/qemu/qemu_hotplug.c | 8 +-
src/qemu/qemu_migration.c | 2 +-
src/qemu/qemu_monitor.c | 2 +-
src/qemu/qemu_monitor_json.c | 4 +-
src/qemu/qemu_parse_command.c | 6 +-
src/qemu/qemu_process.c | 10 +-
src/remote/remote_daemon_dispatch.c | 50 +-
src/remote/remote_daemon_stream.c | 2 +-
src/remote/remote_driver.c | 620 ++++++++++++-------------
src/remote/remote_protocol.x | 18 +-
src/rpc/virnetclientstream.c | 4 +-
src/rpc/virnetserverclient.c | 2 +-
src/rpc/virnetserverprogram.c | 2 +-
src/rpc/virnetsocket.c | 6 +-
src/security/security_apparmor.c | 6 +-
src/security/security_dac.c | 42 +-
src/security/security_selinux.c | 14 +-
src/security/virt-aa-helper.c | 2 +-
src/storage/storage_backend_fs.c | 2 +-
src/storage/storage_backend_gluster.c | 6 +-
src/storage/storage_backend_logical.c | 2 +-
src/storage/storage_backend_vstorage.c | 6 +-
src/storage/storage_driver.c | 6 +-
src/storage/storage_util.c | 44 +-
src/test/test_driver.c | 4 +-
src/uml/uml_driver.c | 6 +-
src/util/iohelper.c | 2 +-
src/util/viralloc.h | 12 +-
src/util/virarptable.c | 2 +-
src/util/viratomic.h | 14 +-
src/util/virbitmap.c | 4 +-
src/util/virbuffer.c | 2 +-
src/util/vircgroup.c | 10 +-
src/util/vircommand.c | 4 +-
src/util/virdnsmasq.c | 2 +-
src/util/virfdstream.c | 6 +-
src/util/virfile.c | 46 +-
src/util/virfirmware.c | 4 +-
src/util/virhostcpu.c | 2 +-
src/util/virhostmem.c | 8 +-
src/util/viridentity.c | 2 +-
src/util/virjson.c | 4 +-
src/util/virlog.c | 8 +-
src/util/virmacaddr.c | 2 +-
src/util/virmacmap.c | 2 +-
src/util/virnetdev.c | 4 +-
src/util/virnetdevtap.c | 2 +-
src/util/virobject.c | 2 +-
src/util/virpidfile.c | 6 +-
src/util/virpolkit.c | 4 +-
src/util/virprocess.c | 26 +-
src/util/virresctrl.c | 4 +-
src/util/virsexpr.c | 8 +-
src/util/virstoragefile.c | 8 +-
src/util/virstring.c | 14 +-
src/util/virsysinfo.c | 2 +-
src/util/virsystemd.c | 4 +-
src/util/virthreadjob.c | 4 +-
src/util/virthreadpool.c | 4 +-
src/util/virtime.c | 4 +-
src/util/virutil.c | 26 +-
src/util/virutil.h | 6 +-
src/util/virxml.c | 30 +-
src/vbox/vbox_common.c | 4 +-
src/vbox/vbox_tmpl.c | 2 +-
src/vmx/vmx.c | 4 +-
src/vz/vz_utils.h | 2 +-
src/xenapi/xenapi_driver.c | 4 +-
src/xenconfig/xen_common.c | 4 +-
src/xenconfig/xen_xl.c | 2 +-
tests/domaincapstest.c | 4 +-
tests/qemuhotplugtest.c | 2 +-
tests/qemumonitorjsontest.c | 42 +-
tests/qemuxml2argvtest.c | 4 +-
tests/testutils.c | 2 +-
tests/testutils.h | 2 +-
tests/testutilshostcpus.h | 88 ++--
tests/virbitmaptest.c | 4 +-
tests/vircaps2xmltest.c | 2 +-
tests/virfiletest.c | 18 +-
tests/virfilewrapper.c | 2 +-
tests/virhashtest.c | 8 +-
tests/virhostcputest.c | 2 +-
tests/virhostdevtest.c | 2 +-
tests/virpcimock.c | 2 +-
tests/virpcitest.c | 2 +-
tests/virresctrltest.c | 2 +-
tests/virschematest.c | 2 +-
tests/virstoragetest.c | 42 +-
tests/virstringtest.c | 12 +-
tests/virusbmock.c | 2 +-
tools/nss/libvirt_nss.c | 14 +-
tools/virsh-domain-monitor.c | 14 +-
tools/virsh-domain.c | 16 +-
tools/virsh-interface.c | 12 +-
tools/virsh-network.c | 10 +-
tools/virsh-nodedev.c | 14 +-
tools/virsh-nwfilter.c | 6 +-
tools/virsh-pool.c | 36 +-
tools/virsh-secret.c | 6 +-
tools/virsh-util.c | 4 +-
tools/virsh-volume.c | 16 +-
tools/virt-admin.c | 4 +-
tools/vsh.c | 18 +-
152 files changed, 1097 insertions(+), 1082 deletions(-)
--
2.17.0
6 years, 2 months
[libvirt] [RFC] cgroup settings and systemd daemon-reload conflict
by Nikolay Shirokovskiy
Hi, all.
It turns out that systemd daemon-reload reset settings that are managable
thru 'systemctl set-property' interface.
> virsh schedinfo tst3 | grep global_quota
global_quota : -1
> virsh schedinfo tst3 --set global_quota=50000 | grep global_quota
global_quota : 50000
> systemctl daemon-reload
> virsh schedinfo tst3 | grep global_quota
global_quota : -1
This behaviour does not limited to cpu controller, same for blkio for example.
I checked different versions of systemd (219 - Feb 15, and quite recent 236 - Dec 17)
to make sure it is not kind of bug of old version. So systemd does not play well
with direct writes to cgroup parameters that managable thru systemd. Looks like
libvirtd needs to use systemd's dbus interface to change all such parameters.
I only wonder how this can be unnoticed for such long time (creating cgroup for domain
thru systemd - Jul 2013) as daemon-reload is called upon libvirtd package update. May
be I miss something?
Nikolay
6 years, 2 months
Re: [libvirt] [PATCH 0/3] sample: vfio mdev display devices.
by Alex Williamson
On Mon, 9 Apr 2018 12:35:10 +0200
Gerd Hoffmann <kraxel(a)redhat.com> wrote:
> This little series adds three drivers, for demo-ing and testing vfio
> display interface code. There is one mdev device for each interface
> type (mdpy.ko for region and mbochs.ko for dmabuf).
Erik Skultety brought up a good question today regarding how libvirt is
meant to handle these different flavors of display interfaces and
knowing whether a given mdev device has display support at all. It
seems that we cannot simply use the default display=auto because
libvirt needs to specifically configure gl support for a dmabuf type
interface versus not having such a requirement for a region interface,
perhaps even removing the emulated graphics in some cases (though I
don't think we have boot graphics through either solution yet).
Additionally, GVT-g seems to need the x-igd-opregion support
enabled(?), which is a non-starter for libvirt as it's an experimental
option!
Currently the only way to determine display support is through the
VFIO_DEVICE_QUERY_GFX_PLANE ioctl, but for libvirt to probe that on
their own they'd need to get to the point where they could open the
vfio device and perform the ioctl. That means opening a vfio
container, adding the group, setting the iommu type, and getting the
device. I was initially a bit appalled at asking libvirt to do that,
but the alternative is to put this information in sysfs, but doing that
we risk that we need to describe every nuance of the mdev device
through sysfs and it becomes a dumping ground for every possible
feature an mdev device might have.
So I was ready to return and suggest that maybe libvirt should probe
the device to know about these ancillary configuration details, but
then I remembered that both mdev vGPU vendors had external dependencies
to even allow probing the device. KVMGT will fail to open the device
if it's not associated with an instance of KVM and NVIDIA vGPU, I
believe, will fail if the vGPU manager process cannot find the QEMU
instance to extract the VM UUID. (Both of these were bad ideas)
Therefore, how can libvirt know if a given mdev device supports a
display and which type of display it supports, and potentially which
vendor specific options might be required to further enable that
display (if they weren't experimental)? A terrible solution would be
that libvirt hard codes that NVIDIA works with regions and Intel works
with dmabufs, but even then there's a backwards and forwards
compatibility problem, that libvirt needs to support older kernels and
drivers where display support is not present and newer drivers where
perhaps Intel is now doing regions and NVIDIA is supporting dmabuf, so
it cannot simply be assumed based on the vendor. The only solution I see
down that path would be identifying specific {vendor,type} pairs that
support a predefined display type, but that's just absurd to think that
vendors would rev their mdev types to expose this and that libvirt
would keep a database mapping types to features. We also have the name
and description attributes, but these are currently free form, so
libvirt rightfully ignores them entirely. I don't know if we could
create a defined feature string within those free form strings.
Otherwise, it seems we have no choice but to dive into the pool of
exposing such features via sysfs and we'll need to be vigilant of
feature creep or vendor specific features (ex. we're not adding a
feature to indicate an opregion requirement). How should we do this?
Perhaps a bar we can set is that if a feature cannot be discovered
through a standard vfio API, then it is not suitable for this sysfs
API. Such things can be described via our existing mdev vendor
specific attribute interface.
We currently have this sysfs interface:
mdev_supported_types/
|-- $VENDOR_TYPE
| |-- available_instances
| |-- create
| |-- description
| |-- device_api
| |-- devices
| `-- name
ioctls for vfio devices which only provide information include:
VFIO_DEVICE_GET_INFO
VFIO_DEVICE_GET_REGION_INFO
VFIO_DEVICE_GET_IRQ_INFO
VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
VFIO_DEVICE_QUERY_GFX_PLANE
We don't need to support all of these initially, but here's a starting
idea for what this may look like in sysfs:
$VENDOR_TYPE/
|-- available_instances
|-- create
|-- description
|-- device_api
|-- devices
|-- name
`-- vfio-pci
`-- device
|-- gfx_plane
| |-- dmabuf
| `-- region
|-- irqs
| |-- 0
| | |-- count
| | `-- flags
| `-- 1
| |-- count
| `-- flags
`-- regions
|-- 0
| |-- flags
| |-- offset
| `-- size
`-- 3
|-- flags
|-- offset
`-- size
The existing device_api file reports "vfio-pci", so we base the device
API info in a directory named vfio-pci. We're specifically exposing
device information, so we have a device directory. We have a GFX_PLANE
query ioctl, so we have a gfx_plane sub-directory. I imagine the
dmabuf and region files here expose either Y/N or 1/0. I continue on
the example with how we might expose irqs and regions, but even with
regions we can bury down into how is sparse mmap exposed, how are
device specific regions described, etc. Filling this in to completion
without a specific userspace need to expose the information is just an
exercise in bloating the kernel.
That almost begins to look reasonable, but then we can only expose this
for mdev devices, what if we were to hack a back door into a directly
assigned GPU that tracks the location of active display in the
framebuffer and implement the GFX_PLANE interface for that? We have no
sysfs representation for either the template or the actual device for
anything other than mdev. This inconsistency with physically assigned
devices has been one of my arguments against enhancing mdev sysfs.
Thanks to anyone still reading this. Ideas how we might help libvirt
fill this information void so that they can actually configure a VM
with a display device? Thanks,
Alex
6 years, 4 months
[libvirt] [PATCH libvirt v2 0/9] Fix virConnectRegisterCloseCallback and get rid of global variables
by Marc Hartmayer
The first part of this patch series fixes the behavior of
virConnectRegisterCloseCallback and converts the testDriver to
virObjectLockable.
The subsequent patches remove the need to have the global variables
'qemuProgram' and 'remoteProgram' in libvirtd.[ch]. They only work in
combination with the fixed behavior of virConnectRegisterCloseCallback.
Changelog:
+ v1->v2:
- Removed accepted patches
- Removed NACKed patches
- Added r-b to patch 5
- Worked in comments
- Rebased
- Added patches 7-9
Marc Hartmayer (9):
virConnectRegisterCloseCallback: Cleanup 'opaque' if there is no
connectRegisterCloseCallback
test: Convert testDriver to virObjectLockable
remote: Add the information which program has to be used to
daemonClientEventCallback
remote: Use domainClientEventCallbacks for
remoteReplayConnectionClosedEvent
rpc: Introduce virNetServerGetProgramLocked helper function
remote/rpc: Use virNetServerGetProgram() to determine the program
rpc: use the return value of virObjectRef directly
remote: remove ATTRIBUTE_UNUSED when attribute is actually used
remote: shrink the critical sections
src/libvirt-host.c | 10 +-
src/libvirt_remote.syms | 1 +
src/remote/remote_daemon.c | 4 +-
src/remote/remote_daemon.h | 3 -
src/remote/remote_daemon_dispatch.c | 264 +++++++++++++++++++++++-------------
src/rpc/gendispatch.pl | 6 +
src/rpc/virnetserver.c | 57 ++++++--
src/rpc/virnetserver.h | 2 +
src/test/test_driver.c | 200 ++++++++++++---------------
9 files changed, 328 insertions(+), 219 deletions(-)
--
2.13.4
6 years, 4 months
[libvirt] [PATCH v3 0/2] Support network stats for VF representor interface
by Jai Singh Rana
With availability of switchdev model in linux, it is possible to capture
stats for SR-IOV device with interface_type as 'hostdev' provided device
supports VF represontor in switchdev mode[1] on host.
These stats are supported by adding helper APIs for getting/verifying VF
representor name based on PCI Bus:Device:Function information in domains
'hostdev' structure and querying required net sysfs directory and file
entries on host according to switchdev model. These helper APIs are then
used in qemu/conf to get the interface stats for VF representor on host
of pci SR-IOV device.
[1] https://www.kernel.org/doc/Documentation/networking/switchdev.txt
V2 https://www.redhat.com/archives/libvir-list/2018-February/msg00561.html
Jai Singh Rana (2):
util: Add helper APIs to get/verify VF Representor name
qemu: conf: Network stats support for VF Representors
docs/news.xml | 9 ++
po/POTFILES.in | 1 +
src/conf/domain_conf.c | 15 ++
src/libvirt_private.syms | 7 +
src/qemu/qemu_driver.c | 33 +++-
src/util/Makefile.inc.am | 2 +
src/util/virhostdev.c | 2 +-
src/util/virhostdev.h | 8 +
src/util/virnetdevhostdev.c | 374 ++++++++++++++++++++++++++++++++++++++++++++
src/util/virnetdevhostdev.h | 35 +++++
10 files changed, 481 insertions(+), 5 deletions(-)
create mode 100644 src/util/virnetdevhostdev.c
create mode 100644 src/util/virnetdevhostdev.h
--
2.13.6
6 years, 4 months