Re: [PATCH v1 0/4] virtio-msg transport layer

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Feb 25, 2026 at 03:36:36PM +0530, Manivannan Sadhasivam wrote:
> > > But that being said, I somewhat agree with Parav that we should define the bus
> > > implementations in the spec to avoid fixing the ABI in the implementations. For
> > > instance, if we try to use this transport over PCI, we've got questions like:
> > >
> > > 1. How the device should be bind to the virtio-msg-pci bus driver and not with
> > > the existing virtio-pci driver? Should it use a new Vendor ID or Sub-IDs?
> > 
> > One bus is appearing as one pci device with its own Vendor ID,
> > 
> 
> What should be the 'own Vendor ID' here?
> 
> The existing virtio-pci driver binds to all devices with the Vendor ID of
> PCI_VENDOR_ID_REDHAT_QUMRANET. So are you expecting the Vendors to use their own
> VID for exposing the Virtio devices? That would mean, the drivers on the host
> need update as well, which will not scale.
> 
> It would be good if the existing virtio-pci devices can use this new transport
> with only device side modifications.

ah maybe i misuderstand. you do not mean do not change drivers.
you mean a generic driver for everyone?

there are several ways to address this in pci
- use a shared vendor/device id: worked so far reasonably well for virtio.
  we can allocate a new range of device ids or a new vendor id.

- class / prog ifc
  it seems like a cleaner solution but will preclude declaring e.g.
  a virtio net interface as a network interface.



-- 
MST