|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 12/19] x86/mce: handle LMCE locally
>>> On 17.02.17 at 07:39, <haozhong.zhang@xxxxxxxxx> wrote:
> --- a/xen/arch/x86/cpu/mcheck/barrier.c
> +++ b/xen/arch/x86/cpu/mcheck/barrier.c
> @@ -20,7 +20,7 @@ void mce_barrier_enter(struct mce_softirq_barrier *bar)
> {
> int gen;
>
> - if (!mce_broadcast)
> + if ( !mce_broadcast || __get_cpu_var(lmce_in_process) )
this_cpu() please instead of __get_cpu_var() (which we should get
rid of rather sooner than later).
> @@ -462,6 +474,7 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
> uint64_t gstatus;
> mctelem_cookie_t mctc = NULL;
> struct mca_summary bs;
> + bool *lmce_in_process = &__get_cpu_var(lmce_in_process);
>
> mce_spin_lock(&mce_logout_lock);
>
> @@ -505,6 +518,8 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
> }
> mce_spin_unlock(&mce_logout_lock);
>
> + *lmce_in_process = bs.lmce;
You don't need a new local variable for this.
> @@ -1709,6 +1724,7 @@ static void mce_softirq(void)
> {
> int cpu = smp_processor_id();
> unsigned int workcpu;
> + bool lmce = per_cpu(lmce_in_process, cpu);
Is this flag valid to be looked at anymore at this point in time? MCIP
was cleared a lot earlier, so there may well have been a 2nd #MC
in between. In any event you again don#t need the local variable
here afaict.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |