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

> On Thu, Jun 19, 2025 at 01:10:33PM +0800, Xuewei Niu wrote:
> >> > From: Xuewei Niu <[email protected]>
> >> > Sent: 19 June 2025 08:57 AM
> >> >
> >> > Hi Parav,
> >> >
> >> > Could you please take a look at the diagram in [1]?
> >> >
> >> > IIUC, for VM0, there are two groups, and for VM1, there is only one group.
> >> > Am I right? If yes, I think the group concept is reasonable but we don't need
> >> > at this time.
> >> >
> >> > I think the first thing is to figure out how to pick the right group.
> >> >
> >> > Standard socket doesn't provide a way to access the group information.
> >> >
> >> > Source and destination are from `bind()` and `connect()`, respectively. If we
> >> > don't call `bind()`, only the destination is known.
> >> >
> >> > However, only destination is not enough to find the group. For example, the
> >> > well-known CIDs (e.g. 2) are valid for all groups.
> >> >
> >> > 1:
> >> > https://lore.kernel.org/virtio-comment/[email protected]/
> >>
> >> Right. Sock addressing scheme is naïve presently to select the group. 
> >> Not sure when/how you or others plan to do.
> >> This is transport layer problem to solve (not to confuse with transport = pci/mmio etc).
> 
> 
> >>
> >> However, at device level, we should have the construct of grouping.
> >> Without this construct, all devices will be part of single group and one will not be able to build the group concept later.
> >> So even if you don't need it explicitly now, grouping the device is what you need when connect() is called.
> >>
> >> So I was imagining a relatively simple scheme:
> >> For example, virtio device level, some kind of group id is present.
> >> So two devices which has same group id, are part of single group.
> >> An example group id format can be a UUID.
> >>
> >> And this is completely optional for devices to implement.
> >> Generic enough and usable beyond just vsock device in other use cases 
> >> we discussed in past.
> >
> >Fair enough.
> >
> >@Stefano, could you please take a look at this? I'd love to have some 
> >input
> >from you.
> >
> >A brief summary of the idea is: The config space will be extended to
> >include a group id. The devices with the same group id are considered 
> >to be
> >in the same group.
> 
> Thanks for the summary, but please avoid top posting, otherwise is very 
> hard to follow the discussion :-(
> https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying

Sorry, I'll avoid it in the future.

> I like the idea of groups. What is not clear to me, is how groups will 
> allow the driver to select the default output device when the source 
> socket is not bind to any source CID.

Well, we did discuss, but we need your input.

I said in the thread [1] based on the standard socket API, the driver can't
pick a group. Parav [2] suggested that the group, as a basic concept,
should be present even if we are unable to use it.

IMHO, we might use "{group_id}-{cid}" as the vsock addressing scheme to use
the concept. But it is a very big change, leading to incompatibility with
the existing apps.

I think it might be beyond the scope of this patch, and would make the
vsock more complex. The current conclusion is that we will keep the concept
of grouping as a placeholder, but we will not use it.

1: https://lore.kernel.org/virtio-comment/[email protected]/T/#mcfa6ca71da3147930e3d4edcf3c1ef097f808d4d
2: https://lore.kernel.org/virtio-comment/[email protected]/T/#m3e97c051721f053da4d15e0c531c6f6c8ff38f60

> But if it's already discussed, 
> please go head and I'll check the next version.
> 
> Just a note, AF_VSOCK is suppose to be very similar to AF_UNIX. It's a 
> point ot point connection, we don't have any transport layer like TCP.
> What we call "transport" in AF_VSOCK world, is usually the driver/device 
> usend to send data (e.g. vmci, virtio, vhost, hyperv).

Thanks for the clarification, sometimes I am lost in the many "transports".

Thanks,
Xuewei

> Thanks,
> Stefano