For clarification, in case there is any doubt:
Device - the backend running on the host. Driver - the guest kernel driver (frontend).
On 08-11-23, 08:41, Erik Schilling wrote:
On Fri Nov 3, 2023 at 11:42 AM CET, Viresh Kumar wrote:
+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?
Yeah, but that isn't part of backend's memory but the guest itself. The spec doesn't need to talk about such a memory.
Also, what does "presented" mean?
Made available for the frontend to use. This word is used few times in the spec, maybe I should choose a different word here ?
I wonder whether the following requirements do not already cover what this statement is stating. So maybe this can simply be dropped?
The below ones don't talk about invalid access to memory over what is allowed. Or am I missing something ?
+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.
There is virtqueue reset option. I guess that's what gets used in such circumstances. Wonder if I should talk about it here.