Hi Everyone,
As you know we have a pending subject around Version handling to solve to have some kind of "stable" version of the protocol and I think we have a bit over engineered this so far so i will try to explain my current train of thoughts so that we could have a productive discussion on Thursday.
What are other transports doing and why ?
- PCI: there is no real protocol version. Capabilities are used and there is only one used for Legacy devices - MMIO: One version register which an be 1 or 2, read only from the driver which is used to inform a driver of the layout of the registers. There is no negociation - Channel I/O: A revision, a length and some way to set additional options depending on the revision. The driver is here telling to the device which revision of the protocol it wants to use and the device just say no if it does not support what the driver wants. Once selected any change must be rejected by the device and the driver must begin by setting it. Somehow the virtio spec says that this is per device as the only change was a status message not existing but it is clear that this must be handled at the transport level and not in a specific driver.
What we need ?
I think we need something very close to what Channel I/O is defining and it would be a good idea to do reuse the same principles: - the driver side sets the revision - the device side just say "Error" if it does not support what is requested - once the revision is set, only a reset can allow to change it - driver side should start with highest revision and go down until it finds a revision it supports
Now I think that having this per device is not useful because we want to have a generic transport and having different sets of messages per device due to different revision seems like a complexity we do not need.
So i think this is something that we should offload at the bus level and define the following: - A bus implementation must inform the virtio message generic transport of the version of the protocol to be used for a specific bus device instance (ie all devices on this instance will use the same protocol version). This is to be done through an implementation defined way. - A bus implementation must inform the virtio message generic transport of the maximum message size its support through an implementation defined way. This can also be per bus device instance. - It is the bus driver responsibility to negociate a version and maximum message size with a bus device instance. - It is the bus device responsibility to know which versions are supported by its own virtio message generic implementation.
Follwing those principles i would propose to do the following changes in the specification: - remove the VIRTIO_MSG_VERSION message - introduce a BUS_MSG_VERSION message with more or less the same definition as the current VIRTIO_MSG_VERSION (only simplifying by saying that the driver sets a version and device say yes or no, the size would work as it is now)
Some questions for discussion:
- Do you think it is ok to move this to the BUS or should we keep it in the generic layer to be more "coherent" with other transports ?
- Should we provision something like the "data" part in Channel I/O to have options on a specific revision ?
- Anything else ?
Cheers Bertrand
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Bertrand,
Thanks for this deep analysis of the versioning on other transport!
On 3/25/25 09:59, Bertrand Marquis wrote:
Hi Everyone,
As you know we have a pending subject around Version handling to solve to have some kind of "stable" version of the protocol and I think we have a bit over engineered this so far so i will try to explain my current train of thoughts so that we could have a productive discussion on Thursday.
What are other transports doing and why ?
- PCI: there is no real protocol version. Capabilities are used and there is only one used for Legacy devices
- MMIO: One version register which an be 1 or 2, read only from the driver which is used to inform a driver of the layout of the registers. There is no negociation
- Channel I/O: A revision, a length and some way to set additional options depending on the revision. The driver is here telling to the device which revision of the protocol it wants to use and the device just say no if it does not support what the driver wants. Once selected any change must be rejected by the device and the driver must begin by setting it. Somehow the virtio spec says that this is per device as the only change was a status message not existing but it is clear that this must be handled at the transport level and not in a specific driver.
Regarding linux implementation [1], it seems that it is handled at transport level in virtio-ccw.
[1] https://elixir.bootlin.com/linux/v6.14-rc6/source/drivers/s390/virtio/virtio...
What we need ?
I think we need something very close to what Channel I/O is defining and it would be a good idea to do reuse the same principles:
- the driver side sets the revision
- the device side just say "Error" if it does not support what is requested
- once the revision is set, only a reset can allow to change it
- driver side should start with highest revision and go down until it finds a revision it supports
Now I think that having this per device is not useful because we want to have a generic transport and having different sets of messages per device due to different revision seems like a complexity we do not need.
Agree! and we have also another specificity that increase the complexity: we support multiplexing of several devices on the same transport.
So i think this is something that we should offload at the bus level and define the following:
- A bus implementation must inform the virtio message generic transport of the version of the protocol to be used for a specific bus device instance (ie all devices on this instance will use the same protocol version). This is to be done through an implementation defined way.
- A bus implementation must inform the virtio message generic transport of the maximum message size its support through an implementation defined way. This can also be per bus device instance.
- It is the bus driver responsibility to negociate a version and maximum message size with a bus device instance.
- It is the bus device responsibility to know which versions are supported by its own virtio message generic implementation.
Follwing those principles i would propose to do the following changes in the specification:
- remove the VIRTIO_MSG_VERSION message
- introduce a BUS_MSG_VERSION message with more or less the same definition as the current VIRTIO_MSG_VERSION (only simplifying by saying that the driver sets a version and device say yes or no, the size would work as it is now)
Some questions for discussion:
- Do you think it is ok to move this to the BUS or should we keep it in the generic layer to be more "coherent" with other transports ?
Ok for me to move this in the bus.
- Should we provision something like the "data" part in Channel I/O to have options on a specific revision ?
No strong opinion in that point... By default, I would say that it should not cost much to add it.
Thanks, Arnaud
- Anything else ?
Cheers Bertrand
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Virtio-msg mailing list -- virtio-msg@lists.linaro.org To unsubscribe send an email to virtio-msg-leave@lists.linaro.org
-
Arnaud POULIQUEN -
Bertrand Marquis