About booting Xen with UEFI on FastModel

About booting Xen with UEFI on FastModel

[Chen Baozi]

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?

Cheers,

Baozi

Re: About booting Xen with UEFI on FastModel

[Ian Campbell]

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?

Xen doesn't yet have an EFI stub (it's on my list, but it looks like it
will be early next year at this rate).

If booting via Grub then I think it doesn't speak the Xen boot module
protocol, so you'd need to do the grub equivalent of the fdt commands
which are in the u-boot runes on the wiki.

In any case, if you want advice with this then you need to be quite
specific about what exactly you have done and what didn't wor.

Ian.


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

Re: About booting Xen with UEFI on FastModel

[Chen Baozi]

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. 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. But I’m not sure whether there would be other
problems for it to boot Xen. And I’ll continue to work on it until
it can boot Xen successfully at the end.

(At least, there are early printk messages on the UART now, :-))

Cheers,

Baozi

Re: About booting Xen with UEFI on FastModel

[Ian Campbell]

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.

>  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. But I’m not sure whether there would be other
> problems for it to boot Xen. And I’ll continue to work on it until
> it can boot Xen successfully at the end.

Have fun ;-)

> (At least, there are early printk messages on the UART now, :-))

> 
> Cheers,
> 
> Baozi



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

Re: About booting Xen with UEFI on FastModel

[Chen Baozi]

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

> 
>> 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. But I’m not sure whether there would be other
>> problems for it to boot Xen. And I’ll continue to work on it until
>> it can boot Xen successfully at the end.
> 
> Have fun ;-)
> 
>> (At least, there are early printk messages on the UART now, :-))
> 
>> 
>> Cheers,
>> 
>> Baozi

Re: About booting Xen with UEFI on FastModel

[Ian Campbell]

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)

>  But I’m not sure whether there would be other
> >> problems for it to boot Xen. And I’ll continue to work on it until
> >> it can boot Xen successfully at the end.
> > 
> > Have fun ;-)
> > 
> >> (At least, there are early printk messages on the UART now, :-))
> > 
> >> 
> >> Cheers,
> >> 
> >> Baozi
> 



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

Re: About booting Xen with UEFI on FastModel

[Chen Baozi]

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.

2. Modify LinuxLoader of EFI to load zImage at 2M aligned address.

3. Use smaller (e.g. 4K) page size in start-of-day page table.

> 
>> But I’m not sure whether there would be other
>>>> problems for it to boot Xen. And I’ll continue to work on it until
>>>> it can boot Xen successfully at the end.
>>> 
>>> Have fun ;-)
>>> 
>>>> (At least, there are early printk messages on the UART now, :-))
>>> 
>>>> 
>>>> Cheers,
>>>> 
>>>> Baozi

Re: About booting Xen with UEFI on FastModel

[Ian Campbell]

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.

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

> 3. Use smaller (e.g. 4K) page size in start-of-day page table.

This should work.



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

Re: About booting Xen with UEFI on FastModel

[Chen Baozi]

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

Re: About booting Xen with UEFI on FastModel

[Ian Campbell]

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

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@lists.xen.org
http://lists.xen.org/xen-devel

Re: About booting Xen with UEFI on FastModel

[Chen Baozi]

On Dec 18, 2013, at 19:59, Ian Campbell <Ian.Campbell@citrix.com> wrote:

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

Sorry, my bad, I mean the virtual start address of Xen.

Baozi.

Re: About booting Xen with UEFI on FastModel

[Ian Campbell]

On Wed, 2013-12-18 at 20:09 +0800, Chen Baozi wrote:
> On Dec 18, 2013, at 19:59, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> >>>> 
> >>>> 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.
> 
> Sorry, my bad, I mean the virtual start address of Xen.

The virtual address is baked into Xen at link time.

I don't think changing it would help though.

Ian.

Re: About booting Xen with UEFI on FastModel

[Chen Baozi]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]


On Dec 18, 2013, at 19:59, Ian Campbell <Ian.Campbell@citrix.com> wrote:

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

I wrote a experimental patch allowing Xen to be loaded at a 4KB aligned
address using the 4KB page size solution. It has been tested on FastModel
and works.

However, after I finished this patch, I think it would be better to make
bootloader to load Xen on a 2M aligned address. There are mainly two
reasons:

1. As mentioned, it doesn’t increase the .bss size and avoid complexity in 
the asm code.

2. This patch still cannot deal with the situation where [paddr, paddr+2M)
and [vaddr, vaddr+2M) are overlapped but not aligned with the same size
(e.g., paddr = 0x80000 & vaddr = 0x200000).

So I guess a 2MB aligned load address is required in boot protocol?

Cheers,

Baozi


[-- Attachment #2: 0001-xen-arm64-Allowing-to-load-Xen-spanning-consecutive-.patch --]
[-- Type: application/octet-stream, Size: 5477 bytes --]

From 78ceea3584a21cd7198dc1bcfb02956735832918 Mon Sep 17 00:00:00 2001
From: Chen Baozi <baozich@gmail.com>
Date: Fri, 13 Dec 2013 02:36:30 +0800
Subject: [PATCH] xen/arm64: Allowing to load Xen spanning consecutive 2MB
 blocks

Currently, Xen use a 2MB block mapping of itself at XEN_VIRT_START in
start-of-day pagetable. If the bootloader loads Xen at a address not
aligned with 2MB (e.g., 0x80000), the start-of-day pagetable won't work
properly. Because the base physical address of the block has been cut
to aligned with 2MB. Using a 4KB page mapping would avoid this situation
though requiring 4KB .bss space for additional 512 pages.

There is no such offset conflict mapping paddr(start). But one additional
slot of 2MB block mapping is still needed for Xen to span consecutive
2MB blocks.

Signed-off-by: Chen Baozi <baozich@gmail.com>
---
 xen/arch/arm/arm64/head.S | 65 ++++++++++++++++++++++++++++++++++++++---------
 xen/arch/arm/mm.c         |  3 +++
 2 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 31afdd0..b61cc42 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -29,6 +29,7 @@
 #define PT_MEM    0xe7d /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=0 P=1 */
 #define PT_DEV    0xe71 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=0 P=1 */
 #define PT_DEV_L3 0xe73 /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=100 T=1 P=1 */
+#define PG_MEM    0xe7f /* nG=1 AF=1 SH=10 AP=01 NS=1 ATTR=111 T=1 P=1 */
 
 #if (defined (EARLY_PRINTK)) && (defined (EARLY_PRINTK_INC))
 #include EARLY_PRINTK_INC
@@ -303,26 +304,66 @@ skip_bss:
         ldr   x4, =boot_second
         add   x4, x4, x20            /* x4 := paddr (boot_second) */
 
-        lsr   x2, x19, #20           /* Base address for 2MB mapping */
-        lsl   x2, x2, #20
-        mov   x3, #PT_MEM            /* x2 := Section map */
-        orr   x2, x2, x3
+        /* ... map boot_third in boot_second */
+        ldr   x1, =boot_third
+        add   x1, x1, x20            /* x1 := paddr(boot_third) */
+        mov   x3, #PT_PT             /* x2 := table map of boot_second */
+        orr   x2, x1, x3             /*       + rights for linear PT */
 
-        /* ... map of vaddr(start) in boot_second */
         ldr   x1, =start
-        lsr   x1, x1, #18            /* Slot for vaddr(start) */
-        str   x2, [x4, x1]           /* Map vaddr(start) */
+        lsr   x1, x1, #18            /* x1 := Slot offset for vaddr(start) */
+        str   x2, [x4, x1]
 
         /* ... map of paddr(start) in boot_second */
-        lsr   x1, x19, #30           /* Base paddr */
-        cbnz  x1, 1f                 /* If paddr(start) is not in slot 0
+        lsr   x5, x19, #30           /* Base paddr */
+        cbnz  x5, 1f                 /* If paddr(start) is not in slot 0
                                       * then the mapping was done in
                                       * boot_pgtable or boot_first above */
+        lsr   x5, x19, #18           /* Slot for paddr(start) */
 
-        lsr   x1, x19, #18           /* Slot for paddr(start) */
-        str   x2, [x4, x1]           /* Map Xen there */
-1:
+        lsr   x2, x19, #20           /* Base address of 2MB mapping */
+        lsl   x2, x2, #20
+        mov   x6, #PT_MEM            /* x2 := Section map */
+        orr   x2, x2, x6
+
+        mov   x3, #0x1ffff           /* If paddr(start) is not 2MB aligned */
+        and   x3, x19, x3            /* then we have to map it in two */
+        cbz   x3, 2f                 /* consecutive blocks */
+
+        add   x5, x5, #8             /* x5 := Next slot */
+        cmp   x5, x1
+        b.eq  fail                   /* For the paddr and vaddr might not
+                                      * be aligned to the same size, it
+                                      * would be dangerous if they are mapped
+                                      * in the same block slot. */
+        add   x2, x2, #0x200000
+        str   x2, [x4, x5]
+        sub   x2, x2, #0x200000
+        sub   x5, x5, #8
+2:
+        cmp   x5, x1
+        b.eq  fail
+        str   x2, [x4, x5]
+
+1:      /* Setup boot_third: */
+        ldr   x4, =boot_third
+        add   x4, x4, x20            /* x4 := paddr (boot_second) */
+
+        lsr   x2, x19, #12           /* Base address for 4KB mapping */
+        lsl   x2, x2, #12
+        mov   x3, #PG_MEM            /* x2 := Page map */
+        orr   x2, x2, x3
 
+        mov   x1, #512
+        add   x2, x2, #0x200000
+
+2:
+        sub   x1, x1, #1
+        sub   x2, x2, #PAGE_SIZE
+        str   x2, [x4, x1, lsl #3]           /* Map a 4KB page */
+        cbnz  x1, 2b
+
+1:
         /* Defer fixmap and dtb mapping until after paging enabled, to
          * avoid them clashing with the 1:1 mapping. */
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 654281a..9e363cc 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -70,6 +70,9 @@ lpae_t boot_pgtable[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 lpae_t boot_first[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
 #endif
 lpae_t boot_second[LPAE_ENTRIES]  __attribute__((__aligned__(4096)));
+#ifdef CONFIG_ARM_64
+lpae_t boot_third[LPAE_ENTRIES] __attribute__((__aligned__(4096)));
+#endif
 
 /* Main runtime page tables */
 
-- 
1.8.4.3


[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: About booting Xen with UEFI on FastModel

[Ian Campbell]

On Fri, 2013-12-20 at 16:50 +0800, Chen Baozi wrote:
> 2. This patch still cannot deal with the situation where [paddr, paddr+2M)
> and [vaddr, vaddr+2M) are overlapped but not aligned with the same size
> (e.g., paddr = 0x80000 & vaddr = 0x200000).

I think it ought to be possible in principal to make this work?

> So I guess a 2MB aligned load address is required in boot protocol?

That would certainly be easiest from the Xen side, as it involves no
changes at all!

Ian

Re: About booting Xen with UEFI on FastModel

[Chen Baozi]

On Dec 20, 2013, at 18:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Fri, 2013-12-20 at 16:50 +0800, Chen Baozi wrote:
>> 2. This patch still cannot deal with the situation where [paddr, paddr+2M)
>> and [vaddr, vaddr+2M) are overlapped but not aligned with the same size
>> (e.g., paddr = 0x80000 & vaddr = 0x200000).
> 
> I think it ought to be possible in principal to make this work?

I’m afraid not. Unless we don’t have the identical 1:1 physical address
mappings when booting, I think.

Baozi

> 
>> So I guess a 2MB aligned load address is required in boot protocol?
> 
> That would certainly be easiest from the Xen side, as it involves no
> changes at all!
> 
> Ian
> 

Re: About booting Xen with UEFI on FastModel

[Ian Campbell]

On Fri, 2013-12-20 at 19:01 +0800, Chen Baozi wrote:
> On Dec 20, 2013, at 18:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Fri, 2013-12-20 at 16:50 +0800, Chen Baozi wrote:
> >> 2. This patch still cannot deal with the situation where [paddr, paddr+2M)
> >> and [vaddr, vaddr+2M) are overlapped but not aligned with the same size
> >> (e.g., paddr = 0x80000 & vaddr = 0x200000).
> > 
> > I think it ought to be possible in principal to make this work?
> 
> I’m afraid not. Unless we don’t have the identical 1:1 physical address
> mappings when booting, I think.

Ugh, yes.

> 
> Baozi
> 
> > 
> >> So I guess a 2MB aligned load address is required in boot protocol?
> > 
> > That would certainly be easiest from the Xen side, as it involves no
> > changes at all!
> > 
> > Ian
> > 
> 



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