Re: Xen HVM regression on certain Intel CPUs

[Stefan Bader <stefan.bader@canonical.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1532 bytes --]

On 27.03.2013 17:52, H. Peter Anvin wrote:
> On 03/27/2013 09:45 AM, Stefan Bader wrote:
>>
>> Rebooting with smep=1 as a hv argument does not fix it. But I
>> would be careful since I just quickly did this without checking
>> whether Xen 4.2.1 undestands the flag already.
>>
>> Second using x86info --all on bare metal does show bits set for 
>> cpuid[7] and /proc/cpuinfo values are consistent across BP and
>> APs. So I am a tool for using the wrong tool there.
>>
>> So I would say the main issue to look at is why reading cr4 as a 
>> HVM guest produces the flags on boot. Surely the hypervisor itself 
>> has set certain things up but likely there are some epxectations 
>> about the initial setup on boot.
>>
> 
> What does x86info and /proc/cpuinfo show in HVM?

x86info cpuid[7].ebx = 0xbbb and /proc/cpuinfo also shows smep set.

> 
> 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.
> 
> 	-hpa
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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