qemu/hw/i386/kvm/xen_overlay.h

/*
 * QEMU Xen emulation: Shared/overlay pages support
 *
 * Copyright © 2022 Amazon.com, Inc. or its affiliates. All Rights Reserved.
 *
 * Authors: David Woodhouse <dwmw2@infradead.org>
 *
 * This work is licensed under the terms of the GNU GPL, version 2 or later.
 * See the COPYING file in the top-level directory.
 */

#ifndef QEMU_XEN_OVERLAY_H
#define QEMU_XEN_OVERLAY_H

void xen_overlay_create(void);

int xen_overlay_map_shinfo_page(uint64_t gpa);
void *xen_overlay_get_shinfo_ptr(void);

int xen_sync_long_mode(void);
int xen_set_long_mode(bool long_mode);
bool xen_is_long_mode(void);

void xen_overlay_do_map_page(MemoryRegion *page, uint64_t gpa);

#endif /* QEMU_XEN_OVERLAY_H */
hw/xen: Add xen_overlay device for emulating shared xenheap pages For the shared info page and for grant tables, Xen shares its own pages from the "Xen heap" to the guest. The guest requests that a given page from a certain address space (XENMAPSPACE_shared_info, etc.) be mapped to a given GPA using the XENMEM_add_to_physmap hypercall. To support that in qemu when emulating Xen, create a memory region (migratable) and allow it to be mapped as an overlay when requested. Xen theoretically allows the same page to be mapped multiple times into the guest, but that's hard to track and reinstate over migration, so we automatically unmap any previous mapping when creating a new one. This approach has been used in production with.... a non-trivial number of guests expecting true Xen, without any problems yet being noticed. This adds just the shared info page for now. The grant tables will be a larger region, and will need to be overlaid one page at a time. I think that means I need to create separate aliases for each page of the overall grant_frames region, so that they can be mapped individually. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> 2022-12-07 12:19:31 +03:00			`/*`
			`* QEMU Xen emulation: Shared/overlay pages support`
			`*`
			`* Copyright © 2022 Amazon.com, Inc. or its affiliates. All Rights Reserved.`
			`*`
			`* Authors: David Woodhouse <dwmw2@infradead.org>`
			`*`
			`* This work is licensed under the terms of the GNU GPL, version 2 or later.`
			`* See the COPYING file in the top-level directory.`
			`*/`

			`#ifndef QEMU_XEN_OVERLAY_H`
			`#define QEMU_XEN_OVERLAY_H`

			`void xen_overlay_create(void);`

			`int xen_overlay_map_shinfo_page(uint64_t gpa);`
			`void *xen_overlay_get_shinfo_ptr(void);`

i386/xen: manage and save/restore Xen guest long_mode setting Xen will "latch" the guest's 32-bit or 64-bit ("long mode") setting when the guest writes the MSR to fill in the hypercall page, or when the guest sets the event channel callback in HVM_PARAM_CALLBACK_IRQ. KVM handles the former and sets the kernel's long_mode flag accordingly. The latter will be handled in userspace. Keep them in sync by noticing when a hypercall is made in a mode that doesn't match qemu's idea of the guest mode, and resyncing from the kernel. Do that same sync right before serialization too, in case the guest has set the hypercall page but hasn't yet made a system call. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> 2022-12-12 17:03:41 +03:00			`int xen_sync_long_mode(void);`
			`int xen_set_long_mode(bool long_mode);`
			`bool xen_is_long_mode(void);`

hw/xen: Support mapping grant frames Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> 2022-12-16 21:33:49 +03:00			`void xen_overlay_do_map_page(MemoryRegion *page, uint64_t gpa);`

hw/xen: Add xen_overlay device for emulating shared xenheap pages For the shared info page and for grant tables, Xen shares its own pages from the "Xen heap" to the guest. The guest requests that a given page from a certain address space (XENMAPSPACE_shared_info, etc.) be mapped to a given GPA using the XENMEM_add_to_physmap hypercall. To support that in qemu when emulating Xen, create a memory region (migratable) and allow it to be mapped as an overlay when requested. Xen theoretically allows the same page to be mapped multiple times into the guest, but that's hard to track and reinstate over migration, so we automatically unmap any previous mapping when creating a new one. This approach has been used in production with.... a non-trivial number of guests expecting true Xen, without any problems yet being noticed. This adds just the shared info page for now. The grant tables will be a larger region, and will need to be overlaid one page at a time. I think that means I need to create separate aliases for each page of the overall grant_frames region, so that they can be mapped individually. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> 2022-12-07 12:19:31 +03:00			`#endif /* QEMU_XEN_OVERLAY_H */`