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

[Parav Pandit <parav@nvidia.com>]

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

> So what is it? Was admin vq a mistake and we should do memory mapped?
No. Certainly not.
AQ is needed for LM, SR-IOV (SR-PCIM management), SIOV device life cycle.

> Or is
> legacy emulation doable over a vq and latency is not a concern, and the real
> reason is because it makes you push out a host driver with a bit less effort?
> 
Legacy registers emulation is doable over VQ and has its merits (I listed in previous email).
I forgot to mention in previous email that device reset is also better via tvq.
It is just that legacy_registers_transport_vq (LRT_VQ) requires more complex hypervisor driver and only works for the VFs.

At spec level, MMR has value on the PF as well, hence I previously proposed last week on your first email that spec should allow both.

Efforts of hypervisor not really a big concern.
Once we converge that LRT_VQ is good, it is viable option too.
I will shortly send out little more verbose command on lrt_vq so that its optimal enough.

> I just do not see how these claims do not contradict each other.

An AQ for queuing, parallelism, memory saving.