Re: [virtio-dev] Re: [PATCH v9 02/10] admin: introduce device group and related concepts

[Cornelia Huck <cohuck@redhat.com>]

On Thu, Nov 24 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Thu, Nov 24, 2022 at 03:37:42PM +0800, Jason Wang wrote:
>> On Thu, Nov 24, 2022 at 3:08 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>> >
>> > On Thu, Nov 24, 2022 at 01:41:41PM +0800, Jason Wang wrote:
>> > > On Thu, Nov 24, 2022 at 5:08 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>> > > > +The following group types, and their identifiers, are currently specified):
>> > > > +\begin{description}
>> > > > +\item[SR-IOV group type (0x1)]
>> > > > +This device group has a PCI Single Root I/O Virtualization
>> > > > +(SR-IOV) physical function (PF) device as the owner and includes
>> > > > +all its SR-IOV virtual functions (VFs) as members (see
>> > > > +\hyperref[intro:PCIe]{[PCIe]}).
>> > >
>> > > So I wonder what's the advantage of using a global identifier over the
>> > > transport specific one. There's almost no way for CCW/MMIO to use
>> > > SR-IOV. Limiting it to PCI seems much easier and avoids layer
>> > > violation.
>> > >
>> > > Thanks
>> >
>> > So we burn up an identifier, ccw and mmio won't be able to use it.
>> > Big deal? Why?
>> 
>> Because it is transport specific. The basic facility should be
>> transport independent.
>
> I tried this but the result is spread all over the spec
> and does not result in a readable cohesive whole.
> So we give up on the transport independent purity a bit and it
> seems worth it.
> Also explained this in the cover letter - have you seen that?
>
>
>
>> > And I think we might find a use for this with MMIO
>> > down the road with some kind of passthrough. Who knows.
>> 
>> Probably, but can it be modeled exactly as what SR-IOV looks like? Or
>> anyhow, it's not too late to define this for MMIO at that time. For
>> example, we know MSI-X may work for MMIO but we define it only for PCI
>> now.
>> 
>> Thanks
>
> Right. So if we reserve the id for all transports then it will
> be easy to do.

Also, if we go with transport-specific ids, we might end up with
different ids per transport when we add a future transport-independent
feature. The global id space really should be big enough to accommodate
even single-transport groups.