Re: [Xen-devel] vcpu_block() and do_poll() question

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Tue, 2019-04-30 at 11:13 +0200, Juergen Gross wrote:
> In xen/common/schedule.c there is a weird "#ifndef CONFIG_X86" in
> do_poll().
> 
> It was introduced way before anyone would think about ARM by commit
> ef4c6b079cc55e (I couldn't find any xen-devel mail related to that
> commit), so I guess it is related to IA64?
> 
I guess it must be that one.

I rolled back the tree at that commit, and went checking how set_bit()
was implemented for IA64.

Interestingly, there's a comment above clear_bit(), which says:

 * clear_bit() is atomic and may not be reordered.  However, it does
 * not contain a memory barrier, so if it is used for locking purposes,
 * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit()  
                         
 * in order to ensure changes are visible on other processors.

which seems to confirm what we're thinking. Memory barriers are,
however, not mentioned at all for set_bit().

It's also explicitly stated that test_and_set_bit() and
test_and_clear_bit() do act as memory barriers.

The code appears to having been taken from Linux (it's even in
xen/include/asm-ia64/linux/asm/bitops.h), so maybe some more
investigation is possible, if deemed interesting.

> Question is: can we just drop it, or does ARM depend on it? And if
> ARM
> really needs it, is it the memory barrier only? And why wouldn't a
> similar barrier be needed in vcpu_block() then?
> 
Well, the difference between vcpu_block() and do_poll() is that the
former does just one set_bit(), while the latter does two, with an
assignment in between.

So I guess what we're trying to deal with is the case of some CPU
having seen any random combination of poll_evtchn and the bits of
pause_flags and poll_mask, on an arch that permits enough reordering.

But, yes, if what you're saying is that, on an architectures that need
a barrier after set_bit(), that's then necessary in both functions,
that makes sense to me too.

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel