[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.