[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 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.

David

_______________________________________________
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®.