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-dev] Re: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ


> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, June 8, 2023 2:03 PM
> 
> On Thu, Jun 08, 2023 at 03:16:02PM +0000, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Thursday, June 8, 2023 11:04 AM
> > >
> > > On Thu, Jun 08, 2023 at 02:53:28PM +0000, Parav Pandit wrote:
> > > > > From: Michael S. Tsirkin <mst@redhat.com>
> > > > > Sent: Thursday, June 8, 2023 10:44 AM
> > > > > > Since this ABI reflects what we agree on, I would want to
> > > > > > raise for vote in coming days to be part of 1.3 in few days as
> > > > > > we have more than 3
> > > > > weeks to sort out non-ABI language part.
> > > > >
> > > > > I think there's a bunch of work to tighten wording in v4, don't
> > > > > believe it is ready for vote yet.
> > > > 3rd patch has the conformance section.
> > > > Rest of the legacy interface semantics are just same as today.
> > > > We are not fixing the legacy interface itself, so not sure what to
> > > > tighten
> > > specifically.
> > >
> > > I'll do a proper review after the forum. Generally lots of small
> > > things. Went looking just to give you a couple of
> > > examples:
> > > 	  too many mentions of VFs and PFs.
> > > 	  text should talk about owner and member. Minimise
> > > 	  mention of VFs to make it easier to extend to
> > > 	  different group types.
> > >
> > True but most additions are in PCI transport chapter.
> > But will change to member and owner.
> >
> > > another example:
> > > 	+The PCI VF device SHOULD NOT expose PCI BAR 0 when it prefers to
> > > support
> > >
> > > VFs don't expose BARs at all. PF exposes VF BARs in SRIOV capability.
> > >
> > Yes, it is exposed by PF, the wording of "PCI VF device exposing" is not right.
> > I will reword it.
> 
> Note that this will then apply to all VFs of this PF, even those without legacy
> support. Still not sure why it's SHOULD not a MUST.
It applies to all the VFs, but it doesn't apply without legacy.
For example, if one wants to build a PCI VF device that doesn't want to support legacy, it can still be on BAR2 or BAR 4.
This is fine.

> So that driver actually checks, but it's ok to fail if the rule is not followed
> maybe? In that case add a driver normative statement too.

Yes.
I will add.

Change log and commit log already capture this, but in case you missed it,
v4 extended the struct virtio_pci_notify_cap with a boolean and removed the AQ notify query command as you suggested.


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