Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Prasad Sodagudi <psodagud@codeaurora.org>,
	Srinivas Ramana <sramana@codeaurora.org>,
	kernel-team@android.com,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Ajay Patil <pajay@qti.qualcomm.com>,
	Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 09/21] arm64: cpufeature: Add global feature override facility
Date: Tue, 12 Jan 2021 11:59:22 +0000	[thread overview]
Message-ID: <168970f2-89d8-4e57-ab8d-59fa52bd830a@arm.com> (raw)
In-Reply-To: <d98aed718a26d0455d5549d53f97db06@kernel.org>

On 1/12/21 11:50 AM, Marc Zyngier wrote:
> Hi Suzuki,
> 
> On 2021-01-12 09:17, Suzuki K Poulose wrote:
>> Hi Marc,
>>
>> On 1/11/21 7:48 PM, Marc Zyngier wrote:
> 
> [...]
> 
>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>> index 894af60b9669..00d99e593b65 100644
>>> --- a/arch/arm64/kernel/cpufeature.c
>>> +++ b/arch/arm64/kernel/cpufeature.c
>>> @@ -774,6 +774,7 @@ static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
>>>       u64 strict_mask = ~0x0ULL;
>>>       u64 user_mask = 0;
>>>       u64 valid_mask = 0;
>>> +    u64 override_val = 0, override_mask = 0;
>>>
>>>       const struct arm64_ftr_bits *ftrp;
>>>       struct arm64_ftr_reg *reg = get_arm64_ftr_reg(sys_reg);
>>> @@ -781,9 +782,35 @@ static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
>>>       if (!reg)
>>>           return;
>>>
>>> +    if (reg->override_mask && reg->override_val) {
>>> +        override_mask = *reg->override_mask;
>>> +        override_val = *reg->override_val;
>>> +    }
>>> +
>>>       for (ftrp = reg->ftr_bits; ftrp->width; ftrp++) {
>>>           u64 ftr_mask = arm64_ftr_mask(ftrp);
>>>           s64 ftr_new = arm64_ftr_value(ftrp, new);
>>> +        s64 ftr_ovr = arm64_ftr_value(ftrp, override_val);
>>> +
>>> +        if ((ftr_mask & override_mask) == ftr_mask) {
>>> +            if (ftr_ovr < ftr_new) {
>>
>> Here we assume that all the features are FTR_LOWER_SAFE. We could
>> probably use arm64_ftr_safe_value(ftrp, ftr_new, ftr_ovr) here ?
>> That would cover us for both HIGHER_SAFE and LOWER_SAFE features.
>> However that may be restrictive for FTR_EXACT, as we the safe
>> value would be set to "ftr->safe_val". I guess that may be better
>> than forcing to use an unsafe value for the boot CPU, which could
>> anyway conflict with the other CPUs and eventually trigger the
>> ftr alue to be safe_val.
> 
> I like the idea of using the helper, as it cleanups up the code a bit.
> However, not being to set a feature to a certain value could be restrictive,
> as in general, it means that we can only disable a feature and not adjust
> its level of support.
> 
> Take PMUVER for example: with the helper, I can't override it from v8.4 to
> v8.1. I can only go to v8.0.

My point is, we set this only for the "init" of cpu features. So, even if we
init to a custom , non-(default-safe) value, the secondary CPUs could scream,
and the system wide safe value could fall back to the "safe" value for EXACT features,
no matter what you did to init it.

Also, it will be dangerous for things like PAC, as the lower level value may
not be compatible with the "actual" cpu feature supported.

So simply setting to a lower value for EXACT features is generally not safe,
though I understand some are exceptions.

Suzuki



> 
> Is it something we care about?
> 
> Thanks,
> 
>          M.

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  parent reply	other threads:[~2021-01-12 11:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 13:27 [PATCH v3 00/21] arm64: Early CPU feature override, and applications to VHE, BTI and PAuth Marc Zyngier
2021-01-11 13:27 ` [PATCH v3 01/21] arm64: Fix labels in el2_setup macros Marc Zyngier
2021-01-11 13:27 ` [PATCH v3 02/21] arm64: Fix outdated TCR setup comment Marc Zyngier
2021-01-11 13:27 ` [PATCH v3 03/21] arm64: Turn the MMU-on sequence into a macro Marc Zyngier
2021-01-11 13:27 ` [PATCH v3 04/21] arm64: Provide an 'upgrade to VHE' stub hypercall Marc Zyngier
2021-01-11 13:53   ` Marc Zyngier
2021-01-11 13:27 ` [PATCH v3 05/21] arm64: Initialise as nVHE before switching to VHE Marc Zyngier
2021-01-11 13:27 ` [PATCH v3 06/21] arm64: Move VHE-specific SPE setup to mutate_to_vhe() Marc Zyngier
2021-01-11 13:27 ` [PATCH v3 07/21] arm64: Simplify init_el2_state to be non-VHE only Marc Zyngier
2021-01-11 13:27 ` [PATCH v3 08/21] arm64: Move SCTLR_EL1 initialisation to EL-agnostic code Marc Zyngier
2021-01-11 13:27 ` [PATCH v3 09/21] arm64: cpufeature: Add global feature override facility Marc Zyngier
2021-01-11 18:41   ` Catalin Marinas
2021-01-11 19:48     ` Marc Zyngier
2021-01-12  9:17       ` Suzuki K Poulose
2021-01-12 11:50         ` Marc Zyngier
2021-01-12 11:51           ` Marc Zyngier
2021-01-12 12:20             ` Suzuki K Poulose
2021-01-12 11:59           ` Suzuki K Poulose [this message]
2021-01-12 14:54             ` Marc Zyngier
2021-01-11 20:38     ` Srinivas Ramana
2021-01-11 13:28 ` [PATCH v3 10/21] arm64: cpufeature: Use IDreg override in __read_sysreg_by_encoding() Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 11/21] arm64: Extract early FDT mapping from kaslr_early_init() Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 12/21] arm64: cpufeature: Add an early command-line cpufeature override facility Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 13/21] arm64: Allow ID_AA64MMFR1_EL1.VH to be overridden from the command line Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 14/21] arm64: Honor VHE being disabled from the command-line Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 15/21] arm64: Add an aliasing facility for the idreg override Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 16/21] arm64: Make kvm-arm.mode={nvhe, protected} an alias of id_aa64mmfr1.vh=0 Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 17/21] KVM: arm64: Document HVC_VHE_RESTART stub hypercall Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 18/21] arm64: Move "nokaslr" over to the early cpufeature infrastructure Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 19/21] arm64: cpufeatures: Allow disabling of BTI from the command-line Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 20/21] arm64: Defer enabling pointer authentication on boot core Marc Zyngier
2021-01-11 13:28 ` [PATCH v3 21/21] arm64: cpufeatures: Allow disabling of Pointer Auth from the command-line 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=168970f2-89d8-4e57-ab8d-59fa52bd830a@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=pajay@qti.qualcomm.com \
    --cc=psodagud@codeaurora.org \
    --cc=sramana@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox