Re: [libvirt] [PATCH 0/6] VFIO mdev aggregated resources handling
On Thu, 24 Oct 2019 13:08:23 +0800
Zhenyu Wang <zhenyuw(a)linux.intel.com> wrote:
Hi,
This is a refresh for previous send of this series. I got impression that
some SIOV drivers would still deploy their own create and config method so
stopped effort on this. But seems this would still be useful for some other
SIOV driver which may simply want capability to aggregate resources. So here's
refreshed series.
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. This requirement comes not only from to be able to
allocate flexible resources for KVMGT, but also from Intel scalable IO
virtualization which would use vfio/mdev to be able to allocate arbitrary
resources on mdev instance. More info on [1] [2] [3].
To allow to create user defined resources for mdev, it trys to extend mdev
create interface by adding new "aggregate=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>,aggregate=10" > create
VM manager e.g libvirt can check mdev type with "aggregation" attribute which
can support this setting. If no "aggregation" attribute found for mdev type,
previous behavior is still kept for one instance allocation. And new sysfs
attribute "aggregated_instances" is created for each mdev device to show
allocated number.
Given discussions we've had recently around libvirt interacting with
mdev, I think that libvirt would rather have an abstract interface via
mdevctl[1]. Therefore can you evaluate how mdevctl would support this
creation extension? It seems like it would fit within the existing
mdev and mdevctl framework if aggregation were simply a sysfs attribute
for the device. For example, the mdevctl steps might look like this:
mdevctl define -u UUID -p PARENT -t TYPE
mdevctl modify -u UUID --addattr=mdev/aggregation --value=2
mdevctl start -u UUID
When mdevctl starts the mdev, it will first create it using the
existing mechanism, then apply aggregation attribute, which can consume
the necessary additional instances from the parent device, or return an
error, which would unwind and return a failure code to the caller
(libvirt). I think the vendor driver would then have freedom to decide
when the attribute could be modified, for instance it would be entirely
reasonable to return -EBUSY if the user attempts to modify the
attribute while the mdev device is in-use. Effectively aggregation
simply becomes a standardized attribute with common meaning. Thoughts?
[cc libvirt folks for their impression] Thanks,
Alex
[1] https://github.com/mdevctl/mdevctl
References:
[1]
https://software.intel.com/en-us/download/intel-virtualization-technology...
[2]
https://software.intel.com/en-us/download/intel-scalable-io-virtualizatio...
[3] https://schd.ws/hosted_files/lc32018/00/LC3-SIOV-final.pdf
Zhenyu Wang (6):
vfio/mdev: Add new "aggregate" parameter for mdev create
vfio/mdev: Add "aggregation" attribute for supported mdev type
vfio/mdev: Add "aggregated_instances" attribute for supported mdev
device
Documentation/driver-api/vfio-mediated-device.rst: Update for
vfio/mdev aggregation support
Documentation/ABI/testing/sysfs-bus-vfio-mdev: Update for vfio/mdev
aggregation support
drm/i915/gvt: Add new type with aggregation support
Documentation/ABI/testing/sysfs-bus-vfio-mdev | 24 ++++++
.../driver-api/vfio-mediated-device.rst | 23 ++++++
drivers/gpu/drm/i915/gvt/gvt.c | 4 +-
drivers/gpu/drm/i915/gvt/gvt.h | 11 ++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 53 ++++++++++++-
drivers/gpu/drm/i915/gvt/vgpu.c | 56 ++++++++++++-
drivers/vfio/mdev/mdev_core.c | 36 ++++++++-
drivers/vfio/mdev/mdev_private.h | 6 +-
drivers/vfio/mdev/mdev_sysfs.c | 79 ++++++++++++++++++-
include/linux/mdev.h | 19 +++++
10 files changed, 294 insertions(+), 17 deletions(-)