Oops in guest after ioremap() on ARMv7

[catalin.marinas@arm.com (Catalin Marinas)]

On Thu, Feb 16, 2012 at 05:01:42PM +0000, Ian Campbell wrote:
> On Tue, 2012-01-31 at 14:40 +0000, Catalin Marinas wrote:
> > On 19 January 2012 17:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Tue, 2012-01-03 at 16:50 +0000, Catalin Marinas wrote:
> > >> On Fri, Dec 23, 2011 at 12:00:25PM +0000, Ian Campbell wrote:
> > >> > At the moment we build the entire p2m before we ever load the VTTBR or
> > >> > enable stage-2 translations in the HCR. Is that sufficient or do we also
> > >> > need to flush something?
> > >>
> > >> If the model does not correctly implement cacheable page table walks for
> > >> either stage 1 or stage 2 translation (though ID_MMFR3[23:20] indicate
> > >> that it should), the hypervisor would need to clean the D-cache to the
> > >> point of unification (not necessary to go to the point of coherency)
> > >> before any of the state 2 translation tables are used.
> > >
> > > I added a copy of Linux's v7_flush_dcache_all after building the p2m but
> > > just before loading the VTTBR and it didn't help.
> > >
> > > I turned off cacheability in VTCR and that didn't help either.
> > >
> > > Then I turned off cacheability in the Linux TTBR{0,1} (by frobbing both
> > > TTB_FLAGS_UP and TTB_FLAGS_SMP to use FOO_NC everywhere) and this _did_
> > > make a difference -- the kernel now boots.
> > >
> > > I then tested just that change by itself and it seems to have done the
> > > trick.
> > >
> > > Does that indicate a model bug?
> > 
> > It is possible. The scenario I'm thinking of is that with cacheable
> > PTWs enabled in TTBR, the model wrongly decides to use the
> > intermediate physical address (IPA) to look up the caches and gets the
> > wrong information.
> > 
> > I'll take this to the model guys but most likely they'll ask for an
> > image to load and just run. Could you provide such simple image
> > (minimal filesystem)? I'm not familiar with Xen and building it.
> > 
> > (I'll first ask the model guys, maybe they can spot the error easily
> > without additional debugging).
> 
> Did they conclude anything? Can I provide any more info?

No, they didn't :(. They would like to run some image showing the
problem so they can trace the internal state of the model. Unfortunately
I didn't have time to look into this.

Is it possible for you to create an ELF image that can be loaded onto
the model with some instructions to show the failure?

Thanks.

-- 
Catalin