> From: Michael S. Tsirkin <[email protected]>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
