[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 13/45] xen: arm64: dcache flush



On Thu, 2013-02-07 at 16:30 +0000, Tim Deegan wrote:
> At 16:22 +0000 on 07 Feb (1360254170), Ian Campbell wrote:
> > On Thu, 2013-02-07 at 16:14 +0000, Tim Deegan wrote:
> > > At 15:56 +0000 on 23 Jan (1358956579), Ian Campbell wrote:
> > > > This drops the
> > > >     "m" (*_p)
> > > > asm contraint. I can't figure out what this was for.
> > > > 
> > > 
> > > It's to stop the compiler hoisting writes to the wrong side of the
> > > flush.  It's the lighter-weight equivalent to the "memory" clobber in
> > > the range version.  By moving from inline "dsb;" to dsb() you've
> > > reintroduced the full memory clobber here anyway. :(
> > 
> > Ah, I forgot about the "memory" on the inline asm of the dsb macro.
> > 
> > How about #define _dsb() __asm__ __volatile__ ("dsb" : : :)
> > for cases such as this?
> 
> Maybe.  The profusion of undersocre-prefixed operations is staring to
> confuse me, though.

Ack.

> > I think on 32-bit "dsb" == "dsb sy", while on 64-bit only the "dsb sy"
> > form is valid. The reason I didn't err on the side of just adding the
> > "sy" was that often there is something else which differs between the
> > two in the same asm inline block and so using the macro throughout
> > seemed cleaner. Perhaps I should rethink this.
> 
> I see.  So maybe we could just switch to using 'dsb sy' in
> flush_xen_dcache() and just macro up the one line of inline asm that
> expands to STORE_CP32(0, DCCMVAC) ?

Actually, yes, I subsequently to make this change invented
READ/WRITE_SYSREG to abstract this stuff away -- I should extend that to
inline ASM too.

Ian.


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


 


Rackspace

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