RE: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Monday, May 15, 2023 1:56 PM
> 
> On Mon, May 15, 2023 at 05:51:05PM +0000, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Monday, May 15, 2023 1:45 PM
> > >
> > > On Mon, May 15, 2023 at 03:49:44PM +0000, Parav Pandit wrote:
> > > > All legacy interface via AQ.
> > > > All modern interface access via PCI or its own transport between
> > > > driver and
> > > device.
> > >
> > > I am wondering however about the hypervisor notifications.
> > > Generally these are the most problematic aspect here I feel.  For
> > > example, how does it interact with VIRTIO_F_NOTIF_CONFIG_DATA?  And
> > > generally, having both guest and host be allowed to access device's BAR
> seems problematic.
> > > Can we reserve a PF BAR region for these things or is that too expensive?
> >
> > VIRTIO_F_NOTIF_CONFIG_DATA is not present for the legacy.
> 
> it is not but it just might be required, or it won't be there.
> 
How can it be required if it not part of it?
I likely didn't follow your question/comment, can you please explain.

> > For modern device, guest driver will access the device own BAR directly with
> its own config_data anyway.
> > Should we reserve a region in the PF BAR for SF/SIOV device?, should device
> report which BAR/area to use for the given SF/SIOV device?
> > May be yes, those are different discussions with tradeoff to consider during
> SIOV discussions. It is not related to VFs.
> 
> For SIOV it's a given. But we can do this for SRIOV: reserve a PF region per VF.
Each VF has its own BAR area for driver notifications.