[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120530223334.GB28417@andromeda.dapyr.net>
Date: Wed, 30 May 2012 18:33:34 -0400
From: Konrad Rzeszutek Wilk <konrad@...nok.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Borislav Petkov <bp@...en8.de>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Jacob Shin <jacob.shin@....com>,
Andre Przywara <andre.przywara@....com>, jeremy@...p.org,
xen-devel@...ts.xensource.com, linux-kernel@...r.kernel.org,
Jan Beulich <JBeulich@...e.com>, mingo@...e.hu,
tglx@...utronix.de
Subject: Re: [Xen-devel] [PATCH] x86/amd: fix crash as Xen Dom0 on AMD Trinity systems
> > 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,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists