Re: [RFC][PATCH 2/3] docs/specs: Add specification of ivshmem device revision 2

[Jan Kiszka]

On 12.11.19 09:04, Michael S. Tsirkin wrote:
> On Mon, Nov 11, 2019 at 05:38:29PM +0100, Jan Kiszka wrote:
> > On 11.11.19 17:11, Michael S. Tsirkin wrote:
> > > On Mon, Nov 11, 2019 at 03:27:43PM +0000, Daniel P. Berrangé wrote:
> > > > On Mon, Nov 11, 2019 at 10:08:20AM -0500, Michael S. Tsirkin wrote:
> > > > > On Mon, Nov 11, 2019 at 02:59:07PM +0100, Jan Kiszka wrote:
> > > > > > On 11.11.19 14:45, Michael S. Tsirkin wrote:
> > > > > > > On Mon, Nov 11, 2019 at 01:57:11PM +0100, Jan Kiszka wrote:
> > > > > > > > +| Offset | Register               | Content                                    
> > > > > > > >           |
> > > > > > > > +|-------:|:-----------------------|:-----------------------------------------------------|
> > > > > > > > +|    00h | Vendor ID              | 1AF4h                                      
> > > > > > > >           |
> > > > > > > > +|    02h | Device ID              | 1110h                                      
> > > > > > > >           |
> > > > > > >
> > > > > > > Given it's a virtio vendor ID, please reserve a device ID
> > > > > > > with the virtio TC.
> > > > > >
> > > > > > Yeah, QEMU's IVSHMEM was always using that. I'm happy to make this finally
> > > > > > official.
> > > > >
> > > > > And I guess we will just mark it reserved or something right?
> > > > > Since at least IVSHMEM 1 isn't a virtio device.
> > > > > And will you be reusing same ID for IVSHMEM 2 or a new one?
> > > >
> > > > 1110h isn't under either of the virtio PCI device ID allowed ranges
> > > > according to the spec:
> > > >
> > > >     "Any PCI device with PCI Vendor ID 0x1AF4, and PCI Device
> > > >      ID 0x1000 through 0x107F inclusive is a virtio device.
> > > >      ...
> > > >      Additionally, devices MAY utilize a Transitional PCI Device
> > > >      ID range, 0x1000 to 0x103F depending on the device type. "
> > > >
> > > > So there's no need to reserve 0x1110h from the virtio spec POV.
> > >
> > > Well we do have:
> > >
> > >         B.3
> > >         What Device Number?
> > >         Device numbers can be reserved by the OASIS committee: email 
> > > address@hidden to secure
> > >         a unique one.
> > >         Meanwhile for experimental drivers, use 65535 and work backwards.
> > >
> > > So it seems it can  in theory conflict at least with experimental virtio 
> > > devices.
> > >
> > > Really it's messy that people are reusing the virtio vendor ID for
> > > random stuff - getting a vendor ID is only hard for a hobbyist, any big
> > > company already has an ID - but if it is a hobbyist and they at least
> > > register then doesn't cause much harm.
> >
> > Note that ivshmem came from a research environment. I do know if there was a
> > check for the IDs at the point the code was merged.
> >
> > That said, I may get a device ID here as well, provided I can explain that
> > not a single "product" will own it, but rather an open specification.
> >
> > Jan
>
> OK, up to you - if you decide you want an ID reserved, pls let us know.

Turned out to be much simpler than expect:

I reserved device ID 4106h under the vendor ID 110Ah (Siemens AG) for 
the purpose of specifying a shared memory device via the VIRTIO TC. Will 
update this "detail" in the next revision of the patches, also resetting 
the device revision ID to 0 as no longer need to tell us apart from the 
current implementation this way.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux