From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754507AbcHZRKW (ORCPT ); Fri, 26 Aug 2016 13:10:22 -0400 Received: from foss.arm.com ([217.140.101.70]:42142 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754250AbcHZRKV (ORCPT ); Fri, 26 Aug 2016 13:10:21 -0400 Date: Fri, 26 Aug 2016 18:00:34 +0100 From: Catalin Marinas To: Will Deacon Cc: Suzuki K Poulose , Mark Rutland , Ard Biesheuvel , Marc Zyngier , "linux-kernel@vger.kernel.org" , Andre Przywara , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2 9/9] arm64: Work around systems with mismatched cache line sizes Message-ID: <20160826170034.GD15779@e104818-lin.cambridge.arm.com> References: <1472203398-8751-1-git-send-email-suzuki.poulose@arm.com> <1472203398-8751-10-git-send-email-suzuki.poulose@arm.com> <20160826161627.GL30302@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160826161627.GL30302@arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 26, 2016 at 05:16:27PM +0100, Will Deacon wrote: > On Fri, Aug 26, 2016 at 02:08:01PM +0100, Suzuki K Poulose wrote: > > On 26/08/16 14:04, Suzuki K Poulose wrote: > > >On 26/08/16 12:03, Ard Biesheuvel wrote: > > >>IMO, this is a pattern that we should avoid: you are introducing one > > >>instance now, which will make it hard to say no to the next one in the > > >>future. Isn't there a better way to organize the arm64_ftr_reg array > > >>that allows us to reference entries directly? Ideally, a way that gets > > >>rid of the runtime sorting, since I don't think that is a good > > >>replacement for developer discipline anyway (although I should have > > >>spoken up when that was first introduced) Or am I missing something > > >>here? I'm not sure we can have some simple direct access. Suzuki did some grouping originally but I wouldn't call that a direct access either, more like iterating through several groups. A possibility would be to generate global variables for each arm64_ftr_reg with the ARM64_FTR_REG macro extended to also place a pointer in a dedicated section to be used as array. Assembly code would access the global variable directly. But I'm not really sure it's worth it. > > >I had some form of direct access to the feature register in one of > > >the versions [0], but was dropped based on Catalin's suggestion at [1]. > > > > Forgot to add, [0] wouldn't solve this issue cleanly either. It would simply > > speed up the read_system_reg(). So we do need a call to read_system_reg() > > from assembly code, which makes it a little bit tricky. > > It might be worth looking to see if we can pass the ctr as an extra > parameter to the assembly routines that need it. Then you can access it > easily from C code, and if you pass it as 0 that could result in the asm > code reading it from the h/w register, removing the need for the _raw > stuff you add. How often to we need to access a sanitised sysreg from assembly? AFAICT, CTR_EL0 is the first. If we only need it to infer the minimum cache line size, we could as well store the latter in a global variable and access it directly. If we feel brave, we could patch a "mov \reg, #x" instruction in the ?cache_line_size macros (starting with 32 by default, though to make it less cumbersome we'd have to improve the run-time patching code a bit). -- Catalin