Re: [virtio-comment] RE: [PATCH v6 4/4] transport-pci: Introduce group legacy group member config region access

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 21, 2023 at 08:04:22PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Wednesday, June 21, 2023 3:43 PM
> > 
> > On Wed, Jun 21, 2023 at 04:01:00PM +0000, Parav Pandit wrote:
> > >
> > >
> > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > Sent: Wednesday, June 21, 2023 11:56 AM
> > >
> > > > Not like v3 please. If you want to re-open this:
> > > >
> > > >
> > > > First I think we need multiple offsets just like notification
> > > > capaiblity, sorted by priority. Second I think we need ability to
> > > > report offset within owner not member.
> > > >
> > > > So please add ability to report multiple offsets, and add e.g.
> > > > a flags field, with bits for owner, member.
> > >
> > > What are these multiple offsets for?
> > 
> > Different BARs.  For example, IO versus memory. Yes I know VFs don't support
> > IO but PFs do. prefetch vs non-prefetch might matter too (non-prefetch is
> > mostly limited to 32 bit).
> >
> BAR type and its prefetch attributes are told by the PCI anyway so no duplication here anyway.

yes they are! But for example, software PF device might prefer notification in IO
BAR if that can be mapped. If not - use MMIO.


> For owner and member I get it. 
> > 
> > > Do you mean two offsets? One for owner and one for member?
> > > Both bits are optional. Do you agree?
> > 
> > I agree that everything should be optional sure. Let's not limit it to two though.
> > There could be multiple BARs or whatever. We have ability to pass buffers of
> > arbitrary length and device reports the length.
> > Maybe have a SHOULD recommending not more than 10 of these (1 for each
> > possible PCI BAR one for each possible VF BAR).
> > 
> > This is to match the functionality that notification capability has.
> > 
> A device can expose multiple offsets within the single bar to a count of 100 entries;
> Also allowed in the notification capability.
> (I don't see why any sane device would do that anyway)

Me neither.

> So I will avoid such extra restrictions and limit the scope of this patch to be minimal to have arbitrary number of BAR entries limited by the command result length.

That sounds OK.

> > 
> > 
> > > This publicly archived list offers a means to provide input to the
> > > OASIS Virtual I/O Device (VIRTIO) TC.
> > >
> > > In order to verify user consent to the Feedback License terms and to
> > > minimize spam in the list archive, subscription is required before
> > > posting.
> > >
> > > Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> > > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> > > List help: virtio-comment-help@lists.oasis-open.org
> > > List archive: https://lists.oasis-open.org/archives/virtio-comment/
> > > Feedback License:
> > > https://www.oasis-open.org/who/ipr/feedback_license.pdf
> > > List Guidelines:
> > > https://www.oasis-open.org/policies-guidelines/mailing-lists
> > > Committee: https://www.oasis-open.org/committees/virtio/
> > > Join OASIS: https://www.oasis-open.org/join/