Re: [Xen-devel] [PATCH v4 02/11] xen/mce: allow mce_barrier_{enter, exit} to return without waiting

[<haozhong.zhang@xxxxxxxxx>]

On 06/27/17 00:38 -0600, Jan Beulich wrote:
> >>> Haozhong Zhang <haozhong.zhang@xxxxxxxxx> 06/26/17 11:17 AM >>>
> >Add a 'nowait' argument to mce_barrier_{enter,exit}() to allow them
> >return immediately without waiting mce_barrier_{enter,exit}() on other
> >CPUs. This is useful when handling LMCE, where mce_barrier_{enter,exit}
> >are called only on one CPU.
> >
> >Signed-off-by: Haozhong Zhang <haozhong.zhang@xxxxxxxxx>
> 
> The patch could have my ack in principle, but ...
> 
> >--- a/xen/arch/x86/cpu/mcheck/barrier.h
> >+++ b/xen/arch/x86/cpu/mcheck/barrier.h
> >@@ -32,6 +32,14 @@ void mce_barrier_init(struct mce_softirq_barrier *);
>  >void mce_barrier_dec(struct mce_softirq_barrier *);
>  >
>  >/*
> >+ * If nowait is true, mce_barrier_enter/exit() will return immediately
> >+ * without touching the barrier. It's used when handling a LMCE which
> >+ * is received on only one CPU and thus does not invoke
> >+ * mce_barrier_enter/exit() calls on all CPUs.
> >+ *
> >+ * If nowait is false, mce_barrier_enter/exit() will handle the given
> >+ * barrier as below.
> >+ *
>   >* Increment the generation number and the value. The generation number
>   >* is incremented when entering a barrier. This way, it can be checked
>   >* on exit if a CPU is trying to re-enter the barrier. This can happen
> 
> ... especially with the complete lack of mentioning the mce_broadcast
> check inside the functions I wonder whether it wouldn't better be the
> callers now to pass "!mce_broadcast" into the functions, instead of
> "false". What do you think? Which then further makes me wonder
> whether the parameter wouldn't better be inverted ("wait" instead of
> "nowait").
> 

In that case, it's better to use "wait" and let caller pass in
"mce_broadcast".

Haozhong

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel