RE: [Xen-devel] [PATCH] DOM0: Adding MCA Loging support in DOM0

["Ke, Liping" <liping.ke@xxxxxxxxx>]

Jan Beulich wrote:
>>>> "Ke, Liping" <liping.ke@xxxxxxxxx> 01.07.09 03:42 >>>
>> Jan Beulich wrote:
>>> Actually, there are still two issues with this:
>>> 
>>> First, shouldn't bind_virq_for_mce() and the associated message
>>> printing really only happen on Dom0 (i.e. be guarded by
>>> is_initial_xendomain()),
>>> just like the name suggests?
>> 
>> Yes. DOM0 is the only one who's responsible for MCE logging (Even
>> the error address belongs to other Guest). Currently mce_dom0.o is
>> only compiled when it is a privileged guest [depends on
>> (!XEN_UNPRIVILEGED_GUEST) according to Kconfig]. bind_virq_for_mce()
>> is also protected by the same thing [#if
>> defined(CONFIG_X86_XEN_MCE)] You mean we still need other guard? 
> 
> !XEN_UNPRIVILEGED_GUEST doesn't mean the kernel can't run as DomU,
> it's only the other way around. Hence a build-time check only isn't
> sufficient. 
> 

Ok, I will send out a patch adding guard before calling bind_virq_for_mce.

>>> 
>>> Second, I'm now seeing
>>> 
>>> (XEN) traps.c:2263:d0 Domain attempted WRMSR 000000000000017b from
>>> 00000000:0000003f to ffffffff:ffffffff. (XEN) traps.c:2263:d0 Domain
>>> attempted WRMSR 0000000000000400 from 00000000:000000ff to
>>> ffffffff:ffffffff. (XEN) traps.c:2263:d0 Domain attempted WRMSR
>>> 0000000000000404 from 00000000:ffffffff to ffffffff:ffffffff. (XEN)
>>> traps.c:2263:d0 Domain attempted WRMSR 0000000000000408 from
>>> 00000000:00000fff to ffffffff:ffffffff. (XEN) traps.c:2263:d0 Domain
>>> attempted WRMSR 000000000000040c from 00000000:00000003 to
>>> ffffffff:ffffffff. (XEN) traps.c:2263:d0 Domain attempted WRMSR
>>> 0000000000000410 from 00000000:3fffffff to ffffffff:ffffffff. (XEN)
>>> traps.c:2263:d0 Domain attempted WRMSR 0000000000000414 from
>>> 00000000:00000001 to ffffffff:ffffffff.
>>> 
>>> which isn't really nice.
>> 
>> I looked into the code, current CONFIG_X86_MCE is defaultly 'y', so
>> mce.o 
>> DOM0 will be compiled by default. Yet we now only support intel 64
>> bit for 
>> DOM0 vMSR. I guess this is the reason why you see those printings.
>> Shall I sent a patch to make stricker limitations for compiling
>> mce.o? 
> 
> I'm not sure if you can avoid compiling mce.o altogether - if that's
> possible, it would certainly be the best approach. If not, some other
> mechanism to suppress the actual hardware touching bits would be
> desirable. 

I plan first send a patch making mce.o compiled for x86_64 Intel arch. 
Since we do plan to make AMD and Intel have a common MCA handling
logic. Both AMD and Intel arch shall support vMSR then. This common
handler might need some time. How do you think?

> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel