RE: [PATCH v7] virtio-vsock: Add support for multi devices

> From: Xuewei Niu <[email protected]>
> Sent: Monday, June 16, 2025 1:48 PM
> 
> Hi, Parav.
> 
> Thanks for your detailed comments.
> 
> > Hi Xuewei,
> >
> > > From: Xuewei Niu <[email protected]>
> > > Sent: Monday, May 19, 2025 3:08 PM
> > >
> > > > On Sat, Apr 12, 2025 at 10:28:25PM +0800, Xuewei Niu wrote:
> > > > > This patch brings a new feature, called "multi devices", to the
> > > > > virtio vsock. It introduces a "VIRTIO_VSOCK_F_MULTI_DEVICES"
> > > > > feature bit, and a "device_order" field to the config for the virtio vsock.
> > > > >
> > > > > == Motivition ==
> > > > >
> > > > > Vsock is a lightweight and widely used data exchange mechanism
> > > > > between host and guest.
> >
> > Even though it is the current use, the specification does not prevent its usage
> between two guests via a host.
> > So we should not assume such guest <-> host communication as the only
> case to add new feature.
> >
> > For example, in the spec only must requirement is that src_cid ==
> config.guest_cid.
> > Dst_cid can be anything, it need not be well known 0x2 (for the host).
> 
> Yes.
> 
> > With this flexibility in the spec, one can connect vsock devices with multiple
> different backends.
> >
> > For example,
> > QEMU can insert one vsock device for VM to HV communication.
> 
> It is also able to communicate with other devices on the same host, i.e.
> VM-to-VM.
> 
> > A real PCI device can insert one voscket device for VM-to-VM
> communication bypassing a full TCP/IP stack.
> 
> AFAIK, all devices are implemented in software. Is it a real PCI HW device?
> 
Yes. virto PCI devices are implemented as hw or as vdpa for many years now by cloud operators and by NIC vendors.

> > This means there are two different backends.
> > And these two devices should not be grouped in the use case you described.
> 
> I think one group is enough for all use cases. It is required that CIDs are unique
> in global, i.e. all backends.
> 
> As your example, let me assume there are two VMs
> 
> 1. VM0 (two vsock backends)
>     1.1 device0 (cid=3, default), backend is host kernel (vhost-vsock);
>     1.2 device1 (cid=4), backend is HV (virtio-vsock).
> 2. VM1
>     2.1 device2 (cid=5, default), backend is host kernel (vhost-vsock).
> 
> The device0 is able to do VM0-HOST (src_cid=3, dst_cid=2) and VM0-VM1
> (src_cid=3, dst_cid=5) communicatation, while the device1 is only able to do
> VM0-HV (src_cid=4, dst_cid=2) communicatation.
> 
In example 1.1 and 1.2 no devices are grouped.
Your proposal of this patch wants to group the two devices and pick one of them as default device.
If device0 and device1 are inserted to the VM0 with the feature bit you suggested, the guest things that they are part of the same group.

When bind() call is not done, host sw does not know which device to pick up between device0 and device1 when binding the devices.


> In a word, a tuple identifies a connection.
> 
> "Refuse to connect" will be raised if the device1 attempts to connect to the
> device2. "They are not in the same group" is a reasonable explaination.
> Am I right?
> 
During bind call, one needs to select the device when the devices are coming from multiple different backends.

[..]