July 2018 - Devel - libvirt List Archives

[libvirt] Matching the type of mediated devices in the migration
by Wang, Zhi A 23 Aug '18

23 Aug '18

BACKGROUND As the live migration of mdev is going to be supported in VFIO, a scheme of deciding if a mdev could be migratable between the source machine and the destination machine is needed. Mostly, this email is going to discuss a possible solution which needs fewer modifications of libvirt/VFIO. The configuration of a mdev is located in the domain XML, which guides libvirt how to find the mdev and generating the command line for QEMU. It basically only includes the UUID of a mdev. The domain XML of the source machine and destination machine are going to be compared before the migration really happens. Each configuration item would be compared and checked by libvirt. If one item of the source machine is different from the item of destination machine, the migration fails. For mdev, there is no any check/match before the migration happens yet. The user could use the node device list of libvirt to list the host devices and see the capabilities of those devices. The current node device code of libvirt has already been able to extract the supported mdev types from a host PCI device, plus some basic information, like max supported mdev instance of a host PCI device. THE SOLUTION To strictly check the mdev type and make sure the migration happens between the compatible mediated devices, three new mandatory elements in the domain XML below the hostdev element would be introduced: vendorid: The vendor ID of the mdev, which comes from the host PCI device. A user could obtain this information from the host PCI device which supports mdev in the node device list. productid: The product ID of the mdev, which also comes from the host PCI device. A user could obtain this information from the same approach above. mdevtype: The type of the mdev. As the creation of the mdev is managed by the user, the user knows the type of the mdev and would be responsible for filling out this information. These three elements are only needed when the device API of a mdev is "vfio-PCI". Take the example of mdev configuration from https://libvirt.org/formatdomain.html to illustrate the modification: <devices> <hostdev mode='subsystem' type='mdev' model='vfio-pci'> <source> <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'/> <vendorid>0xdead</vendorid>  <productid>0xbeef</productid>  <mdevtype>type</mdevtype>  </source> </hostdev> With the newly introduced elements above, the flow of the creation of a domain XML with mdev will be like: 1. The user obtains the vendorid/productid from node device list 2. The user fills the vendorid/productid/mdevtype in the domain XML 3. When a migration happens, libvirt check these elements. If one item is different between two domain XML, then migration fails. POSSIBLE MODIFICATION OF LIBVIRT 1) Introduce three new elements in domain XML parsing and processing functions. 2) Extend the function virDomainDeviceInfoCheckABIStability() which is going to check the host dev part of the domain XMLs between the source machine and the destination machine. So it could fail the migration when it finds out the IDs and the mdev type are different between domain XMLs. PROS Minor changes in libvirt could achieve the mdev type match in the migration. Modifying VFIO and other mdev components is not necessary. Thanks, Zhi.

6 21

[libvirt] [PATCH 0/2] vnc: remove deprecated TLS related features
by Daniel P. Berrangé 21 Aug '18

21 Aug '18

Daniel P. Berrangé (2): doc: switch to modern syntax for VNC TLS setup vnc: remove support for deprecated tls, x509, x509verify options qemu-deprecated.texi | 20 ---------- qemu-doc.texi | 20 +++++++--- qemu-options.hx | 43 --------------------- ui/vnc.c | 91 -------------------------------------------- 4 files changed, 15 insertions(+), 159 deletions(-) -- 2.17.1

2 3

[libvirt] [PATCHv2 00/11] BaselineHypervisorCPU using QEMU QMP exchanges
by Chris Venteicher 17 Aug '18

17 Aug '18

