On 08-11-23, 09:19, Erik Schilling wrote:
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.
Thanks for your feedback Erik :)
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
s/device/driver/ ?
the driver. Or am I misunderstanding the term here? What is the
s/driver/device/ ?
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.
Just to clarify, what we are talking about is the device memory accessible at the driver. For a MMIO device, it is a range of length 0x200 per device. The MMIO section also says this:
"The driver MUST NOT access memory locations not described in the table 4.1."
The table here talks about the memory space of 0x200 bytes.
What I am trying to say is that the driver shouldn't try to access anything beyond this 0x200 memory region. Not sure how it works for PCI and Channel I/O though.
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.
Maybe that, or maybe outside the shared page too..
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.
Yeah, I should clarify that.