From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754444AbdKANbN (ORCPT ); Wed, 1 Nov 2017 09:31:13 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:47040 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752408AbdKANbH (ORCPT ); Wed, 1 Nov 2017 09:31:07 -0400 Subject: Re: [PATCH v1 1/3] arm64: add a macro for SError synchronization To: gengdongjiu , catalin.marinas@arm.com, will.deacon@arm.com, marc.zyngier@arm.com, christoffer.dall@linaro.org, james.morse@arm.com, mark.rutland@arm.com, ard.biesheuvel@linaro.org, cov@codeaurora.org, Dave.Martin@arm.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu References: <1509563697-6359-1-git-send-email-gengdongjiu@huawei.com> <1509563697-6359-2-git-send-email-gengdongjiu@huawei.com> <6dc82768-8564-a54e-041b-3b9965fa038b@arm.com> From: Robin Murphy Message-ID: <32039c76-8e9b-77e5-dfe6-3f519821a08d@arm.com> Date: Wed, 1 Nov 2017 13:31:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/11/17 12:54, gengdongjiu wrote: > Hi Robin, > > On 2017/11/1 19:24, Robin Murphy wrote: >>> + esb >>> +alternative_else_nop_endif >>> +1: >>> + .endm >> Having a branch in here is pretty horrible, and furthermore using label >> number 1 has a pretty high chance of subtly breaking code where this >> macro is inserted. >> >> Can we not somehow nest or combine the alternative conditions here? > > I found it will report error if combine the alternative conditions here. > > For example: > > + .macro error_synchronize > +alternative_if ARM64_HAS_IESB > +alternative_if ARM64_HAS_RAS_EXTN > + esb > +alternative_else_nop_endif > +alternative_else_nop_endif > + .endm > > And even using b.eq/cbz instruction in the alternative instruction in arch/arm64/kernel/entry.S, > it will report Error. > > For example below > > alternative_if ARM64_HAS_PAN > xxxxxxxxxxxxxxxxxxxx > b.eq xxxxx > alternative_else_nop_endif > > I do not dig it deeply, do you know the reason about it or good suggestion about that? > Thanks a lot in advance. Actually, on second look ARM64_HAS_RAS_EXTN doesn't even matter - ESB is a hint, so if the CPU doesn't have RAS it should behave as a NOP anyway. On which note, since I don't see one here - are any of those other patches defining an "esb" assembly macro similar to the inline asm case? If not then this isn't going to build with older toolchains - perhaps we should just use the raw hint syntax directly. Robin. From mboxrd@z Thu Jan 1 00:00:00 1970 From: robin.murphy@arm.com (Robin Murphy) Date: Wed, 1 Nov 2017 13:31:03 +0000 Subject: [PATCH v1 1/3] arm64: add a macro for SError synchronization In-Reply-To: References: <1509563697-6359-1-git-send-email-gengdongjiu@huawei.com> <1509563697-6359-2-git-send-email-gengdongjiu@huawei.com> <6dc82768-8564-a54e-041b-3b9965fa038b@arm.com> Message-ID: <32039c76-8e9b-77e5-dfe6-3f519821a08d@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 01/11/17 12:54, gengdongjiu wrote: > Hi Robin, > > On 2017/11/1 19:24, Robin Murphy wrote: >>> + esb >>> +alternative_else_nop_endif >>> +1: >>> + .endm >> Having a branch in here is pretty horrible, and furthermore using label >> number 1 has a pretty high chance of subtly breaking code where this >> macro is inserted. >> >> Can we not somehow nest or combine the alternative conditions here? > > I found it will report error if combine the alternative conditions here. > > For example: > > + .macro error_synchronize > +alternative_if ARM64_HAS_IESB > +alternative_if ARM64_HAS_RAS_EXTN > + esb > +alternative_else_nop_endif > +alternative_else_nop_endif > + .endm > > And even using b.eq/cbz instruction in the alternative instruction in arch/arm64/kernel/entry.S, > it will report Error. > > For example below > > alternative_if ARM64_HAS_PAN > xxxxxxxxxxxxxxxxxxxx > b.eq xxxxx > alternative_else_nop_endif > > I do not dig it deeply, do you know the reason about it or good suggestion about that? > Thanks a lot in advance. Actually, on second look ARM64_HAS_RAS_EXTN doesn't even matter - ESB is a hint, so if the CPU doesn't have RAS it should behave as a NOP anyway. On which note, since I don't see one here - are any of those other patches defining an "esb" assembly macro similar to the inline asm case? If not then this isn't going to build with older toolchains - perhaps we should just use the raw hint syntax directly. Robin.