[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 1/9] x86/mce: handle LMCE locally



On 03/31/17 01:24 -0600, Jan Beulich wrote:
> >>> On 31.03.17 at 04:34, <haozhong.zhang@xxxxxxxxx> wrote:
> > On 03/30/17 08:35 -0600, Jan Beulich wrote:
> >> >>> On 30.03.17 at 08:19, <haozhong.zhang@xxxxxxxxx> wrote:
> >> > --- a/xen/arch/x86/cpu/mcheck/mce.c
> >> > +++ b/xen/arch/x86/cpu/mcheck/mce.c
> >> > @@ -42,6 +42,13 @@ DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, 
> >> > poll_bankmask);
> >> >  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, no_cmci_banks);
> >> >  DEFINE_PER_CPU_READ_MOSTLY(struct mca_banks *, mce_clear_banks);
> >> >  
> >> > +/*
> >> > + * Flag to indicate that at least one non-local MCE on this CPU has
> >> > + * not been completed handled. It's set by mcheck_cmn_handler() and
> >> > + * cleared by mce_softirq().
> >> > + */
> >> > +static DEFINE_PER_CPU(bool, nonlocal_mce_in_progress);
> >> 
> >> Does a boolean really suffice here? I.e. can't there be a 2nd one
> >> while the first one is still being dealt with?
> > 
> > It's to indicate the existence of a non-local MCE, and mce_softirq()
> > will call mctelem_process_deferred() to handle all MCE's if it's true,
> > so a boolean flag is suffice.
> 
> I don't buy this, I'm sorry. What if a 2nd #MC occurs at the
> instruction boundary of setting the variable to false (in
> mce_softirq())? A subsequent mce_softirq() would then see
> the variable being false, wouldn't it?
> 

You are right. I missed the point that MC# can happen during
mce_softirq() and this patch 1 is problematic in that case. Let me
rethink about this.

Thanks,
Haozhong

_______________________________________________
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®.