Some architectures (S390) depend on QEMU to compute baseline CPU model and expand a models feature set. Interacting with QEMU requires starting the QEMU process and completing one or more query-cpu-model-baseline QMP exchanges with QEMU in addition to a query-cpu-model-expansion QMP exchange to expand all features in the model. See "s390x CPU models: exposing features" patch set on Qemu-devel for discussion of QEMU aspects. This is part of resolution of: https://bugzilla.redhat.com/show_bug.cgi?id=1511999 Version 2 address all issues raised by Collin as well as all other issues identified with additional testing. Chris Venteicher (11): qemu_monitor_json: Introduce qemuMonitorCPUModelInfo / JSON conversion qemu_monitor: Introduce qemuMonitorGetCPUModelBaseline (query-cpu-model-baseline) qemu_monitor: Indicate when CPUModelInfo props report migratablity qemu_monitor: Introduce qemuMonitorCPUModelInfoInit and qemuMonitorCPUModelInfoFreeContents qemu_monitor: CPUModelExpansion on both model name and properties qemu_monitor: Introduce qemuMonitorCPUModelInfoRemovePropByBoolValue qemu_capabilities: Introduce virCPUDef / qemuMonitorCPUModelInfo conversions qemu_capabilities: QMPCommandPtr without maintaining shadow qmperr qemu_capabilities: Persist QEMU instance over multiple QMP Cmds qemu_capabilities: Introduce virQEMUCapsQMPBaselineCPUModel (baseline using QEMU) qemu_driver: BaselineHypervisorCPU supports S390 using QEMU/QMP src/qemu/qemu_capabilities.c | 349 +++++++++++++++++++++++++++++------ src/qemu/qemu_capabilities.h | 33 ++++ src/qemu/qemu_driver.c | 74 +++++++- src/qemu/qemu_monitor.c | 117 +++++++++++- src/qemu/qemu_monitor.h | 21 ++- src/qemu/qemu_monitor_json.c | 232 +++++++++++++++++++---- src/qemu/qemu_monitor_json.h | 14 +- tests/cputest.c | 7 +- 8 files changed, 724 insertions(+), 123 deletions(-) -- 2.17.1

4 41

[libvirt] [RFC PATCH 00/17] Add vhost-user-gpu support
by marcandre.lureau＠redhat.com 16 Aug '18

16 Aug '18

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, This series of patches add support for running a virtio GPU in a seperate process, using vhost-user. The QEMU series "[PATCH v4 00/29] vhost-user for input & GPU" is still under review, and will hopefully land in 3.1. There are several benefits of running the GPU process in an external process, since Mesa is rather heavy on the qemu main loop, and may block for a while or crash. I observe x5 performance improvements with Unigine Heaven 4 benchmark. The external GPU process is started with one end of the vhost-user socket pair, the other end is given to a QEMU chardev. It is also added to the emulator cgroup to restrict its CPU usage. vhost-user requires shared VM memory. A few preliminary patches ease and improve shared memory setup, when no explicit domain NUMA configuration is given. Also, if there is no need for file-backed memory, teach libvirt to make use of memfd memory backend, which has better security guarantees and is easier to setup. Review welcome! Marc-André Lureau (17): qemu: setup shared memory without explicit numa configuration qemu: add memory-backend-memfd capability check qemu: use memory-backend-memfd if possible qemu: add vhost-user-gpu capabilities domain: add "vhost-user" video type qemu: fill the vhost-user video type capability qemu: check that qemu is vhost-user-vga capable qemu: vhost-user is valid as non-primary video device qemu: validate vhost-user video model qemu: add qemuSecurityStartVhostUserGPU helper qemu: add vhost-user-gpu helper unit qemu: restrict 'virgl=' option to 'virtio' video type qemu: set default address type on vhost-user video model qemu: start/stop the vhost-user-gpu external device qemu: build vhost-user-backend for vhost-user-gpu qemu: build vhost-user-gpu video device arguments tests: add vhost-user-gpu xml2argv tests docs/formatdomain.html.in | 5 +- docs/schemas/domaincommon.rng | 1 + src/conf/device_conf.h | 1 + src/conf/domain_conf.c | 4 +- src/conf/domain_conf.h | 1 + src/qemu/Makefile.inc.am | 2 + src/qemu/qemu_capabilities.c | 10 + src/qemu/qemu_capabilities.h | 5 + src/qemu/qemu_command.c | 191 ++++++++--- src/qemu/qemu_domain.c | 8 +- src/qemu/qemu_domain_address.c | 4 +- src/qemu/qemu_extdevice.c | 47 ++- src/qemu/qemu_process.c | 6 +- src/qemu/qemu_security.c | 48 +++ src/qemu/qemu_security.h | 6 + src/qemu/qemu_vhost_user_gpu.c | 318 ++++++++++++++++++ src/qemu/qemu_vhost_user_gpu.h | 48 +++ tests/domaincapsschemadata/full.xml | 1 + .../caps_2.12.0.aarch64.xml | 1 + .../caps_2.12.0.ppc64.xml | 1 + .../caps_2.12.0.s390x.xml | 1 + .../caps_2.12.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 1 + .../caps_3.0.0.x86_64.xml | 1 + .../fd-memory-no-numa-topology.args | 4 + tests/qemuxml2argvdata/memfd.args | 28 ++ tests/qemuxml2argvdata/memfd.xml | 32 ++ .../vhost-user-gpu-secondary.args | 34 ++ .../vhost-user-gpu-secondary.xml | 38 +++ tests/qemuxml2argvdata/vhost-user-vga.args | 31 ++ tests/qemuxml2argvdata/vhost-user-vga.xml | 35 ++ tests/qemuxml2argvtest.c | 14 + 32 files changed, 877 insertions(+), 51 deletions(-) create mode 100644 src/qemu/qemu_vhost_user_gpu.c create mode 100644 src/qemu/qemu_vhost_user_gpu.h create mode 100644 tests/qemuxml2argvdata/memfd.args create mode 100644 tests/qemuxml2argvdata/memfd.xml create mode 100644 tests/qemuxml2argvdata/vhost-user-gpu-secondary.args create mode 100644 tests/qemuxml2argvdata/vhost-user-gpu-secondary.xml create mode 100644 tests/qemuxml2argvdata/vhost-user-vga.args create mode 100644 tests/qemuxml2argvdata/vhost-user-vga.xml -- 2.18.0.129.ge3331758f1

5 25

[libvirt] [PATCH v3 0/3] Don't touch user data from tests
by Michal Privoznik 15 Aug '18

15 Aug '18

v3 of: https://www.redhat.com/archives/libvir-list/2018-July/msg00747.html diff to v2: - pushed some already ACKed patches - dropped controversial line from 1/3 that turned off error reporting Michal Prívozník (3): qemuxml2argvtest: Set more fake drivers check-file-access: Allow specifying action virtestmock: Track action tests/check-file-access.pl | 32 +++++++++++++++++++++++++++----- tests/file_access_whitelist.txt | 15 ++++++++++----- tests/qemuxml2argvtest.c | 4 ++++ tests/virtestmock.c | 39 ++++++++++++++++++++++----------------- 4 files changed, 63 insertions(+), 27 deletions(-) -- 2.16.4

3 10

[libvirt] [dbus PATCH 0/4] Fix 'make check' with libvirt 3.0.0
by Andrea Bolognani 14 Aug '18

14 Aug '18

Andrea Bolognani (4): tests: Drop pytest.mark.usefixtures from test_nodedev tests: Move some test cases to test_nodedev tests: Don't open-code node_device_create() tests: Make node_device_create() work with libvirt 3.0.0 tests/libvirttest.py | 17 ++++++++++++++++- tests/test_connect.py | 27 --------------------------- tests/test_nodedev.py | 26 +++++++++++++++++++++++++- tests/xmldata.py | 2 +- 4 files changed, 42 insertions(+), 30 deletions(-) -- 2.17.1

3 8

[libvirt] [PATCH v2] libvirt_iohelper: record the libvirt_iohelper's error message at virFileWrapperFdFree
by xinhua.Cao 14 Aug '18

14 Aug '18

Currently iohelper's error log is recorded in virFileWrapperFdClose. In qemuDomainSaveMemory, it usually fails at qemuMigrationSrcToFile, and then goto cleanup, so the iohelper error log is not recorded, and so is the another placement. We now record the error log of iohelper by move it to the virFileWrapperFdFree record. And for the virCommandWait() - we should call virCommandAbort() in virFileWrapperFdFree() to make sure no process is left behind. If virCommandWait() is called then virCommandAbort() is a NO-OP. If it isn't, then Abort() will kill iohelper. Thanks for Michal for this advice Signed-off-by: xinhua.Cao <caoxinhua(a)huawei.com> --- src/util/virfile.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/util/virfile.c b/src/util/virfile.c index 1faeebb..590fc0e 100644 --- a/src/util/virfile.c +++ b/src/util/virfile.c @@ -330,9 +330,6 @@ virFileWrapperFdClose(virFileWrapperFdPtr wfd) return 0; ret = virCommandWait(wfd->cmd, NULL); - if (wfd->err_msg && *wfd->err_msg) - VIR_WARN("iohelper reports: %s", wfd->err_msg); - return ret; } @@ -351,6 +348,10 @@ virFileWrapperFdFree(virFileWrapperFdPtr wfd) if (!wfd) return; + if (wfd->err_msg && *wfd->err_msg) + VIR_WARN("iohelper reports: %s", wfd->err_msg); + + virCommandAbort(wfd->cmd); VIR_FREE(wfd->err_msg); virCommandFree(wfd->cmd); -- 2.8.3

