From: "Aiqun Yu (Maria)" <quic_aiquny@quicinc.com>
To: Marc Zyngier <maz@kernel.org>, Arnd Bergmann <arnd@arndb.de>
Cc: <kvmarm@lists.linux.dev>, <linux-arm-kernel@lists.infradead.org>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
Mark Rutland <mark.rutland@arm.com>,
Joey Gouly <joey.gouly@arm.com>, Will Deacon <will@kernel.org>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
Linaro Kernel Functional Testing <lkft@linaro.org>
Subject: Re: [PATCH] KVM: arm64: nv: Work around lack of pauth support in old toolchains
Date: Wed, 24 Apr 2024 09:54:05 +0800 [thread overview]
Message-ID: <71adaafe-5075-4508-b9a6-f009531cf99b@quicinc.com> (raw)
In-Reply-To: <86le54qclu.wl-maz@kernel.org>
On 4/24/2024 12:15 AM, Marc Zyngier wrote:
> On Tue, 23 Apr 2024 13:37:09 +0100,
> "Arnd Bergmann" <arnd@arndb.de> wrote:
>>
>> On Tue, Apr 23, 2024, at 14:06, Marc Zyngier wrote:
>>> On Tue, 23 Apr 2024 13:00:55 +0100,
>>> "Aiqun Yu (Maria)" <quic_aiquny@quicinc.com> wrote:
>>>> On 4/23/2024 4:24 PM, Arnd Bergmann wrote:
>>>>> On Tue, Apr 23, 2024, at 00:48, Marc Zyngier wrote:
>>>>>> We still support GCC 8.x, and it appears that this toolchain
>>>>>> does not understand "pauth" as a valid architectural extension.
>>>>>> After all, it's only been 8 years since ARMv8.3 was released...
>>>>>
>>>>> Just to clarify: I'm fairly sure that all supported toolchains
>>>>> support ARMv8.3 and PACGA, the problem with ".arch_extension pauth\n"
>>>>> seems to be that it was retroactively made an optional
>>>>> feature for earlier architecture versions a few years after
>>>>> ARMv8.3, so most binutils versions we support understand
>>>>> pacga as an armv8.3 feature but reject the pauth name for the
>>>>> extension.
>>>> Kind of agree with Arnd here.
>>>> Shall the fix just remove the ".arch_extension pauth"?
>>>>
>>>> I've tried gcc 7 failed with the pauth name for the extension.
>>>> After I remove the ".arch_extension pauth" and use "pacga" instruction
>>>> directly pass the gcc 7 compilation.
>>
>> It really depends on the binutils version, not gcc of course.
>
> Right. I'll amend the commit message to reflect that.
>
>>
>>> And breaks with LLVM:
>>>
>>> CC arch/arm64/kvm/pauth.o
>>> arch/arm64/kvm/pauth.c:40:9: error: instruction requires: pauth
>>> "pacga %0, %1, %2" : "=r" (pac) : "r" (ptr), "r" (mod));
>>> ^
>>> <inline asm>:2:1: note: instantiated into assembly here
>>> pacga x19, x1, x9
>>> ^
>>
>> It works when building with LLVM_IAS=0, which we obviously don't
>> want to mandate here. The variant below works for both clang+ias
>> (including all still supported versions) and gcc+binutils, but at
>> that point it gets obscure enough that your .inst version is easier
>> to understand.
>
> Exactly. Either we have a good way to abstract this behind the scenes
> (which I don't see right now), or we just assume control of the
> instruction generation, which is what my patch does.
Ack.
>
> In general, I question the value of the ".arch_extension" requirement
> for something like Linux, where we already have a pretty fine grained
> control of what we want to see being output by the compiler. but that
> ship has sailed long ago.
>
> Thanks,
>
> M.
>
>>
>> arnd
>>
>> --- a/arch/arm64/kvm/pauth.c
>> +++ b/arch/arm64/kvm/pauth.c
>> @@ -36,7 +36,12 @@ static u64 compute_pac(struct kvm_vcpu *vcpu, u64 ptr,
>> __ptrauth_key_install_nosync(APGA, ikey);
>> isb();
>>
>> - asm volatile(ARM64_ASM_PREAMBLE ".arch_extension pauth\n"
>> + asm volatile(ARM64_ASM_PREAMBLE
>> +#ifdef CONFIG_AS_IS_LLVM
>> + ".arch_extension pauth\n"
>> +#else
>> + ".arch armv8.3-a\n"
>> +#endif
>> "pacga %0, %1, %2" : "=r" (pac) : "r" (ptr), "r" (mod));
>> isb();
>>
>>
>
--
Thx and BRs,
Aiqun(Maria) Yu
next prev parent reply other threads:[~2024-04-24 1:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 22:48 [PATCH] KVM: arm64: nv: Work around lack of pauth support in old toolchains Marc Zyngier
2024-04-23 8:24 ` Arnd Bergmann
2024-04-23 12:00 ` Aiqun Yu (Maria)
2024-04-23 12:06 ` Marc Zyngier
2024-04-23 12:37 ` Arnd Bergmann
2024-04-23 16:15 ` Marc Zyngier
2024-04-24 1:54 ` Aiqun Yu (Maria) [this message]
2024-04-23 8:37 ` Mark Rutland
2024-04-23 11:33 ` Marc Zyngier
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=71adaafe-5075-4508-b9a6-f009531cf99b@quicinc.com \
--to=quic_aiquny@quicinc.com \
--cc=arnd@arndb.de \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lkft@linaro.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).