> From: Michael S. Tsirkin <[email protected]> > Sent: Thursday, June 8, 2023 2:03 PM > > On Thu, Jun 08, 2023 at 03:16:02PM +0000, Parav Pandit wrote: > > > > > From: Michael S. Tsirkin <[email protected]> > > > 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 <[email protected]> > > > > > 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 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. > > Note that this will then apply to all VFs of this PF, even those without > legacy > support. Still not sure why it's SHOULD not a MUST. It applies to all the VFs, but it doesn't apply without legacy. For example, if one wants to build a PCI VF device that doesn't want to support legacy, it can still be on BAR2 or BAR 4. This is fine.
> So that driver actually checks, but it's ok to fail if the rule is not > followed > maybe? In that case add a driver normative statement too. Yes. I will add. Change log and commit log already capture this, but in case you missed it, v4 extended the struct virtio_pci_notify_cap with a boolean and removed the AQ notify query command as you suggested. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
