Hi Alex,
Thank you for doing this. I am looking forward to STR-20, I have been wanting a clean-up in that area for years. Also STR-19 is well worded and looks mostly fine. I only have a comment on the last statement:
QEMU should also be able to act as the stub setup to pass IOREQ events to a separate vhost-user daemon as a stepping stone to a future Xen aware vhost-user stub program.
Xen can actually have multiple IOREQ servers running for the same domain. Given that the code for receiving IOREQs is minimal and easily portable, it would be better to make any other daemon a proper IOREQ server talking to Xen directly, rather than having to go via QEMU. The architecture would look cleaner and would lead to far better performance, removing a step in the hot path. In other words I think the vhost-user daemon should be run as its own IOREQ server.
On Wed, 4 Nov 2020, Alex Bennée via Stratos-dev wrote:
Hi Stefano,
I've re-written STR-19 (https://projects.linaro.org/browse/STR-19) now I have a hopefully better understanding of the relationship between IOREQ backends and how QEMU is launched with Xen. I see this approach as a stop-gap for testing additional virtio devices. Eventually we need to specify a new card for a Xen aware vhost-user launching stub that will link our hypervisor agnostic user-space daemons to the Xen specific virtio instance. I think we can hold off on that until we have a better idea of the sort of interface Xen and other type-1's need to provide for them.
I've also raised STR-20 (https://projects.linaro.org/browse/STR-20) to cover the work to fix up the current build and allow for using a leaner native qemu-system-aarch64 to be used instead of qemu-system-i386 and it's additional baggage. I have patches in train for that which I'll post soon.
Could you have a look over both for any obvious snafus?
-- Alex Bennée -- Stratos-dev mailing list Stratos-dev@op-lists.linaro.org https://op-lists.linaro.org/mailman/listinfo/stratos-dev