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

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



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.

> Or maybe FIXMAP_BOOT_FDT?

Assuming that it fits in a single 4k page, that could work. However we
would have a "temporary" fixmap mapping that is only used at boot time
and never again.
At that point maybe it is better to map the DTB somewhere else in
another 2MB slot from head.S, preserve the mapping in setup_pagetables
and remove it at the beginning of setup_mm. Maybe it could be called
BOOT_EARLY_FDT.

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


 


Rackspace

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