[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

 


Rackspace

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