[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
[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
[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, 1 month
[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 v2 0/3] Add "memfd" memory backing type
by marcandre.lureau＠redhat.com
From: Marc-André Lureau <marcandre.lureau(a)redhat.com>
Hi,
This is an alternative series from "[PATCH 0/5] Use memfd if
possible". Instead of automatically using memfd for anonymous memory
when available (as suggested by Daniel), it introduces the "memfd"
memory backing type.
Although using memfd transparently when possible is a good idea, it is
a source of various complications for migration & save/restore. This
could eventually be challenged in a different series.
The first two patches have been modified and reviewed by John
Ferlan. Hopefully they can be merged early, regardless of the last
patch outcome, to avoid the painful rebase conflicts due to
capabilities checks introduction.
Thanks
Marc-André Lureau (3):
qemu: add memory-backend-memfd capability check
qemu: check memory-backend-memfd.hugetlb capability
qemu: add memfd source type
docs/formatdomain.html.in | 9 +-
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 3 +-
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 10 ++
src/qemu/qemu_capabilities.h | 2 +
src/qemu/qemu_command.c | 69 +++++++----
src/qemu/qemu_domain.c | 12 +-
.../caps_2.12.0.aarch64.replies | 94 ++++++++++++---
.../caps_2.12.0.aarch64.xml | 4 +-
.../caps_2.12.0.ppc64.replies | 90 +++++++++++---
.../caps_2.12.0.ppc64.xml | 4 +-
.../caps_2.12.0.s390x.replies | 98 ++++++++++++----
.../caps_2.12.0.s390x.xml | 4 +-
.../caps_2.12.0.x86_64.replies | 110 +++++++++++++-----
.../caps_2.12.0.x86_64.xml | 4 +-
.../caps_3.0.0.ppc64.replies | 90 +++++++++++---
.../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 4 +-
.../caps_3.0.0.riscv32.replies | 86 +++++++++++---
.../caps_3.0.0.riscv32.xml | 2 +
.../caps_3.0.0.riscv64.replies | 86 +++++++++++---
.../caps_3.0.0.riscv64.xml | 2 +
.../caps_3.0.0.x86_64.replies | 110 +++++++++++++-----
.../caps_3.0.0.x86_64.xml | 4 +-
.../memfd-memory-numa.x86_64-latest.args | 34 ++++++
tests/qemuxml2argvdata/memfd-memory-numa.xml | 36 ++++++
tests/qemuxml2argvtest.c | 2 +
27 files changed, 788 insertions(+), 183 deletions(-)
create mode 100644 tests/qemuxml2argvdata/memfd-memory-numa.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/memfd-memory-numa.xml
--
2.19.0
6 years
[libvirt] [PATCH v2] vhost-user: define conventions for vhost-user backends
by Marc-André Lureau
As discussed during "[PATCH v4 00/29] vhost-user for input & GPU"
review, let's define a common set of backend conventions to help with
management layer implementation, and interoperability.
v2:
- drop --pidfile
- add some notes about daemonizing & stdin/out/err
Cc: libvir-list(a)redhat.com
Cc: Gerd Hoffmann <kraxel(a)redhat.com>
Cc: Daniel P. Berrangé <berrange(a)redhat.com>
Cc: Changpeng Liu <changpeng.liu(a)intel.com>
Cc: Dr. David Alan Gilbert <dgilbert(a)redhat.com>
Cc: Felipe Franciosi <felipe(a)nutanix.com>
Cc: Gonglei <arei.gonglei(a)huawei.com>
Cc: Maxime Coquelin <maxime.coquelin(a)redhat.com>
Cc: Michael S. Tsirkin <mst(a)redhat.com>
Cc: Victor Kaplansky <victork(a)redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com>
---
docs/interop/vhost-user.txt | 109 +++++++++++++++++++++++++++++++++++-
1 file changed, 107 insertions(+), 2 deletions(-)
diff --git a/docs/interop/vhost-user.txt b/docs/interop/vhost-user.txt
index ba5e37d714..339b335e9c 100644
--- a/docs/interop/vhost-user.txt
+++ b/docs/interop/vhost-user.txt
@@ -17,8 +17,13 @@ The protocol defines 2 sides of the communication, master and slave. Master is
the application that shares its virtqueues, in our case QEMU. Slave is the
consumer of the virtqueues.
-In the current implementation QEMU is the Master, and the Slave is intended to
-be a software Ethernet switch running in user space, such as Snabbswitch.
+In the current implementation QEMU is the Master, and the Slave is the
+external process consuming the virtio queues, for example a software
+Ethernet switch running in user space, such as Snabbswitch, or a block
+device backend processing read & write to a virtual disk. In order to
+facilitate interoperability between various backend implementations,
+it is recommended to follow the "Backend program conventions"
+described in this document.
Master and slave can be either a client (i.e. connecting) or server (listening)
in the socket communication.
@@ -859,3 +864,103 @@ resilient for selective requests.
For the message types that already solicit a reply from the client, the
presence of VHOST_USER_PROTOCOL_F_REPLY_ACK or need_reply bit being set brings
no behavioural change. (See the 'Communication' section for details.)
+
+Backend program conventions
+---------------------------
+
+vhost-user backends provide various services and they may need to be
+configured manually depending on the use case. However, it is a good
+idea to follow the conventions listed here when possible. Users, QEMU
+or libvirt, can then rely on some common behaviour to avoid
+heterogenous configuration and management of the backend program and
+facilitate interoperability.
+
+In order to be discoverable, default vhost-user backends should be
+located under "/usr/libexec", and be named "vhost-user-$device" where
+"$device" is the device name in lower-case following the name listed
+in the Linux virtio_ids.h header (ex: the VIRTIO_ID_RPROC_SERIAL
+backend would be named "vhost-user-rproc-serial").
+
+Mechanisms to list, and to select among alternatives implementations
+or modify the default backend are not described at this point (a
+distribution may use update-alternatives, for example, to list and to
+pick a different default backend).
+
+The backend program must not daemonize itself, but it may be
+daemonized by the management layer. It may also have a restricted
+access to the system.
+
+File descriptors 0, 1 and 2 will exist, and have regular
+stdin/stdout/stderr usage (they may be redirected to /dev/null by the
+management layer, or to a log handler).
+
+The backend program must end (as quickly and cleanly as possible) when
+the SIGTERM signal is received. Eventually, it may be SIGKILL by the
+management layer after a few seconds.
+
+The following command line options have an expected behaviour. They
+are mandatory, unless explicitly said differently:
+
+* --socket-path=PATH
+
+This option specify the location of the vhost-user Unix domain socket.
+It is incompatible with --fd.
+
+* --fd=FDNUM
+
+When this argument is given, the backend program is started with the
+vhost-user socket as file descriptor FDNUM. It is incompatible with
+--socket-path.
+
+* --print-capabilities
+
+Output to stdout a line-seperated list of backend capabilities, and
+then exit successfully. Other options and arguments should be ignored,
+and the backend program should not perform its normal function.
+
+At the time of writing, there are no common capabilities. Some
+device-specific capabilities are listed in the respective sections. By
+convention, device-specific capabilities are prefixed by their device
+name.
+
+vhost-user-input program conventions
+------------------------------------
+
+Capabilities:
+
+input-evdev-path
+
+ The --evdev-path command line option is supported.
+
+input-no-grab
+
+ The --no-grab command line option is supported.
+
+* --evdev-path=PATH (optional)
+
+Specify the linux input device.
+
+* --no-grab (optional)
+
+Do no request exclusive access to the input device.
+
+vhost-user-gpu program conventions
+----------------------------------
+
+Capabilities:
+
+gpu-render-node
+
+ The --render-node command line option is supported.
+
+gpu-virgl
+
+ The --virgl command line option is supported.
+
+* --render-node=PATH (optional)
+
+Specify the GPU DRM render node.
+
+* --virgl (optional)
+
+Enable virgl rendering support.
--
2.19.0
6 years
[libvirt] [PATCH 00/11] Avoid numerous calls of virQEMUCapsCacheLookup
by Marc Hartmayer
For a domain definition there are numerous calls of
virQEMUCapsCacheLookup (the same applies to the domain start). This
slows down the process since virQEMUCapsCacheLookup validates that the
QEMU capabilitites are still valid (among other things, a fork is done
for this if the user for the QEMU processes is 'qemu'). Therefore
let's reduce the number of virQEMUCapsCacheLookup calls whenever
possible and reasonable.
In addition to the speed up, there is the risk that
virQEMUCapsCacheLookup returns different QEMU capabilities during a
task if, for example, the QEMU binary has changed during the task.
The correct way would be:
- get the QEMU capabilities only once per task via virQEMUCapsCacheLookup
- do the task with these QEMU capabilities
or
- abort the task after a cache invalidation
Note: With this patch series the behavior is still not (completely)
fixed, but the performance has been significantly improved. In a quick
test this gave a speed up of factor 4 for a simple define/undefine
loop.
In general, the more devices a domain has, the more drastic the
overhead becomes (because a cache validation is performed for each
device).
Marc Hartmayer (11):
qemu: Use VIR_STEAL_PTR macro
qemu: Introduce qemuDomainUpdateQEMUCaps()
qemu: Pass QEMUCaps to virDomainDefPostParse
conf: Use getParseOpaque() in virDomainObjSetDefTransient
conf: Add function description for virDomainDefPostParse
conf: Get rid of virDomainDeviceDefPostParseOne
conf: Extend virDomainDefValidate(Callback) for parseOpaque
conf: Use domainPostParseData(Alloc|Free) in virDomainDefValidate
qemu: Use @parseOpaque in qemuDomainDefValidate
conf: Extend virDomainDeviceDefValidate(Callback) for parseOpaque
qemu: Use @parseOpaque in qemuDomainDeviceDefValidate
src/conf/domain_conf.c | 98 ++++++++++++++++++++++++++---------------
src/conf/domain_conf.h | 9 ++--
src/qemu/qemu_domain.c | 82 +++++++++++++++++++---------------
src/qemu/qemu_domain.h | 4 ++
src/qemu/qemu_process.c | 18 +++-----
src/vz/vz_driver.c | 6 ++-
6 files changed, 128 insertions(+), 89 deletions(-)
--
2.17.0
6 years
[libvirt] [PATCH v6 00/13] PCI passthrough support on s390
by Yi Min Zhao
Abstract
========
The PCI representation in QEMU has recently been extended for S390
allowing configuration of zPCI attributes like uid (user-defined
identifier) and fid (PCI function identifier).
The details can be found here:
https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07262.html
To support the new zPCI feature of the S390 platform, a new element of
PCI address is introduced. It has two optional attributes, @uid and
@fid. For example:
<hostdev mode='subsystem' type='pci'>
<driver name='vfio'/>
<source>
<address domain='0x0001' bus='0x00' slot='0x00' function='0x0'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'>
<zpci uid='0x0003' fid='0x00000027'/>
</address>
</hostdev>
If they are defined by the user, unique values within the guest domain
must be used. If they are not specified and the architecture requires
them, they are automatically generated with non-conflicting values.
zPCI address as an extension of the PCI address are stored in a new
structure 'virZPCIDeviceAddress' which is a member of common PCI
Address structure. Additionally, two hashtables are used for assignment
and reservation of zPCI uid/fid.
In support of extending the PCI address, a new PCI address extension flag is
introduced. This extension flag allows is not only dedicated for the S390
platform but also other architectures needing certain extensions to PCI
address space.
Code Base
=========
commit in master:
b1a0f691ce4652fc71aca6776f085355040322da
spec: Build ceph and gluster support everywhere
Change Log
==========
v5->v6:
1. Modify zPCI XML definition.
2. Optimize the logic of zPCI address assignment and reservation.
3. Add extension flag into PCI address structure.
4. Update commit messages.
v4->v5:
1. Update the version number.
2. Fixup code style error.
3. Separate qemu code into single patch.
4. Rebase the patches to the new code of master branch.
v3->v4:
1. Update docs.
2. Format code style.
3. Optimize zPCI support check.
4. Move the check of zPCI defined in xml but unsupported by Qemu to
qemuDomainDeviceDefValidate().
5. Change zpci address member of PCI address struct from pointer to
instance.
6. Modify zpci address definition principle. Currently the user must
either define both of uid and fid or not.
v2->v3:
1. Revise code style.
2. Update test cases.
3. Introduce qemuDomainCollectPCIAddressExtension() to collect PCI
extension addresses.
4. Introduce virDeviceInfoPCIAddressExtensionPresent() to check if zPCI
address exists.
5. Optimize zPCI address check logic.
6. Optimize passed parameters of zPCI addr alloc/release/reserve functions.
7. Report enum range error in qemuDomainDeviceSupportZPCI().
8. Update commit messages.
v1->v2:
1. Separate test commit and merge testcases into corresponding commits that
introduce the functionalities firstly.
2. Spare some checks for zpci device.
3. Add vsock and controller support.
4. Add uin32 type schema.
5. Rename zpciuid and zpcifid to zpci_uid and zpci_fid.
6. Always return multibus support on S390.
Yi Min Zhao (13):
conf: Add definitions for 'uid' and 'fid' PCI address attributes
qemu: Introduce zPCI capability
conf: Introduce a new PCI address extension flag
qemu: Enable PCI multi bus for S390 guests
qemu: Auto add pci-root for s390/s390x guests
conf: Introduce address caching for PCI extensions
conf: Introduce parser, formatter for uid and fid
qemu: Add zPCI address definition check
conf: Allocate/release 'uid' and 'fid' in PCI address
qemu: Generate and use zPCI device in QEMU command line
qemu: Add hotpluging support for PCI devices on S390 guests
docs: Add 'uid' and 'fid' information
news: Update news for PCI address extension attributes
cfg.mk | 1 +
docs/formatdomain.html.in | 9 +-
docs/news.xml | 11 +
docs/schemas/basictypes.rng | 27 ++
docs/schemas/domaincommon.rng | 1 +
src/conf/device_conf.c | 90 +++++
src/conf/device_conf.h | 7 +
src/conf/domain_addr.c | 332 ++++++++++++++++++
src/conf/domain_addr.h | 30 ++
src/conf/domain_conf.c | 14 +-
src/libvirt_private.syms | 7 +
src/qemu/qemu_capabilities.c | 6 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 102 ++++++
src/qemu/qemu_command.h | 2 +
src/qemu/qemu_domain.c | 39 ++
src/qemu/qemu_domain_address.c | 204 ++++++++++-
src/qemu/qemu_hotplug.c | 162 ++++++++-
src/util/virpci.c | 7 +
src/util/virpci.h | 14 +
.../caps_2.10.0.s390x.xml | 1 +
.../caps_2.11.0.s390x.xml | 1 +
.../caps_2.12.0.s390x.xml | 1 +
.../qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 +
.../qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 +
.../qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 +
.../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 1 +
.../disk-virtio-s390-zpci.args | 26 ++
.../disk-virtio-s390-zpci.xml | 19 +
.../hostdev-vfio-zpci-autogenerate.args | 25 ++
.../hostdev-vfio-zpci-autogenerate.xml | 18 +
.../hostdev-vfio-zpci-boundaries.args | 29 ++
.../hostdev-vfio-zpci-boundaries.xml | 30 ++
.../hostdev-vfio-zpci-multidomain-many.args | 39 ++
.../hostdev-vfio-zpci-multidomain-many.xml | 79 +++++
tests/qemuxml2argvdata/hostdev-vfio-zpci.args | 25 ++
tests/qemuxml2argvdata/hostdev-vfio-zpci.xml | 21 ++
tests/qemuxml2argvtest.c | 20 ++
.../disk-virtio-s390-zpci.xml | 31 ++
.../hostdev-vfio-zpci-autogenerate.xml | 34 ++
.../hostdev-vfio-zpci-boundaries.xml | 48 +++
.../hostdev-vfio-zpci-multidomain-many.xml | 97 +++++
.../qemuxml2xmloutdata/hostdev-vfio-zpci.xml | 32 ++
tests/qemuxml2xmltest.c | 17 +
44 files changed, 1648 insertions(+), 15 deletions(-)
create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.args
create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.args
create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.xml
create mode 100644 tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml
--
Yi Min
6 years, 1 month
[libvirt] [RFC PATCH 0/2] Add new mdev type for aggregated resources
by Zhenyu Wang
Current mdev device create interface depends on fixed mdev type, which get uuid
from user to create instance of mdev device. If user wants to use customized
number of resource for mdev device, then only can create new mdev type for that
which may not be flexible.
To allow to create user defined resources for mdev, this RFC trys
to extend mdev create interface by adding new "instances=xxx" parameter
following uuid, for target mdev type if aggregation is supported, it can
create new mdev device which contains resources combined by number of
instances, e.g
echo "<uuid>,instances=10" > create
VM manager e.g libvirt can check mdev type with "aggregation" attribute
which can support this setting. And new sysfs attribute "instances" is
created for each mdev device to show allocated number. Default number
of 1 or no "instances" file can be used for compatibility check.
This RFC trys to create new KVMGT type with minimal vGPU resources which
can be combined with "instances=x" setting to allocate for user wanted resources.
Zhenyu Wang (2):
vfio/mdev: Add new instances parameters for mdev create
drm/i915/gvt: Add new aggregation type
drivers/gpu/drm/i915/gvt/gvt.c | 26 ++++++++++++---
drivers/gpu/drm/i915/gvt/gvt.h | 14 +++++---
drivers/gpu/drm/i915/gvt/kvmgt.c | 9 +++--
drivers/gpu/drm/i915/gvt/vgpu.c | 56 ++++++++++++++++++++++++++++----
drivers/s390/cio/vfio_ccw_ops.c | 3 +-
drivers/vfio/mdev/mdev_core.c | 11 ++++---
drivers/vfio/mdev/mdev_private.h | 6 +++-
drivers/vfio/mdev/mdev_sysfs.c | 42 ++++++++++++++++++++----
include/linux/mdev.h | 3 +-
samples/vfio-mdev/mbochs.c | 3 +-
samples/vfio-mdev/mdpy.c | 3 +-
samples/vfio-mdev/mtty.c | 3 +-
12 files changed, 141 insertions(+), 38 deletions(-)
--
2.18.0.rc2
6 years, 1 month
