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

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

[Stefan Bader]

[-- Attachment #1.1: Type: text/plain, Size: 483 bytes --]

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Jan Beulich]

>>> On 03.11.14 at 10:45, <stefan.bader@canonical.com> 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?

Often guest MSR accesses cause this. addr2line on the corresponding
xen-syms should tell you.

Jan

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

[Stefan Bader]

[-- Attachment #1.1: Type: text/plain, Size: 856 bytes --]

On 03.11.2014 10:52, Jan Beulich wrote:
>>>> On 03.11.14 at 10:45, <stefan.bader@canonical.com> 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?
> 
> Often guest MSR accesses cause this. addr2line on the corresponding
> xen-syms should tell you.
> 
> Jan
> 
Ah, yes. There are usually messages about MSR access as well. Thanks for the
pointer about addr2line. I'll try that.

-Stefan


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Andrew Cooper]

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

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

[Stefan Bader]

[-- Attachment #1.1: Type: text/plain, Size: 2540 bytes --]

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.

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):

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Stefan Bader]

[-- Attachment #1.1: Type: text/plain, Size: 2916 bytes --]

On 03.11.2014 12: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.
> 
> 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):
> 
> (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.

Ok, 0x610 -> Running Average Power Limit (RAPL) control (MSR_PKG_POWER_LIMIT)
vol3 35.8

> (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)...
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Andrew Cooper]

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

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

[Stefan Bader]

[-- Attachment #1.1: Type: text/plain, Size: 3334 bytes --]

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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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