OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[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: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

>
> Thanks
>
>
> >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]