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

[Parav Pandit <parav@nvidia.com>]

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

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