[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v1 00/15] Xen PV backend support for KVM/Xen guests
From: |
Joao Martins |
Subject: |
Re: [RFC PATCH v1 00/15] Xen PV backend support for KVM/Xen guests |
Date: |
Tue, 10 Jan 2023 15:43:36 +0000 |
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 (?)
- [RFC PATCH v1 15/15] i386/xen: Initialize XenBus and legacy backends from pc_init1(), (continued)
- [RFC PATCH v1 15/15] i386/xen: Initialize XenBus and legacy backends from pc_init1(), David Woodhouse, 2023/01/10
- [RFC PATCH v1 14/15] hw/xen: Remove old version of Xen headers, David Woodhouse, 2023/01/10
- [RFC PATCH v1 12/15] hw/xen: Add backend implementation of grant table operations, David Woodhouse, 2023/01/10
- [RFC PATCH v1 04/15] hw/xen: Pass grant ref to gnttab unmap, David Woodhouse, 2023/01/10
- [RFC PATCH v1 13/15] hw/xen: Implement soft reset for emulated gnttab, David Woodhouse, 2023/01/10
- [RFC PATCH v1 07/15] hw/xen: Move xenstore_store_pv_console_info to xen_console.c, David Woodhouse, 2023/01/10
- [RFC PATCH v1 03/15] hw/xen: Add gnttab operations to allow redirection to internal emulation, David Woodhouse, 2023/01/10
- [RFC PATCH v1 06/15] hw/xen: Add xenstore operations to allow redirection to internal emulation, David Woodhouse, 2023/01/10
- [RFC PATCH v1 01/15] hw/xen: Add evtchn operations to allow redirection to internal emulation, David Woodhouse, 2023/01/10
- [RFC PATCH v1 02/15] hw/xen: Add emulated evtchn ops, David Woodhouse, 2023/01/10
- Re: [RFC PATCH v1 00/15] Xen PV backend support for KVM/Xen guests,
Joao Martins <=