From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
mark.rutland@arm.com, will@kernel.org, joey.gouly@arm.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com,
catalin.marinas@arm.com, broonie@kernel.org, qperret@google.com,
vdonnefort@google.com
Subject: Re: [PATCH v1 1/3] KVM: arm64: Initialize HCRX_EL2 traps in pKVM
Date: Wed, 26 Feb 2025 15:28:22 +0000 [thread overview]
Message-ID: <865xkwrai1.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTwRNj6z_TTCXR8UNiB0ty=85_VKWDVsFOLke31UGnBE7A@mail.gmail.com>
On Wed, 26 Feb 2025 12:44:49 +0000,
Fuad Tabba <tabba@google.com> wrote:
>
> Hi Marc,
>
> On Wed, 26 Feb 2025 at 02:45, Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 26 Feb 2025 10:07:56 +0000,
> > Oliver Upton <oliver.upton@linux.dev> wrote:
> > >
> > > Hi Fuad,
> > >
> > > Series LGTM overall, one comment:
> > >
> > > On Fri, Feb 14, 2025 at 03:02:56PM +0000, Fuad Tabba wrote:
> > > > Initialize and set the traps controlled by the HCRX_EL2 in pKVM
> > > > when the register is supported by the system.
> > > >
> > > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > > ---
> > > > arch/arm64/kvm/hyp/nvhe/pkvm.c | 46 ++++++++++++++++++++++++++++++++++
> > > > 1 file changed, 46 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > > > index 3927fe52a3dd..668ebec27f1b 100644
> > > > --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > > > +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > > > @@ -58,6 +58,30 @@ static void pkvm_vcpu_reset_hcr(struct kvm_vcpu *vcpu)
> > > > vcpu->arch.hcr_el2 |= HCR_ATA;
> > > > }
> > > >
> > > > +static void pkvm_vcpu_reset_hcrx(struct pkvm_hyp_vcpu *hyp_vcpu)
> > > > +{
> > > > + struct kvm_vcpu *host_vcpu = hyp_vcpu->host_vcpu;
> > > > + struct kvm_vcpu *vcpu = &hyp_vcpu->vcpu;
> > > > +
> > > > + if (!cpus_have_final_cap(ARM64_HAS_HCX))
> > > > + return;
> > > > +
> > > > + /*
> > > > + * In general, all HCRX_EL2 bits are gated by a feature.
> > > > + * The only reason we can set SMPME without checking any
> > > > + * feature is that its effects are not directly observable
> > > > + * from the guest.
> > > > + */
> > > > + vcpu->arch.hcrx_el2 = HCRX_EL2_SMPME;
> > > > +
> > >
> > > The comment isn't wrong, but we don't support SME at all in KVM at this
> > > point.
> >
> > This is a copy/paste of what we have in kvm_calculate_traps(), and the
> > result of the removal of the dreaded HCRX_GUEST_FLAGS.
> >
> > > Any objection to dropping this bit? I can fix it when applying the
> > > series, no need to respin.
> >
> > Whatever we do, I think we should keep the two side of the trap
> > configuration in sync, as this is otherwise a cause of bugs.
>
> I could take the initialization of hcrx part from
> kvm_calculate_traps() and place it in an inline function in
> kvm_emulate.h. This then would be called by kvm_calculate_traps() and
> pkvm_vcpu_init_traps().
>
> What do you think?
That could be a good option indeed, irrespective of the fate of SMPME.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-02-26 15:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-14 15:02 [PATCH v1 0/3] KVM: arm64: Fix initializing HCRX_EL2 and other traps in pKVM Fuad Tabba
2025-02-14 15:02 ` [PATCH v1 1/3] KVM: arm64: Initialize HCRX_EL2 " Fuad Tabba
2025-02-26 10:07 ` Oliver Upton
2025-02-26 10:45 ` Marc Zyngier
2025-02-26 12:44 ` Fuad Tabba
2025-02-26 15:28 ` Marc Zyngier [this message]
2025-02-26 18:53 ` Oliver Upton
2025-02-26 18:54 ` Fuad Tabba
2025-02-26 12:36 ` Fuad Tabba
2025-02-14 15:02 ` [PATCH v1 2/3] KVM: arm64: Factor out pkvm hyp vcpu creation to separate function Fuad Tabba
2025-02-14 15:02 ` [PATCH v1 3/3] KVM: arm64: Create each pKVM hyp vcpu after its corresponding host vcpu Fuad Tabba
2025-02-17 15:30 ` Will Deacon
2025-02-17 15:41 ` Fuad Tabba
2025-02-17 15:56 ` Fuad Tabba
2025-02-18 9:27 ` Will Deacon
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=865xkwrai1.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=oliver.upton@linux.dev \
--cc=qperret@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--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