Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2992669AbbEENvb (ORCPT ); Tue, 5 May 2015 09:51:31 -0400 Received: from mail-la0-f54.google.com ([209.85.215.54]:35963 "EHLO mail-la0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2992628AbbEENva (ORCPT ); Tue, 5 May 2015 09:51:30 -0400 MIME-Version: 1.0 In-Reply-To: <1430751735-5471-1-git-send-email-boris.ostrovsky@oracle.com> References: <1430751735-5471-1-git-send-email-boris.ostrovsky@oracle.com> From: Andy Lutomirski Date: Tue, 5 May 2015 06:51:08 -0700 Message-ID: Subject: Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests To: Boris Ostrovsky Cc: Konrad Rzeszutek Wilk , David Vrabel , "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xenproject.org" , linux@eikelenboom.it 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: 1657 Lines: 44 On Mon, May 4, 2015 at 8:02 AM, Boris Ostrovsky wrote: > Commit 61f01dd941ba ("x86_64, asm: Work around AMD SYSRET SS descriptor > attribute issue") makes AMD processors set SS to __KERNEL_DS in > __switch_to() to deal with cases when SS is NULL. > > This breaks Xen PV guests who do not want to load SS with__KERNEL_DS. > > Since the problem that the commit is trying to address would have to be > fixed in the hypervisor (if it in fact exists under Xen) there is no > reason to set X86_BUG_SYSRET_SS_ATTRS flag for PV VPCUs here. > > This can be easily achieved by adding x86_hyper_xen_hvm.set_cpu_features > op which will clear this flag. (And since this structure is no longer > HVM-specific we should do some renaming). Looks good to me, but: > static void __init xen_hvm_guest_init(void) > { > + if (xen_pv_domain()) > + return; > + How can a platform be "hvm" and "pv"? Is that the PVHVM thing? > +static void xen_set_cpu_features(struct cpuinfo_x86 *c) > +{ > + if (xen_pv_domain()) > + clear_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS); > +} I haven't followed all the twists and turns, but, if the guest platform is such that the guest kernel is really executing SYSRET and we're on AMD, then we have the sysret_ss_attrs bug. If PVHVM has xen_pv_domain() returning true but also uses SYSRET for real, then this looks wrong. --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/