Re: [virtio-comment] [PATCH 00/11] Introduce transitional mmr pci device

[Parav Pandit <parav@nvidia.com>]

On 4/3/2023 5:14 PM, Michael S. Tsirkin wrote:
> On Mon, Apr 03, 2023 at 08:42:52PM +0000, Parav Pandit wrote:
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Monday, April 3, 2023 4:03 PM
> > >
> > > On Mon, Apr 03, 2023 at 07:48:56PM +0000, Parav Pandit wrote:
> > > > > OK but supporting them with a passthrough driver such as vfio does
> > > > > not seem that important.
> > > > Not sure on what basis you assert it.
> > > > I clarified in the cover letter that these are the user level requirements to
> > > support transitional and non-transitional devices both via single vfio subsystem.
> > >
> > > And what is so wrong with vdpa?  Really I don't see how the virtio spec needs to
> > > accomodate specific partitioning between linux modules, be it vdpa or vfio.
> > > Way beyond the scope of the driver.
> > vdpa has its own value.
> >
> > Here requirements are different as listed so let's focus on it.
>
> I'm not sure how convincing that is. Yes simpler software is good,
> it's nice to have, but it's not such a hard requirement to use vfio
> when vdpa is there. And again, the cost is reduced robustness.
It is not hard requirement to use vdpa or vfio one way or either.

vdpa users can use vdpa.
vfio users can use vfio.

> > > But anyway, my main
> > > point is about DMA. On the one hand you are asking for a VQ based
> > > management interface because it saves money. On the other you are saying
> > > DMA operations take extremely long to the point where they are unusable in
> > > the boot sequence.
> >
> > I think you missed the point I described few emails back.
> > The legacy registers are subset of the 1.x registers, so a device that implements existing 1.x registers, they get legacy registers for free.
> > Hence, there is no _real_ saving.
>
> First not 100%.  E.g. MAC is writeable so that's a R/W register as
> opposed to RO.  But generally, why implement 1.0 registers at all? Do it
> all in transport vq.
1.x non transitional VFs and SIOV devices will use their own 
register_transport_vq once that infrastructure is in place to access its 
registers. Such VQ is directly accessible in the guest VM without 
hypervisor intervention.

It is orthogonal to this use case (and such future VQ still works with 
this design).

In this approach a hypervisor needs to use PF's AQ because the VF device 
(its registers, features etc) is not owned by the hypervisor VF driver.