[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 02/11] xen/mce: allow mce_barrier_{enter, exit} to return without waiting
>>> 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"). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |