From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752853Ab2GTHKN (ORCPT ); Fri, 20 Jul 2012 03:10:13 -0400 Received: from edison.jonmasters.org ([173.255.233.168]:57326 "EHLO edison.jonmasters.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751353Ab2GTHKJ (ORCPT ); Fri, 20 Jul 2012 03:10:09 -0400 Message-ID: <5009044E.9060908@jonmasters.org> Date: Fri, 20 Jul 2012 03:10:06 -0400 From: Jon Masters Organization: World Organi{s,z}ation of Broken Dreams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Christopher Covington CC: Catalin Marinas , linux-kernel@vger.kernel.org, Arnd Bergmann , Will Deacon References: <1341608777-12982-1-git-send-email-catalin.marinas@arm.com> <1341608777-12982-9-git-send-email-catalin.marinas@arm.com> <50065E6B.3060602@jonmasters.org> <5008445B.2010109@codeaurora.org> In-Reply-To: <5008445B.2010109@codeaurora.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 74.92.29.237 X-SA-Exim-Mail-From: jonathan@jonmasters.org Subject: Re: [PATCH 08/36] AArch64: Kernel booting and initialisation X-SA-Exim-Version: 4.2.1 (built Sun, 08 Nov 2009 07:31:22 +0000) X-SA-Exim-Scanned: Yes (on edison.jonmasters.org) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. >> 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. Jon.