[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 15/07/14 12:10, Ian Campbell wrote:
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.

I stopped to count the number of patch I completely reworked after the first version...

I think this is adding complexity in the assembly code and restriction (see your panic) where the bootloader load Xen in the memory. Even though, the restriction where already there but hidden by the fact we are using 2MB mapping.
        
This could be replaced by:
ARM32: adding a couple of assembly lines to relocate down to a 2MB address. ARM64: using the offset in the Image, unless if we released bootloader is not able to correctly cope with it.

Regards,

--
Julien Grall

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