On 18/06/2021 17:00, Jan Beulich wrote:
> At the time of d838ac2539cf ("x86: don't allow Dom0 access to the HT
> address range") documentation correctly stated that the range was
> completely fixed. For Fam17 and newer, it lives at the top of physical
> address space, though.
>
> To correctly determine the top of physical address space, we need to
> account for their physical address reduction, hence the calculation of
> paddr_bits also gets adjusted.
>
> While for paddr_bits < 40 the HT range is completely hidden, there's no
> need to suppress the range insertion in that case: It'll just have no
> real meaning.
>
> Reported-by: Andrew Cooper <andrew.coop...@citrix.com>
Really, this ought to be reported by Igor. He did all the hard work.
Also, I'd like to get something more formal out of AMD if possible.
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -349,13 +349,17 @@ void __init early_cpu_init(void)
>
> eax = cpuid_eax(0x80000000);
> if ((eax >> 16) == 0x8000 && eax >= 0x80000008) {
> + ebx = eax >= 0x8000001f ? cpuid_ebx(0x8000001f) : 0;
> eax = cpuid_eax(0x80000008);
> - paddr_bits = eax & 0xff;
> +
> + paddr_bits = (eax & 0xff) - ((ebx >> 6) & 0x3f);
While I can see the attraction of editing paddr_bits, I think it will
break the emulated pagewalk (at least).
With SME active, the address space reduction is only physical addresses
only, not guest physical. An HVM guest still needs to see the original
paddr_bits, and the emulated pagewalk needs to use this for reserved bit
calculations.
i.e. under NPT, you can still have a working 2^48 guest physical address
space despite the host physical address space is limited to 2^43 by
encryption being active.
~Andrew
