Re: [PATCH v2 26/27] accel/mshv: Workaround for overlappig mem mappings

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

Hi Magnus,

On 1/7/25 19:28, Magnus Kulke wrote:
> QEMU maps certain regions into the guest multiple times, as seen in the
> trace below. Currently the MSHV kernel driver will reject those
> mappings. To workaround this, a record is kept (a static global list of
> "slots", inspired by what the HVF accelerator has implemented). An
> overlapping region is not registered at the hypervisor, and marked as
> mapped=false. If there is an UNMAPPED_GPA exit, we can look for a slot
> that is unmapped and would cover the GPA. In this case we map out the
> conflicting slot and map in the requested region.
> 
> mshv_set_phys_mem       add=1 name=pc.bios
> mshv_map_memory      => u_a=7ffff4e00000 gpa=00fffc0000 size=00040000
> mshv_set_phys_mem       add=1 name=ioapic
> mshv_set_phys_mem       add=1 name=hpet
> mshv_set_phys_mem       add=0 name=pc.ram
> mshv_unmap_memory       u_a=7fff67e00000 gpa=0000000000 size=80000000
> mshv_set_phys_mem       add=1 name=pc.ram
> mshv_map_memory         u_a=7fff67e00000 gpa=0000000000 size=000c0000
> mshv_set_phys_mem       add=1 name=pc.rom
> mshv_map_memory         u_a=7ffff4c00000 gpa=00000c0000 size=00020000
> mshv_set_phys_mem       add=1 name=pc.bios
> mshv_remap_attempt   => u_a=7ffff4e20000 gpa=00000e0000 size=00020000
> 
> Signed-off-by: Magnus Kulke <magnuskulke@linux.microsoft.com>
> ---
>   accel/mshv/mem.c            | 264 ++++++++++++++++++++++++++++++++----
>   accel/mshv/trace-events     |   7 +-
>   include/system/mshv.h       |  16 ++-
>   target/i386/mshv/mshv-cpu.c |  43 ++++++
>   4 files changed, 295 insertions(+), 35 deletions(-)
> 
> diff --git a/accel/mshv/mem.c b/accel/mshv/mem.c
> index 6d7a726898..0ffe379601 100644
> --- a/accel/mshv/mem.c
> +++ b/accel/mshv/mem.c
> @@ -20,44 +20,167 @@
>   #include <sys/ioctl.h>
>   #include "trace.h"
>   
> +MshvMemorySlot mem_slots[MSHV_MAX_MEM_SLOTS];

Ideally this should be in MshvState. Just a comment, not asking for
changes... yet ;).