[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [ovirt-devel] Re: device compatibility interface for live migration with assigned devices
- From: Cornelia Huck <cohuck redhat com>
- To: Jason Wang <jasowang redhat com>
- Cc: "kvm vger kernel org" <kvm vger kernel org>, "libvir-list redhat com" <libvir-list redhat com>, "qemu-devel nongnu org" <qemu-devel nongnu org>, Kirti Wankhede <kwankhede nvidia com>, "eauger redhat com" <eauger redhat com>, "xin-ran wang intel com" <xin-ran wang intel com>, "corbet lwn net" <corbet lwn net>, Jiri, "openstack-discuss lists openstack org" <openstack-discuss lists openstack org>, "shaohe feng intel com" <shaohe feng intel com>, "kevin tian intel com" <kevin tian intel com>, Yan Zhao <yan y zhao intel com>, Parav Pandit <parav mellanox com>, "jian-feng ding intel com" <jian-feng ding intel com>, "dgilbert redhat com" <dgilbert redhat com>, "zhenyuw linux intel com" <zhenyuw linux intel com>, "hejie xu intel com" <hejie xu intel com>, "bao yumeng zte com cn" <bao yumeng zte com cn>, Parav Pandit <parav nvidia com>, "sm ooney redhat com" <smooney redhat com>, "intel-gvt-dev lists freedesktop org" <intel-gvt-dev lists freedesktop org>, Alex, "eskultet redhat com" <eskultet redhat com>, Pirko <jiri mellanox com>, "dinechin redhat com" <dinechin redhat com>, "devel ovirt org" <devel ovirt org>
- Subject: Re: [ovirt-devel] Re: device compatibility interface for live migration with assigned devices
- Date: Thu, 20 Aug 2020 14:27:40 +0200
On Wed, 19 Aug 2020 17:28:38 +0800
Jason Wang <jasowang redhat com> wrote:
> On 2020/8/19 下午4:13, Yan Zhao wrote:
> > On Wed, Aug 19, 2020 at 03:39:50PM +0800, Jason Wang wrote:
> >> On 2020/8/19 下午2:59, Yan Zhao wrote:
> >>> On Wed, Aug 19, 2020 at 02:57:34PM +0800, Jason Wang wrote:
> >>>> 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)
I thought the 'software_version' was supposed to describe kind of a
'protocol version' for the data we transmit? I.e., you add a new field,
you bump the version number.
> >>> sorry, I don't understand here, why virtio devices need to use vfio interface?
> >> I don't see any reason that virtio devices can't be used by VFIO. Do you?
> >> Actually, virtio devices have been used by VFIO for many years:
> >> - passthrough a hardware virtio devices to userspace(VM) drivers
> >> - using virtio PMD inside guest
> > So, what's different for it vs passing through a physical hardware via VFIO?
> The difference is in the guest, the device could be either real hardware
> or emulated ones.
> > even though the features are negotiated dynamically, could you explain
> > why it would cause software_version not work?
> Virtio device 1 supports feature A, B, C
> Virtio device 2 supports feature B, C, D
> So you can't migrate a guest from device 1 to device 2. And it's
> impossible to model the features with versions.
We're talking about the features offered by the device, right? Would it
be sufficient to mandate that the target device supports the same
features or a superset of the features supported by the source device?
> >>> I think this thread is discussing about vfio related 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.
> >>> for device_api of vfio-pci, why it's not true?
> >>> for vfio-ccw, it's subchannel_type.
> >> Ok but having two different attributes for the same file is not good idea.
> >> How mgmt know there will be a 3rd type?
> > that's why some attributes need to be common. e.g.
> > device_api: it's common because mgmt need to know it's a pci device or a
> > ccw device. and the api type is already defined vfio.h.
> > (The field is agreed by and actually suggested by Alex in previous mail)
> > type: mdev_type for mdev. if mgmt does not understand it, it would not
> > be able to create one compatible mdev device.
> > software_version: mgmt can compare the major and minor if it understands
> > this fields.
> I think it would be helpful if you can describe how mgmt is expected to
> work step by step with the proposed sysfs API. This can help people to
My proposal would be:
- check that device_api matches
- check possible device_api specific attributes
- check that type matches [I don't think the combination of mdev types
and another attribute to determine compatibility is a good idea;
actually, the current proposal confuses me every time I look at it]
- check that software_version is compatible, assuming semantic
- check possible type-specific attributes
> Thanks for the patience. Since sysfs is uABI, when accepted, we need
> support it forever. That's why we need to be careful.
[Date Prev][Date Next] [Thread Prev][Thread Next]