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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Thursday, July 6, 2023 3:59 PM

> > Hardwaring BAR0 is in BAR area of the VF.
> > But virtio pci capabilities without this can still report bar 0 and virtio
> capabilities.
> 
> How do they do this?
>
 Device must not do it, but a broken device can report pci capabilities as garbage.
I will skip writing about it.

> > 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.
> 
> If you really want to go ahead, but prefix it with "In consequence" and do not
> start a new paragraph, so reader knows it's not an extra requirement.
> 
> So I started writing it using correct grammar and spec terminology:
> 
> 	In consequence, non of the group member devices has BAR0, and
> 	in particular none of the virtio structure capabilities
> 	of a member device has \field{bar} with the value of 0.
> 
> 
> However, this actually is kind of wrong (and so is your text).  Not all caps have a
> RO bar value.  virtio_pci_cfg_cap has bar that is RW by driver.  So if we are going
> this route we also need to explain that it's true for all caps except
> virtio_pci_cfg_cap.  And for virtio_pci_cfg_cap driver is not allowed to write 0
> there.
> 
> Frankly too much trouble but if you want to, keep trying.

What I wrote still holds true because device wont have BAR0 and driver writing there is ignored.
But it is some weird broken device who expose PCI capabilities, so I am going to skip writing this.