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

["Michael S. Tsirkin" <mst@redhat.com>]

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.

> 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.