Oops in guest after ioremap() on ARMv7

Ian Campbell Ian.Campbell at citrix.com
Thu Feb 16 12:21:25 EST 2012


On Thu, 2012-02-16 at 17:18 +0000, Catalin Marinas wrote:
> 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 at 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?

Yes I'll do that (tomorrow hopefully) and contact you off list with a
pointer to the binaries etc.

Thanks!

Ian.





More information about the linux-arm-kernel mailing list