Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752281AbbKPULd (ORCPT ); Mon, 16 Nov 2015 15:11:33 -0500 Received: from mail-oi0-f48.google.com ([209.85.218.48]:33696 "EHLO mail-oi0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751543AbbKPULc (ORCPT ); Mon, 16 Nov 2015 15:11:32 -0500 MIME-Version: 1.0 In-Reply-To: <20151116195906.GB20137@pd.tnic> References: <1447456706-24347-1-git-send-email-boris.ostrovsky@oracle.com> <56468D24.8030801@oracle.com> <564A0371.2040104@oracle.com> <20151116195906.GB20137@pd.tnic> From: Andy Lutomirski Date: Mon, 16 Nov 2015 12:11:11 -0800 Message-ID: Subject: Re: [PATCH] xen/x86: Adjust stack pointer in xen_sysexit To: Borislav Petkov Cc: Boris Ostrovsky , "linux-kernel@vger.kernel.org" , xen-devel , David Vrabel , Konrad Rzeszutek Wilk Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2151 Lines: 54 On Mon, Nov 16, 2015 at 11:59 AM, Borislav Petkov wrote: > On Mon, Nov 16, 2015 at 11:03:22AM -0800, Andy Lutomirski wrote: > >> ... >> The reader surely doesn't remember that this isn't guaranteed to be a >> swapgs instruction on native. Using: >> >> ALTERNATIVE "swapgs" "" X86_FEATURE_XENPV >> >> would be safer (it would get rid of the SWAPGS_UNSAFE_STACK mess) and >> much clearer. We could hide *that* behind a macro and no one would be >> confused. (Well, they'd be confused by the fact that Xen PV handles >> gsbase very differently from native, but that has nothing to do with >> the macro.) >> >> I think we could convert piecemeal, and I wonder if this new patch for >> 32-bit native on 4.4 (this is needed for 4.4, right?) would be a good >> starting point. Borislav, what do you think? Would you be okay with >> adding a Xen PV pseudofeature? > > AFAICT, I'd prefer this becomes rather a jump label which gets enabled > on xen. Especially if a single pseudofeature might not be enough, > apprently... Except it's not a jump. (Also, the alternatives infrastructure is IMO much nicer than the jump label infrastructure.) Taking SWAPGS as an example, the semantics we need are: - On native, do swapgs. This *can't* be a call due to RSP issues. - On Xen PV, swapgs will work, but it's emulated. We'd rather just nop it out. In principle, we could static jump over it on Xen, but that also involves forcing the jump label to be built on old GCC versions, which PeterZ objected to the last time I asked. If it would make you feel better, it could be X86_BUG_XENPV :-p Are there really multiple feature bits for this stuff? I'd like to imagine that the entry code is all either Xen PV or native/PVH/PVHVM -- i.e. I assumed that PVH works like native for all entries. --Andy tip #101: Trim your mails when you reply. -- Andy Lutomirski AMA Capital Management, LLC -- 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/