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

On Wed, Feb 25, 2026 at 05:22:32AM -0500, Michael S. Tsirkin wrote:
> 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?
> 

I actually meant to say that any device that supports virtio-msg-pci transport
should just work without modifying the virtio-msg-pci driver on the host.

> 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.
> 

This sounds good to me.

- Mani

-- 
மணிவண்ணன் சதாசிவம்