Stefano Stabellini stefano.stabellini@xilinx.com writes:
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 intention is to enable testing of the existing virtio daemons (for example virtio-gpu) where was can translate an IOREQ message and forward a vhost-user event to the daemon. I'm not expecting it to be the final performance orientated solution.
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.
Well this is where we may need to consider supporting another message format from Xen. Remember the individual daemons are attempting to be hypervisor agnostic with a minimal shim dealing with the specifics of setting up on each hypervisor. That said maybe terminating IOREQ and vhost-user messages isn't that tricky or maybe another message stream makes more sense (vfio user messages?). I haven't dug into the differences yet but I suspect there is a fair degree of commonality given the problem domain.
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