RE: [virtio-comment] RE: [PATCH v19] virtio-net: support inner header hash

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Wednesday, June 28, 2023 1:16 PM

> > 1. Because than device is 100% sure that it does not fulfill MMIO
> > needs 2. Single interface to access extended config space, which is what you
> asked for.
> > 3. Single driver code because there is single way to get it.
> >
> 
> Right. But I think there's a better way.
> Just say that any feature in MMIO MUST be also in DMA.
> So any modern driver will have no reason at all to use MMIO - DMA is a
> superset.
>
How does that relax the need of MMIO for the device?

> If we say that drivers should use DMA, they will.  If we additionally explain that
> some features might not be in MMIO no sane driver will use MMIO if it does not
> have to.
> Or if it does then it has violated the spec and will get less features?
> 
So than why to have it in MMIO anyway?
Why not say driver must use dma?

> > This demands two ways of access and that conflicts with your point of desire
> to do single way.
> > I proposed single way, extended config space via DMA interface, that is really
> as simple as that.
> 
> 
> My desire is to have a single way that works for everything.
> We have legacy so we will have legacy ways too, these might not work for
> everything.
Here is what can work well,

A device tells the offset of the extended config space to the driver.
Any field starting from that offset must be accessed via a DMA interface.
This way, driver must support DMA and all new features come from there.

If device chose to use MMIO, say sw, it can still do it using MMIO.