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

Michael S. Tsirkin
2026-02-25T10:22:41Z

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