All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keir Fraser <keir.xen@gmail.com>
To: "Li, Xin" <xin.li@intel.com>, Jan Beulich <JBeulich@novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH v2] Enable SMEP CPU feature support for XEN hypervisor
Date: Sun, 05 Jun 2011 16:10:17 +0100	[thread overview]
Message-ID: <CA115AE9.1B9FF%keir.xen@gmail.com> (raw)
In-Reply-To: <FC2FB65B4D919844ADE4BE3C2BB739AD5AB9EE16@shsmsx501.ccr.corp.intel.com>

On 05/06/2011 09:39, "Li, Xin" <xin.li@intel.com> wrote:

>> I mean, I know we may as well just hide the feature from PV 64b guests
>> totally. That's obvious. Let's stop talking about PV 64b guests already! The
>> question is: what to do about PV 32b guests?
> 
>> Quite obviously we ought to allow 32-bit pv guests to control this for
>> themselves (and hence see the feature).
> 
> 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.

 -- Keir

>> Besides that, assuming Xin verified it's working, your latest patch
>> looks great to me.
> 
> Yeah, verified, the system crashed from a SMEP fault from 64-bit pv kernel.
> Thanks!
> -Xin

  reply	other threads:[~2011-06-05 15:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-05  7:36 [PATCH v2] Enable SMEP CPU feature support for XEN hypervisor Jan Beulich
2011-06-05  8:39 ` Li, Xin
2011-06-05 15:10   ` Keir Fraser [this message]
2011-06-05 15:43     ` Li, Xin
2011-06-05 17:04       ` Keir Fraser
  -- strict thread matches above, loose matches on Subject: below --
2011-06-03 14:36 Jan Beulich
2011-06-03 16:18 ` Li, Xin
2011-06-03 17:09   ` Li, Xin
2011-06-03 13:57 Li, Xin
2011-06-03 17:23 ` Keir Fraser
2011-06-03 18:49   ` Li, Xin
2011-06-03 19:22     ` Keir Fraser
2011-06-03 19:37       ` Li, Xin
2011-06-03 20:15         ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA115AE9.1B9FF%keir.xen@gmail.com \
    --to=keir.xen@gmail.com \
    --cc=JBeulich@novell.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xin.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.