[RFC PATCH] arm64: Move HYP text out of kernel mapping

[Mark Rutland]

On Fri, Feb 10, 2023 at 11:56:01AM +0000, Marc Zyngier wrote:
> On Fri, 10 Feb 2023 10:00:06 +0000,
> Ard Biesheuvel <ardb at kernel.org> wrote:
> > So the questions are:
> > a) Mark pointed out off-list that he has been getting rid of static keys
> >    in favor of alternatives in the arch code, as those are guaranteed to
> >    be patched only once. Should we try to get rid of these as well?
> 
> The question is whether we can use these alternatives at such a late
> point in the boot process. Today, we are done with the alternatives as
> soon as all the early CPUs are up.

My thinking is that anything pKVM relies upon must be settled around that time
(and certainly before any late secondaries are onlined), so we should be able
to pull the few remaining bits and pieces a little earlier.

> > b) These look like they are set only once and never turned off again.
> >    The pKVM one is definitely only set at boot time, but I couldn't
> >    figure out whether the same applies to the PMU one?
> 
> Yes, the PMU is in the same bag. As soon as we have found an
> architectural PMU *and* that the driver has been registered, we're
> good. 

As above, I was hoping we could somehow pull that before patching.

> But we cannot just rely on the CPU ID regs as the perf backend
> could fail to register.

I thought pKVM just cared about homgeneity here, and was hiding the PMU state
from the host, so does it matter what the host does, and if the host fails to
register a perf backend?

It doesn't seem right that pKVM would rely upon the host to manage the PMU
given pKVM cannot trust the host...

Thanks,
Mark.