> From: Michael S. Tsirkin <m...@redhat.com> > Sent: Wednesday, June 21, 2023 4:31 PM > To: Parav Pandit <pa...@nvidia.com> > Cc: virtio-comm...@lists.oasis-open.org; coh...@redhat.com; > david.edmond...@oracle.com; virtio-dev@lists.oasis-open.org; > sbu...@marvell.com; jasow...@redhat.com; Yishai Hadas > <yish...@nvidia.com>; Maor Gottlieb <ma...@nvidia.com>; Shahaf Shuler > <shah...@nvidia.com> > 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 <m...@redhat.com> > > > 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: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
