Re: [virtio-dev] Re: [PATCH v3 0/3] transport-pci: Introduce legacy registers access using AQ

[Jason Wang <jasowang@redhat.com>]

On Fri, Jun 9, 2023 at 10:53âAM Parav Pandit <parav@nvidia.com> wrote:
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Thursday, June 8, 2023 10:43 PM
>
> > > It is passthrough device, none of the 1.x objects are accessible or mediated by
> > the hypervisor.
> >
> > Let me quote my reply once again:
> >
> > "
> > Hypervisor just need to prepare
> >
> > 1) legacy BAR with legacy config and device configuration space
> > 2) modern BAR with modern capabilities (common cfg and device cfg)
> >
> This is what is done in v5.

I meant this could be done with _F_LEGACY_HEADER/MAC as well.

>
> > For 2) it could be mapped directly to guest without any mediation For
> > 1) hypervisor needs to mediate
> > "
> >
> > There's zero mediation for 1.x objects at all. No?
> >
>
> > For accessing 1.x objects by hypervisor, what's wrong with that especially
> > considering it is used for legacy mediation only but not modern?
> I didnât follow the question.
>
> > (Btw, how do
> > you define 1.x objects, isn't any facility via adminq an 1.x object?)
> >
> 1.x objects of the passthrough VF device.
>
> > In order to converge the discussion, maybe you can explain which one of your 3
> > use cases and why can't work with _F_LEGACY_HEADER + _F_LEGACY_MAC.
> Hypervisor does not involve in feature negotiation and device life cycle phase so it cannot negotiate it.

With  _F_LEGACY_HEADER + _F_LEGACY_MAC, hypervisor doesn't need to be
involved in the feature negotiation for modern devices as well.

Anything I missed?

Thanks