Closed thomasdangl closed 1 year ago
Thanks for taking a look.
Our initial approach used error codes to signal allocation and deallocation requests to QEMU. The main drawback of that method is handling requests while waiting for an event reply. Dealing with this correctly would require significant refactoring to save the thread's state (message on the stack).
Sending the status as an additional event would circumvent that problem but also complicate the implementation because it would put most of the synchronization in the hands of the user. The most common use case, we believe, would be allocating memory and remapping a physical page to the new memory in response to an event. Here, the thread processing the initial event would have to wait for a separate thread to handle and signal the success message, which our solution avoids. Furthermore, the event response, e.g., reinject behavior, can not be changed after the remapping. So, in a way, our approach is also more flexible.
However, if you prefer a solution without synchronization in the kernel, let us know, and we will reconsider.
Best, Thomas
See related PR https://github.com/KVM-VMI/qemu/pull/14 for details.