Re: [virtio-dev] [PATCH 1/1] Allow "Vendor Specific" extension to virtio PCI capabilities.
On Tue, May 22, 2018 at 08:48:58AM -0500, Venu Busireddy wrote: > On 2018-05-22 11:03:37 +0100, Stefan Hajnoczi wrote: > > 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. > > I will redo the patch to extend the virtio specification. > > Since the new patch will be conceptually different, shall I create a > new thread, or should I post it as v2? Please post a new patch. Thanks! Stefan signature.asc Description: PGP signature
Re: [virtio-dev] [PATCH 1/1] Allow "Vendor Specific" extension to virtio PCI capabilities.
On 2018-05-22 11:03:37 +0100, Stefan Hajnoczi wrote: > 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. I will redo the patch to extend the virtio specification. Since the new patch will be conceptually different, shall I create a new thread, or should I post it as v2? Venu - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
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 signature.asc Description: PGP signature
Re: [virtio-dev] [PATCH 1/1] Allow "Vendor Specific" extension to virtio PCI capabilities.
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.
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.
> This proposal only supports the PCI transport, so do extensions only
> affect the PCI transport behavior or also other aspects of VIRTIO
> (device behavior, vring, etc)?
The proposal is only for PCI transport. It does not affect other
transports.
> > +\devicenormative{\paragraph}{Vendor Specific Extension capability}{Virtio
> > Transport Options / Virtio Over PCI Bus / PCI Device Layout / Vendor
> > Specific Extension capability}
> > +
> > +The device may or may not present the VIRTIO_PCI_CAP_VENDOR_EXT_CFG
> > capability.
>
> s/may or may not/MAY/
Will change that, along with any other suggestions, in v2.
> > +
> > +\drivernormative{\paragraph}{Vendor Specific Extension capability}{Virtio
> > Transport Options / Virtio Over PCI Bus / PCI Device Layout / Vendor
> > Specific Extension capability}
> > +
> > +The driver MUST NOT write to vendor_specific_data[] area or the BAR region.
>
> How does a driver identify vendor-specific extensions that it supports?
> No Vendor ID is included in the capability, just an opaque blob, so how
> are collisions avoided?
Sorry for not making this clear! Since the capability is vendor specific,
the driver also needs to have corresponding vendor specific changes. The
driver needs to look at the Subsystem ID and Subsystem Vendor ID of the
virtio device, and interpret the data associated with the new capability
only when the IDs match with the IDs built into the driver. Vendors are
free to implement their own versioning scheme into that data to maintain
backward/forward compatibility.
> How does a driver behave upon encountering an unknown vendor-specific
> extension?
Drivers should ignore the data associated with the new capability if
the Subsystem ID and Subsystem Vendor ID do not match with the IDs built
into the driver. And, the specification already mandates that the drivers
should ignore VIRTIO_PCI_CAP_VENDOR_EXT_CFG if they don't know about it.
Venu
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] [PATCH 1/1] Allow "Vendor Specific" extension to virtio PCI capabilities.
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?
This proposal only supports the PCI transport, so do extensions only
affect the PCI transport behavior or also other aspects of VIRTIO
(device behavior, vring, etc)?
> +\devicenormative{\paragraph}{Vendor Specific Extension capability}{Virtio
> Transport Options / Virtio Over PCI Bus / PCI Device Layout / Vendor Specific
> Extension capability}
> +
> +The device may or may not present the VIRTIO_PCI_CAP_VENDOR_EXT_CFG
> capability.
s/may or may not/MAY/
> +
> +\drivernormative{\paragraph}{Vendor Specific Extension capability}{Virtio
> Transport Options / Virtio Over PCI Bus / PCI Device Layout / Vendor Specific
> Extension capability}
> +
> +The driver MUST NOT write to vendor_specific_data[] area or the BAR region.
How does a driver identify vendor-specific extensions that it supports?
No Vendor ID is included in the capability, just an opaque blob, so how
are collisions avoided?
How does a driver behave upon encountering an unknown vendor-specific
extension?
signature.asc
Description: PGP signature
