Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3303479imm; Fri, 25 May 2018 03:26:04 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq8kp9xYvsKdyNak56vJQXYtCuZRhqTQhL/BORI4+HkvHYI7vK5D8esBbG/ECciTeSD/yEj X-Received: by 2002:a17:902:4203:: with SMTP id g3-v6mr2018552pld.315.1527243964721; Fri, 25 May 2018 03:26:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527243964; cv=none; d=google.com; s=arc-20160816; b=PWw5RxwxrD2kI90qf4HyZ4hOzxzsRNMN7b9WMOyhAfcWEHTPzEvLDCoHRc3M7D1IPJ 5VtFEwtNW4L/Y7VhG97cTwj75ZZennOiSic5t+c9tkG3bOQRHj+5kjIEEumAqCtGAmWN NyFC32MJcok3V9n542/qQ+6MyhYUjmK9McAKmGdMg5N3W21HrVUd8yGQgE3HBmwN1yWJ /Wl5Th2iw0x+L6eIEGf598eRihF8VsGvHqZGqAczsUoUvifbcWhbbrktzjszKDZ/OJ/R X2BQheQp2d1BWW72oKHtMRUFnSkoQArA30qGBAFnkBoXdDTirGeQmzFovFnmHLpqktty FHZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=5/eyLhR8aBc769AA5v5P3MUdb6xP2O+hR6scW2VcHDo=; b=0gdttw08l5sRCOyUPIilsR1jCTElnEcFD1MlirJGwyNwsg+sGqWtO/BgK+qXOOOd2M YuJLH5cWI05BrZbzbIaO8uJ7a1c207Q27h1XfjFqXbTX+0lA5gZkGIWjkuaKr0QNOFGt SoTKGg/qyr9RHvH42IKtfNaeHBbWQqN8hXoEfZNNqB3xcpyZhYjXKcmPMD1QE7clx2ZI 9m/qFX7/BA0sWZ/jwuwk4DrTcrIQlDhKaLnotTvcaE86tsAgtIcv2Qp9rMC5uA7r+Pwq U41/DjrZbuErhgNyhJuZV0++1cjZEpt9q5RretSo+P0dfEn0hh14C8ny47AaPoWVtThN kSZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k75-v6si22615050pfk.369.2018.05.25.03.25.50; Fri, 25 May 2018 03:26:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965858AbeEYKZj (ORCPT + 99 others); Fri, 25 May 2018 06:25:39 -0400 Received: from foss.arm.com ([217.140.101.70]:58828 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965102AbeEYKZi (ORCPT ); Fri, 25 May 2018 06:25:38 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E875180D; Fri, 25 May 2018 03:25:37 -0700 (PDT) Received: from [10.1.206.24] (e112298-lin.cambridge.arm.com [10.1.206.24]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E16E93F578; Fri, 25 May 2018 03:25:35 -0700 (PDT) Subject: Re: [PATCH v4 04/26] arm64: alternative: Apply alternatives early in boot process To: Suzuki K Poulose , linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org, daniel.thompson@linaro.org, joel@joelfernandes.org, marc.zyngier@arm.com, mark.rutland@arm.com, christoffer.dall@arm.com, james.morse@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, Christoffer Dall References: <1527241772-48007-1-git-send-email-julien.thierry@arm.com> <1527241772-48007-5-git-send-email-julien.thierry@arm.com> <89769f8d-2ed0-1eb7-0373-09fc25f8071a@arm.com> From: Julien Thierry Message-ID: <7e579de3-cab2-0677-a3d0-d150ee72f839@arm.com> Date: Fri, 25 May 2018 11:25:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <89769f8d-2ed0-1eb7-0373-09fc25f8071a@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/05/18 11:00, Suzuki K Poulose wrote: > On 25/05/18 10:49, Julien Thierry wrote: >> From: Daniel Thompson >> >> Currently alternatives are applied very late in the boot process (and >> a long time after we enable scheduling). Some alternative sequences, >> such as those that alter the way CPU context is stored, must be applied >> much earlier in the boot sequence. >> >> Introduce apply_boot_alternatives() to allow some alternatives to be >> applied immediately after we detect the CPU features of the boot CPU. >> >> Signed-off-by: Daniel Thompson >> [julien.thierry@arm.com: rename to fit new cpufeature framework better, >>              apply BOOT_SCOPE feature early in boot] >> Signed-off-by: Julien Thierry >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Christoffer Dall >> Cc: Suzuki K Poulose >> --- >>   arch/arm64/include/asm/alternative.h |  3 +-- >>   arch/arm64/include/asm/cpufeature.h  |  2 ++ >>   arch/arm64/kernel/alternative.c      | 30 >> +++++++++++++++++++++++++++--- >>   arch/arm64/kernel/cpufeature.c       |  5 +++++ >>   arch/arm64/kernel/smp.c              |  7 +++++++ >>   5 files changed, 42 insertions(+), 5 deletions(-) >> > > ... > >> +unsigned long boot_capabilities; >> + >>   /* >>    * Flag to indicate if we have computed the system wide >>    * capabilities based on the boot time active CPUs. This >> @@ -1370,6 +1372,9 @@ static void __update_cpu_capabilities(const >> struct arm64_cpu_capabilities *caps, >>           if (!cpus_have_cap(caps->capability) && caps->desc) >>               pr_info("%s %s\n", info, caps->desc); >>           cpus_set_cap(caps->capability); >> + >> +        if (scope_mask & SCOPE_BOOT_CPU) >> +            __set_bit(caps->capability, &boot_capabilities); > > Julien > > I think this check is problematic. The scope_mask passed on by the boot CPU > is (SCOPE_BOOT_CPU | SCOPE_LOCAL_CPU) to cover both BOOT CPU > capabilities *and* > CPU local capabilites on the boot CPU. So, you might apply the > alternatives for > a "local" CPU erratum, which is not intended. You may change the above > check to : > >     if (caps->type & SCOPE_BOOT_CPU) > > to make sure you check the "capability" has the SCOPE_BOOT_CPU set. > Makes sense, I'll do that. Thanks, -- Julien Thierry