[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v2 0/2] transport-pci: Introduce legacy registers access using AQ
On Tue, May 16, 2023 at 11:43:09AM +0800, Jason Wang wrote: > On Tue, May 16, 2023 at 11:37âAM Jason Wang <jasowang@redhat.com> wrote: > > > > > > å 2023/5/16 02:01, Michael S. Tsirkin åé: > > > On Mon, May 15, 2023 at 06:00:02PM +0000, Parav Pandit wrote: > > >>> 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. > > > VIRTIO_F_NOTIF_CONFIG_DATA is there presumably for a reason. > > > > > >>>> 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. > > > But it is passed through to guest presumably. > > > > > > Probably not in the case of VIRTIO_F_NOTIF_CONFIG_DATA. Did you see any > > problem if we do mediation here except for some performance penalty? > > Ok, rethink of this, when using legacy, VIRTIO_F_NOTIF_CONFIG_DATA > should be assumed to be not negotiated. So I think I agree with Parav, > it should not be a problem. > > Or do you mean for the devices that have some mandated features? > > Thanks Exactly. VIRTIO_F_NOTIF_CONFIG_DATA if there is likely to be required for device to work as opposed to being an optimization. > > > > Thanks > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]