Re: [Xen-devel] [PATCH 3/7] x86/pagewalk: Helpers for reserved bit handling

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/03/17 15:09, Tim Deegan wrote:
> At 14:17 +0000 on 02 Mar (1488464221), Andrew Cooper wrote:
>> On 02/03/17 14:12, Tim Deegan wrote:
>>> At 14:03 +0000 on 27 Feb (1488204194), Andrew Cooper wrote:
>>>> +static inline bool guest_has_pse36(const struct vcpu *v)
>>>> +{
>>>> +     /* No support for 2-level PV guests. */
>>>> +    return is_pv_vcpu(v) ? 0 : paging_mode_hap(v->domain);
>>>> +}
>>> Should this check the CPUID policy to see whether PSE36 is supported?
>>> There's no way to disable it in a HAP guest anyway, so maybe not, for
>>> consistency?
>> Hmm - perhaps I need to rethink this slightly.
>>
>> CR4.PSE controls this part of the pagewalk, which we can control with
>> CPUID checks.  However, if CR4.PSE it set, we cannot hide hardware’s
>> preference of PSE36 from the guest, and in reality it will always be
>> present.
> Yeah, I don't think there's anything you can do here.  You can hide
> PSE36 from CPUID but a guest that _relies_ on PSE36 _not_ being supported
> is going to fail on HAP.
>
> I guess you could force PSE36 to be present in CPUID for HAP guetsts
> and absent for PV and shadowed geuests...

We do this anyway, modulo the fudge factor to make HyperV not BSOD on
boot (which it turns out is now XTF's backdoor way to evaluate whether
it is running on HAP or Shadow, so it can avoid the livelock referenced
in patch 2.)

> In any case I thin this patch is correct as far as it goes.

I am going to litter some more comments throughout, because some of
these details are far too subtle to be left unexplained.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel