OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] [PATCH 1/1] Allow "Vendor Specific" extension to virtio PCI capabilities.


On Fri, May 18, 2018 at 04:43:36PM -0500, Venu Busireddy wrote:
> On 2018-05-18 17:06:23 +0100, Stefan Hajnoczi wrote:
> > On Thu, May 17, 2018 at 09:06:04AM -0400, Venu Busireddy wrote:
> > 
> > Can you describe a use case where vendor-specific extensions make sense
> > as opposed to extending the VIRTIO specification?
> 
> Sometimes, qemu may need to group certain devices together. In our
> problem scenario, qemu needed to tell the driver which virtio device is a
> fallback device for a given vfio-pci device. If the virtio device's PCI
> capabilities are extended, the new capability could be used to store a
> unique ID (say, the bus:device:function) that identifies the vfio-pci
> device. The driver can use that information when needed to pair the
> virtio device with the vfio-pci device.

This feature seems generic and could be in the VIRTIO spec proper.  What
is vendor-specific about it?

> Extending the VIRTIO specification is also a good alternative, but
> every time the vendor needs something new, the specification needs to
> be changed again. A generic "vendor specific" mechanism alleviates that.

If you plan to push Linux code changes upstream to implement this
feature then a vendor-specific extension is inappropriate and you should
extend the VIRTIO spec.

Stefan

Attachment: signature.asc
Description: PGP signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]