Re: [Xen-devel] Xen HVM regression on certain Intel CPUs

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

On 28.03.2013 16:02, Stefan Bader wrote:
> On 28.03.2013 14:34, Jan Beulich wrote:
>>>>> On 27.03.13 at 18:23, "H. Peter Anvin" <hpa@xxxxxxxxx> wrote:
>>> On 03/27/2013 10:17 AM, Stefan Bader wrote:
>>>>> What does x86info and /proc/cpuinfo show in HVM?
>>>>
>>>> x86info cpuid[7].ebx = 0xbbb and /proc/cpuinfo also shows smep
>>>> set.
>>>
>>> On all CPUs?
>>>
>>>>> The inbound %cr4 shouldn't matter at all, we try to not rely on
>>>>> it.
>>>>>
>>>>> If the hypervisor presents SMEP to the guest then the guest is
>>>>> pretty obviously going to try to use it.
>>>>
>>>> To me it looks like when bootstrapping the APs things are not yet
>>>> ready to use it. If I did not miss something, the only place that
>>>> the saved contents of cr4 are used is in startup_32 when the cpus
>>>> are brought up. And then just stop dead. Would need to read more
>>>> code but a bit weird why the BP is not affected.
>>>
>>> This feels like a bug in Xen, but I don't know for sure yet.  Either
>>> which way, it is odd.  That write to cr4 should be entirely legitimate.
>>
>> And I would guess one that got fixed already.
>>
>> Stefan, please try 4.2.2-rc1, or (separately)
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=485f374230d39e153d7b9786e3d0336bd52ee661
>> (which I think requires the immediately preceding
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=1e6275a95d3e35a72939b588f422bb761ba82f6b
>> too).
> 
> The backing explanation does make a lot of sense in reasoning what is going
> wrong. Unfortunately the two patches above on their own do not fix the problem
> (I will try to make another go with 4.2.2-rc1).

The whole of 4.2.2-rc1 has the same (smep still present in
trampoline_cr4_features) outcome.
> 
> For a bit more info I am running a kernel inside the HVM guest which shows the
> contents of the cr4 shadow used in the trampoline. Out of interest I compared
> those values to the ones used on a bare metal boot and both are identical
> (0x1407F0).
> 
> That somehow gives some explanation for the patch above failing. Looking at 
> the
> code for cr4 updates in vmx_update_guest_cr() a few lines above the new SMEP
> handling, there already was code which would clear the PAE flag when
> paging_mode_hap(v->domain) was true. And that would need to be true if the 
> SMEP
> flag should get cleared. And the PAE flag was (and has to be) set before.
> 

> Will be looking into this further.
Going back to gather more info and to find some fix.

-Stefan

Attachment: signature.asc
Description: OpenPGP digital signature

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