[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |