From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 7/8] xen/x86: Rework CR4 handling for PV guests Date: Fri, 26 Jun 2015 09:50:05 +0100 Message-ID: <558D2E5D020000780008A0FF@mail.emea.novell.com> References: <1435163500-10589-1-git-send-email-andrew.cooper3@citrix.com> <1435163500-10589-8-git-send-email-andrew.cooper3@citrix.com> <558C2F3E0200007800089BA9@mail.emea.novell.com> <558C2AB2.1070001@citrix.com> <558D0BBD0200007800089FAC@mail.emea.novell.com> <558D08FE.8010402@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <558D08FE.8010402@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 26.06.15 at 10:10, wrote: > On 26/06/2015 07:22, Jan Beulich wrote: >>>>> On 25.06.15 at 18:22, wrote: >>> After recent consideration, I am still not sure if we want to support >>> SMAP in 32bit PV guests or not. The trapping of stac/clac would be a >>> high overhead, although the guest could modify EFLAGS.AC itself using popf. >> If it technically works (which it looks like it does) I see no reason >> leaving the decision to guests. > > True. For now, I will leave SMAP/SMEP unexposed and leave the CPUID > side of things to my levelling work. In which case there's no point assuming an "aware" guest - with the CPUID flag unexposed, writes to CR4.SMAP are simply invalid. Jan