From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Julien Grall <julien.grall@citrix.com>,
Andrew Turner <andrew@fubar.geek.nz>,
Shannon Zhao <zhaoshenglong@huawei.com>
Cc: <devicetree@vger.kernel.org>, <linux-efi@vger.kernel.org>,
<ian.campbell@citrix.com>, <ard.biesheuvel@linaro.org>,
<stefano.stabellini@eu.citrix.com>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <leif.lindholm@linaro.org>,
<xen-devel@lists.xen.org>, <freebsd-arm@freebsd.org>,
<matt.fleming@intel.com>, <christoffer.dall@linaro.org>,
<jbeulich@suse.com>, <peter.huangpeng@huawei.com>,
<linux-arm-kernel@lists.infradead.org>, <shannon.zhao@linaro.org>
Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
Date: Thu, 10 Sep 2015 14:05:49 +0200 [thread overview]
Message-ID: <55F1721D.1010801@citrix.com> (raw)
In-Reply-To: <55F16DF5.1080705@citrix.com>
El 10/09/15 a les 13.48, Julien Grall ha escrit:
> On 10/09/15 12:32, Andrew Turner wrote:
>> On Thu, 10 Sep 2015 16:41:56 +0800
>> Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> These EFI stub parameters are used to internal communication between
>>> EFI stub and Linux kernel and EFI stub creates these parameters. But
>>> for Xen on ARM when booting with UEFI, Xen will create a minimal DT
>>> providing these parameters for Dom0 and Dom0 is not only Linux
>>> kernel, but also other OS (such as FreeBSD) which will be used in the
>>> future. So here we plan to standardize the names by dropping the
>>> prefix "linux," and make them common to other OS. Also this will not
>>> break the compatibility since these parameters are used to internal
>>> communication between EFI stub and kernel.
>>
>> It is unlikely FreeBSD will use this property when booting ad Xen dom0.
>> The kernel expects to be passed a data structure to find boot this
>> information.
>>
>> My preference would be to have the FreeBSD loader load the xen binary,
>> the FreeBSD kernel, and set up these data structs before passing
>> control to Xen, with the information it needs to boot the kernel. My
>> understanding is this is how it is done on x86.
>
> Well, AFAICT, there is no FreeBSD specific code in Xen for x86. We are
> faking a multiboot module which contains all the informations.
>
> I know that the bootloader is at least involved, I don't remember if
> there is some code in FreeBSD to read this boot module. I've CCed Roger
> to confirm.
The metadata/modules needed by the FreeBSD Dom0 kernel is generated by
the native FreeBSD bootloader (as would be done when booting bare
metal). Then this blob is passed as a multiboot module in the same place
that Linux puts it's initramfs. Xen simply copies this blob straight
into guest memory and sets start_info.mod_start to point to the start
memory address of this blob.
I've done it this way because I don't see many other options. Xen is
tailored for Linux and only allows passing one module to the Dom0 kernel
(initramfs). For FreeBSD it would be good to be able to pass at least
two modules to the Dom0 kernel, one containing the metadata, and the
other one containing the modules themselves. The new PVH work (HVMlite
or whatever) will hopefully allow passing more than one module to the
Dom0 kernel, and should make the code in the FreeBSD loader simpler.
Roger.
WARNING: multiple messages have this Message-ID (diff)
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Julien Grall <julien.grall@citrix.com>,
Andrew Turner <andrew@fubar.geek.nz>,
Shannon Zhao <zhaoshenglong@huawei.com>
Cc: devicetree@vger.kernel.org, linux-efi@vger.kernel.org,
ian.campbell@citrix.com, ard.biesheuvel@linaro.org,
stefano.stabellini@eu.citrix.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, leif.lindholm@linaro.org,
xen-devel@lists.xen.org, freebsd-arm@freebsd.org,
matt.fleming@intel.com, christoffer.dall@linaro.org,
jbeulich@suse.com, peter.huangpeng@huawei.com,
linux-arm-kernel@lists.infradead.org, shannon.zhao@linaro.org
Subject: Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
Date: Thu, 10 Sep 2015 14:05:49 +0200 [thread overview]
Message-ID: <55F1721D.1010801@citrix.com> (raw)
In-Reply-To: <55F16DF5.1080705@citrix.com>
El 10/09/15 a les 13.48, Julien Grall ha escrit:
> On 10/09/15 12:32, Andrew Turner wrote:
>> On Thu, 10 Sep 2015 16:41:56 +0800
>> Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> These EFI stub parameters are used to internal communication between
>>> EFI stub and Linux kernel and EFI stub creates these parameters. But
>>> for Xen on ARM when booting with UEFI, Xen will create a minimal DT
>>> providing these parameters for Dom0 and Dom0 is not only Linux
>>> kernel, but also other OS (such as FreeBSD) which will be used in the
>>> future. So here we plan to standardize the names by dropping the
>>> prefix "linux," and make them common to other OS. Also this will not
>>> break the compatibility since these parameters are used to internal
>>> communication between EFI stub and kernel.
>>
>> It is unlikely FreeBSD will use this property when booting ad Xen dom0.
>> The kernel expects to be passed a data structure to find boot this
>> information.
>>
>> My preference would be to have the FreeBSD loader load the xen binary,
>> the FreeBSD kernel, and set up these data structs before passing
>> control to Xen, with the information it needs to boot the kernel. My
>> understanding is this is how it is done on x86.
>
> Well, AFAICT, there is no FreeBSD specific code in Xen for x86. We are
> faking a multiboot module which contains all the informations.
>
> I know that the bootloader is at least involved, I don't remember if
> there is some code in FreeBSD to read this boot module. I've CCed Roger
> to confirm.
The metadata/modules needed by the FreeBSD Dom0 kernel is generated by
the native FreeBSD bootloader (as would be done when booting bare
metal). Then this blob is passed as a multiboot module in the same place
that Linux puts it's initramfs. Xen simply copies this blob straight
into guest memory and sets start_info.mod_start to point to the start
memory address of this blob.
I've done it this way because I don't see many other options. Xen is
tailored for Linux and only allows passing one module to the Dom0 kernel
(initramfs). For FreeBSD it would be good to be able to pass at least
two modules to the Dom0 kernel, one containing the metadata, and the
other one containing the modules themselves. The new PVH work (HVMlite
or whatever) will hopefully allow passing more than one module to the
Dom0 kernel, and should make the code in the FreeBSD loader simpler.
Roger.
WARNING: multiple messages have this Message-ID (diff)
From: roger.pau@citrix.com (Roger Pau Monné)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters
Date: Thu, 10 Sep 2015 14:05:49 +0200 [thread overview]
Message-ID: <55F1721D.1010801@citrix.com> (raw)
In-Reply-To: <55F16DF5.1080705@citrix.com>
El 10/09/15 a les 13.48, Julien Grall ha escrit:
> On 10/09/15 12:32, Andrew Turner wrote:
>> On Thu, 10 Sep 2015 16:41:56 +0800
>> Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> These EFI stub parameters are used to internal communication between
>>> EFI stub and Linux kernel and EFI stub creates these parameters. But
>>> for Xen on ARM when booting with UEFI, Xen will create a minimal DT
>>> providing these parameters for Dom0 and Dom0 is not only Linux
>>> kernel, but also other OS (such as FreeBSD) which will be used in the
>>> future. So here we plan to standardize the names by dropping the
>>> prefix "linux," and make them common to other OS. Also this will not
>>> break the compatibility since these parameters are used to internal
>>> communication between EFI stub and kernel.
>>
>> It is unlikely FreeBSD will use this property when booting ad Xen dom0.
>> The kernel expects to be passed a data structure to find boot this
>> information.
>>
>> My preference would be to have the FreeBSD loader load the xen binary,
>> the FreeBSD kernel, and set up these data structs before passing
>> control to Xen, with the information it needs to boot the kernel. My
>> understanding is this is how it is done on x86.
>
> Well, AFAICT, there is no FreeBSD specific code in Xen for x86. We are
> faking a multiboot module which contains all the informations.
>
> I know that the bootloader is at least involved, I don't remember if
> there is some code in FreeBSD to read this boot module. I've CCed Roger
> to confirm.
The metadata/modules needed by the FreeBSD Dom0 kernel is generated by
the native FreeBSD bootloader (as would be done when booting bare
metal). Then this blob is passed as a multiboot module in the same place
that Linux puts it's initramfs. Xen simply copies this blob straight
into guest memory and sets start_info.mod_start to point to the start
memory address of this blob.
I've done it this way because I don't see many other options. Xen is
tailored for Linux and only allows passing one module to the Dom0 kernel
(initramfs). For FreeBSD it would be good to be able to pass at least
two modules to the Dom0 kernel, one containing the metadata, and the
other one containing the modules themselves. The new PVH work (HVMlite
or whatever) will hopefully allow passing more than one module to the
Dom0 kernel, and should make the code in the FreeBSD loader simpler.
Roger.
next prev parent reply other threads:[~2015-09-10 12:06 UTC|newest]
Thread overview: 182+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-10 8:41 [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Shannon Zhao
2015-09-10 8:41 ` Shannon Zhao
2015-09-10 8:41 ` Shannon Zhao
2015-09-10 9:52 ` Mark Rutland
2015-09-10 9:52 ` Mark Rutland
2015-09-10 9:52 ` Mark Rutland
2015-09-10 9:52 ` Mark Rutland
2015-09-10 10:19 ` Stefano Stabellini
2015-09-10 10:19 ` Stefano Stabellini
2015-09-10 10:19 ` Stefano Stabellini
2015-09-10 10:19 ` Stefano Stabellini
2015-09-10 11:24 ` Mark Rutland
2015-09-10 11:24 ` Mark Rutland
2015-09-10 11:24 ` Mark Rutland
2015-09-10 11:37 ` Stefano Stabellini
2015-09-10 11:37 ` Stefano Stabellini
2015-09-10 11:37 ` Stefano Stabellini
2015-09-10 11:37 ` Stefano Stabellini
2015-09-10 12:15 ` Mark Rutland
2015-09-10 12:15 ` Mark Rutland
2015-09-10 12:15 ` Mark Rutland
2015-09-10 12:15 ` Mark Rutland
2015-09-10 12:58 ` Ian Campbell
2015-09-10 12:58 ` [Xen-devel] " Ian Campbell
2015-09-10 12:58 ` Ian Campbell
2015-09-10 12:58 ` Ian Campbell
2015-09-10 13:08 ` Jan Beulich
2015-09-10 13:08 ` [Xen-devel] " Jan Beulich
2015-09-10 13:08 ` Jan Beulich
2015-09-10 13:08 ` Jan Beulich
2015-09-10 13:30 ` Ian Campbell
2015-09-10 13:30 ` Ian Campbell
2015-09-10 13:30 ` Ian Campbell
2015-09-10 13:30 ` Ian Campbell
2015-09-10 13:52 ` Stefano Stabellini
2015-09-10 13:52 ` Stefano Stabellini
2015-09-10 13:52 ` Stefano Stabellini
2015-09-10 13:52 ` Stefano Stabellini
2015-09-10 14:13 ` Leif Lindholm
2015-09-10 14:13 ` Leif Lindholm
2015-09-10 14:13 ` Leif Lindholm
2015-09-10 14:13 ` Leif Lindholm
2015-09-10 14:49 ` Mark Rutland
2015-09-10 14:49 ` Mark Rutland
2015-09-10 14:49 ` Mark Rutland
2015-09-10 16:10 ` Stefano Stabellini
2015-09-10 16:10 ` Stefano Stabellini
2015-09-10 16:10 ` Stefano Stabellini
2015-09-10 16:10 ` Stefano Stabellini
2015-09-10 16:23 ` Mark Rutland
2015-09-10 16:23 ` Mark Rutland
2015-09-10 16:23 ` Mark Rutland
2015-09-10 16:23 ` Mark Rutland
2015-09-11 12:46 ` Daniel Kiper
2015-09-11 12:46 ` Daniel Kiper
2015-09-11 12:46 ` Daniel Kiper
2015-09-11 13:14 ` Stefano Stabellini
2015-09-11 13:14 ` Stefano Stabellini
2015-09-11 13:14 ` Stefano Stabellini
2015-09-11 13:30 ` Ard Biesheuvel
2015-09-11 13:30 ` Ard Biesheuvel
2015-09-11 13:30 ` Ard Biesheuvel
2015-09-11 15:45 ` Daniel Kiper
2015-09-11 15:45 ` Daniel Kiper
2015-09-11 15:45 ` Daniel Kiper
2015-09-11 15:45 ` Daniel Kiper
2015-09-14 8:42 ` Shannon Zhao
2015-09-14 8:42 ` Shannon Zhao
2015-09-14 8:42 ` Shannon Zhao
2015-09-14 9:09 ` Ard Biesheuvel
2015-09-14 9:09 ` Ard Biesheuvel
2015-09-14 9:09 ` Ard Biesheuvel
2015-09-14 9:09 ` Ard Biesheuvel
2015-09-14 9:31 ` Shannon Zhao
2015-09-14 9:31 ` Shannon Zhao
2015-09-14 9:31 ` Shannon Zhao
2015-09-14 9:36 ` Ard Biesheuvel
2015-09-14 9:36 ` Ard Biesheuvel
2015-09-14 9:36 ` Ard Biesheuvel
2015-09-14 10:39 ` Jan Beulich
2015-09-14 10:39 ` [Xen-devel] " Jan Beulich
2015-09-14 10:39 ` Jan Beulich
2015-09-14 10:39 ` Jan Beulich
2015-09-14 11:16 ` Ard Biesheuvel
2015-09-14 11:16 ` [Xen-devel] " Ard Biesheuvel
2015-09-14 11:16 ` Ard Biesheuvel
2015-09-14 11:16 ` Ard Biesheuvel
2015-09-14 11:34 ` Jan Beulich
2015-09-14 11:34 ` Jan Beulich
2015-09-14 11:34 ` Jan Beulich
2015-09-14 11:34 ` Jan Beulich
2015-09-14 9:36 ` Ard Biesheuvel
2015-09-11 16:33 ` Mark Rutland
2015-09-11 16:33 ` Mark Rutland
2015-09-11 16:33 ` Mark Rutland
2015-09-11 16:33 ` Mark Rutland
2015-09-11 13:30 ` Ard Biesheuvel
2015-09-11 13:14 ` Stefano Stabellini
2015-09-11 16:25 ` Mark Rutland
2015-09-11 16:25 ` Mark Rutland
2015-09-11 16:25 ` Mark Rutland
2015-09-11 16:25 ` Mark Rutland
2015-09-12 11:36 ` Daniel Kiper
2015-09-12 11:36 ` Daniel Kiper
2015-09-12 11:36 ` Daniel Kiper
2015-09-14 9:25 ` Mark Rutland
2015-09-14 9:25 ` Mark Rutland
2015-09-14 9:25 ` Mark Rutland
2015-09-14 9:25 ` Mark Rutland
2015-09-14 9:43 ` Ard Biesheuvel
2015-09-14 9:43 ` Ard Biesheuvel
2015-09-14 9:57 ` Ian Campbell
[not found] ` <CAKv+Gu9ER1cKvPHobq-wo7ggPesJj4OQ7=aTr24GVpubHvVqjQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-14 9:57 ` Ian Campbell
2015-09-14 9:57 ` Ian Campbell
2015-09-14 10:02 ` Ard Biesheuvel
[not found] ` <1442224673.3549.131.camel-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
2015-09-14 10:02 ` Ard Biesheuvel
2015-09-14 10:02 ` Ard Biesheuvel
2015-09-14 10:25 ` Ian Campbell
[not found] ` <CAKv+Gu_Gh649EwdtodLY9Q28JhqYg8o6RShXXH1ZbxsfYRfi2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-14 10:25 ` Ian Campbell
2015-09-14 10:25 ` Ian Campbell
2015-09-14 12:28 ` Daniel Kiper
2015-09-14 12:28 ` Daniel Kiper
2015-09-14 13:09 ` Ard Biesheuvel
[not found] ` <20150914122858.GI4530-fJNZiO034lp9pOct4yEdx/3oZC3j2Omk@public.gmane.org>
2015-09-14 13:09 ` Ard Biesheuvel
2015-09-14 13:09 ` Ard Biesheuvel
[not found] ` <CAKv+Gu_z2X=9-qgoKTS7dKLqtSUvysyu9LzZryJqcSR4X8Ss6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-09-14 13:57 ` Daniel Kiper
2015-09-14 13:57 ` Daniel Kiper
2015-09-14 13:57 ` Daniel Kiper
2015-09-14 12:28 ` Daniel Kiper
2015-09-14 9:43 ` Ard Biesheuvel
2015-09-14 9:47 ` Stefano Stabellini
2015-09-14 9:47 ` Stefano Stabellini
2015-09-14 9:47 ` Stefano Stabellini
2015-09-14 9:47 ` Stefano Stabellini
2015-09-14 12:19 ` Daniel Kiper
2015-09-14 12:19 ` Daniel Kiper
2015-09-14 12:19 ` Daniel Kiper
2015-09-14 12:19 ` Daniel Kiper
2015-09-12 11:36 ` Daniel Kiper
2015-09-11 12:46 ` Daniel Kiper
2015-09-11 11:00 ` Ian Campbell
2015-09-11 11:00 ` Ian Campbell
2015-09-11 11:00 ` Ian Campbell
2015-09-11 11:00 ` Ian Campbell
2015-09-10 14:49 ` Mark Rutland
2015-09-10 12:55 ` Jan Beulich
2015-09-10 12:55 ` Jan Beulich
2015-09-10 12:55 ` Jan Beulich
2015-09-10 12:55 ` Jan Beulich
2015-09-10 14:53 ` Mark Rutland
2015-09-10 14:53 ` Mark Rutland
2015-09-10 14:53 ` Mark Rutland
2015-09-10 15:06 ` Jan Beulich
2015-09-10 15:06 ` Jan Beulich
2015-09-10 15:06 ` Jan Beulich
2015-09-11 16:36 ` Mark Rutland
2015-09-11 16:36 ` Mark Rutland
2015-09-11 16:36 ` Mark Rutland
2015-09-11 16:36 ` Mark Rutland
2015-09-10 15:06 ` Jan Beulich
2015-09-10 11:24 ` Mark Rutland
2015-09-10 11:32 ` Andrew Turner
2015-09-10 11:32 ` Andrew Turner
2015-09-10 11:32 ` Andrew Turner
2015-09-10 11:32 ` Andrew Turner
2015-09-10 11:48 ` Julien Grall
2015-09-10 11:48 ` Julien Grall
2015-09-10 11:48 ` Julien Grall
2015-09-10 11:48 ` Julien Grall
2015-09-10 12:05 ` Roger Pau Monné
2015-09-10 12:05 ` Roger Pau Monné [this message]
2015-09-10 12:05 ` Roger Pau Monné
2015-09-10 12:05 ` Roger Pau Monné
2015-09-10 12:53 ` Julien Grall
2015-09-10 12:53 ` [Xen-devel] " Julien Grall
2015-09-10 12:53 ` Julien Grall
2015-09-10 12:53 ` Julien Grall
2015-09-17 11:43 ` Shannon Zhao
2015-09-17 11:43 ` Shannon Zhao
2015-09-17 11:43 ` Shannon Zhao
2015-09-17 11:43 ` Shannon Zhao
-- strict thread matches above, loose matches on Subject: below --
2015-09-10 8:41 Shannon Zhao
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=55F1721D.1010801@citrix.com \
--to=roger.pau@citrix.com \
--cc=andrew@fubar.geek.nz \
--cc=ard.biesheuvel@linaro.org \
--cc=christoffer.dall@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=freebsd-arm@freebsd.org \
--cc=ian.campbell@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien.grall@citrix.com \
--cc=leif.lindholm@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=peter.huangpeng@huawei.com \
--cc=shannon.zhao@linaro.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=zhaoshenglong@huawei.com \
/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.