[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [PATCH v9 02/10] admin: introduce device group and related concepts
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]