From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752428AbbKPUWp (ORCPT ); Mon, 16 Nov 2015 15:22:45 -0500 Received: from mail.skyhub.de ([78.46.96.112]:48870 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751811AbbKPUWn (ORCPT ); Mon, 16 Nov 2015 15:22:43 -0500 Date: Mon, 16 Nov 2015 21:22:33 +0100 From: Borislav Petkov To: Andy Lutomirski , "H. Peter Anvin" Cc: Boris Ostrovsky , "linux-kernel@vger.kernel.org" , xen-devel , David Vrabel , Konrad Rzeszutek Wilk Subject: Re: [PATCH] xen/x86: Adjust stack pointer in xen_sysexit Message-ID: <20151116202232.GC20137@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 16, 2015 at 12:11:11PM -0800, Andy Lutomirski wrote: > 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. Huh, so what's wrong with a jump: jmp 1f swapgs 1: > 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 That doesn't matter - I just don't want to open the flood gates on pseudo feature bits. hpa, what do you think? > 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. I just reacted to Boris' statement: "We don't currently have a Xen-specific CPU feature. We could, in principle, add it but we can't replace all of current paravirt patching with a single feature since PVH guests use a subset of existing pv ops (and in the future it may become even more fine-grained)." -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.