On Thu, 13 Aug 2020 15:02:53 -0400 Eric Farman <farman@linux.ibm.com> wrote:
On 8/13/20 11:33 AM, Cornelia Huck wrote:
On Fri, 7 Aug 2020 13:59:42 +0200 Cornelia Huck <cohuck@redhat.com> wrote:
On Wed, 05 Aug 2020 12:35:01 +0100 Sean Mooney <smooney@redhat.com> wrote:
On Wed, 2020-08-05 at 12:53 +0200, Jiri Pirko wrote:
Wed, Aug 05, 2020 at 11:33:38AM CEST, yan.y.zhao@intel.com wrote:
(...)
software_version: device driver's version. in <major>.<minor>[.bugfix] scheme, where there is no compatibility across major versions, minor versions have forward compatibility (ex. 1-> 2 is ok, 2 -> 1 is not) and bugfix version number indicates some degree of internal improvement that is not visible to the user in terms of features or compatibility,
vendor specific attributes: each vendor may define different attributes device id : device id of a physical devices or mdev's parent pci device. it could be equal to pci id for pci devices aggregator: used together with mdev_type. e.g. aggregator=2 together with i915-GVTg_V5_4 means 2*1/4=1/2 of a gen9 Intel graphics device. remote_url: for a local NVMe VF, it may be configured with a remote url of a remote storage and all data is stored in the remote side specified by the remote url. ... just a minor not that i find ^ much more simmple to understand then the current proposal with self and compatiable. if i have well defiend attibute that i can parse and understand that allow me to calulate the what is and is not compatible that is likely going to more useful as you wont have to keep maintianing a list of other compatible devices every time a new sku is released.
in anycase thank for actully shareing ^ as it make it simpler to reson about what you have previously proposed.
So, what would be the most helpful format? A 'software_version' field that follows the conventions outlined above, and other (possibly optional) fields that have to match?
Just to get a different perspective, I've been trying to come up with what would be useful for a very different kind of device, namely vfio-ccw. (Adding Eric to cc: for that.)
software_version makes sense for everybody, so it should be a standard attribute.
For the vfio-ccw type, we have only one vendor driver (vfio-ccw_IO).
Given a subchannel A, we want to make sure that subchannel B has a reasonable chance of being compatible. I guess that means:
- same subchannel type (I/O) - same chpid type (e.g. all FICON; I assume there are no 'mixed' setups -- Eric?)
Correct.
- same number of chpids? Maybe we can live without that and just inject some machine checks, I don't know. Same chpid numbers is something we cannot guarantee, especially if we want to migrate cross-CEC (to another machine.)
I think we'd live without it, because I wouldn't expect it to be consistent between systems.
Yes, and the guest needs to be able to deal with changing path configurations anyway.
Other possibly interesting information is not available at the subchannel level (vfio-ccw is a subchannel driver.)
I presume you're alluding to the DASD uid (dasdinfo -x) here?
Yes, or the even more basic Sense ID information.
So, looking at a concrete subchannel on one of my machines, it would look something like the following:
<common> software_version=1.0.0 type=vfio-ccw <-- would be vfio-pci on the example above <vfio-ccw specific> subchannel_type=0 <vfio-ccw_IO specific> chpid_type=0x1a chpid_mask=0xf0 <-- not sure if needed/wanted
Let's just drop the chpid_mask here.
Does that make sense?
Would be interesting if someone could come up with some possible information for a third type of device.