Re: [PATCH 08/36] AArch64: Kernel booting and initialisation

[Christopher Covington <cov@codeaurora.org>]

Hi Jon,

On 07/20/2012 03:10 AM, Jon Masters wrote:
> On 07/19/2012 01:31 PM, Christopher Covington wrote:
>> On 07/18/2012 02:57 AM, Jon Masters wrote:
>>> On 07/06/2012 05:05 PM, Catalin Marinas wrote:
>>>
>>>> +- CPU mode
>>>> +  All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError,
>>>> +  IRQ and FIQ).
>>>> +  The CPU must be in either EL2 (RECOMMENDED) or non-secure EL1.
>>
>> Why not secure EL1?
> 
> Because secure world and non-secure world are separated. Although ARMv8
> does define EL0 and EL1 in both secure and non-secure worlds, they're
> really two different things. General purpose OSes run their kernel in
> EL1 (userspace in EL0). We don't ever even see the secure EL1.

I do not understand how the separation between the secure world and
non-secure world affects the ability of separate instances of Linux to
run as the non-secure OS, the secure OS, or both. Is there something
different about secure EL1 that makes it unsuitable for a general
purpose OS? I consider your assumption that the people on this mailing
list will never see their code executed in secure EL1 to be wrong.
Surely on the simulators and development boards that will eventually be
available, the possibility will be there, and explored by somebody.

What I really mean to suggest is that if there's a clear technical
reason for a requirement, give it. If the requirement is really more of
a convention, then say so. If there might be a technical reason but
nobody has bothered to investigate, write that it's untested. Some very
basic explanation of the requirements would make them better, and give
someone looking to support a more exotic use case a helpful starting point.

>>> Even though this stuff is likely to be replaced with the result of some
>>> of the other standardization, I'd like it if you'd strongly consider
>>> removing the "or non-secure EL1". If you give an inch, someone will take
>>> a mile and build a system that enters other than in EL2. Or, something
>>> to the effect of "the highest non-secure exception level implemented"
>>> would be my preference if you don't want to specify.
>>
>> I think it would be best to list the technical limitations, from the
>> kernel's perspective, of the unsupported exception levels and the
>> advantages of the supported exception levels here. If you want to guide
>> system builders towards EL2, I think it'd be more convincing to document
>> the relevant technical aspects (perhaps KVM needs facilities only
>> available in EL2) than just providing an unexplained requirement.
> 
> Unless you enter at EL2 you can never install a hypervisor. That's the
> reason for the requirement for generally entering at EL2 when possible.

That brief explanation would make a useful addition to the documentation
in my opinion.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum