On 21.05.2024 12:00, Sergiy Kibrik wrote:
> 21.05.24 09:05, Jan Beulich:
>>> This is because MCG_LMCE_P is defined in arch/x86/cpu/mcheck/x86_mca.h
>>> -- so either MCG_LMCE_P (+ a bunch of MCG_* declarations) has to be
>>> moved to common header to be accessible, or local x86_mca.h got to be
>>> i
21.05.24 09:05, Jan Beulich:
This is because MCG_LMCE_P is defined in arch/x86/cpu/mcheck/x86_mca.h
-- so either MCG_LMCE_P (+ a bunch of MCG_* declarations) has to be
moved to common header to be accessible, or local x86_mca.h got to be
included from common arch/x86/include/asm/mce.h.
As for th
On 20.05.2024 11:32, Sergiy Kibrik wrote:
> 16.05.24 12:39, Jan Beulich:
>> On 14.05.2024 10:20, Sergiy Kibrik wrote:
>>> Moving this function out of mce_intel.c would make it possible to disable
>>> build of Intel MCE code later on, because the function gets called from
>>> common x86 code.
>>
>>
16.05.24 12:39, Jan Beulich:
On 14.05.2024 10:20, Sergiy Kibrik wrote:
Moving this function out of mce_intel.c would make it possible to disable
build of Intel MCE code later on, because the function gets called from
common x86 code.
Why "would"? "Will" or "is going to" would seem more to the
On 14.05.2024 10:20, Sergiy Kibrik wrote:
> Moving this function out of mce_intel.c would make it possible to disable
> build of Intel MCE code later on, because the function gets called from
> common x86 code.
Why "would"? "Will" or "is going to" would seem more to the point to me.
But anyway.
>
Moving this function out of mce_intel.c would make it possible to disable
build of Intel MCE code later on, because the function gets called from
common x86 code.
Also replace boilerplate code that checks for MCG_LMCE_P flag with
vmce_has_lmce(), which might contribute to readability a bit.
Signe
