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

On Tue, Jun 17, 2025 at 10:52 AM Jason Wang <[email protected]> wrote:
>
> 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.

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

>
> >
> > 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?
>
> >
> > Thanks,
> > Stefano
> >
>
> Thanks

Thanks