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

Parav Pandit
2023-04-10T20:17:08Z

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.