From: Mark Rutland <mark.rutland@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Quentin Perret <qperret@google.com>,
Kees Cook <keescook@chromium.org>
Subject: Re: [RFC PATCH] arm64: Move HYP text out of kernel mapping
Date: Fri, 10 Feb 2023 16:40:33 +0000 [thread overview]
Message-ID: <Y+ZzgboOiEHJGCq5@FVFF77S0Q05N> (raw)
In-Reply-To: <86a61lzqcu.wl-maz@kernel.org>
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@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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2023-02-10 16:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 10:00 [RFC PATCH] arm64: Move HYP text out of kernel mapping Ard Biesheuvel
2023-02-10 11:56 ` Marc Zyngier
2023-02-10 16:40 ` Mark Rutland [this message]
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=Y+ZzgboOiEHJGCq5@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=peterz@infradead.org \
--cc=qperret@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox