From: Will Deacon <will.deacon@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
catalin.marinas@arm.com, christoffer.dall@arm.com,
drjones@redhat.com, marc.zyngier@arm.com,
ramana.radhakrishnan@arm.com, awallis@codeaurora.org
Subject: Re: [PATCHv4 05/10] arm64/cpufeature: detect pointer authentication
Date: Wed, 4 Jul 2018 17:09:09 +0100 [thread overview]
Message-ID: <20180704160909.GR4828@arm.com> (raw)
In-Reply-To: <20180525100137.mte5z2sonob3vffq@lakrids.cambridge.arm.com>
On Fri, May 25, 2018 at 11:01:37AM +0100, Mark Rutland wrote:
> On Wed, May 23, 2018 at 09:48:28AM +0100, Suzuki K Poulose wrote:
> > On 03/05/18 14:20, Mark Rutland wrote:
> > > diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> > > index bc51b72fafd4..9dcb4d1b14f5 100644
> > > --- a/arch/arm64/include/asm/cpucaps.h
> > > +++ b/arch/arm64/include/asm/cpucaps.h
> > > @@ -48,7 +48,10 @@
> > > #define ARM64_HAS_CACHE_IDC 27
> > > #define ARM64_HAS_CACHE_DIC 28
> > > #define ARM64_HW_DBM 29
> > > +#define ARM64_HAS_ADDRESS_AUTH_ARCH 30
> > > +#define ARM64_HAS_ADDRESS_AUTH_IMP_DEF 31
> >
> > Where are these caps used ? I couldn't find anything in the series
> > that uses them. Otherwise looks good to me.
>
> Those were consumed by KVM support, which needed to detect if CPUs had
> mismatched support. Currently they're just placeholders as I need a
> cpucap value for the separate IMP-DEF / architected probing cases.
>
> I *could* get rid of those and just have the ARM64_HAS_ADDRESS_AUTH case
> log "Address authentication", but I wanted to have separate messages for
> IMP-DEF vs architected.
Why? Surely it only matters if we find a mixture, and then you'll shout
loudly. I'd certainly be in favour of reducing the number of caps you're
adding here, particularly if they're just there for a line in dmesg.
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 05/10] arm64/cpufeature: detect pointer authentication
Date: Wed, 4 Jul 2018 17:09:09 +0100 [thread overview]
Message-ID: <20180704160909.GR4828@arm.com> (raw)
In-Reply-To: <20180525100137.mte5z2sonob3vffq@lakrids.cambridge.arm.com>
On Fri, May 25, 2018 at 11:01:37AM +0100, Mark Rutland wrote:
> On Wed, May 23, 2018 at 09:48:28AM +0100, Suzuki K Poulose wrote:
> > On 03/05/18 14:20, Mark Rutland wrote:
> > > diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> > > index bc51b72fafd4..9dcb4d1b14f5 100644
> > > --- a/arch/arm64/include/asm/cpucaps.h
> > > +++ b/arch/arm64/include/asm/cpucaps.h
> > > @@ -48,7 +48,10 @@
> > > #define ARM64_HAS_CACHE_IDC 27
> > > #define ARM64_HAS_CACHE_DIC 28
> > > #define ARM64_HW_DBM 29
> > > +#define ARM64_HAS_ADDRESS_AUTH_ARCH 30
> > > +#define ARM64_HAS_ADDRESS_AUTH_IMP_DEF 31
> >
> > Where are these caps used ? I couldn't find anything in the series
> > that uses them. Otherwise looks good to me.
>
> Those were consumed by KVM support, which needed to detect if CPUs had
> mismatched support. Currently they're just placeholders as I need a
> cpucap value for the separate IMP-DEF / architected probing cases.
>
> I *could* get rid of those and just have the ARM64_HAS_ADDRESS_AUTH case
> log "Address authentication", but I wanted to have separate messages for
> IMP-DEF vs architected.
Why? Surely it only matters if we find a mixture, and then you'll shout
loudly. I'd certainly be in favour of reducing the number of caps you're
adding here, particularly if they're just there for a line in dmesg.
Will
next prev parent reply other threads:[~2018-07-04 16:09 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-03 13:20 [PATCHv4 00/10] ARMv8.3 pointer authentication userspace support Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-03 13:20 ` [PATCHv4 01/10] arm64: add pointer authentication register bits Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-03 13:20 ` [PATCHv4 02/10] arm64/kvm: consistently handle host HCR_EL2 flags Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-03 13:20 ` [PATCHv4 03/10] arm64/kvm: hide ptrauth from guests Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-03 13:20 ` [PATCHv4 04/10] arm64: Don't trap host pointer auth use to EL2 Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-03 13:20 ` [PATCHv4 05/10] arm64/cpufeature: detect pointer authentication Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-23 8:48 ` Suzuki K Poulose
2018-05-23 8:48 ` Suzuki K Poulose
2018-05-25 10:01 ` Mark Rutland
2018-05-25 10:01 ` Mark Rutland
2018-07-04 16:09 ` Will Deacon [this message]
2018-07-04 16:09 ` Will Deacon
2018-05-03 13:20 ` [PATCHv4 06/10] arm64: add basic pointer authentication support Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-22 19:08 ` Adam Wallis
2018-05-22 19:08 ` Adam Wallis
2018-05-23 8:42 ` Suzuki K Poulose
2018-05-23 8:42 ` Suzuki K Poulose
2018-05-25 10:18 ` Mark Rutland
2018-05-25 10:18 ` Mark Rutland
2018-06-08 13:11 ` Kristina Martsenko
2018-06-08 13:11 ` Kristina Martsenko
2018-06-08 13:11 ` Kristina Martsenko
2018-05-03 13:20 ` [PATCHv4 07/10] arm64: expose user PAC bit positions via ptrace Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-03 13:20 ` [PATCHv4 08/10] arm64: perf: strip PAC when unwinding userspace Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-03 13:20 ` [PATCHv4 09/10] arm64: enable pointer authentication Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-05-03 13:20 ` [PATCHv4 10/10] arm64: docs: document " Mark Rutland
2018-05-03 13:20 ` Mark Rutland
2018-07-04 16:12 ` [PATCHv4 00/10] ARMv8.3 pointer authentication userspace support Will Deacon
2018-07-04 16:12 ` Will Deacon
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=20180704160909.GR4828@arm.com \
--to=will.deacon@arm.com \
--cc=Suzuki.Poulose@arm.com \
--cc=awallis@codeaurora.org \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@arm.com \
--cc=drjones@redhat.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=ramana.radhakrishnan@arm.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 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.