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

[Parav Pandit <parav@nvidia.com>]

On 3/31/2023 3:03 AM, Michael S. Tsirkin wrote:
> OK but this does not answer the following question:
> since a legacy driver can not bind to this type of MMR device,
> a new driver is needed anyway so
> why not implement a modern driver?
Not sure I follow "implement a modern driver".
If you mean hypervisor driver over modern driver, than yes, you captured 
those two problems below.

More reply below.

> I think we discussed this at some call and it made some kind of sense.
Yep.
> Unfortunately it has been a while and I am not sure I remember the
> detail, so I can no longer say for sure whether this proposal is fit for
> the purpose.  Here is what I vaguely remember:
>
> A valid use-case is an emulation layer (e.g. a hypervisor) translating
> a legacy driver I/O accesses to MMIO. 
Yes.

> Ideally layering this emulation
> on top of a modern device would work ok
> but there are several things making this approach problematic.
Right.

> One is a different virtio net header size between legacy and modern
> driver. Another is use of control VQ by modern where legacy used
> IO writes. In both cases the different would require the
> emulation getting involved on the DMA path, in particular
> somehow finding private addresses for communication between
> emulation and modern device.
Both of these issues are resolved by this proposal.

> Does above summarize it reasonably?
>
>
> And if yes, would an alternative approach of adding legacy config
> support to transport vq work well?

VF is supplying the legacy config region (subset of 1.x) in memory 
mapped area.

A transport vq on the parent PF is yet another option for legacy 
register emulation. I think latency wise it will be a lot more higher, 
though it is not of lot of importance.

The good part of transport vq is, device reset is better as it can act 
as slow operation.

Given that device already implements part of registers in 1.x memory 
mapped area, it is reasonable for device to provide similar registers 
via memory map. (legacy is subset, no new addition).

> I can not say I thought about this
> deeply so maybe there's some problem, or maybe it's a worse approach -
> could you comment on this? It looks like this could be a smaller change,
> but maybe it isn't? Did you consider this option?

We can possibly let both the options open for device vendors to implement.

Change wise transport VQ is fairly big addition for both hypervisor 
driver and also for the device.

> More review later.
ok.