All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Hector Martin <marcan@marcan.st>, Arnd Bergmann <arnd@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	kernel-team@android.com
Subject: Re: [PATCH 1/2] arm64: cpufeature: Allow early filtering of feature override
Date: Fri, 26 Mar 2021 10:56:23 +0000	[thread overview]
Message-ID: <87tuoyfajs.wl-maz@kernel.org> (raw)
In-Reply-To: <20210325192759.GA16123@willie-the-truck>

On Thu, 25 Mar 2021 19:27:59 +0000,
Will Deacon <will@kernel.org> wrote:
> 
> On Thu, Mar 25, 2021 at 12:47:20PM +0000, Marc Zyngier wrote:
> > Some CPUs are broken enough that some overrides need to be rejected
> > at the earliest opportunity. In some cases, that's right at cpu
> > feature override time.
> > 
> > Provide the necessary infrastructure to filter out overrides,
> > and to report such filtered out overrides to the core cpufeature code.
> > 
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> >  arch/arm64/kernel/cpufeature.c     |  6 ++++++
> >  arch/arm64/kernel/idreg-override.c | 13 +++++++++++++
> >  2 files changed, 19 insertions(+)
> > 
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 066030717a4c..6de15deaa912 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -809,6 +809,12 @@ static void __init init_cpu_ftr_reg(u32 sys_reg, u64 new)
> >  					reg->name,
> >  					ftrp->shift + ftrp->width - 1,
> >  					ftrp->shift, str, tmp);
> > +		} else if ((ftr_mask & reg->override->val) == ftr_mask) {
> 
> This seems to rely on 'val == mask' being invalid, but I'm not sure why
> that's generally true.

This is really 'ovr->val == mask && ovr->mask != mask', thanks to
being on the 'else' branch. The encoding rules of val/mask are, for a
given field:

- no override set: mask = 0, val = 0
- valid override set: mask = 0xf, val = (override value)
- invalid override set: mask = 0, val = 0xf

I don't see where the ambiguity could be (though the above could
figure in a comment to make things clearer).

> Can we just invoke the filter function again here to figure out if
> the field has been ignored? Then in match_options, we can just clear
> the override val/mask to zero.

The filter function isn't available outside of idreg-override.c:
that's where the per-field override structures are defined, and I'd
rather not expose that to the rest of the kernel.

Also, calling the filter implies that you parse the whole command-line
again, and you get into a real mess because the invalid override can
come from the expansion of an alias (e.g. 'kvm-arm.mode=nvhe'). Seems
totally overkill to me.

If, for some reason that I can't see at the moment, we need an extra
u64 to communicate that there is an invalid option, we can add that to
the override structure.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

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

  reply	other threads:[~2021-03-26 10:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-25 12:47 [PATCH 0/2] arm64: Dealing with VHE-only CPUs Marc Zyngier
2021-03-25 12:47 ` [PATCH 1/2] arm64: cpufeature: Allow early filtering of feature override Marc Zyngier
2021-03-25 19:27   ` Will Deacon
2021-03-26 10:56     ` Marc Zyngier [this message]
2021-03-29 10:21       ` Will Deacon
2021-03-25 12:47 ` [PATCH 2/2] arm64: Cope with CPUs stuck in VHE mode Marc Zyngier
2021-03-25 19:33   ` Will Deacon
2021-03-26 11:20     ` Marc Zyngier
2021-03-29 10:22       ` Will Deacon
2021-03-30 17:00         ` 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=87tuoyfajs.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=arnd@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=marcan@marcan.st \
    --cc=mark.rutland@arm.com \
    --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.