The issue here is, Kernel has same config option/file for MCE/Thermal. Although
Xen HV provide virtual MCE to dom0 so that we don't need anything changes for
dom0, but that's not ture forthermal. We will consider that. Really thanks for
pointing that.
--jyh
Jan Beulich wrote:
>>>>> "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 10.06.09 04:45 >>>
>> Jan Beulich wrote:
>>>>>> "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> 09.06.09 11:30 >>>
>>>> Jan, I think the native sub-options (X86_MCE_INTEL and
>>> X86_MCE_AMD) needs be enabled still.
>>>> When a MCE happens, and dom0 is effected, that MCE will be
>>> injected to dom0 as virtual MCE, and that requires to enable these
>>>> otions.
>>>> When a MCE happens and dom0 is not effected, that MCE will be
>>> sent to dom0 as vIRQ so that dom0 can log that event for
>>>> analysis.
>>>
>>> Oh, okay, if the code is indeed needed, than that's fine. But
>>> the hacks needed
>>> to get mce_amd.c to compile look suspicious. As much as e.g.
>>> changing the defaults for the MCE Kconfig sub-options - those
>>> should be
>>> kept as is, and if
>>> the new code has any kind of dependency on them, the to-be-added new
>>> Kconfig option should express this accurately.
>>
>> Maybe we should change the "add" to "copy back". That two code are
>> from native kernel, but it is missed when copy the apic.c to
>> apic-xen.c, we just add it back. (After all, these hunks just change
>> xen specific code, apic-xen.c and mach-xen/asm/hw-irq.h)
>
> But both changes are wrong for Xen: Neither can you do APIC writes in
> Dom0 (or setup an APIC local vector entry in particular), nor do
> vectors 0xf9 and 0xfa have any significance there.
>
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home