On Mon, Jun 28, 2021 at 01:48:53PM +0200, 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: Igor Druzhinin <[email protected]>
> Signed-off-by: Jan Beulich <[email protected]>
Reviewed-by: Roger Pau Monné <[email protected]>
> ---
> v2: Move adjustment last, to leave hap_paddr_bits unaffected. Add
> comment.
>
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -349,16 +349,23 @@ 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;
> if (paddr_bits > PADDR_BITS)
> paddr_bits = PADDR_BITS;
> +
> vaddr_bits = (eax >> 8) & 0xff;
> if (vaddr_bits > VADDR_BITS)
> vaddr_bits = VADDR_BITS;
> +
> hap_paddr_bits = ((eax >> 16) & 0xff) ?: paddr_bits;
> if (hap_paddr_bits > PADDR_BITS)
> hap_paddr_bits = PADDR_BITS;
> +
> + /* Account for SME's physical address space reduction. */
> + paddr_bits -= (ebx >> 6) & 0x3f;
Does it make sense to check for 0x8000001f[eax] bit 0 in order to
assert that there's support for SME, or assuming that the reduction is
!= 0 in the other cpuid leaf is enough.
It's possible for firmware vendors to disable advertising the SME
support bit and leave the physical address space reduction one in
place?
Thanks, Roger.
