From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 -> ffff82d080222806 Date: Mon, 3 Nov 2014 11:38:26 +0000 Message-ID: <54576932.9030803@citrix.com> References: <54574EA0.5070101@canonical.com> <54575E32.6040603@citrix.com> <545764BB.7080005@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <545764BB.7080005@canonical.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefan Bader , Xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/11/14 11:19, Stefan Bader wrote: > On 03.11.2014 11:51, Andrew Cooper wrote: >> On 03/11/14 09:45, Stefan Bader wrote: >>> I see the message from the subject on my Intel box whenever a guest (iirc even >>> dom0) starts up. It is not fatal and everything seems ok. I am just curious >>> about what might trigger this. The addresses look to be inside the hypervisor >>> code. I was wondering whether there is a simple way to figure out what this >>> relates to (likely need to look at the objdump of the unstripped hv module). >>> >>> Or has someone already looked into this and knows what likely is the cause? >>> >>> -Stefan >> Specifically, the message indicates : faulting address -> >> fixup address >> >> It is probably a wrmsr, and a higher logging level will indicate this. >> My gut feeling is that it is dom0 attempting to load microcode using the >> native method. >> >> ~Andrew >> > The faulting address in my case seems to be rdmsr_save (xen-4.4.1 base), the > fixup address somewhere unspecific in hvm.c (not sure whether that makes sense > coming from a dom0 startup). I will have to re-compile this with the gdprintk > enabled to see which MSR that was. The fixup address lives in the .fixup section which is generally linked elsewhere. See the definition of rdmsr_safe() which does section-jumping in the asm statement. > > rdmsr_normal: > /* Everyone can read the MSR space. */ > /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n", > _p(regs->ecx));*/ > if ( rdmsr_safe(regs->ecx, msr_content) ) > goto fail; > > Though likely related to the following WRMSRs following (the addresses differ > from the subject I wasn't sure from where exactly I took the others and these > are with 4.4.1 and directly after boot): These will most likely be in wrmsr_safe() > > (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685 > (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685 > (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685 > (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685 > (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x004281c2001 > a8168 to 0x004281c200148168. > (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x004281c2001 > a8168 to 0x004281c2001a0168. > (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x004281c2001 > a8168 to 0x004201c2001a8168. > (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685 > (XEN) traps.c:2514:d0 Domain attempted WRMSR 00000000000001b2 from 0x00000000000 > 00000 to 0x0000000000009600. > > The 0x1b2 seems to be thermal interrupt control. Cannot find the 0x610 right now > (need to refresh my docs)... > MSR 0x610 is MSR_PKG_POWER_LIMIT on SandyBridge and later. ~Andrew