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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Friday, April 7, 2023 8:03 AM
> 
> On Tue, Apr 04, 2023 at 12:08:54PM -0400, Parav Pandit wrote:

[..]
> > > I took a fresh look at it, and I don't get it: what exactly is wrong
> > > with just using modern ID? Why do we need new ones?
> >
> > A modern (non transitional device) do not support legacy functionality
> > such as virtio net hdr,
> 
> It's all a question of terminology, but it is not worth sacrificing functionality for
> cleaner terminology.
> Basically most of the spec just talks about the legacy interface, and will work
> fine with this.
> 
> Yes we do say:
> Devices or drivers with no legacy compatibility are referred to as non-
> transitional devices and drivers, respectively.
> 
> 
> So we will want to refine this somewhat. Maybe:
> 
> 	Devices not compatible with legacy drivers and drivers not compatible
> 	with legacy devices are referred to as non-transitional devices and
> 	drivers, respectively.
> 
> 
> This allows non-transitional devices to expose the legacy capability - having this
> capability does not make them compatible with
> 
> Similarly in the conformance section:
> 
> An implementation MAY choose to implement OPTIONAL support for the
> legacy interface, including support for legacy drivers or devices, by conforming
> to all of the MUST or REQUIRED level requirements for the legacy interface for
> the transitional devices and drivers.
> 
> we would just remove "for the transitional devices and drivers"
> here as now non-transitional can have a legacy interface.
> 
> Similarly:
> 
> The requirements for the legacy interface for transitional implementations
> 
> would become:
> 
> "The requirements for the legacy interface"
> 
>
I will hold to respond to other emails in this series, because the key part is here.

If I understand you correctly, will above wording translate to below behavior?

1. A non-transitional device will expose a capability (not a feature bit, but a capability at transport level).
This capability indicates that, it supports legacy interface.
Lets name it legacy_if_emulation for sake of this discussion.
It is a two-way pci capability.
Device reports it.
And driver enables it. (Why two way and why driver needs to enable it, described later in point #d below).

Hence, such non transitional device does not need to comply to below listed requirements #a and #b.

a. A driver MUST accept VIRTIO_F_VERSION_1 if it is offered.
(Because hypervisor driver is a passthrough driver; and legacy driver will not accept this feature bit).

b. device MAY fail to operate further if VIRTIO_F_VERSION_1 is not accepted.

c. A non-transitional device with above legacy_if_supported capability, will allow device reset sequence, described in
[1] Driver Requirements: Device Initialization (3.1.1)
[2] Legacy Interface: Device Initialization (3.1.2)

> > device reset sequence.
> 
> what is this one?

I listed above in #c.
And 

d. When legacy_if_emulation capability is offered and hypervisor driver enabled it, when driver perform device reset, driver will not wait for device reset to go zero.
When legacy_if_emulation capability is not enabled by (hypervisor or other say existing) driver, driver will wait for device reset to turn 0. (Following the driver requirement 2.4.2).