Re: [Xen-devel] (XEN) traps.c:3156: GPF messages in xen dmesg

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.12.12 at 18:55, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:

> Monday, December 17, 2012, 5:57:24 PM, you wrote:
> 
>>>>> On 17.12.12 at 17:48, Valtteri Kiviniemi <kiviniemi.valtteri@xxxxxxxxx> 
>>>>> wrote:
>>> I'm running Xen 4.2.0 with Linux kernel 3.7.0 and I'm seeing a flood of
>>> these messages in xen dmesg:
>>> 
>>> (XEN) traps.c:3156: GPF (0060): ffff82c480159247 -> ffff82c4802170e4
>>> (XEN) traps.c:3156: GPF (0060): ffff82c480159247 -> ffff82c4802170e4
>>> (XEN) traps.c:3156: GPF (0060): ffff82c480159247 -> ffff82c4802170e4
>>> (XEN) traps.c:3156: GPF (0060): ffff82c480159247 -> ffff82c4802170e4
>>> (XEN) traps.c:3156: GPF (0060): ffff82c480159247 -> ffff82c4802170e4
>>> (XEN) traps.c:3156: GPF (0060): ffff82c480159247 -> ffff82c4802170e4
>>> (XEN) traps.c:3156: GPF (0060): ffff82c480159247 -> ffff82c4802170e4
>>> 
>>> What does that mean and is it something that I should worry about?
> 
>> It means that the hypervisor recovered from #GP faults several
>> times. What exactly it was that faulted you'd need to look up by
>> translating the addresses above and resolving them to source
>> locations. That'll also tell you whether you ought to be worried.
> 
>> A common example of these happening is Xen carrying out MSR
>> accesses on behalf of the kernel, when the MSR actually isn't
>> implemented (i.e. the kernel itself also is prepared to handle
>> faults upon accessing them).
> 
> Perhaps related to a previous discussion (with a open end ..)
> http://lists.xen.org/archives/html/xen-devel/2012-09/msg01599.html 

Not impossible, but iirc those would generally be accompanied
by SIGSEGV-s and/or kernel crashes in some guest.

Jan


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