[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 2/5] xen: arm: Handle 4K aligned hypervisor load address.
On Tue, 2014-07-15 at 12:07 +0100, Julien Grall wrote: > > On 15/07/14 12:03, Julien Grall wrote: > > > > > > On 15/07/14 10:13, Ian Campbell wrote: > >> On Mon, 2014-07-14 at 23:33 +0100, Julien Grall wrote: > >>> Hi Ian, > >>> > >>> On 14/07/14 17:39, Ian Campbell wrote: > >>>> Currently the boot page tables map Xen at XEN_VIRT_START using a 2MB > >>>> section > >>>> mapping. This means that the bootloader must load Xen at a 2MB > >>>> aligned address. > >>>> Unfortunately this is not the case with UEFI on the Juno platform > >>>> where Xen > >>>> fails to boot. Furthermore the Linux boot protocol (which Xen claims > >>>> to adhere > >>>> to) does not have this restriction, therefore this is our bug and > >>>> not the > >>>> bootloader's. > >>>> > >>>> Fix this by adding third level pagetables to the boot time > >>>> pagetables, allowing > >>>> us to map a Xen which is aligned only to a 4K boundary. This only > >>>> affects the > >>>> boot time page tables since Xen will later relocate itself to a 2MB > >>>> aligned > >>>> address. Strictly speaking the non-boot processors could make use of > >>>> this and > >>>> use a section mapping, but it is simpler if all processors follow > >>>> the same boot > >>>> path. > >>> > >>> OOI, did you think about the solution to copy Xen to a 2MB aligned > >>> address before setup the early page table? > >> > >> I did but I was worried about clobbering something useful, like a boot > >> module. > >> > >>> It would avoid to use third level page table during boot > >> > >> This isn't really that expensive, and it's marked __init so it goes away > >> after boot. > >> > >>> but will > >>> introduce an extra copy of Xen (only for the boot processor). > >>> > >>> FYI, it's what Linux does. > >> > >> Interesting, how does it choose the address? Just by rounding down the > >> loading address? > > > > For ARM32 yes. > > > > For ARM64, I don't find anything about relocating the Image. AFAIU, they > > use a field in the header to specify at which offset we need to load the > > kernel from the RAM base address. > > > > On Xen, this field is set to 0, which means loading at any address. So I > > suspect for ARM64 we can change this offset and avoid to modify page > > table code. > > Hrm... I misread the documentation for this part. > > "The image must be placed at the specified offset (currently 0x80000) > from the start of the system RAM and called there. The start of the > system RAM must be aligned to 2MB." > Regardless of this being more flexible in what load addresses we accept is relatively easy, has no impact after boot and the code is already written. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |