Re: [PATCH v3 2/3] transport-pci: Introduce legacy registers access commands

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

On Sun, Jun 04, 2023 at 01:51:20PM +0000, Parav Pandit wrote:
> 
> > From: Michael S. Tsirkin <mst@redhat.com>
> > Sent: Sunday, June 4, 2023 9:22 AM
> 
> > > +The driver that may use the driver notifications region of the VF
> > > +device returned in this result likely attain higher performance or
> > > +the drier may use the VIRTIO_ADMIN_CMD_LREG_WRITE command.
> > 
> > Obtain I guess ... but how? There's no explanation.
> >
> Do you suggest to rewrite, above as below?
> 
> The driver that MAY use the driver notifications region of the VF likely obtain higher performance.
> The driver may use VIRTIO_ADMIN_CMD_LCC_REG_WRITE command for doorbell notifications.

No this does not address the issue that there is no description of how
this command is used just a hint at what it returns. So this gets us
some offset into some bar now what?  I am guessing writing vqn at this
offset into bar has the same effect as issuing
VIRTIO_ADMIN_CMD_LCC_REG_WRITE with offset 16 and data including the
vqn?


BTW all these may/must/should need to go into conformance section.

Generally the way we structure the spec is an explanation of
the theory of operation (mostly missing here)


> > > +\begin{note}
> > > +The PCI VF device should not use PCI BAR 0 when it prefers to support
> > > +legacy interface registers access using its group owner PF. This
> > > +enables hypervisor software to operate with least complexities to
> > > +compose a legacy interface I/O space BAR and passthrough other PCI
> > > +BARs and PCI device capabilities to the guest virtual machine without any
> > translation.
> > > +\end{note}
> > 
> > Is this related to this last command somehow? what does it mean for PCI VF
> > device to use a BAR? not use a BAR? Prefer what to what?
> 
> This is no different than v2, not sure why to discuss this in v3.

v2 had other issues so I missed this one.

> But ok.
> 
> No. It is not related to last command.
> What does a PCI Device use BAR for?

To reserve address space and know which addresses to claim.

Generally if I heard "not use BAR0" I would assume that the
meaning is that VF BAR0 in SRIOV expended capability
should be 0. However, that affects all VFs and not just
this VF so I don't really know what can it mean.

> As described in the spec, it uses the BAR in struct virtio_pci_cap for exposing various things.

Now I'm confused.
So do you mean the \field{bar} in virtio_pci_cap or PCI BAR?

> So it means that PCI VF should use other than PCI BAR 0 for various Virtio Structure PCI Capabilities that it exposes.

I suspect you then want to say "should not expose to driver
any structures inside it's BAR0"?
And does this include this new command you are adding or not?
It mentions bar too.  What about e.g. MSIX tables? Could there be other
capabilities referring to a BAR? How does hypervisor know
whether VF followed this rule (it's a should, not a hard rule after all)?


-- 
MST