All of lore.kernel.org
 help / color / mirror / Atom feed
From: cov@codeaurora.org (Christopher Covington)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested
Date: Wed, 10 Sep 2014 10:58:15 -0400	[thread overview]
Message-ID: <54106707.4010006@codeaurora.org> (raw)
In-Reply-To: <CAD=FV=UwfP0x-bswbtV_eUvpKeOSNnsVVLTE3VHguyhm_jiSug@mail.gmail.com>

On 09/05/2014 06:11 PM, Doug Anderson wrote:
> Mark,
> 
> On Thu, Aug 28, 2014 at 2:35 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> Not if you boot Linux at hyp, as we've recommended for this precise
>> reason. That doesn't fix other things like CNTFRQ if the secure
>> initialisation doesn't poke that, however.
> 
> I'll freely admit that I'm out of my league and out of my comfort zone
> here, but...
> 
> In the theory that firmware ought to be as minimal as possible
> (because it's hard to update and hard to keep in sync with kernel
> versions), it seems like firmware ought to start the kernel out in as
> permissive mode as it's willing to provide, right?
> 
> If the kernel is started out as permissive as possible then it can do
> anything it needs to.  Future versions of the kernel can be
> implemented to do any way-cool things that they want to do without an
> update to firmware, right?  ...and current versions of the kernel can
> just shed permissions if they don't want them.
> 
> ...so if I understand correctly, "Secure SVC" mode is more permissive
> than "Non Secure HYP" mode, right?  It looks to me as if we currently
> start the kernel in "Secure SVC" mode.  What do you think about the
> kernel detecting Secure SVC and then dropping down permission levels
> (to Non Secure HYP).  Once it did this, it could update things like
> the virtual offset and then transition down further into non-secure
> SVC mode.
> 
> ...or maybe this has been discussed millions of times already and I'm
> just clueless.  ...or maybe this is just too hard for the kernel to do
> in a generic way?

I think this is a great idea. When running on simulators, it would make (the
non-DTB parts of) the bootwrapper and QEMU's built-in bootloader unnecessary.

Implementing it on AArch64 should be trivial as you can just read CurrentEL
and work from whatever EL/PL you're at. Is there an easy way to check whether
you're in secure or nonsecure mode in AArch32? I seem to recall discussion
about putting this information into the DTB, which makes me think there isn't.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

WARNING: multiple messages have this Message-ID (diff)
From: Christopher Covington <cov@codeaurora.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Russell King <linux@arm.linux.org.uk>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Will Deacon <Will.Deacon@arm.com>,
	Sudeep Holla <Sudeep.Holla@arm.com>,
	Olof Johansson <olof@lixom.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	Sonny Rao <sonnyrao@chromium.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested
Date: Wed, 10 Sep 2014 10:58:15 -0400	[thread overview]
Message-ID: <54106707.4010006@codeaurora.org> (raw)
In-Reply-To: <CAD=FV=UwfP0x-bswbtV_eUvpKeOSNnsVVLTE3VHguyhm_jiSug@mail.gmail.com>

On 09/05/2014 06:11 PM, Doug Anderson wrote:
> Mark,
> 
> On Thu, Aug 28, 2014 at 2:35 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> Not if you boot Linux at hyp, as we've recommended for this precise
>> reason. That doesn't fix other things like CNTFRQ if the secure
>> initialisation doesn't poke that, however.
> 
> I'll freely admit that I'm out of my league and out of my comfort zone
> here, but...
> 
> In the theory that firmware ought to be as minimal as possible
> (because it's hard to update and hard to keep in sync with kernel
> versions), it seems like firmware ought to start the kernel out in as
> permissive mode as it's willing to provide, right?
> 
> If the kernel is started out as permissive as possible then it can do
> anything it needs to.  Future versions of the kernel can be
> implemented to do any way-cool things that they want to do without an
> update to firmware, right?  ...and current versions of the kernel can
> just shed permissions if they don't want them.
> 
> ...so if I understand correctly, "Secure SVC" mode is more permissive
> than "Non Secure HYP" mode, right?  It looks to me as if we currently
> start the kernel in "Secure SVC" mode.  What do you think about the
> kernel detecting Secure SVC and then dropping down permission levels
> (to Non Secure HYP).  Once it did this, it could update things like
> the virtual offset and then transition down further into non-secure
> SVC mode.
> 
> ...or maybe this has been discussed millions of times already and I'm
> just clueless.  ...or maybe this is just too hard for the kernel to do
> in a generic way?

I think this is a great idea. When running on simulators, it would make (the
non-DTB parts of) the bootwrapper and QEMU's built-in bootloader unnecessary.

Implementing it on AArch64 should be trivial as you can just read CurrentEL
and work from whatever EL/PL you're at. Is there an easy way to check whether
you're in secure or nonsecure mode in AArch32? I seem to recall discussion
about putting this information into the DTB, which makes me think there isn't.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.

  parent reply	other threads:[~2014-09-10 14:58 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27 21:03 [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested Sonny Rao
2014-08-27 21:03 ` Sonny Rao
2014-08-27 21:19 ` Olof Johansson
2014-08-27 21:19   ` Olof Johansson
2014-08-27 21:27   ` Sonny Rao
2014-08-27 21:27     ` Sonny Rao
2014-08-27 22:26     ` Stephen Boyd
2014-08-27 22:26       ` Stephen Boyd
2014-08-27 22:33       ` Olof Johansson
2014-08-27 22:33         ` Olof Johansson
2014-08-28  0:56         ` Stephen Boyd
2014-08-28  0:56           ` Stephen Boyd
2014-08-28  2:58           ` Olof Johansson
2014-08-28  2:58             ` Olof Johansson
2014-08-28  3:33             ` Doug Anderson
2014-08-28  3:33               ` Doug Anderson
2014-08-28  9:35               ` Mark Rutland
2014-08-28  9:35                 ` Mark Rutland
2014-08-28 17:09                 ` Christopher Covington
2014-08-28 17:09                   ` Christopher Covington
2014-08-28 18:04                   ` Mark Rutland
2014-08-28 18:04                     ` Mark Rutland
2014-08-29  0:10                 ` Sonny Rao
2014-08-29  0:10                   ` Sonny Rao
2014-08-29 10:04                   ` Mark Rutland
2014-08-29 10:04                     ` Mark Rutland
2014-09-04 17:01                     ` Sonny Rao
2014-09-04 17:01                       ` Sonny Rao
2014-09-04 17:47                       ` Mark Rutland
2014-09-04 17:47                         ` Mark Rutland
2014-09-04 17:48                       ` Lorenzo Pieralisi
2014-09-04 17:48                         ` Lorenzo Pieralisi
2014-09-05 22:11                 ` Doug Anderson
2014-09-05 22:11                   ` Doug Anderson
2014-09-08 13:54                   ` Catalin Marinas
2014-09-08 13:54                     ` Catalin Marinas
2014-09-10 17:17                     ` Doug Anderson
2014-09-10 17:17                       ` Doug Anderson
2014-09-10 17:34                       ` Will Deacon
2014-09-10 17:34                         ` Will Deacon
2014-09-10 18:09                         ` Doug Anderson
2014-09-10 18:09                           ` Doug Anderson
2014-09-10 18:46                           ` Will Deacon
2014-09-10 18:46                             ` Will Deacon
2014-09-10 19:50                             ` Doug Anderson
2014-09-10 19:50                               ` Doug Anderson
2014-09-11  9:57                               ` Will Deacon
2014-09-11  9:57                                 ` Will Deacon
2014-09-11 15:54                                 ` Doug Anderson
2014-09-11 15:54                                   ` Doug Anderson
2014-09-10 14:58                   ` Christopher Covington [this message]
2014-09-10 14:58                     ` Christopher Covington
2014-09-10 15:47                     ` Catalin Marinas
2014-09-10 15:47                       ` Catalin Marinas
2014-09-10 15:55                     ` Mark Rutland
2014-09-10 15:55                       ` Mark Rutland
2014-09-10 16:39                       ` Olof Johansson
2014-09-10 16:39                         ` Olof Johansson
2014-09-10 17:19                       ` Doug Anderson
2014-09-10 17:19                         ` Doug Anderson
2014-08-28  9:23 ` Marc Zyngier
2014-08-28  9:23   ` Marc Zyngier
2014-09-10 17:27 ` Mark Rutland
2014-09-10 17:27   ` Mark Rutland
2014-09-10 17:52   ` Doug Anderson
2014-09-10 17:52     ` Doug Anderson
2014-09-10 18:05     ` Sonny Rao
2014-09-10 18:05       ` Sonny Rao
2014-09-10 18:35     ` Doug Anderson
2014-09-10 18:35       ` Doug Anderson

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=54106707.4010006@codeaurora.org \
    --to=cov@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.