On Fri Nov 3, 2023 at 11:42 AM CET, Viresh Kumar wrote:
The virtio documentation currently doesn't define any generic requirements that are applicable to all transports. These may be useful while adding support for a new transport.
This commit tries to define the same.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org
Alex,
Sending it to Stratos list first to get some initial feedback.
content.tex | 48 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 46 insertions(+), 2 deletions(-)
diff --git a/content.tex b/content.tex index 0a62dce5f65f..489028b6ef3f 100644 --- a/content.tex +++ b/content.tex @@ -631,8 +631,52 @@ \section{Device Cleanup}\label{sec:General Initialization And Device Operation / \chapter{Virtio Transport Options}\label{sec:Virtio Transport Options} -Virtio can use various different buses, thus the standard is split -into virtio general and bus-specific sections. +The virtio devices are exposed to the guest as if they are physical +devices using a specific transport method, like PCI, MMIO or Channel +I/O. The transport methods define various aspects of communication +between the device and the driver, like device discovery, exchanging +capabilities, interrupt handling, and data transfer. Virtio can use +various different buses, thus the standard is split into virtio general +and bus-specific sections.
+\section{Virtio Transport Requirements}\label{sec:Virtio Transport Options / Virtio Transport Requirements}
+\devicenormative{\subsection}{Virtio Transport Requirements}{Virtio Transport Options}
+The device MUST present each event, in a transport defined way, from the +moment it takes place until the driver acknowledges the interrupt, in a +transport defined way.
+The device MUST NOT access virtqueue contents before the driver notifies +that the queue is ready for access, in a transport defined way.
+The device MUST NOT access buffers previously modified on the queue by +it, after it has notified the driver about their availability.
+The device MUST reset the virtqueues if asked by the driver, in a +transport defined way.
+\drivernormative{\subsection}{Virtio Transport Requirements}{Virtio Transport Options}
+The driver MUST NOT access memory locations outside what's presented by +the device.
I get what this is trying to state, but I am worried whether this is a bit ambigious... A driver surely will access driver-private, virtio-unrelated data, right? Also, what does "presented" mean? I wonder whether the following requirements do not already cover what this statement is stating. So maybe this can simply be dropped?
+The driver MUST NOT write to the read-only registers and MUST NOT read +from the write-only registers.
+The driver MUST acknowledge events presented by the device, as mandated +by the transport.
+The driver MUST NOT access virtqueue contents before the device notifies +that the queue is ready for access, in a transport defined way.
+The driver MUST NOT access buffers previously added to the queue by the +driver, after it has notified the device about their availability. The +driver MAY access the same after the device has processed them and +notified the same to the driver, in a transport defined way.
Is there no escape hatch here? What happens, for example, if the device fails to respond? Can the driver forcibly regain access, for example, by resetting the device? The way the statement is currently written it seems to disallow any recovery from a hung or dead device.
+The driver MAY ask the device to reset the virtqueues, in a transport +defined way. \input{transport-pci.tex} \input{transport-mmio.tex}