[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Attachment: signature.asc
Description: OpenPGP digital signature

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.