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. 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|