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

On Wed, Jun 18, 2025 at 10:47 AM Xuewei Niu <[email protected]> wrote:
>
> > On Tue, Jun 17, 2025 at 3:46 PM Xuewei Niu <[email protected]> wrote:
> > >
> > > 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.
> >
> > Well, you need at least explain the advantages or why you choose to do this.
>
> I listed in the previous message. Maybe it is not clear enough. I'll try to
> explain it again.
>
> I think people should pick up the device by a `bind()` call, which takes a
> CID as an argument.
>
> Generally, the device is picked up by the source CID, which is achieved
> through a `bind()` call.
>
> The default device, which is equivalent to the current single device, is
> used to be compatible with the existing applications.
>
> Apart from that, the default device is used to communicate with hypervisor
> for some init works, such as gathering information about other vsock
> devices.
>
> To summarize, users must do `bind()` call explicitly to select the desired
> device for non-HV-VM communications.

So if I understand correctly you need a way to select the default when
bind() is not called?

>
> > > 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?
> >
> > There're various ways to build trust (for example device attestation)
> > and more might come in the future.
> >
> > > The guest only
> > > knows the information from its config space, which is provided by the host.
> >
> > The way to build trust is probably beyond the scope of virtio, but it
> > is something we need to consider.
>
> Agree with you. If it comes in the future, I think the driver should have
> the ability to make decisions.


Actually, I meant the way to build trust via virtio is something that
needs to be considered. But now we have other ways to build trust.
That would result a situlation:

1) "default" vsock device is not trusted but other might

or

2) two device claims that they are all "default"

This means anyhow we need a decision from the driver side so the
device side order seems to be useless here.

>
> > > > > 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.
> >
> > Ok, so in your example, vhost-user-vsock should route those packets
> > back to kernel vsock?
>
> It depends. Two cases are possible:
>
> 1. dev0(cid1) and dev1(cid2) are from the same type of backend, e.g.
> vhost-vsock, so the packets will be routed back as you described.
> 2. dev0(cid1) from vhost-user-vsock, and dev1(cid2) from vhost-vsock, the
> packets will be dropped if vhost-user-vsock device can't find a device
> whose cid is cid2.

Well, this means the behavior depends on the implementation which is not good.

Thanks

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