All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh@nvidia.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, ardb@kernel.org,
	catalin.marinas@arm.com, james.morse@arm.com, joey.gouly@arm.com,
	maz@kernel.org, will@kernel.org,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v2 6/8] arm64: alternatives: have callbacks take a cap
Date: Thu, 29 Sep 2022 12:01:24 +0100	[thread overview]
Message-ID: <9317eb32-4dc3-c865-a1ac-320a14ebea56@nvidia.com> (raw)
In-Reply-To: <YzV3y361Mj9N+CcW@FVFF77S0Q05N>


On 29/09/2022 11:47, Mark Rutland wrote:
> On Thu, Sep 29, 2022 at 10:53:56AM +0100, Jon Hunter wrote:
>>
>> On 27/09/2022 10:31, Jon Hunter wrote:
>>
>> ...
>>
>>>> diff --git a/arch/arm64/include/asm/alternative-macros.h
>>>> b/arch/arm64/include/asm/alternative-macros.h
>>>> index 7e157ab6cd505..189c31be163ce 100644
>>>> --- a/arch/arm64/include/asm/alternative-macros.h
>>>> +++ b/arch/arm64/include/asm/alternative-macros.h
>>>> @@ -2,10 +2,16 @@
>>>>    #ifndef __ASM_ALTERNATIVE_MACROS_H
>>>>    #define __ASM_ALTERNATIVE_MACROS_H
>>>> +#include <linux/const.h>
>>>> +
>>>>    #include <asm/cpucaps.h>
>>>>    #include <asm/insn-def.h>
>>>> -#define ARM64_CB_PATCH ARM64_NCAPS
>>>> +#define ARM64_CB_BIT    (UL(1) << 15)
>>>> +
>>>> +#if ARM64_NCAPS >= ARM64_CB_BIT
>>>> +#error "cpucaps have overflown ARM64_CB_BIT"
>>>> +#endif
>>>
>>>
>>> Some of our builders are failing and bisect is pointing to this commit.
>>> Looks like they don't like the above and I see the following errors ...
>>>
>>>     CC      arch/arm64/kvm/hyp/vhe/debug-sr.o
>>> /tmp/ccY3kbki.s: Assembler messages:
>>> /tmp/ccY3kbki.s:1600: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1600: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1600: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1600: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1600: Error: junk at end of line, first unrecognized
>>> character is `L'
>>> /tmp/ccY3kbki.s:1723: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1723: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1723: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1723: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1723: Error: junk at end of line, first unrecognized
>>> character is `L'
>>> scripts/Makefile.build:249: recipe for target
>>> 'arch/arm64/kvm/hyp/vhe/debug-sr.o' failed
>>>
>>> Seems that it does not like the 'UL' macro for some reason. Any thoughts?
>>
>>
>> FYI, this issue is seen with GCC6 but GCC7 and beyond appear to work fine.
> 
> Hmm... IIRC there was an issue with some older binutils here not liking the UL
> suffix, but I thought we'd moved beyond those versions now; can you tell me
> exactly which binutils version you're using?
> 
> I currently can't run the kernel.org crosstool GCC 5.5.0 release on my machine
> since something's going wrong looking for an older version of libisl.so than my
> system provides; I'll see if I can get that going and test locally.
> 
> I suspect we can bodge around this with something like the diff below.
> 
> Thanks,
> Mark.
> 
> ---->8----
> diff --git a/arch/arm64/include/asm/alternative-macros.h b/arch/arm64/include/asm/alternative-macros.h
> index 966767debaa3..4dd23bdbfb9e 100644
> --- a/arch/arm64/include/asm/alternative-macros.h
> +++ b/arch/arm64/include/asm/alternative-macros.h
> @@ -2,12 +2,14 @@
>   #ifndef __ASM_ALTERNATIVE_MACROS_H
>   #define __ASM_ALTERNATIVE_MACROS_H
>   
> +#include <linux/bits.h>
>   #include <linux/const.h>
>   
>   #include <asm/cpucaps.h>
>   #include <asm/insn-def.h>
>   
> -#define ARM64_CB_BIT	(UL(1) << 15)
> +#define ARM64_CB_SHIFT	15
> +#define ARM64_CB_BIT	BIT(ARM64_CB_SHIFT)
>   
>   #if ARM64_NCAPS >= ARM64_CB_BIT
>   #error "cpucaps have overflown ARM64_CB_BIT"
> @@ -80,7 +82,7 @@
>   	__ALTERNATIVE_CFG(oldinstr, newinstr, feature, IS_ENABLED(cfg))
>   
>   #define ALTERNATIVE_CB(oldinstr, feature, cb) \
> -	__ALTERNATIVE_CFG_CB(oldinstr, ARM64_CB_BIT | (feature), 1, cb)
> +	__ALTERNATIVE_CFG_CB(oldinstr, (1 << ARM64_CB_SHIFT) | (feature), 1, cb)
>   #else
>   
>   #include <asm/assembler.h>
> @@ -150,7 +152,7 @@
>   .macro alternative_cb cap, cb
>   	.set .Lasm_alt_mode, 0
>   	.pushsection .altinstructions, "a"
> -	altinstruction_entry 661f, \cb, ARM64_CB_BIT | \cap, 662f-661f, 0
> +	altinstruction_entry 661f, \cb, (1 << ARM64_CB_SHIFT) | \cap, 662f-661f, 0
>   	.popsection
>   661:
>   .endm


Yes that fixes it.

Tested-by: Jon Hunter <jonathanh@nvidia.com>

Cheers
Jon

-- 
nvpublic

WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jonathanh@nvidia.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, ardb@kernel.org,
	catalin.marinas@arm.com, james.morse@arm.com, joey.gouly@arm.com,
	maz@kernel.org, will@kernel.org,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v2 6/8] arm64: alternatives: have callbacks take a cap
Date: Thu, 29 Sep 2022 12:01:24 +0100	[thread overview]
Message-ID: <9317eb32-4dc3-c865-a1ac-320a14ebea56@nvidia.com> (raw)
In-Reply-To: <YzV3y361Mj9N+CcW@FVFF77S0Q05N>


On 29/09/2022 11:47, Mark Rutland wrote:
> On Thu, Sep 29, 2022 at 10:53:56AM +0100, Jon Hunter wrote:
>>
>> On 27/09/2022 10:31, Jon Hunter wrote:
>>
>> ...
>>
>>>> diff --git a/arch/arm64/include/asm/alternative-macros.h
>>>> b/arch/arm64/include/asm/alternative-macros.h
>>>> index 7e157ab6cd505..189c31be163ce 100644
>>>> --- a/arch/arm64/include/asm/alternative-macros.h
>>>> +++ b/arch/arm64/include/asm/alternative-macros.h
>>>> @@ -2,10 +2,16 @@
>>>>    #ifndef __ASM_ALTERNATIVE_MACROS_H
>>>>    #define __ASM_ALTERNATIVE_MACROS_H
>>>> +#include <linux/const.h>
>>>> +
>>>>    #include <asm/cpucaps.h>
>>>>    #include <asm/insn-def.h>
>>>> -#define ARM64_CB_PATCH ARM64_NCAPS
>>>> +#define ARM64_CB_BIT    (UL(1) << 15)
>>>> +
>>>> +#if ARM64_NCAPS >= ARM64_CB_BIT
>>>> +#error "cpucaps have overflown ARM64_CB_BIT"
>>>> +#endif
>>>
>>>
>>> Some of our builders are failing and bisect is pointing to this commit.
>>> Looks like they don't like the above and I see the following errors ...
>>>
>>>     CC      arch/arm64/kvm/hyp/vhe/debug-sr.o
>>> /tmp/ccY3kbki.s: Assembler messages:
>>> /tmp/ccY3kbki.s:1600: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1600: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1600: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1600: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1600: Error: junk at end of line, first unrecognized
>>> character is `L'
>>> /tmp/ccY3kbki.s:1723: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1723: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1723: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1723: Error: found 'L', expected: ')'
>>> /tmp/ccY3kbki.s:1723: Error: junk at end of line, first unrecognized
>>> character is `L'
>>> scripts/Makefile.build:249: recipe for target
>>> 'arch/arm64/kvm/hyp/vhe/debug-sr.o' failed
>>>
>>> Seems that it does not like the 'UL' macro for some reason. Any thoughts?
>>
>>
>> FYI, this issue is seen with GCC6 but GCC7 and beyond appear to work fine.
> 
> Hmm... IIRC there was an issue with some older binutils here not liking the UL
> suffix, but I thought we'd moved beyond those versions now; can you tell me
> exactly which binutils version you're using?
> 
> I currently can't run the kernel.org crosstool GCC 5.5.0 release on my machine
> since something's going wrong looking for an older version of libisl.so than my
> system provides; I'll see if I can get that going and test locally.
> 
> I suspect we can bodge around this with something like the diff below.
> 
> Thanks,
> Mark.
> 
> ---->8----
> diff --git a/arch/arm64/include/asm/alternative-macros.h b/arch/arm64/include/asm/alternative-macros.h
> index 966767debaa3..4dd23bdbfb9e 100644
> --- a/arch/arm64/include/asm/alternative-macros.h
> +++ b/arch/arm64/include/asm/alternative-macros.h
> @@ -2,12 +2,14 @@
>   #ifndef __ASM_ALTERNATIVE_MACROS_H
>   #define __ASM_ALTERNATIVE_MACROS_H
>   
> +#include <linux/bits.h>
>   #include <linux/const.h>
>   
>   #include <asm/cpucaps.h>
>   #include <asm/insn-def.h>
>   
> -#define ARM64_CB_BIT	(UL(1) << 15)
> +#define ARM64_CB_SHIFT	15
> +#define ARM64_CB_BIT	BIT(ARM64_CB_SHIFT)
>   
>   #if ARM64_NCAPS >= ARM64_CB_BIT
>   #error "cpucaps have overflown ARM64_CB_BIT"
> @@ -80,7 +82,7 @@
>   	__ALTERNATIVE_CFG(oldinstr, newinstr, feature, IS_ENABLED(cfg))
>   
>   #define ALTERNATIVE_CB(oldinstr, feature, cb) \
> -	__ALTERNATIVE_CFG_CB(oldinstr, ARM64_CB_BIT | (feature), 1, cb)
> +	__ALTERNATIVE_CFG_CB(oldinstr, (1 << ARM64_CB_SHIFT) | (feature), 1, cb)
>   #else
>   
>   #include <asm/assembler.h>
> @@ -150,7 +152,7 @@
>   .macro alternative_cb cap, cb
>   	.set .Lasm_alt_mode, 0
>   	.pushsection .altinstructions, "a"
> -	altinstruction_entry 661f, \cb, ARM64_CB_BIT | \cap, 662f-661f, 0
> +	altinstruction_entry 661f, \cb, (1 << ARM64_CB_SHIFT) | \cap, 662f-661f, 0
>   	.popsection
>   661:
>   .endm


