[PATCH v2 1/3] arm64: Avoid enabling KPTI unnecessarily

[Will Deacon]

On Tue, Nov 28, 2023 at 02:13:16PM +0000, Mark Rutland wrote:
> On Tue, Nov 28, 2023 at 11:03:40AM +0000, Will Deacon wrote:
> > On Mon, Nov 27, 2023 at 05:49:21PM +0000, Mark Rutland wrote:
> > > In addition to that intent, these functions are executed precisely once during
> > > boot, so using cpus_have_cap() avoids the space for the alt_instr and the cost
> > > of the patching of the site for a single check. I was also hoping to get rid of
> > > most of the feature check helpers now that they're largely trivial wrappers
> > > around alternative_has_cap(), which'd make it clearer which callsites care
> > > about the alterntive-ness and clear up the inconsistent naming.
> > 
> > We can always remove the helpers when you get round to it, but ideally
> > many of these things would BUG() if they're called too early, much like
> > e.g. cpus_have_final_cap(). Inlining the alternative is going to make that
> > more difficult.
> 
> That's fair.
> 
> My major goal is that it's clear where we're using an altnernative and where
> we're not; if the thinking is the vast majority *should* be alternatives, I can
> annotate the non-alternative cases to make that clear.
> 
> > > If you want these cases moves back to alternatives-based feature check helpers,
> > > I can go do that.
> > 
> > I was thinking of something like the diff below to start with.
> 
> Sure; as-is that breaks the hyp offset patching, and we'll need ensure we still
> call hyp_mode_check() before apply_alternatives_all(). In hyp_mode_check() we
> call kvm_compute_layout(), which generates the 'va_mask', 'tag_val', and
> 'tag_lsb' values which are used by the kvm_update_va_mask() patching callback
> (for kern_hyp_va() and __kern_hyp_va()).
> 
> I think that can be moved before enable_cpu_capabilities() ratehr than needing
> to be between enable_cpu_capabilities() and apply_alternatives_all(), but I'll
> need to go digging to make certain.
> 
> Do you want this as a cleanup for v6.7-rc*, or as something to queue for
> v6.8-rc1?

Sorry, I keep forgetting to reply to this after we spoke in-person. If
you're able to spin something in the next day or so, I can pick it up for
the next merge window. In the meantime, I'll grab Ard's changes so this can
go on top.

Cheers,

Will