From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 -> ffff82d080222806 Date: Mon, 03 Nov 2014 13:50:03 +0100 Message-ID: <545779FB.7060602@canonical.com> References: <54574EA0.5070101@canonical.com> <54575E32.6040603@citrix.com> <545764BB.7080005@canonical.com> <54576932.9030803@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5146011419674642202==" Return-path: In-Reply-To: <54576932.9030803@citrix.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: Andrew Cooper , Xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============5146011419674642202== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="L8kKQa9TP3MWoCC0kccNHPM3NH9EGtr1N" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L8kKQa9TP3MWoCC0kccNHPM3NH9EGtr1N Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03.11.2014 12:38, Andrew Cooper wrote: > 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 h= ypervisor >>>> code. I was wondering whether there is a simple way to figure out wh= at 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= =2E=20 >>> 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 mak= es sense >> coming from a dom0 startup). I will have to re-compile this with the g= dprintk >> enabled to see which MSR that was. >=20 > 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. >=20 >> >> 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 an= d these >> are with 4.4.1 and directly after boot): >=20 > These will most likely be in wrmsr_safe() >=20 >> >> (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 0x0= 04281c2001 >> a8168 to 0x004281c200148168. >> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0= 04281c2001 >> a8168 to 0x004281c2001a0168. >> (XEN) traps.c:2514:d0 Domain attempted WRMSR 0000000000000610 from 0x0= 04281c2001 >> a8168 to 0x004201c2001a8168. >> (XEN) traps.c:3071: GPF (0000): ffff82d08018ef10 -> ffff82d080222685 >> (XEN) traps.c:2514:d0 Domain attempted WRMSR 00000000000001b2 from 0x0= 0000000000 >> 00000 to 0x0000000000009600. >> >> The 0x1b2 seems to be thermal interrupt control. Cannot find the 0x610= right now >> (need to refresh my docs)... >> >=20 > MSR 0x610 is MSR_PKG_POWER_LIMIT on SandyBridge and later. >=20 After enabling the output for REDMSR as well it looks like the GPF messag= e is associated with RDMSR 0x61c (MSR_DRAM_POWER_INFO). (XEN) traps.c:2606:d0 Domain attempted RDMSR 000000000000061c. (XEN) traps.c:3071: GPF (0000): ffff82d08018ef37 -> ffff82d080222685 --L8kKQa9TP3MWoCC0kccNHPM3NH9EGtr1N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUV3n7AAoJEOhnXe7L7s6jGPwQAKVj6gLb3Fs9CFRvo6H4xW1W nCI+Wnd7pKP0Whph8n0Vh0VCvOODxfdb5BIr/A7rldhO3yosuXNlju9/kbk++ZJI t2z0J8xPZgqRtKlQYf1S+w6Th1LnF/2Fd/uADM0GXdBbHXqUiqO35P056JZlwJxI gsVG33nu+H5npr4YKwElM2/igD1xMm2+qrBrF8OLE2r/iiT3cTmMYFxG08A41s6p 6H1TEqQdBwJXNKxoqhQTGnYxWGuQGYumar/uedwCCo7aoxQvqDzG7xYrqcr8gVI9 5say7ABp7wcYt32849tkWn2NpMmjtbH27YanUaG+Qze1NE2FtL0dJcI+Szgb72cI ikpYRlTH05YgCq7ICnp7evZrESIjcB/gReG1Ijx6FCvlFT+SXTo5K5ms3R5/dPsF Fp9naVt6a+xQyNBp00MbWa2PRvV4mPDE+2Sz5VaHxqLZ66oiPuPmpRqGUxowjqGO 1wOWLJQFtKo0T971QgfUVHVaVXG1ZV+BVKB/xJATQeMb6tNKbob44bgWNh/4lxfd tLDWPCJfHxtuFiJAFaJnOJ1QB1qdPd7DcjniEVMmmmVzsYXNlYG0K8Q+5/JdXEqy Iv7Rs1zcdMh5R6oEDCUDIJmhFoGDN6dJWgAtxvIgf7nOMPUs+uOjXJmfleRGgsNb VUkJscFKgKoo9ivRfnMP =lZdb -----END PGP SIGNATURE----- --L8kKQa9TP3MWoCC0kccNHPM3NH9EGtr1N-- --===============5146011419674642202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5146011419674642202==--