2 1

[libvirt] [PATCH v2 RESEND 00/17] Introduce RDT memory bandwidth allocation support
by bing.niu＠intel.com 14 Aug '18

14 Aug '18

From: Bing Niu <bing.niu(a)intel.com> This series is to introduce RDT memory bandwidth allocation support by extending current virresctrl implementation. The Memory Bandwidth Allocation (MBA) feature provides indirect and approximate control over memory bandwidth available per-core. This feature provides a method to control applications which may be over-utilizing bandwidth relative to their priority in environments such as the data-center. The details can be found in Intel's SDM 17.19.7. Kernel supports MBA through resctrl file system same as CAT. Each resctrl group have a MB parameter to control how much memory bandwidth it can utilize in unit of percentage. In this series, MBA is enabled by enhancing existing virresctrl implementation. The policy employed for MBA is similar with CAT: The sum of each MBA group's bandwidth dose not exceed 100%. The enhancement of virresctrl include two main parts: Part 1: Add two new structures virResctrlInfoMemMB and virResctrlAllocMemBW for collecting host system MBA capability and domain memory bandwidth allocation. Those two structures are the extension of existing virResctrlInfo and virResctrlAlloc. With them, virresctrl framework can support MBA and CAT concurrently. Each virResctrlAlloc represent a resource allocation including CAT, or MBA, or CAT&MBA. The policy of MBA is that: total memory bandwidth of each resctrl group, created by virresctrl, does not exceed to 100%. Part 2: On XML part, add new elements to host capabilities query and domain allocation to support memory bandwidth allocation. --------------------------------------------------------------------------------------------- For host capabilities XML, new XML format like below example, <host> ..... <memory_bandwidth> <node id='0' cpus='0-19'> <control granularity='10' min ='10' maxAllocs='8'/> </node> </memory_bandwidth> </host> granularity --- memory bandwidth granularity min --- minimum memory bandwidth allowed maxAllocs --- maximum concurrent memory bandwidth allocation allowed. --------------------------------------------------------------------------------------------- For domain XML, new format as below example <domain type='kvm' id='2'> ...... <cputune> ...... <shares>1024</shares> <memorytune vcpus='0-1'> <node id='0' bandwidth='20'/> </memorytune> </cputune> ...... </domain> id --- node where memory bandwidth allocation will happen bandwidth --- bandwidth allocated in percentage ---------------------------------------------------------------------------------------------- With this extension of the virresctrl, the overall working follow of CAT and MBA is described by below picture. XML parser will aggregate MBA and CAT configuration and represents it in one virresctrl object. The methods of virresctrl class will manipulate resctrl interface to allocate corresponding resources. <memorytune cpus='0-3'> +---------+ | <cachetune vcpus='0-3'> XML | + parser +-----------+ | | +------------------------------+ | | internal object +------v--------------+ virResctrlAlloc | backing object | +------+--------------+ | | +------------------------------+ | +--v-------+ | | | schemata | /sys/fs/resctrl | tasks | | . | | . | | | +----------+ --------------------------------------------------------------------- previous versions and discussion can be found at v1: https://www.redhat.com/archives/libvir-list/2018-July/msg01144.html RFC v2: https://www.redhat.com/archives/libvir-list/2018-June/msg01268.html RFC v1: https://www.redhat.com/archives/libvir-list/2018-May/msg02101.html Changelog: v1 -> this: John's comment: 1. Split calculation of number of memory bandwidth control to one patch. 2. Split virResctrlAllocMemBW relating methods to 5 patch, each provides one kind of function, eg: schemata processing, memory bandwidth calculation..... 3. Use resctrl to replace cachetune in domain conf. 4. Split refactor virDomainCachetuneDefParse into 3 patches. And adjust some logic, eg: use %s format error log, renaming functions..... 5. Complete doc description. eg: update cachetune part about vcpus overlapping with memorytune, update libvirt version info for memory bandwidth control availability. 6. Some coding style fix. RFC_v2->v1: John's comment: 1. use name MemBW to replace MB for a more clear description. 2. split rename patch and put refactor function part separately. 3. split virResctrlInfoMemMB and virResctrlAllocMemBW to different patches. 4. add docs/schemas/*.rng for XML related patches. 5. some cleanup for coding conventions. RFC_ v1->RFC_v2: Jano's comment: 1. put renaming parts into separated patches. 2. set the initial return value as -1. 3. using full name in structure definition. 4. do not use VIR_CACHE_TYPE_LAST for memory bandwidth allocation formatting. Pavel's comment: 1. add host capabilities XML for memory bandwidth allocation. 2. do not mix use cachetune section in XML for memory bandwidth allocation in domain XML. define a dedicated one for memory bandwidth allocation. Bing Niu (17): util: Rename some functions of virresctrl util: Refactor virResctrlGetInfo in virresctrl util: Refactor virResctrlAllocFormat of virresctrl util: Add MBA capability information query to resctrl util: Add MBA check to virResctrlInfoGetCache util: Add MBA allocation to virresctrl util: Add MBA schemata parse and format methods util: Add support to calculate MBA utilization util: Introduce virResctrlAllocForeachMemory util: Introduce virResctrlAllocSetMemoryBandwidth conf: Rename cachetune to resctrl conf: Factor out vcpus parsing part from virDomainCachetuneDefParse conf: Factor out vcpus overlapping from virDomainCachetuneDefParse conf: Factor out virDomainResctrlDef update from virDomainCachetuneDefParse conf: Add support for memorytune XML processing for resctrl MBA conf: Add return value check to virResctrlAllocForeachCache conf: Add memory bandwidth allocation capability of host docs/formatdomain.html.in | 39 +- docs/schemas/capability.rng | 33 ++ docs/schemas/domaincommon.rng | 17 + src/conf/capabilities.c | 107 ++++ src/conf/capabilities.h | 11 + src/conf/domain_conf.c | 428 ++++++++++++--- src/conf/domain_conf.h | 10 +- src/libvirt_private.syms | 6 +- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_process.c | 18 +- src/util/virresctrl.c | 611 +++++++++++++++++++-- src/util/virresctrl.h | 55 +- .../memorytune-colliding-allocs.xml | 30 + .../memorytune-colliding-cachetune.xml | 32 ++ tests/genericxml2xmlindata/memorytune.xml | 33 ++ tests/genericxml2xmltest.c | 5 + .../linux-resctrl/resctrl/info/MB/bandwidth_gran | 1 + .../linux-resctrl/resctrl/info/MB/min_bandwidth | 1 + .../linux-resctrl/resctrl/info/MB/num_closids | 1 + tests/vircaps2xmldata/vircaps-x86_64-resctrl.xml | 8 + tests/virresctrldata/resctrl.schemata | 1 + 21 files changed, 1280 insertions(+), 169 deletions(-) create mode 100644 tests/genericxml2xmlindata/memorytune-colliding-allocs.xml create mode 100644 tests/genericxml2xmlindata/memorytune-colliding-cachetune.xml create mode 100644 tests/genericxml2xmlindata/memorytune.xml create mode 100644 tests/vircaps2xmldata/linux-resctrl/resctrl/info/MB/bandwidth_gran create mode 100644 tests/vircaps2xmldata/linux-resctrl/resctrl/info/MB/min_bandwidth create mode 100644 tests/vircaps2xmldata/linux-resctrl/resctrl/info/MB/num_closids -- 2.7.4

3 26

[libvirt] [PATCH] spec: Use %make_install
by Cole Robinson 13 Aug '18

13 Aug '18

It's on RHEL7, saves a bit of typing, and lets us drop the comment Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- There's also a %make_build macro which handles smp_mflags, but it uses make -O which makes build output noisier at least libvirt.spec.in | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 4113579e47..01f4e07b1c 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1255,10 +1255,7 @@ rm -fr %{buildroot} export SOURCE_DATE_EPOCH=$(stat --printf='%Y' %{_specdir}/%{name}.spec) -# Avoid using makeinstall macro as it changes prefixes rather than setting -# DESTDIR. Newer make_install macro would be better but it's not available -# on RHEL 5, thus we need to expand it here. -make %{?_smp_mflags} install DESTDIR=%{?buildroot} SYSTEMD_UNIT_DIR=%{_unitdir} V=1 +%make_install %{?_smp_mflags} SYSTEMD_UNIT_DIR=%{_unitdir} V=1 make %{?_smp_mflags} -C examples distclean V=1 -- 2.17.1

3 2

Re: [libvirt] [PATCH 0/3] sample: vfio mdev display devices.
by Alex Williamson 08 Aug '18

08 Aug '18

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

11 31