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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, June 8, 2023 3:04 PM

> > Moving now to admin will surely have more back-n-forth as it needs to talk
> about PCI part and that PCI part will reside in PCI section.
> 
> well the point is that it's *back" not *forth*.
> IOW add the command description in admin chapter, make it point to legacy
> description in pci chapter which reader has already read.
> 
There is no back-n forth today. Reader interested only reads the pci chapter.
Only to know the opcode value in a common table it reads the admin chapter.

Putting command descriptions in the "basic facilities" without referring to transport will create back-n-forth, where reader needs to go to PCI chapter to understand the motivation.
Come and to basic facilities and implement it.

When there are too many things common across all transports and very little changing across transport, placement in common place results in better reading.
I find the opposite here.

> > > > > 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.
> > >
> > Yes good one. Will use.
> 
> right and my point is try to word all of it like this.
Yes, as owner and group.