Re: [virtio-comment] Re: [PATCH 07/11] transport-pci: Introduce transitional MMR device id

[Parav Pandit <parav@nvidia.com>]

On 4/10/2023 3:58 PM, Michael S. Tsirkin wrote:
> On Mon, Apr 10, 2023 at 10:34:16AM -0400, Parav Pandit wrote:

> > > 	A device MUST offer VIRTIO_F_VERSION_1.  A device MAY fail to operate further
> > > 	if VIRTIO_F_VERSION_1 is not accepted.
> > >
> > > it's implied that this does not refer to legacy interface.
> > But the interface being exposes is not a legacy interface at the PCI device
> > level.
> >
> > A PCI device is exposing a interface that can be used
> > by either
> > a. existing non transitional driver who will negotiate _1, just fine.
> > or
> > b. by legacy driver in the guest VM, which will not negotiate _1.
> >
> > And here device must not fail to operate.
> > Hence spec should say that it should not fail to operate.
>
> sorry, what? it's exactly the legacy interface that's the whole
> value of this hack, just exposed through another bar.
I am aligned with you on this part of exposing legacy interface via 
another bar (or a window within an existing memory bar).

What is translates to is a spec wording something like below:

A non transitional device exposes legacy interface using a memory mapped 
registers in a BAR or its parent PCI device through AQ.

Legacy common configuration registers and device specific registers 
accessed through such interface work as legacy interface defined in rest 
of the specification.

> > And since the guest driver may be 1.x, _1 will be offered by the device.
>
> _1 is not offered in the legacy interface. And if you negotiate
Right.

> _1 you better not touch legacy with a 10 foot pole.
Right.

> Just add a new capability and explain that it exposes
> the legacy interface in a window at an offset inside a memory bar.
> that is mostly it. if there's an adapting layer that forwards
> IO requests from legacy driver to that window, this allows this
> driver to work and use the device through the legacy
> interface.
ok. Something like above?

> There could be a small patch or two on top to tweak wording if there are
> places where it says "non transitional devices have no legacy
> interfaces". And probably an explicit list of devices
> which are allowed to have this capability.
Make sense to me.

effectively we will have,

1. one or two patches, as you describe in above point for tweaking 
wording + device list.
2. new optional capability (in extended area because legacy area is near 
to full).
   a. indicates it supports memory mapped and/or
   b. via aq (when aq is ready)

3. patch to make use of notification region as done in patch-10.