On Thu, Mar 02, 2023 at 01:49:07PM +0530, Viresh Kumar wrote:
On 01-03-23, 12:29, Stefan Hajnoczi wrote:
What is the advantage over defining separate messages? Separate messages are cleaner and more typesafe.
I thought we wanted to keep single message for one kind of functionality, which is mmap related quirks here. And so it would be better if we can reuse the same for next hypervisor which may need this.
The value parameter is not fixed and is hypervisor specific, for Xen this is the domain id, for others it may mean something else.
mmap-related quirks have no parameters or behavior in common so there's no advantage in sharing a single vhost-user protocol message. Sharing the same message just makes it awkward to build and parse the message.
I don't have a concrete example, but was thinking of a guest that shares memory with other guests (like the experimental virtio-vhost-user device). Maybe there would be a scenario where some memory belongs to one domain and some belongs to another (but has been mapped into the first domain), and the vhost-user back-end needs to access both.
These look tricky (and real) and I am not sure how we would want to handle these. Maybe wait until we have a real use-case ?
A way to deal with that is to include mmap information every time fds are passed with a message instead of sending one global message at the start of the vhost-user connection. This would allow each mmap to associate extra information instead of forcing them all to use the same information.
The other thing that comes to mind is that the spec must clearly state which mmaps are affected by the Xen domain information. For example, just mem table memory regions and not the VHOST_USER_PROTOCOL_F_LOG_SHMFD feature?
Maybe we can mention that only the mmap's performed via /dev/xen/privcmd and /dev/xen/gntdev files are affected by this ?
No, this doesn't explain when mmap must be performed via /dev/xen/privcmd and /dev/xen/gntdev. The spec should be explicit about this instead of assuming that the device implementer already knows this.
Stefan