> From: Kirti Wankhede [mailto:kwankhede@xxxxxxxxxx] > Sent: Tuesday, September 20, 2016 4:36 AM > > > Hi libvirt experts, > > Thanks for valuable input on v1 version of RFC. > > Quick brief, VFIO based mediated device framework provides a way to > virtualize their devices without SR-IOV, like NVIDIA vGPU, Intel KVMGT > and IBM's channel IO. This framework reuses VFIO APIs for all the > functionalities for mediated devices which are currently being used for > pass through devices. This framework introduces a set of new sysfs files > for device creation and its life cycle management. > > Here is the summary of discussion on v1: > 1. Discover mediated device: > As part of physical device initialization process, vendor driver will > register their physical devices, which will be used to create virtual > device (mediated device, aka mdev) to the mediated framework. > > Vendor driver should specify mdev_supported_types in directory format. > This format is class based, for example, display class directory format > should be as below. We need to define such set for each class of devices > which would be supported by mediated device framework. > > --- mdev_destroy > --- mdev_supported_types > |-- 11 > | |-- create > | |-- name > | |-- fb_length > | |-- resolution > | |-- heads > | |-- max_instances > | |-- params > | |-- requires_group > |-- 12 > | |-- create > | |-- name > | |-- fb_length > | |-- resolution > | |-- heads > | |-- max_instances > | |-- params > | |-- requires_group > |-- 13 > |-- create > |-- name > |-- fb_length > |-- resolution > |-- heads > |-- max_instances > |-- params > |-- requires_group > > Per previous discussion, I'd think below layout is more general and clearer: --- mdev_supported_types |-- ID (or name) | |-- create | |-- available_instances | |-- requires_group |-- ID (or name) | |-- create | |-- available_instances | |-- requires_group ... Then under each mdev directory: |-- type (link to type directory) |-- destroy |-- online |-- reset |-- Destroy Group association may be done under mdev directory too, per Alex's earlier suggestion. Optional vendor-agnostic attributes can be extended in the future, e.g.: |-- priority |-- weight Vendor-specific or class-specific parameters (black string or explicit attributes) could be also extended per-mdev directory, if necessary to support. Thanks Kevin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list