From: Shannon Zhao <shannon.zhao@linaro.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>,
Ingo Molnar <mingo@kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Xen Devel <Xen-devel@lists.xensource.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Borislav Petkov <bp@alien8.de>
Subject: Re: efi_enabled(EFI_PARAVIRT) use
Date: Sat, 30 Apr 2016 22:04:03 +0800 [thread overview]
Message-ID: <5724BB53.40202@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.10.1604291634000.3312@sstabellini-ThinkPad-X260>
On 2016年04月29日 23:37, Stefano Stabellini wrote:
> On Fri, 29 Apr 2016, Stefano Stabellini wrote:
>> On Fri, 29 Apr 2016, Matt Fleming wrote:
>>> On Fri, 29 Apr, at 11:34:45AM, Stefano Stabellini wrote:
>>>> On Fri, 29 Apr 2016, Ingo Molnar wrote:
>>>>> Also, it would be nice to have all things EFI in a single tree, the conflicts are
>>>>> going to be painful! There's very little reason not to carry this kind of commit:
>>>>>
>>>>> arch/arm/xen/enlighten.c | 6 +++++
>>>>> drivers/firmware/efi/arm-runtime.c | 17 +++++++++-----
>>>>> drivers/firmware/efi/efi.c | 45 ++++++++++++++++++++++++++++++++------
>>>>> 3 files changed, 56 insertions(+), 12 deletions(-)
>>>>>
>>>>> in the EFI tree.
>>>>
>>>> That's true. I'll drop this commit from xentip and let Matt pick it up
>>>> or request changes as he sees fit.
>>>
>>> One small change I think would be sensible to make is to expand
>>> EFI_PARAVIRT into a few more bits to clearly indicate the quirks on
>>> Xen, and in the process, to delete EFI_PARAVIRT.
>>>
>>> That should address Ingo's major concern, and also make it much easier
>>> to rework the code in a piecemeal fashion.
>>>
>>> Could somebody enumerate the things that make Xen (dom0) different on
>>> arm* compared with bare metal EFI boot? The list I made for x86 was,
>>>
>>> 1. Has no EFI memory map
>>> 2. Runtime regions do not need to be mapped
>>> 3. Cannot call SetVirtualAddressMap()
>>> 4. /sys/firmware/efi/fw_vendor is invisible
>>>
>>> The first maps to not setting EFI_MEMMAP, the second to not setting
>>> EFI_RUNTIME. If we add EFI_ALREADY_VIRTUAL and EFI_FW_VENDOR_INVISIBLE
>>> to efi.flags that should cover everything on x86. Does arm* require
>>> anything else?
>>
>> Xen on ARM is different, the impact should be limited:
>>
>> - there are no BootServices (ExitBootServices has already been called)
>> - RuntimeServices go via hypercalls
>>
>> The UEFI memory map is still available at an address specified on device
>> tree like on native, but the compatibility string is different
>> ("xen,uefi-mmap-start") to clarify that we are booting on Xen rather
>> than native.
>>
>> That's pretty much it, Shannon please confirm.
>
> This is to say that Xen on ARM might only need EFI_RUNTIME.
>
Yes, it needs EFI_RUNTIME_SERVICES.
Thanks,
--
Shannon
prev parent reply other threads:[~2016-04-30 14:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 4:20 linux-next: manual merge of the xen-tip tree with the tip tree Stephen Rothwell
2016-04-29 6:39 ` efi_enabled(EFI_PARAVIRT) use Ingo Molnar
2016-04-29 6:39 ` Ingo Molnar
2016-04-29 8:25 ` Borislav Petkov
2016-04-29 9:26 ` Matt Fleming
2016-04-29 10:34 ` Stefano Stabellini
2016-04-29 10:46 ` Ingo Molnar
2016-04-29 14:39 ` Matt Fleming
2016-04-29 14:53 ` Ard Biesheuvel
2016-04-30 14:14 ` Shannon Zhao
2016-04-30 20:44 ` Matt Fleming
2016-05-01 3:24 ` Shannon Zhao
2016-05-01 13:26 ` Matt Fleming
2016-05-01 14:36 ` Shannon Zhao
2016-05-02 10:45 ` Matt Fleming
2016-05-03 1:45 ` [Xen-devel] " Shannon Zhao
2016-05-03 1:45 ` Shannon Zhao
2016-05-04 11:36 ` Matt Fleming
2016-05-03 9:13 ` Shannon Zhao
2016-05-03 9:13 ` Shannon Zhao
2016-04-29 14:58 ` Stefano Stabellini
2016-04-29 15:37 ` Stefano Stabellini
2016-04-30 14:04 ` Shannon Zhao [this message]
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=5724BB53.40202@linaro.org \
--to=shannon.zhao@linaro.org \
--cc=Xen-devel@lists.xensource.com \
--cc=ard.biesheuvel@linaro.org \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mcgrof@kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=sstabellini@kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tglx@linutronix.de \
/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.