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

Re: [PATCH v1 5/5] xen/riscv: map FDT



On Thu, 2024-07-11 at 12:54 +0100, Julien Grall wrote:
> Hi,
> 
> On 11/07/2024 12:28, Oleksii wrote:
> > Add Julien as he asked basically the same question in another
> > thread.
> 
> Thanks!
> 
> > 
> > On Thu, 2024-07-11 at 12:50 +0200, Jan Beulich wrote:
> > > On 11.07.2024 12:26, Oleksii wrote:
> > > > On Thu, 2024-07-11 at 11:54 +0200, Jan Beulich wrote:
> > > > > On 11.07.2024 11:40, Oleksii wrote:
> > > > > > On Wed, 2024-07-10 at 14:38 +0200, Jan Beulich wrote:
> > > > > > > On 03.07.2024 12:42, Oleksii Kurochko wrote:
> > > > Does it make sense now?
> > > 
> > > I think so, yet at the same time it only changes the question:
> > > Why is
> > > it
> > > that you absolutely need to use setup_initial_mapping()?
> > There is no strict requirement to use setup_initial_mapping(). That
> > function is available to me at the moment, and I haven't found a
> > better
> > option other than reusing what I currently have.
> 
> I am not very familiar with the code base for RISC-V, but looking at
> the 
> context in the patch, it seems you will still have the identity
> mapping 
> mapped until start_xen().
We have identity mapping only for a small piece of .text section:
        . = ALIGN(IDENT_AREA_SIZE);
        _ident_start = .;
        *(.text.ident)
        _ident_end = .;

All other will be identically mapped only in case of linker address is
equal to load address.

> 
> I assume we don't exactly know where the loader will put Xen in
> memory. 
> Which means that the region may clash with your defined runtime
> regions 
> (such as the FDT). Did I misunderstand anything?
I am not really get what is the issue here.

If we are speaking about physical regions then loader will guarantee
that Xen and FDT regions don't overlap.

If we are speaking about virtual regions then Xen will check that
nothing is overlaped. And the virtual regions are mapped so high so I
am not sure that loader will put something there. ( FDT in Xen is
mapped to 0xffffffffc0200000 ).

Could you please clarify what I am missing?

> 
> That's one of the reason on Arm we are trying to enable the MMU very 
> early. The only thing we setup is a mapping for Xen (and earlyprintk)
> all the rest will be mapped once the MMU is on.
It makes sense. Then I have to introduce map_pages_to_xen() first and
then early_fdt_map().

~ Oleksii

> 
> With that, the only thing you need to take care off the runtime Xen 
> address overlapping with the identity mapping.






 


Rackspace

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