Re: [virtio-comment] Re: [PATCH 09/11] transport-pci: Describe PCI MMR dev config registers

[Jason Wang <jasowang@redhat.com>]

On Fri, Apr 14, 2023 at 11:18âAM Parav Pandit <parav@nvidia.com> wrote:
>
>
>
> > From: Jason Wang <jasowang@redhat.com>
> > Sent: Thursday, April 13, 2023 11:10 PM
>
> > > We have two options to satisfy the requirements.
> > > (partly taken/repeated from Jason's yday email).
> > >
> > > 1. AQ (solves reset) + notification for building non transitional
> > > device that support perform well and it is both backward and forward
> > > compat
> > > Pros:
> > > a. efficient device reset.
> > > b. efficient notifications from OS to device c. device vendor doesn't
> > > need to build transitional configuration space.
> > > d. works without any mediation in hv for 1.x and non 1.x for all non-legacy
> > interfaces (vqs, config space, cvq, and future features).
> >
> > Without mediation, how could you forward guest config access to admin
> > virtqueue? Or you mean:
> >
> > 1) hypervisor medate for legacy
> > 2) otherwise the modern BARs are assigned to the guest
> >
> Right.
>
> > For 2) as we discussed, we can't have such an assumption as
> >
> > 1) spec doesn't enforce the size of a specific structure
> Spec will be extended in coming time.

It's too late to do any new restriction without introducing a flag.
Mandating size may easily end up with a architecte specific solution.

>
> > 2) bing vendor locked thus a blocker for live migration as it mandate the layout
> > for the guest, mediation layer is a must in this case to maintain cross vendor
> > compatibility
> >
> With PCI VF will have compatibility check and also vendor recommendations.

I'm not sure what type of recommendations you want.

We've already had:

1) features
2) config

And what you proposed is to allow the management to know the exact
hardware layout in order to check the compatibility? And the
management needs to evolve as new structures are added. This
complicates the work of management's furtherly which I'm not sure it
can work.

>
> > Hypervisor needs to start from a mediation method and do BAR assignment
> > only when possible.
> >
> Not necessarily.
>
> > > Cons:
> > > a. More AQ commands work in sw
> >
> > Note that this needs to be done on top of the transport virtqueue. And we
> > need to carefully design the command sets since they could be mutually
> > exclusive.
> >
> Not sure what more to expect out of transport virtqueue compared to AQ.
> I didnât follow, which part could be mutually exclusive?

Transport VQ allows a modern device to be transported via adminq.

And you want to add commands to transport for legacy devices.

Can a driver use both the modern transport commands as well as the
legacy transport commands?

Thanks