On 10/01/2023 12:37, David Woodhouse wrote: > Some parts of it are relatively straightforward; others less so. In > particular, it looks really hard to provide a contiguous virtual mapping > of multiple potentially discontiguous pages granted by the guest. To > fix that we might actually need the guest memory blocks to be backed > by real files (perhaps deleted or shmem) in order that they can be mapped > again in at a different virtual address.
I wonder if we really need to go to that extent. As far as Qemu emulated-Xen is concerned, gref is mostly a different lookup mechanism a GPA i.e. an index on a table (that the VMM knows about) that references a GPA. Perhaps if it's simpler to teach the backends to deal with discontiguous grefs (if there's such a case today even). The only user of multi-gref mapping is the block xen driver ... and only for mapping the shared ring if I understood correctly. But even there you could probably twist it... considering that the multi-gref ring is contiguous is guest address space, thus the gref -> HVA conversion ius contiguous too (?). So that way you could still return a single HVA (provided that map-grant implementation validates the backing frame contiguosity). > So for now we'll limit the > back ends to mapping a single grant ref at a time. > Which is not a practical limitation right now. One grant ref is actually fine for the everything else that is not the block shared-ring. Xen devices in Qemu seem to be using the legacy backend interface, and thus (un)mapping one grant at a time, or otherwise copying grefs. > https://git.infradead.org/users/dwmw2/qemu.git/shortlog/refs/heads/xenfv-kvm-backends-1 > Cool stuff! A lot better than the RFC redirection layer > David Woodhouse (14): > hw/xen: Remove old version of Xen headers This patch looks more appropriate to your earlier v6 (?)
