Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2993992AbbEEQGv (ORCPT ); Tue, 5 May 2015 12:06:51 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:37731 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993168AbbEEOYA (ORCPT ); Tue, 5 May 2015 10:24:00 -0400 Message-ID: <5548D1E8.4050609@oracle.com> Date: Tue, 05 May 2015 10:21:28 -0400 From: Boris Ostrovsky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Andy Lutomirski 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 Subject: Re: [PATCH v2] hypervisor/x86/xen: Unset X86_BUG_SYSRET_SS_ATTRS on Xen PV guests References: <1430751735-5471-1-git-send-email-boris.ostrovsky@oracle.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2267 Lines: 55 On 05/05/2015 09:51 AM, Andy Lutomirski wrote: > 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? No, this is meant for "true" PV guest not to go through HVM-specific initialization. We have to do it since now x86_hyper_xen_hvm (renamed to x86_hyper_xen) will have init_platform() op and so init_hypervisor_platform() will call it obviously without knowing the type of the guest. > >> +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. HVM guests execute SYSRET and they will continue having X86_BUG_SYSRET_SS_ATTRS flag on. PV guests OTOH don't do SYSRET, the hypervisor does (which is why if this issue is to be fixed it would have to be done in the hypervisor). -boris -- 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/