On Sat, 2 Oct 2021 14:20:47 -0400 "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > > >From my perspective the problem is that the version of the device > > remains in limbo as long as the features have not yet been finalized, > > which means that the endianness of the config space remains in limbo as > > well. Both device and driver might come to different conclusions. > > Version === legacy versus modern? > It is true that feature negotiation can not be used by device to decide that > question simply because it happens too late. > So let's not use it for that then ;) > > Yes we have VERSION_1 which looks like it should allow this, but > unfortunately it only helps with that for the driver, not the device. > > In practice legacy versus modern has to be determined by > transport specific versioning, luckily we have that for all > specified transports (can't say what happens with rproc). So if we look at ccw, you say that the revision negotiation already determines whether VERSION_1 is negotiated or not, and the feature bit VERSION_1 is superfluous? That would also imply, that 1) if revision > 0 was negotiated then the device must offer VERSION_1 2) if revision > 0 was negotiated and the driver cleared VERSION_1 the device must refuse to operate. 3) if revision > 0 was negotiated then the driver should reject to drive a device if it does not offer VERSION_1 4) if revision > 0 was negotiated the driver must accept VERSION_1 5) if revision > 0 was *not* negotiated then the device should not offer VERSION_1 because at this point it is already certain that the device can not act in accordance to the virtio 1.0 or higher interface. Does that sound about right? IMHO we should also change https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-160003 and the definition of VERSION_1 because both sides have to know what is going on before features are fully negotiated. Or? Regards, Halil
