On Thu, 12 Jan 2023 16:41:32 +0100, Halil Pasic <[email protected]> wrote:
> On Thu, 12 Jan 2023 15:30:58 +0100
> Cornelia Huck <[email protected]> wrote:
>
> > >>
> > >> I like that: we don't want to talk about hosts/VMMs/etc. as we
> > >> fundamentally deal with devices and drivers, but sharing between guests
> > >> is of course the obvious use case.
> > >>
> > >> I'm just wondering how best to express the uniqueness scope, is it per
> > >> (ISM) device?
> > >
> > > No, each vm has at least one separate device. The devices in a host form
> > > an uniqueness scope.
> >
> > Should we call it a 'group', then? A host would be an example of such a
> > group.
>
> How about 'communication domain'? Devices within a single communication
> domain may be able to speak to each other via SMC and may not have the
> same device_id. Two devices from different communication domains can't
> communicate via ISM, but may have the same device_id.

I agree.

>
> I don't like group because it is very generic, and may sound like
> the grouping can be done arbitrarily. E.g. with a shared memory based
> implementation akin to the PoC putting devices on different hosts into
> the same 'group' should be illegal.
>
> On the other hand there is also the following question. If we move away
> form the one ID per host model ("The device MUST ensure that the gid on
> the same entity i same and different from the gid on other entity.") then
> we could also allow having more than one communication domains on a
> single host (to limit what entities can use ISM to communicate).

Yes, this is a good idea.

Thanks.

>
> Regards,
> Halil
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to