Re: [Xen-devel] [PATCH v3 5/8] xen/arm: preserve DTB mappings

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 8 Jan 2013, David Vrabel wrote:
> On 08/01/13 18:33, Stefano Stabellini wrote:
> > On Wed, 19 Dec 2012, Ian Campbell wrote:
> >>> @@ -295,12 +296,23 @@ void __init setup_pagetables(unsigned long 
> >>> boot_phys_offset, paddr_t xen_paddr)
> >>>      write_pte(xen_second + second_linear_offset(XEN_VIRT_START), pte);
> >>>      /* TLBFLUSH and ISB would be needed here, but wait until we set WXN 
> >>> */
> >>>  
> >>> +    /* preserve the DTB mapping a little while longer */
> >>
> >> Not so much "preserve" as "put back" after this function clobbered it.
> >>
> >> I'm not convinced by this effectively open coding of a "stack" of
> >> mappings in the BOOT_MISC_VIRT_START slot. IMHO this slot should only be
> >> used for ephemeral mappings within individual functions or over short
> >> spans of code -- otherwise there is plenty of potential for clashes
> >> which lead to hard to decipher bugs.
> >>
> >> Can we not map the boot fdt as and when we need it instead of trying to
> >> preserve a mapping?
> > 
> > I don't like this idea because it means that the device initialization
> > functions in start_xen that are called after setup_pagetables and before
> > setup_mm, like gic_init, suddenly become position dependent: they cannot
> > be moved after setup_mm.
> 
> The mapping of the DTB into BOOT_MISC_VIRT_START was only for use by
> device_tree_early_init().  Everything else should be using the final
> mapping setup in setup_mm().
> 
> I think this means setup_mm() needs to immediately after
> setup_pagestables() and before gic_init(), pl011_init() etc.

That would be a very easy way out of this problem.
I think I am going to go for it.

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