virtio — archive

[PATCH] content: add vendor specific cfg type

From: Cornelia Huck <[email protected]>
To: [email protected]
Date: Wed, 27 Nov 2019 14:43:00 -0000

On Wed, 27 Nov 2019 08:23:44 -0500 "Michael S. Tsirkin" <[email protected]> wrote: > On Wed, Nov 27, 2019 at 05:59:03AM -0500, Michael S. Tsirkin wrote: > > On Wed, Nov 27, 2019 at 08:59:56AM +0100, Cornelia Huck wrote: > > > On Mon, 25 Nov 2019 03:11:43 -0500 > > > "Michael S. Tsirkin" <[email protected]> wrote: > > > > > > > On Mon, Nov 25, 2019 at 08:45:52AM +0100, Jan Kiszka wrote: > > > > > On 28.10.19 11:55, Michael S. Tsirkin wrote: > > > > > > Vendors might want to add their own capability > > > > > > in the PCI capability list. However, Virtio already > > > > > > uses the vendor specific capability ID (0x09) > > > > > > for its own purposes. > > > > > > > > > > Did some vendor express that need, or do we only assume it so far? IOW: Do > > > > > we know at least once concrete use case? > > > > > > > > Good point, I should have added this in the log. > > > > > > > > I know of a device that implements virtio and has a bug. > > > > > > > > Device is a transitional one so can not have vendor specific > > > > subsystem IDs (that violates the SHOULD below. Do we want to qualify > > > > that this recommendation is for non-transitional devices?). While that > > > > > > What about adding some notes on top that vendor specific subsystem IDs > > > are not for transitional devices? That would also catch the case in the > > > other update. > > > So how about I just skip the following chunk when I commit? > > +The device SHOULD present the PCI subsystem vendor ID matching > +the device vendor, at offset 0x2C in its PCI configuration space > +header. > > that seems to belong to the other ballot that I have withdrawn. > > Minor enough that I don't feel we need to redo the whole ballot, > right?. > I think that's fine.