From: Marc Zyngier <maz@kernel.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, James Morse <james.morse@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
James Clark <james.clark@arm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH 1/5] KVM: arm64: Add accessor for per-CPU state
Date: Sat, 09 Mar 2024 13:00:18 +0000 [thread overview]
Message-ID: <87y1arpnkt.wl-maz@kernel.org> (raw)
In-Reply-To: <4eba8428-fe6c-4c42-b135-ab831e5cf436@arm.com>
On Mon, 04 Mar 2024 12:05:20 +0000,
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
> Hi Marc
>
> On 02/03/2024 11:19, Marc Zyngier wrote:
> > In order to facilitate the introduction of new per-CPU state,
> > add a new host_data_ptr() helped that hides some of the per-CPU
> > verbosity, and make it easier to move that state around in the
> > future.
> >
>
> This series looks like a good cleanup to make the whole host
> data handling cleaner. One comment below.
>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 13 +++++++++++++
> > arch/arm64/kvm/arm.c | 2 +-
> > arch/arm64/kvm/hyp/include/hyp/debug-sr.h | 4 ++--
> > arch/arm64/kvm/hyp/include/hyp/switch.h | 11 +++++------
> > arch/arm64/kvm/hyp/nvhe/psci-relay.c | 2 +-
> > arch/arm64/kvm/hyp/nvhe/setup.c | 3 +--
> > arch/arm64/kvm/hyp/nvhe/switch.c | 4 ++--
> > arch/arm64/kvm/hyp/vhe/switch.c | 4 ++--
> > arch/arm64/kvm/hyp/vhe/sysreg-sr.c | 4 ++--
> > arch/arm64/kvm/pmu.c | 2 +-
> > 10 files changed, 30 insertions(+), 19 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 21c57b812569..3ca2a9444f21 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -492,6 +492,17 @@ struct kvm_cpu_context {
> > u64 *vncr_array;
> > };
> > +/*
> > + * This structure is instanciated on a per-CPU basis, and contains
> > + * data that is:
> > + *
> > + * - tied to a single physical CPU, and
> > + * - either have a lifetime that does not extend past vcpu_put()
> > + * - or is an invariant for the lifetime of the system
> > + *
> > + * Use host_data_ptr(field) as a way to access a pointer to such a
> > + * field.
> > + */
> > struct kvm_host_data {
> > struct kvm_cpu_context host_ctxt;
> > };
> > @@ -1114,6 +1125,8 @@ struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
> > DECLARE_KVM_HYP_PER_CPU(struct kvm_host_data, kvm_host_data);
> > +#define host_data_ptr(f) (&this_cpu_ptr(&kvm_host_data)->f)
> > +
> > static inline void kvm_init_host_cpu_context(struct kvm_cpu_context *cpu_ctxt)
> > {
> > /* The host's MPIDR is immutable, so let's set it up at boot time */
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index a25265aca432..d3d14cc41cb5 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -1960,7 +1960,7 @@ static void cpu_set_hyp_vector(void)
> > static void cpu_hyp_init_context(void)
> > {
> > - kvm_init_host_cpu_context(&this_cpu_ptr_hyp_sym(kvm_host_data)->host_ctxt);
> > + kvm_init_host_cpu_context(host_data_ptr(host_ctxt));
>
> This silently changes the "this_cpu_ptr_hyp_sym" to "this_cpu_ptr()"
> and thus we could be using the VHE host_data even in nVHE ?
> Rest looks fine to me.
Huh, well spotted. I'll switch the definition of host_data_ptr()
outside of the hypervisor code to use this_cpu_ptr_hyp_sym() instead,
like we have for some of the other helpers.
Thanks again,
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
next prev parent reply other threads:[~2024-03-09 13:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-02 11:19 [PATCH 0/5] KVM: arm64: Move host-specific data out of kvm_vcpu_arch Marc Zyngier
2024-03-02 11:19 ` [PATCH 1/5] KVM: arm64: Add accessor for per-CPU state Marc Zyngier
2024-03-04 12:05 ` Suzuki K Poulose
2024-03-09 13:00 ` Marc Zyngier [this message]
2024-03-11 4:50 ` Dongli Zhang
2024-03-11 17:13 ` Marc Zyngier
2024-03-02 11:19 ` [PATCH 2/5] KVM: arm64: Exclude host_debug_data from vcpu_arch Marc Zyngier
2024-03-02 11:19 ` [PATCH 3/5] KVM: arm64: Exclude mdcr_el2_host from kvm_vcpu_arch Marc Zyngier
2024-03-02 11:19 ` [PATCH 4/5] KVM: arm64: Exclude host_fpsimd_state pointer " Marc Zyngier
2024-03-04 20:45 ` Mark Brown
2024-03-02 11:19 ` [PATCH 5/5] KVM: arm64: Exclude FP ownership " Marc Zyngier
2024-03-04 19:10 ` Mark Brown
2024-03-06 9:43 ` Marc Zyngier
2024-03-06 22:19 ` Mark Brown
2024-03-07 11:10 ` Marc Zyngier
2024-03-07 14:26 ` Mark Brown
2024-03-09 11:01 ` Marc Zyngier
2024-03-11 18:42 ` Mark Brown
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=87y1arpnkt.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=james.clark@arm.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=yuzenghui@huawei.com \
/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;
as well as URLs for NNTP newsgroup(s).