Re: [Xen-devel] About booting Xen with UEFI on FastModel

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-12-17 at 23:57 +0800, Chen Baozi wrote:
> On Tue 17 Dec 2013 06:12:21 PM CST, Ian Campbell wrote:
> > On Tue, 2013-12-17 at 12:52 +0800, Chen Baozi wrote:
> >> On Dec 11, 2013, at 19:29, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >>
> >>> On Wed, 2013-12-11 at 19:06 +0800, Chen Baozi wrote:
> >>>> On Dec 11, 2013, at 18:59, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >>>>
> >>>>> On Wed, 2013-12-11 at 13:06 +0800, Chen Baozi wrote:
> >>>>>> Hi Ian,
> >>>>>>
> >>>>>> On Dec 9, 2013, at 23:35, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >>>>>>
> >>>>>>> On Mon, 2013-12-09 at 23:15 +0800, Chen Baozi wrote:
> >>>>>>>> Hi all,
> >>>>>>>>
> >>>>>>>> I noticed that upstream UEFI is now supported ARMv8 on FastModel.
> >>>>>>>> Iâve tried it to boot Linux with it. And it works. But it seems
> >>>>>>>> it still cannot load Xen hypervisor properly. Iâm now looking for
> >>>>>>>> the reasons. Is there any difference for a firmware to load Xen
> >>>>>>>> and Linux kernel?
> >>>>>>>
> >>>>>>> I think you are the first one to try Xen on EFI.
> >>>>>>>
> >>>>>>> Are you using the EFI stub with Linux or are you launching via a
> >>>>>>> bootloader e.g. Grub-EFI?
> >>>>>>
> >>>>>> After reading the source code, I think it is neither the EFI stub
> >>>>>> or a bootloader. A Linux Loader EFI application has been developed
> >>>>>> for ARM in EFI.
> >>>>>
> >>>>> Do you have a link? I'm curious.
> >>>>
> >>>> Instructions to EFI on AArch64:
> >>>>
> >>>> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ArmPlatformPkg/AArch64
> >>>>
> >>>> And Iâm using the git clone of its svn repository:
> >>>>
> >>>> https://github.com/tianocore/edk2.git
> >>>>
> >>>> Under the tree, the Linux Loader locates at:
> >>>>
> >>>> ArmPkg/Application/LinuxLoader
> >>>
> >>> Ah that, yes I think that boots Linux using the zImage protocol.
> >>>
> >>>>>
> >>>>>> It is able to boot Linux either by tagged list or
> >>>>>> dtb method. However, it hardcoded the start address of 0x80000
> >>>>>> when loading Linux kernel, which make it unworkable for Xen after
> >>>>>> paging is enable.
> >>>
> >>> 0x80000 is a problem due to the alignment not being 2M I think?
> >>>
> >>> Really should look into fixing that. (would probably mean allowing Xen
> >>> to span 2 consecutive 2MB blocks and some additional fiddling during
> >>> bring up)
> >>
> >> Yes, it is. I hacked EFI to make it boot Xen with a 2M aligned address.
> >> And it seems to be OK.
> >>
> >> But Iâm afraid it is not simply allowing Xen to span 2 consecutive 2MB
> >> blocks, for it cannot deal with the different offsets within the page
> >> ( 0x80080000 % 2M != 0x80200000 % 2M).
> >>
> >> IMHO, there might be 3 ways to solve this problem:
> >>
> >> 1. If Xen bootstrap code detected it at an address not aligned with
> >> 2MB, then it copies itself to (x19 + 4M)\2M.
> >
> > This runs the risk of overwriting one of the other boot modules or
> > something we need later and would have to happen before we had parsed
> > the DTB to find out where those things are.
> >
> > We could mandate that there is space between the end of Xen and other
> > stuff, but then we could probably just fix the load address too.
> >
> 
> Is there any consideration not to make the load address offset same with
> Linux (0x80000)? Because of memory layout?

I don't beleive Linux is restricted to 0x80000 that's just an
implementation detail in the bootloader/firmware you happen to be using.

> >> 2. Modify LinuxLoader of EFI to load zImage at 2M aligned address.
> >
> > It's not impossible that we will end up with a XenLoader EFI anyway.
> >
> 
> Is a XenLoader EFI necessary in future? Or there would be finally a 
> bootloader such as grub on ARM64?

Both. But in both cases we need a boot protocol which can pass multiple
blobs to the kernel (e.g. fdt, dom0 kernel, dom0 initrd) and a common
which implements that. At that point we may as well make the load
address better suited to us as well. 

> >> 3. Use smaller (e.g. 4K) page size in start-of-day page table.
> >
> > This should work.
> 
> Personally, I prefer the 4K page size solution. But I'm not sure whehter
> it would be appropriate to add a new level page table at first. I'll 
> send
> an experimental patch of it later this week.

Thanks. This is certainly not 4.4 material though I think so no rush.

The only real reason to avoid 4K pages and stick with 2M pages is the
complexity in the asm code (since we need to populate them etc). They
will also require space in the .bss (up to perhaps 512 pages for a full
2M span).

Ian.



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