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

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

On 27.03.2013 21:24, Keir Fraser wrote:
> On 27/03/2013 16:45, "Stefan Bader" <stefan.bader@xxxxxxxxxxxxx> 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 

- 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@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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