From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH 5/9] clocksource: tegra: Enable ARM arch_timer with TSC Date: Thu, 20 Dec 2012 12:33:42 +0000 Message-ID: <50D305A6.2080904@arm.com> References: <1355996654-6579-1-git-send-email-hdoyu@nvidia.com> <1355996654-6579-6-git-send-email-hdoyu@nvidia.com> <50D2EFFB.8030702@arm.com> <20121220.135758.1347753620353343245.hdoyu@nvidia.com> <50D2FF19.4060600@arm.com> <20121220122246.GA6819@tbergstrom-lnx.Nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <20121220122246.GA6819-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Peter De Schrijver Cc: Hiroshi Doyu , "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "andrew-g2DYL2Zd6BY@public.gmane.org" , "linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org" , "jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org" , "johnstul-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org" , "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" , "linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org" , "tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: linux-tegra@vger.kernel.org On 20/12/12 12:22, Peter De Schrijver wrote: >>>>> + >>>>> + /* CNTFRQ */ >>>>> + asm("mcr p15, 0, %0, c14, c0, 0\n" : : "r" (freq)); >>>>> + asm("mrc p15, 0, %0, c14, c0, 0\n" : "=r" (val)); >>>>> + BUG_ON(val != freq); >>>> >>>> This is scary. CNTFRQ is only writable from secure mode, and will >>>> explode in any other situation. >>>> >>>> Also, writing to CNTFRQ doesn't change the timer frequency! This is just >>>> a way for secure mode to tell the rest of the world the frequency the >>>> timer is ticking at. Unless you've wired the input clock to be able to >>>> change the frequency? >>> >>> ATM, our upstream kernel is expected in secure mode. This situation >>> may be changed later, though.... >> >> I appreciate this. But I expect this kernel to be also used on the >> non-secure side if someone tried to run KVM with it. And this would go >> bang right away. >> > > But the guest wouldn't necessarily have this peripheral, or any other Tegra114 > peripheral for that matter? The problem is not so much the guest but the host. The host has to be booted in non-secure, so just saying "we do not support non-secure" is not a very convincing argument. Unless of course you've already decided that you don't want to support KVM on this SoC... M. -- Jazz is not dead. It just smells funny... From mboxrd@z Thu Jan 1 00:00:00 1970 From: marc.zyngier@arm.com (Marc Zyngier) Date: Thu, 20 Dec 2012 12:33:42 +0000 Subject: [PATCH 5/9] clocksource: tegra: Enable ARM arch_timer with TSC In-Reply-To: <20121220122246.GA6819@tbergstrom-lnx.Nvidia.com> References: <1355996654-6579-1-git-send-email-hdoyu@nvidia.com> <1355996654-6579-6-git-send-email-hdoyu@nvidia.com> <50D2EFFB.8030702@arm.com> <20121220.135758.1347753620353343245.hdoyu@nvidia.com> <50D2FF19.4060600@arm.com> <20121220122246.GA6819@tbergstrom-lnx.Nvidia.com> Message-ID: <50D305A6.2080904@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 20/12/12 12:22, Peter De Schrijver wrote: >>>>> + >>>>> + /* CNTFRQ */ >>>>> + asm("mcr p15, 0, %0, c14, c0, 0\n" : : "r" (freq)); >>>>> + asm("mrc p15, 0, %0, c14, c0, 0\n" : "=r" (val)); >>>>> + BUG_ON(val != freq); >>>> >>>> This is scary. CNTFRQ is only writable from secure mode, and will >>>> explode in any other situation. >>>> >>>> Also, writing to CNTFRQ doesn't change the timer frequency! This is just >>>> a way for secure mode to tell the rest of the world the frequency the >>>> timer is ticking at. Unless you've wired the input clock to be able to >>>> change the frequency? >>> >>> ATM, our upstream kernel is expected in secure mode. This situation >>> may be changed later, though.... >> >> I appreciate this. But I expect this kernel to be also used on the >> non-secure side if someone tried to run KVM with it. And this would go >> bang right away. >> > > But the guest wouldn't necessarily have this peripheral, or any other Tegra114 > peripheral for that matter? The problem is not so much the guest but the host. The host has to be booted in non-secure, so just saying "we do not support non-secure" is not a very convincing argument. Unless of course you've already decided that you don't want to support KVM on this SoC... M. -- Jazz is not dead. It just smells funny... From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752546Ab2LTMdz (ORCPT ); Thu, 20 Dec 2012 07:33:55 -0500 Received: from service87.mimecast.com ([91.220.42.44]:41337 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751602Ab2LTMdq convert rfc822-to-8bit (ORCPT ); Thu, 20 Dec 2012 07:33:46 -0500 Message-ID: <50D305A6.2080904@arm.com> Date: Thu, 20 Dec 2012 12:33:42 +0000 From: Marc Zyngier User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peter De Schrijver CC: Hiroshi Doyu , "linux-tegra@vger.kernel.org" , "andrew@lunn.ch" , "linux@arm.linux.org.uk" , "jason@lakedaemon.net" , "johnstul@us.ibm.com" , "devicetree-discuss@lists.ozlabs.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "rob.herring@calxeda.com" , "tglx@linutronix.de" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 5/9] clocksource: tegra: Enable ARM arch_timer with TSC References: <1355996654-6579-1-git-send-email-hdoyu@nvidia.com> <1355996654-6579-6-git-send-email-hdoyu@nvidia.com> <50D2EFFB.8030702@arm.com> <20121220.135758.1347753620353343245.hdoyu@nvidia.com> <50D2FF19.4060600@arm.com> <20121220122246.GA6819@tbergstrom-lnx.Nvidia.com> In-Reply-To: <20121220122246.GA6819@tbergstrom-lnx.Nvidia.com> X-Enigmail-Version: 1.4.6 X-OriginalArrivalTime: 20 Dec 2012 12:33:44.0024 (UTC) FILETIME=[3FD56D80:01CDDEAE] X-MC-Unique: 112122012334401001 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/12/12 12:22, Peter De Schrijver wrote: >>>>> + >>>>> + /* CNTFRQ */ >>>>> + asm("mcr p15, 0, %0, c14, c0, 0\n" : : "r" (freq)); >>>>> + asm("mrc p15, 0, %0, c14, c0, 0\n" : "=r" (val)); >>>>> + BUG_ON(val != freq); >>>> >>>> This is scary. CNTFRQ is only writable from secure mode, and will >>>> explode in any other situation. >>>> >>>> Also, writing to CNTFRQ doesn't change the timer frequency! This is just >>>> a way for secure mode to tell the rest of the world the frequency the >>>> timer is ticking at. Unless you've wired the input clock to be able to >>>> change the frequency? >>> >>> ATM, our upstream kernel is expected in secure mode. This situation >>> may be changed later, though.... >> >> I appreciate this. But I expect this kernel to be also used on the >> non-secure side if someone tried to run KVM with it. And this would go >> bang right away. >> > > But the guest wouldn't necessarily have this peripheral, or any other Tegra114 > peripheral for that matter? The problem is not so much the guest but the host. The host has to be booted in non-secure, so just saying "we do not support non-secure" is not a very convincing argument. Unless of course you've already decided that you don't want to support KVM on this SoC... M. -- Jazz is not dead. It just smells funny...