This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] RE: [PATCH v2] Enable SMEP CPU feature support for XEN hyper

To: Keir Fraser <keir.xen@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH v2] Enable SMEP CPU feature support for XEN hypervisor
From: "Li, Xin" <xin.li@xxxxxxxxx>
Date: Sun, 5 Jun 2011 23:43:58 +0800
Accept-language: zh-CN, en-US
Acceptlanguage: zh-CN, en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 05 Jun 2011 08:44:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA115AE9.1B9FF%keir.xen@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <FC2FB65B4D919844ADE4BE3C2BB739AD5AB9EE16@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CA115AE9.1B9FF%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcwjU0w8vlsr1zIxRuCnN1Lck9yOlQAB+c7AAA3egwgAAKz9kA==
Thread-topic: [PATCH v2] Enable SMEP CPU feature support for XEN hypervisor
> > That needs
> > 1) inject SMEP faults back to the 32-bit pv guest.
> > 2) let the guest see SMEP thru CPUID and config it in CR4 (actually it's
> > already set, but just to let guest see it).
> >
> > Anything else?
> I thought about this myself and realised that we can't let PV guests control
> this feature if we want Xen to benefit from it. There's little point in a
> feature to protect Xen from guests, if an untrusted guest can turn it off!
> Hence I think we probably have to leave the feature always on for PV guests.
> Unless we find some guests are incompatible with that.

As we talked, 64-bit pv kernel can't trigger SMEP faults. So we decided to not
let it see this feature.

Maybe it's okay to inject SMEP faults which are triggered from 32-bit pv
kernel back to it even the guest is not aware of SMEP.
We can refer to Linux SMEP patch, which just turns this feature on without
touching any page table handling functions as SMEP handling actually can
reuse NX handling code path. Ingo wanted to expose SMEP to KVM guest
silently, but it is not architecturally right as it's required to flush TLB when
CR4.SMEP is changed, or a kernel page is changed to user page. But luckily
Linux doesn't have such cases thus doesn't need to flush TLB.


Xen-devel mailing list