> From: Michael S. Tsirkin <[email protected]> > Sent: Wednesday, June 21, 2023 4:31 PM > To: Parav Pandit <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; Yishai Hadas > <[email protected]>; Maor Gottlieb <[email protected]>; Shahaf Shuler > <[email protected]> > Subject: Re: [virtio-comment] RE: [PATCH v6 4/4] transport-pci: Introduce > group > legacy group member config region access > > On Wed, Jun 21, 2023 at 08:22:58PM +0000, Parav Pandit wrote: > > > > > > > From: Michael S. Tsirkin <[email protected]> > > > Sent: Wednesday, June 21, 2023 4:06 PM > > > > [..] > > > > > To put it in our terms, something like this: > > > > > when a legacy driver accesses a member device of > > > > > a group using the > > > > > legacy interface, a modern driver can intercept > > > > > the access and forward it to the owner device. > > > > > > > > > I will not mention "modern driver" as it has zero reference in > > > > spec and don't > > > want to bring Linux terms here. > > > > "the driver can intercept" is enough. > > Maybe a (non legacy) driver can intercept? Would that be acceptable? > Just to clarify the confusion above. > Non legacy driver wording is fine.
> > > when a legacy member device driver accesses a member device of > > > a group using the > > > legacy interface, an owner device driver can intercept > > > the access and forward it to the owner device. > > > > > Above is not correct. > > > > We have 3 drivers in picture. > > 1. guest driver > > this is legacy driver, so easy > > > 2. hypervisor level member device driver > > this is just for notifications, optionally, yes? > For notifications (optionally) and for configuration region access. > > > 3. group owner device driver > > > > Trying to write without introducing guest and hypervisor term, > > > > A group owner device driver provides the service to access member device's > configuration region. > > A member device driver avail this service when it wants to access the member > device's configuration region. > > > I agree, it's getting complicated. > > > > > > > I will rewrite it as, > > > > > > > > The group owner device should not expose PCI BAR0 in the PCI > > > > SR-IOV extended capability for the group member PCI VF devices > > > > when it prefers to > > > support legacy interface for legacy configuration access using this group > owner. > > > > > > > > > This seems to ignore all my comments. > > > > > I replied after that, probably missed in exchanges. > > > > How about: > > The group owner device MUST hardwire PCI BAR0 in the PCI SR-IOV extended > capability for the group member PCI VF devices when it supports legacy > configuration access commands. > > > > better but it's not a PCI BAR0. let's add link to sriov spec, and name it VF > BAR0 > same as in that spec. > Yes, VF BAR0, will correct it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
