On Mon, Nov 11, 2019 at 04:42:52PM +0100, Jan Kiszka wrote: > 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
I agree it needs a separate ID not from the regular range. It's a distinct transport. Maybe even a distinct vendor ID - we could easily get another one if needed. > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux