> On 13. Jan 2026, at 16:37, Magnus Kulke <[email protected]>
> wrote:
>
> This change removes userland code that worked around a restriction
> in the mshv driver in the 6.18 kernel: regions from userland
> couldn't be mapped to multiple regions in the kernel. We maintained a
> shadow mapping table in qemu and used a heuristic to swap in a requested
> region in case of UNMAPPED_GPA exits.
>
> However, this heuristic wasn't reliable in all cases, since HyperV
> behaviour is not 100% reliable across versions. HyperV itself doesn't
> prohibit to map regions at multiple places into the guest, so the
> restriction has been removed in the mshv driver.
>
> Hence we can remove the remapping code. Effectively this will mandate a
> 6.19 kernel, if the workload attempt to map e.g. BIOS to multiple
> reagions. I still think it's the right call to remove this logic:
>
> - The workaround only seems to work reliably with a certain revision
> of HyperV as a nested hypervisor.
> - We expect Direct Virtualization (L1VH) to be the main platform for
> the mshv accelerator, which also requires a 6.19 kernel
>
> This reverts commit efc4093358511a58846a409b965213aa1bb9f31a.
>
> Signed-off-by: Magnus Kulke <[email protected]>
Tested-by: Mohamed Mediouni <[email protected]>