Yes that fixes it.

Tested-by: Jon Hunter <jonathanh@nvidia.com>

Cheers
Jon

-- 
nvpublic

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-09-29 11:01 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-12 16:22 [PATCH v2 0/8] arm64: alternatives: improvements Mark Rutland
2022-09-12 16:22 ` [PATCH v2 1/8] arm64: cpufeature: make cpus_have_cap() noinstr-safe Mark Rutland
2022-09-12 16:22 ` [PATCH v2 2/8] arm64: alternatives: kvm: prepare for cap changes Mark Rutland
2022-09-12 16:22 ` [PATCH v2 3/8] arm64: alternatives: proton-pack: " Mark Rutland
2022-09-12 16:22 ` [PATCH v2 4/8] arm64: alternatives: hoist print out of __apply_alternatives() Mark Rutland
2022-09-12 16:22 ` [PATCH v2 5/8] arm64: alternatives: make alt_region const Mark Rutland
2022-09-12 16:22 ` [PATCH v2 6/8] arm64: alternatives: have callbacks take a cap Mark Rutland
2022-09-27  9:31   ` Jon Hunter
2022-09-27  9:31     ` Jon Hunter
2022-09-29  9:53     ` Jon Hunter
2022-09-29  9:53       ` Jon Hunter
2022-09-29 10:10       ` Ard Biesheuvel
2022-09-29 10:10         ` Ard Biesheuvel
2022-09-29 10:48         ` Jon Hunter
2022-09-29 10:48           ` Jon Hunter
2022-09-29 10:47       ` Mark Rutland
2022-09-29 10:47         ` Mark Rutland
2022-09-29 11:01         ` Jon Hunter [this message]
2022-09-29 11:01           ` Jon Hunter
2022-09-29 11:09           ` Mark Rutland
2022-09-29 11:09             ` Mark Rutland
2022-09-29 13:37             ` Jon Hunter
2022-09-29 13:37               ` Jon Hunter
2022-09-29 14:38               ` Mark Rutland
2022-09-29 14:38                 ` Mark Rutland
2022-09-12 16:22 ` [PATCH v2 7/8] arm64: alternatives: add alternative_has_feature_*() Mark Rutland
2022-09-16 11:13   ` Catalin Marinas
2022-09-17 12:52     ` Mark Rutland
2022-09-19 17:01   ` Nathan Chancellor
2022-09-19 17:01     ` Nathan Chancellor
2022-09-20 12:09     ` Mark Rutland
2022-09-20 12:09       ` Mark Rutland
2022-09-20 13:31       ` Nathan Chancellor
2022-09-20 13:31         ` Nathan Chancellor
2022-09-12 16:22 ` [PATCH v2 8/8] arm64: alternatives: add shared NOP callback Mark Rutland
2022-09-13 13:36 ` [PATCH v2 0/8] arm64: alternatives: improvements Ard Biesheuvel
2022-09-16 17:46 ` Catalin Marinas
2022-09-17 12:46   ` Mark Rutland

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=9317eb32-4dc3-c865-a1ac-320a14ebea56@nvidia.com \
    --to=jonathanh@nvidia.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=will@kernel.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.