Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753684AbbDULNb (ORCPT ); Tue, 21 Apr 2015 07:13:31 -0400 Received: from ozlabs.org ([103.22.144.67]:37713 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751688AbbDULN2 (ORCPT ); Tue, 21 Apr 2015 07:13:28 -0400 From: Rusty Russell To: Andy Lutomirski , Andrew Cooper , Xen-devel Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, Konrad Rzeszutek Wilk , Boris Ostrovsky , David Vrabel , lguest@lists.ozlabs.org, X86 ML , Denys Vlasenko Subject: Re: [PATCH] [RFC] x86/cpu: Fix SMAP check in PVOPS environments In-Reply-To: <55359B57.3070008@kernel.org> References: <1429549782-12962-1-git-send-email-andrew.cooper3@citrix.com> <55359B57.3070008@kernel.org> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Tue, 21 Apr 2015 14:37:33 +0930 Message-ID: <877ft6oyqy.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2799 Lines: 66 Andy Lutomirski writes: > On 04/20/2015 10:09 AM, Andrew Cooper wrote: >> There appears to be no formal statement of what pv_irq_ops.save_fl() is >> supposed to return precisely. Native returns the full flags, while lguest and >> Xen only return the Interrupt Flag, and both have comments by the >> implementations stating that only the Interrupt Flag is looked at. This may >> have been true when initially implemented, but no longer is. >> >> To make matters worse, the Xen PVOP leaves the upper bits undefined, making >> the BUG_ON() undefined behaviour. Experimentally, this now trips for 32bit PV >> guests on Broadwell hardware. The BUG_ON() is consistent for an individual >> build, but not consistent for all builds. It has also been a sitting timebomb >> since SMAP support was introduced. >> >> Use native_save_fl() instead, which will obtain an accurate view of the AC >> flag. That should work for lguest. Indeed, it does (in practice those bits are 0). Tested-by: Rusty Russell (lguest) Thanks, Rusty. >> Signed-off-by: Andrew Cooper >> CC: Thomas Gleixner >> CC: Ingo Molnar >> CC: H. Peter Anvin >> CC: x86@kernel.org >> CC: linux-kernel@vger.kernel.org >> CC: Konrad Rzeszutek Wilk >> CC: Boris Ostrovsky >> CC: David Vrabel >> CC: xen-devel >> CC: Rusty Russell >> CC: lguest@lists.ozlabs.org >> >> --- >> This patch is RFC because I am not certain that native_save_fl() is >> necessarily the correct solution on lguest, but it does seem that setup_smap() >> wants to check the actual AC bit, rather than an idealised value. >> >> A different approach, given the dual nature of the AC flag now is to gate >> setup_smap() on a kernel rpl of 0. SMAP necessarily can't be used in a >> paravirtual situation where the kernel runs in cpl > 0. >> >> Another different approach would be to formally state that >> pv_irq_ops.save_fl() needs to return all the flags, which would make >> local_irq_save() safe to use in this circumstance, but that makes a hotpath >> longer for the sake of a single boot time check. > > ...which reminds me: > > Why does native_restore_fl restore anything other than IF? A branch and > sti should be considerably faster than popf. > > Also, if we did this, could Xen use PVI and then use native_restore_fl > and avoid lots of pvops? > > --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/