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

[Jan Kiszka]

On 11.11.19 16:27, 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.

Indeed.

> I have, however, ensured it is assigned to ivshmem from POV of
> Red Hat's own internal tracking of allocated device IDs, under
> its vendor ID.
>
> If ivshmem 2 is now a virtio device, then it is a good thing that
> it will get a new/different PCI device ID, to show that it is not
> compatible with the old device impl.

At this stage, it is just a PCI device that may be used in combination 
with virtio (stacked on top), but it is not designed like a normal 
virtio (PCI) device. That's because it lacks many properties of regular 
virtio devices, like queues.

So, if such a device could be come part of the virtio spec, it would be 
separate from the rest, and having an ID from the regular range would 
likely not be helpful in this regard.

Jan

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