I should probably have prefixed my last mail with:
All my comments are of minor nature. Your suggestions overall sound fine to me. I am only trying to point out passages where someone amibigious understanding remains - at least when reading each statement with a slightly adversarial stance.
On Wed Nov 8, 2023 at 8:55 AM CET, Viresh Kumar wrote:
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.
Exactly :). But my feeling was that - strictly speaking - the statement may be understood in that way.
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 ?
Ok, if it has established use then that is fine. I am a bit confused though... Why do we need to restrict access to memory that is NOT presented? The device won't see memory that was not presented to it by the driver. Or am I misunderstanding the term here? What is the difference between driver-private memory and memory not presented to the device?
I have not found a clear definition of what is meant by "presenting" in the remaining spec. So chances are that I am misunderstanding something 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 ?
Hm... Which kind of invalid access is not covered? Data outside of virtqueues but still in a shared page? I guess this may be related to my confusion above.
+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.
I was mostly pointing out that if reset allows to restore access, then that should probably be mentioned somewhere. Currently you ONLY define that access may happen again after the device cooperated and sent a notification. No other method is legal with this statement.
- Erik