Re: [Xen-devel] traps.c:3227: GPF (0000): ffff82d080194a4d -> ffff82d080239d85 and other dom0 induced log messages

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.06.15 at 16:01, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 26/06/15 16:51, Jan Beulich wrote:
>>>>> On 26.06.15 at 17:41, <linux@xxxxxxxxxxxxxx> wrote:
>>> from 3.16 to 3.19 we gained a lot of these, if i remember correctly 
>>> related to
>>> perf being enabled in the kernel:
>>>
>>> +   traps.c:2655:d0v0 Domain attempted WRMSR 00000000c0000081 from 
>>> 0xe023e00800000000 to 0x0023001000000000.
>>> +   traps.c:2655:d0v0 Domain attempted WRMSR 00000000c0000082 from 
>>> 0xffff82d0bffff000 to 0xffffffff81bc2670.
>>> +   traps.c:2655:d0v0 Domain attempted WRMSR 00000000c0000083 from 
>>> 0xffff82d0bffff020 to 0xffffffff81bc4630.
>> These are the SYSCALL (STAR) MSRs, which the kernel has no business
>> touching when running on Xen.
>>
>>> from 3.19 to 4.0 we gained:
>>> +   d0 attempted to change d0v0's CR4 flags 00000660 -> 00000760
>>> +   d0 attempted to change d0v1's CR4 flags 00000660 -> 00000760
>>> +   d0 attempted to change d0v2's CR4 flags 00000660 -> 00000760
>>> +   d0 attempted to change d0v3's CR4 flags 00000660 -> 00000760
>>> +   d0 attempted to change d0v4's CR4 flags 00000660 -> 00000760
>>> +   d0 attempted to change d0v5's CR4 flags 00000660 -> 00000760
>> This is X86_CR4_PCE - not sure how to properly handle that.
>> Andrew, you're fiddling with the CR4 handling right now anyway -
>> any thoughts?
> 
> We have no infrastructure whatsoever to allow PV guests to use rdpmc,
> and PCE is unconditionally clear in CR4.
> 
> With Boris' perf series, and oprofile already having other PV interfaces
> to access performance counters, I don't see any reason to open this up
> to native use by PV guests.

Matches my way of thinking.

>>> and from 4.0 to 4.1 we gained the ones you were interested in:
>>> +   traps.c:3227: GPF (0000): ffff82d080194a4d -> ffff82d080239d85
>>> +   traps.c:3227: GPF (0000): ffff82d080194a4d -> ffff82d080239d85
>>> +   traps.c:3227: GPF (0000): ffff82d080194a4d -> ffff82d080239d85
>>> +   traps.c:3227: GPF (0000): ffff82d080194a4d -> ffff82d080239d85
>>> +   traps.c:3227: GPF (0000): ffff82d080194a4d -> ffff82d080239d85
>>> +   traps.c:3227: GPF (0000): ffff82d080194a4d -> ffff82d080239d85
>> For these to be meaningful you need to translate them to symbolic
>> addresses. (And yes, we should see to make the code print them
>> in a more useful manner.)
> 
> For things like {wr,rd}msr_safe(), we should print ecx/eax/edx.  I
> expect there are similar useful debug hints for other areas of code.  Is
> it worth stashing some other information in the extable to aid generic
> debug printing of errors?

Not sure this wouldn't quickly become too complex. My comment
mainly was aiming at converting the hex number to symbol
references.

Jan


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