Re: [RFC PATCH v1 00/15] Xen PV backend support for KVM/Xen guests

[Joao Martins <joao.m.martins@oracle.com>]

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 (?)