[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DD23CB6.3050503@redhat.com>
Date: Tue, 17 May 2011 12:15:34 +0300
From: Avi Kivity <avi@...hat.com>
To: Ingo Molnar <mingo@...e.hu>
CC: "H. Peter Anvin" <hpa@...or.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Asit K Mallick <asit.k.mallick@...el.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: [PATCH v2 0/4] Enable SMEP CPU Feature
On 05/17/2011 10:05 AM, Ingo Molnar wrote:
> * H. Peter Anvin<hpa@...or.com> wrote:
>
> > On 05/16/2011 02:34 PM, Fenghua Yu wrote:
> > >
> > > Note: This patch set doesn't enable the SMEP feature in KVM. If it's needed,
> > > another patch will be pushed for enabling the feature in KVM.
> > >
> >
> > Hi Avi,
> >
> > Could you comment on if this needs to be a gating factor?
It should certainly not be a gating factor. Note that smep will be
disabled when switching to the guest, so there are no compatibility issues.
> I think KVM would benefit from the native kernel playing guinea pig whether
> SMEP is really, truly 100% trouble-free to enable by default (for Linux) ;-)
>
> Some programmable configurability seems necessary on the KVM side, as KVM has
> no control over how sane the guest kernel is.
We should simply expose the cpuid bit and cr4.smep. If the guest kernel
feels it is up to it, it can enable smep itself.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists