Re: [PATCH] x86/AMD: make HT range dynamic for Fam17 and up

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.06.2021 18:32, Andrew Cooper wrote:
> 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.cooper3@xxxxxxxxxx>
> 
> Really, this ought to be reported by Igor.  He did all the hard work.

Sure, changed.

>> --- 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.

Which means we may need to split the variable into paddr_bits
(calculated as above) and gaddr_bits (left at what paddr_bits has
been so far). However, isn't that what hap_paddr_bits is already
for, while for shadow mode it still needs to be the "adjusted" way?
We'd then simply not fall back to the "adjusted" paddr_bits, but to
the original one.

Another aspect I was wondering about is whether

                if (paddr_bits > PADDR_BITS)
                        paddr_bits = PADDR_BITS;

should apply before or after subtracting the value from
80000008.EBX. I was first inclined to make it the more relaxed
way (applying before reduction), but then thought I'd first leave
it as is now, on the basis that the PTE layout doesn't change, and
hence 52 remains the limit for the full address.

Jan