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

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

On 26/06/15 16:51, Jan Beulich wrote:
>>>> On 26.06.15 at 17:41, <linux@eikelenboom.it> 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.

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

~Andrew