Re: [Xen-devel] [PATCH ARM v6 07/14] mini-os: arm: boot code

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-07-30 at 13:20 +0100, Thomas Leonard wrote:

> > The processor can still reorder writes and things like that, so I think
> > it is still needed.
> 
> Ah, I'd assumed it would default everything to Strongly Ordered with
> the MMU off, but I see it depends on how Xen sets the "Default
> cacheable" bit.

Even if memory accesses are strongly ordered that doesn't include co
processor register accesses so they can still be reordered wrt
loads/stores.

> >> How does that happen? Presumably the isb below will block that.
> >
> > I don't think it will, it's effectively just a pipeline flush but that
> > doesn't necessarily mean there isn't a write from below already in that
> > pipeline.
> >
> > (I think, I haven't actually gone back to the spec on this one...)
> >
> > In Xen we do dsb+isb before and after the TLB flush.
> 
> I've added these in various places, but no improvement:
> 
> https://github.com/talex5/xen/commit/39199da8493ad6e235849d7ecd51a1415d7d60a7

Ah, you aren't setting the cacheability of the PT walks, I bet that's
it. If you don't do that then you do need cache maintenance when writing
PTEs (or to have caches disabled).

Xen uses LPAE mode and therefore the extended format of TTBCR (called
HTCR for Xen), which is where the bits controlling the cacheability of
page table walks are held for LPAE.

In non-LPAE mode it looks like the cacheability bits are in TTBR[01] in
bits 0..6.

Ian.


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