Re: [ovirt-devel] Re: device compatibility interface for live migration with assigned devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2020/8/19 上午11:30, Yan Zhao wrote:
hi All,
could we decide that sysfs is the interface that every VFIO vendor driver
needs to provide in order to support vfio live migration, otherwise the
userspace management tool would not list the device into the compatible
list?

if that's true, let's move to the standardizing of the sysfs interface.
(1) content
common part: (must)
    - software_version: (in major.minor.bugfix scheme)


This can not work for devices whose features can be negotiated/advertised independently. (E.g virtio devices)


    - device_api: vfio-pci or vfio-ccw ...
    - type: mdev type for mdev device or
            a signature for physical device which is a counterpart for
	   mdev type.

device api specific part: (must)
   - pci id: pci id of mdev parent device or pci id of physical pci
     device (device_api is vfio-pci)API here.


So this assumes a PCI device which is probably not true.


   - subchannel_type (device_api is vfio-ccw)
vendor driver specific part: (optional)
   - aggregator
   - chpid_type
   - remote_url


For "remote_url", just wonder if it's better to integrate or reuse the existing NVME management interface instead of duplicating it here. Otherwise it could be a burden for mgmt to learn. E.g vendor A may use "remote_url" but vendor B may use a different attribute.



NOTE: vendors are free to add attributes in this part with a
restriction that this attribute is able to be configured with the same
name in sysfs too. e.g.


Sysfs works well for common attributes belongs to a class, but I'm not sure it can work well for device/vendor specific attributes. Does this mean mgmt need to iterate all the attributes in both src and dst?


for aggregator, there must be a sysfs attribute in device node
/sys/devices/pci0000:00/0000:00:02.0/882cc4da-dede-11e7-9180-078a62063ab1/intel_vgpu/aggregator,
so that the userspace tool is able to configure the target device
according to source device's aggregator attribute.


(2) where and structure
proposal 1:
|- [path to device]
   |--- migration
   |     |--- self
   |     |    |-software_version
   |     |    |-device_api
   |     |    |-type
   |     |    |-[pci_id or subchannel_type]
   |     |    |-<aggregator or chpid_type>
   |     |--- compatible
   |     |    |-software_version
   |     |    |-device_api
   |     |    |-type
   |     |    |-[pci_id or subchannel_type]
   |     |    |-<aggregator or chpid_type>
multiple compatible is allowed.
attributes should be ASCII text files, preferably with only one value
per file.


proposal 2: use bin_attribute.
|- [path to device]
   |--- migration
   |     |--- self
   |     |--- compatible

so we can continue use multiline format. e.g.
cat compatible
   software_version=0.1.0
   device_api=vfio_pci
   type=i915-GVTg_V5_{val1:int:1,2,4,8}
   pci_id=80865963
   aggregator={val1}/2


So basically two questions:

- how hard to standardize sysfs API for dealing with compatibility check (to make it work for most types of devices) - how hard for the mgmt to learn with a vendor specific attributes (vs existing management API)

Thanks



Thanks
Yan




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux