OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Michael S. Tsirkin
> Sent: Thursday, July 6, 2023 3:01 PM

> > +\begin{lstlisting}
> > +struct virtio_pci_legacy_notify_region {
> > +        u8 owner;  /* When set to 1, notification region is of the
> > +owner device */
> 
> I propose we rename this to flags:
> 	0x0 - end of list (driver should ignore following values until end of list)
> 	0x1 - owner
> 	0x2 - member
> other values - reserved
>

> and prescribe that driver ignores any reserved values.
> 
> basically we are following how the virtio capabilities work.
>
Looks good. Will change it.

> > +The group owner device hardwires VF BAR0 to zero in the SR-IOV
> > +Extended capability.
> > +
> > +The group member device does not use PCI BAR0 in all the Virtio PCI
> > +capabilities listed in section \ref{sec:Virtio Transport Options / Virtio Over
> PCI Bus / Virtio Structure PCI Capabilities}.
> 
> Just drop this last one. How can they use it if there's no VF BAR0?
>
Hardwaring BAR0 is in BAR area of the VF.
But virtio pci capabilities without this can still report bar 0 and virtio capabilities.
Ofcourse, it is a broken device.
But skipping this line imply that "because VF BAR0 is hardwired", this metadata in pci capability must not expose it.

Why not write it extra thing instead of implying it?
We already wrote few duplicate things to make reader life easier.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]