Le 05/01/2026 à 14:42, Bertrand Marquis a écrit :
Hi Teddy,
On 5 Jan 2026, at 14:09, Teddy Astie teddy.astie@vates.tech wrote:
Hello,
I have some questions / feedback on the Xen side of virtio-msg.
AFAIU virtio-msg defines a protocol in order to deal with discovery (optional) and configuration of the PV devices. But things are undefined regarding what is a "memory address".
In Xen memory model with grants, each guest has its own memory space. The frontend shares memory pages with the backend through grants pages identified by grant references.
So in a design based on grants, virtio addresses can't (or at least shouldn't) be guest physical address; but needs to be something derived on grants. A earlier design [1] was forging a address with the grant reference, but I feel it's not great, as it forces "map+unmap" cycles for temporary buffers thus has the same performance problem as Xen PV drivers (without persistent grants) where map+unmap cycles is a performance problem.
And would make the address space very fragmented and in often limited to 4KB buffers.
One idea that is already used by Xen displif (PV Display) is to have a "gref directory" and describe the address space on that. The gref directory is roughly a array of grant references (shared pages infos) that could describe a address space starting at 0, where each page is defined by a grant reference of the directory. That way, the backend can freely keep all or a part or the address space persistently mapped (or eventually map it all at once); and the address space is also contiguous which would help with >4KB buffers.
Any thoughts ?
I think those problematics can be solved using a gref system by the Xen virtio-msg bus driver. We do something equivalent to define a "bus address" in the virtio-msg over FF-A specification and in any case a Xen based bus will have to exchange information between the backend and the frontend in addition to what is exchanged with the messages defined by Virtio message. We do the same for the FF-A bus to detect devices or exchange information on shared area. In the xen case sharing will be for sure based on grant tables and a gref directory could be created in a page of memory shared between both sides to optimize things.
On Xen, a "grant directory" could be either a way to describe a large shared area. But that doesn't really answer whether the grant reference number or something else describes what would be a "bus address" in Xen.
Do you think such principles would need more definition in the Virtio Message specification or perhaps more guidance on what could be done on those aspects by the bus ?
Here is a link to the current virtio message over FF-A specification
if you want to have a look first:
https://documentation-service.arm.com/static/68f647791134f773ab3f0a7c
Happy to discuss further or answer your questions if you have any.
One of the issues I have in mind and that we encounter in current Xen PV devices is that some shared buffers are often short-lived, and a lot of time is taken in mapping and unmapping those buffers.
For instance, if the frontend passes a new bus address for some grant, the backend would need to explicitly map it; unless it has already been mapped.
One solution is to reuse the buffers, but it wants to be structured. The virtio-msg FF-A appears to define explicit share/unshare operations. I guess the frontend is expected to not abuse it and to try to reuse already shared bus addresses if possible (i.e avoid short-lived buffers) ?
Regards Bertrand
[1] https://static.sched.com/hosted_files/xen2021/bf/Thursday_2021-Xen-Summit-vi...
-- Teddy Astie | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech
Virtio-msg mailing list -- virtio-msg@lists.linaro.org To unsubscribe send an email to virtio-msg-leave@lists.linaro.org
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Virtio-msg mailing list -- virtio-msg@lists.linaro.org To unsubscribe send an email to virtio-msg-leave@lists.linaro.org
-- Teddy Astie | Vates XCP-ng Developer
XCP-ng & Xen Orchestra - Vates solutions
web: https://vates.tech