All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Baozi <baozich@gmail.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: List Developer Xen <xen-devel@lists.xen.org>
Subject: Re: About booting Xen with UEFI on FastModel
Date: Tue, 17 Dec 2013 23:57:32 +0800	[thread overview]
Message-ID: <52B0746C.2060008@gmail.com> (raw)
In-Reply-To: <1387275141.27441.27.camel@kazak.uk.xensource.com>

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@citrix.com> wrote:
>>
>>> On Wed, 2013-12-11 at 19:06 +0800, Chen Baozi wrote:
>>>> On Dec 11, 2013, at 18:59, Ian Campbell <Ian.Campbell@citrix.com> 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@citrix.com> 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?

>> 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?

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

Cheers,

Baozi

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

  reply	other threads:[~2013-12-17 15:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-09 15:15 About booting Xen with UEFI on FastModel Chen Baozi
2013-12-09 15:35 ` Ian Campbell
2013-12-11  5:06   ` Chen Baozi
2013-12-11 10:59     ` Ian Campbell
2013-12-11 11:06       ` Chen Baozi
2013-12-11 11:29         ` Ian Campbell
2013-12-17  4:52           ` Chen Baozi
2013-12-17 10:12             ` Ian Campbell
2013-12-17 15:57               ` Chen Baozi [this message]
2013-12-18 11:59                 ` Ian Campbell
2013-12-18 12:09                   ` Chen Baozi
2013-12-18 12:25                     ` Ian Campbell
2013-12-20  8:50                   ` Chen Baozi
2013-12-20 10:40                     ` Ian Campbell
2013-12-20 11:01                       ` Chen Baozi
2013-12-20 11:04                         ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52B0746C.2060008@gmail.com \
    --to=baozich@gmail.com \
    --cc=ian.campbell@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.