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

Re: [Xen-devel] [PATCH v3 2/6] xen: arm: Handle 4K aligned hypervisor load address.

At 14:29 +0100 on 21 Jul (1405949358), Ian Campbell wrote:
> On Mon, 2014-07-21 at 15:20 +0200, Tim Deegan wrote:
> > At 13:59 +0100 on 21 Jul (1405947596), Ian Campbell wrote:
> > > +virtphys_clash:
> > > +        /* Identity map clashes with boot_third, which we cannot handle 
> > > yet */
> > > +        PRINT("Unable to build boot page tables - virt and phys 
> > > addresses clash.\r\n")
> > 
> > Please tag this string "- Like so -\r\n" to match the other early output
> > from the boot assembler.
> OK. (I may do it on commit unless other comments necessitate a resend)


> > Presumably we could get around this by making a 4k mapping when the 2M
> > mapping would clash (at the cost of some extra code)?  
> It might be workable.
> We'd have to steal the slot from boot_third to point to 4K worth of 1:1
> mapping instead of the expected 4K of virtual mapping and then put back
> the virt mapping right after switching to the virtually mapped PC before
> we touch anything mapped via that slot i.e. before touching anything
> after _end_boot. Doing it at the same time as we establish the fixmap
> and dtb mappings would do the trick, I think.
> I'd previously concluded this wasn't possible, but don't recall why.
> What am I missing this time?

We'd be in trouble if we used the slot that covers the boot_third
table itself.  We could work around that, e.g. by using a linear PT to
update the mapping, but it's getting a bit intricate.  At that point
I'd be inclined to look at ways to get up into C while still PIC and
doing the pagetable build & trampoline from there.


Xen-devel mailing list



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