[virtio-comment] Re: [virtio-dev] Re: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ

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

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 thing that bothers me is that it references admin commands
that are defined later in the spec. I don't like it that we
are making the reader jump back and forth ...
Maybe it's better to put this in the admin command chapter.

> > 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.

So here's an example wording, I don't insist on it exactly but
the point is to show how we should use spec terminology whereever
possible:

If an owner of an SRIOV group supports all of VIRTIO_ADMIN_CMD_LCC_REG_WRITE,
VIRTIO_ADMIN_CMD_LCC_REG_READ .... then it SHOULD NOT
expose VF BAR0 (of non 0 size) as part of its SRIOV capability;
this is to facilitate emulating IO BAR0 for the legacy interface in software.



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/