[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |