Re: [Xen-devel] [PATCH 16/45] xen: arm64: barriers and wait for interrupts/events

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-02-07 at 16:43 +0000, Tim Deegan wrote:
> At 15:56 +0000 on 23 Jan (1358956582), Ian Campbell wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-arm/arm64/system.h
> > @@ -0,0 +1,28 @@
> > +/* Portions taken from Linux arch arm64 */
> > +#ifndef __ASM_ARM64_SYSTEM_H
> > +#define __ASM_ARM64_SYSTEM_H
> > +
> > +#define sev()           asm volatile("sev" : : : "memory")
> > +#define wfe()           asm volatile("wfe" : : : "memory")
> > +#define wfi()           asm volatile("wfi" : : : "memory")
> > +
> > +#define isb()           asm volatile("isb" : : : "memory")
> > +#define dsb()           asm volatile("dsb sy" : : : "memory")
> > +
> > +#define mb()            dsb()
> > +#define rmb()           asm volatile("dsb ld" : : : "memory")
> > +#define wmb()           asm volatile("dsb st" : : : "memory")
> > +
> > +#define smp_mb()        asm volatile("dmb ish" : : : "memory")
> > +#define smp_rmb()       asm volatile("dmb ishld" : : : "memory")
> > +#define smp_wmb()       asm volatile("dmb ishst" : : : "memory")
> 
> Is this effectively declaring that all 'normal' RAM shall be inner
> shareable?  I think if that's the case we might want to update all the
> rest of the memory management to see things that way too.

> What's the intended difference between rmb() and smp_rmb(), anyway? 

It's part of the Linux CONFIG_SMP abstraction, smp_rmb becomes just a
regular barrier on UP but is a proper rmb (e.g. lfence) on SMP, rmp() is
always a proper barrier.

But that's a Linux-ism and I see x86 Xen has diverged from x86 Linux
here and just defines smp_foo as foo (i.e. a stronger barrier than might
strictly be required).

I think I'll do that here as well, until asyou say previously we revisit
this and decide what inner and outer shareable mean for Xen...

Ian.



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