3:18 a.m.
On Wed, Aug 19, 2020 at 11:50:21AM -0600, Alex Williamson wrote:
<...>
> > > > What I care about is that we have a *standard*
userspace API for
> > > > performing device compatibility checking / state migration, for use
by
> > > > QEMU/libvirt/ OpenStack, such that we can write code without
countless
> > > > vendor specific code paths.
> > > >
> > > > If there is vendor specific stuff on the side, that's fine as we
can
> > > > ignore that, but the core functionality for device compat /
migration
> > > > needs to be standardized.
> > >
> > > To summarize:
> > > - choose one of sysfs or devlink
> > > - have a common interface, with a standardized way to add
> > > vendor-specific attributes
> > > ?
> >
> > Please refer to my previous email which has more example and details.
> hi Parav,
> the example is based on a new vdpa tool running over netlink, not based
> on devlink, right?
> For vfio migration compatibility, we have to deal with both mdev and physical
> pci devices, I don't think it's a good idea to write a new tool for it,
given
> we are able to retrieve the same info from sysfs and there's already an
> mdevctl from Alex (https://github.com/mdevctl/mdevctl).
>
> 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)
> - 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)
As noted previously, the parent PCI ID should not matter for an mdev
device, if a vendor has a dependency on matching the parent device PCI
ID, that's a vendor specific restriction. An mdev device can also
expose a vfio-pci device API without the parent device being PCI. For
a physical PCI device, shouldn't the PCI ID be encompassed in the
signature? Thanks,
you are right. I need to put the PCI ID as a vendor specific field.
I didn't do that because I wanted all fields in vendor specific to be
configurable by management tools, so they can configure the target device
according to the value of a vendor specific field even they don't know
the meaning of the field.
But maybe they can just ignore the field when they can't find a matching
writable field to configure the target.
Thanks
Yan
> > - subchannel_type (device_api is vfio-ccw)
> >
> > vendor driver specific part: (optional)
> > - aggregator
> > - chpid_type
> > - remote_url
> >
> > 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.
> > 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
> >
> > Thanks
> > Yan
> >
>