Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757717Ab2EaM2H (ORCPT ); Thu, 31 May 2012 08:28:07 -0400 Received: from [213.199.154.144] ([213.199.154.144]:44146 "EHLO db3outboundpool.messaging.microsoft.com" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1754503Ab2EaM1h (ORCPT ); Thu, 31 May 2012 08:27:37 -0400 X-Forefront-Antispam-Report: CIP:163.181.249.109;KIP:(null);UIP:(null);IPV:NLI;H:ausb3twp02.amd.com;RD:none;EFVD:NLI X-SpamScore: -11 X-BigFish: VPS-11(zzbb2dI9371I1432N98dKzz1202hzz8275bhz2dh668h839hd25he5bhf0ah) X-WSS-ID: 0M4VZVZ-02-JHX-02 X-M-MSG: Message-ID: <4FC762F8.902@amd.com> Date: Thu, 31 May 2012 14:24:24 +0200 From: Andre Przywara User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120404 Thunderbird/11.0.1 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk CC: "H. Peter Anvin" , Borislav Petkov , Konrad Rzeszutek Wilk , Jacob Shin , , , , Jan Beulich , , Subject: Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD Trinity systems References: <20120530144851.GA12184@jshin-Toonie> <20120530145005.GI3207@phenom.dumpdata.com> <20120530150334.GA13349@jshin-Toonie> <20120530171754.GA5115@phenom.dumpdata.com> <20120530173247.GC15635@x1.osrc.amd.com> <4FC65D34.1060803@zytor.com> <20120530175150.GE15438@x1.osrc.amd.com> <4FC66037.6020506@zytor.com> <20120530181722.GF15438@x1.osrc.amd.com> <4FC664E1.9050504@zytor.com> <20120530223334.GB28417@andromeda.dapyr.net> In-Reply-To: <20120530223334.GB28417@andromeda.dapyr.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginatorOrg: amd.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2141 Lines: 61 On 05/31/2012 12:33 AM, Konrad Rzeszutek Wilk wrote: >>> Now, someone probably needs to paravirt the *safe_regs variants in case >>> something else decides to use them. I don't know what to do here, do I >>> want more paravirt code in there? No. I guess if this is done carefully >>> and cleanly, then it should be ok but it can't be done like that - it >>> needs to adhere to the current pv_cpu_ops thing which is already there. > > Using the native variant seems the right thing to do. >>> >> >> I thought I was being told that Xen would trap and emulate the >> rdmsr/wrmsr instructions. I guess they don't want to do that for the > > It does. >> handful of performance-sensitive MSRs there are, but those don't use the >> *_regs variants. > > The underlaying issue (as I understand) was that .rdmsr_regs > (and the corresponding write) was NULL and that caused the crash. > This tiny patch should do it: > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c > index 75f33b2..e74df95 100644 > --- a/arch/x86/xen/enlighten.c > +++ b/arch/x86/xen/enlighten.c > @@ -1116,7 +1116,10 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = { > .wbinvd = native_wbinvd, > > .read_msr = native_read_msr_safe, > + .rdmsr_regs = native_rdmsr_safe_regs, > .write_msr = xen_write_msr_safe, > + .wrmsr_regs = native_wrmsr_safe_regs, > + > .read_tsc = native_read_tsc, > .read_pmc = native_read_pmc, > > Acked-by: Andre Przywara This works on the test machine. Though I'd still like to have my original patch applied, because it makes the thing a bit cleaner. And I made a patch to remove the {rd,wr}msr_regs hooks from paravirt_ops completely. Shall I send it out or do you want to make this part of larger patch series to clean up pvops? Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany -- 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/