Re: Xen HVM regression on certain Intel CPUs

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

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

On 27.03.2013 21:24, Keir Fraser wrote:
> On 27/03/2013 16:45, "Stefan Bader" <stefan.bader@canonical.com> wrote:
> 
>>>> Seems that I was relying on the wrong source of information when checking
>>>> SMEP
>>>> support. The cpuid command seems at fail. But /proc/cpuinfo reports it. So
>>>> that
>>>> at least explains where that comes from... sorry for that.
>>>
>>> OK, so if you boot Xen with smep=1 (which disables SMEP, kind of
>>> counterintuive flag)
>>> that would work fine?
>>
>> 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.
> 
> Yes, the flag is understood by all Xen 4.2 releases. However it is not
> inverted as you believe: it really is smep=0 or smep=off or even no-smep to
> disable SMEP. smep=1 will enable SMEP (which is the default anyway).
> 
> I also checked how CPUID.SMEP gets set for an HVM guest, and it is very
> obviously masked off if SMEP support has been disabled or is unavailable. So
> I do not think we can be erroneously passing the CPUID flag to the guest.

No you are completely right. The inverse boolean got me for good. So to summarize:

- smep=0 as hypervisor argument avoids the problem for all guests
- nosmep as hvm guest arguement avoids the problem for that guest
- /proc/cpuinfo correctly reflects whether smep has been masked off or not

> 
>  -- Keir
> 
> 
> 
> _______________________________________________
> 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