Re: (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 -> ffff82d080222806

[Andrew Cooper <andrew.cooper3@citrix.com>]

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 <type of fault>: 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