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

Resend, because it isn’t listed in the mailing list due to my mistake.

> On Mon, Jun 16, 2025 at 4:38 PM Stefano Garzarella <[email protected]> wrote:
> >
> > On Mon, 16 Jun 2025 at 10:29, Xuewei Niu <[email protected]> wrote:
> > >
> > > > On Fri, Jun 13, 2025 at 4:46 PM Xuewei Niu <[email protected]> wrote:
> > > > >
> > > > > > On Fri, 13 Jun 2025 at 06:57, Xuewei Niu <[email protected]> wrote:
> > > > > > >
> > > > > > > > On Sat, Apr 12, 2025 at 10:39 PM Xuewei Niu <[email protected]> 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. Currently, the virtio-vsock only supports one device, resulting
> > > > > > > > > in the inability to enable more than one backend.
> > > > > > > >
> > > > > > > > I wonder which part of the spec forbids more than one device.
> > > > > > >
> > > > > > > No. The spec, however, is designed for a single device, and lacks some
> > > > > > > specifications for multiple devices.
> > > > > > >
> > > > > > > For example, we should have a mechanism to select a device from all to
> > > > > > > communicate with a peer.
> > > >
> > > > I wonder if this is a:
> > > >
> > > > 1) mechanism that needs to be mandated by the device
> > >
> > > Yes.
> > >
> > > > 2) a policy that is allowed to be tweaked by the user as TCP/IP did
> > >
> > > Not allowed in the current version.
> > >
> > > > (Note anyhow the driver can override what the device suggests...)
> >
> > I think we should follow what we described in the spec:
> > "The virtio socket device is a zero-configuration socket communications device."
>
> We probably need to define "configuration" first.
>
> For example, if it means zero configuration from the user, it does not
> conflict with 2), the driver can use its own algorithm to elect a
> "default" device.

IMHO, it can be done, but it is not the current design.

I prefer to set the default device for VM-HV communication to do some init
work. I don't think people have a strong need for this.

> Another perspective, making decisions in guests may be even more
> helpful for the case where the device is not trusted

How does the guest realize the vsock device is not trusted? The guest only
knows the information from its config space, which is provided by the host.

> > So, IMO the guest (driver) should not be allowed to change anything.
> > E.g. Right now it's not allowed to change the CID assigned by the host (device).
>
> A dumb question when having two cids (cid1 and cid2) in the same
> guest, what happens if src=cid1 and dst=cid2?

The packets will be directed to another application, if any, on the same guest.

Thanks,
Xuewei

> > Thanks,
> > Stefano
> >
>
> Thanks