Re: [Xen-devel] (XEN) traps.c:3071: GPF (0000): ffff82d0801d76b2 -> ffff82d080222806

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

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 
>>>> 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.
> 

After enabling the output for REDMSR as well it looks like the GPF message 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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel