From: Marc Zyngier <maz@kernel.org>
To: Sascha Bischoff <Sascha.Bischoff@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>, nd <nd@arm.com>,
"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
Joey Gouly <Joey.Gouly@arm.com>,
Suzuki Poulose <Suzuki.Poulose@arm.com>,
"yuzenghui@huawei.com" <yuzenghui@huawei.com>,
"will@kernel.org" <will@kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
Timothy Hayes <Timothy.Hayes@arm.com>
Subject: Re: [PATCH 1/5] KVM: arm64: Allow ICC_SRE_EL2 accesses on a GICv5 host
Date: Thu, 28 Aug 2025 15:05:19 +0100 [thread overview]
Message-ID: <86a53jee3k.wl-maz@kernel.org> (raw)
In-Reply-To: <20250828105925.3865158-2-sascha.bischoff@arm.com>
On Thu, 28 Aug 2025 11:59:42 +0100,
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
>
> The bet0 release of the GICv5 specification didn't include the
> ICC_SRE_EL2 register as part of FEAT_GCIE_LEGACY. This was an
> oversight, and support for this register has been added as of the bet1
> release of the specification.
>
> Remove the guarding in the vGICv3 code that skipped the ICC_SRE_EL2
> accesses for a GICv5 host. As a result of this change, it now becomes
> possible to use nested virtualisation on a GICv5 host when running
> legacy GICv3-based VMs.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> ---
> arch/arm64/kvm/hyp/vgic-v3-sr.c | 27 +++++++--------------------
> 1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/vgic-v3-sr.c b/arch/arm64/kvm/hyp/vgic-v3-sr.c
> index d81275790e69..7dbfd35a63a8 100644
> --- a/arch/arm64/kvm/hyp/vgic-v3-sr.c
> +++ b/arch/arm64/kvm/hyp/vgic-v3-sr.c
> @@ -296,19 +296,12 @@ void __vgic_v3_activate_traps(struct vgic_v3_cpu_if *cpu_if)
> }
>
> /*
> - * GICv5 BET0 FEAT_GCIE_LEGACY doesn't include ICC_SRE_EL2. This is due
> - * to be relaxed in a future spec release, at which point this in
> - * condition can be dropped.
> + * Prevent the guest from touching the ICC_SRE_EL1 system
> + * register. Note that this may not have any effect, as
> + * ICC_SRE_EL2.Enable being RAO/WI is a valid implementation.
> */
> - if (!cpus_have_final_cap(ARM64_HAS_GICV5_CPUIF)) {
> - /*
> - * Prevent the guest from touching the ICC_SRE_EL1 system
> - * register. Note that this may not have any effect, as
> - * ICC_SRE_EL2.Enable being RAO/WI is a valid implementation.
> - */
> - write_gicreg(read_gicreg(ICC_SRE_EL2) & ~ICC_SRE_EL2_ENABLE,
> - ICC_SRE_EL2);
> - }
> + write_gicreg(read_gicreg(ICC_SRE_EL2) & ~ICC_SRE_EL2_ENABLE,
> + ICC_SRE_EL2);
At some point, it would be great to elide this on systems where
GICv2-on-v3 doesn't exist, as there is no way for the guest to disable
the system register view. This would avoid a couple of pointless traps
on each entry-exit for a nested guest.
>
> /*
> * If we need to trap system registers, we must write
> @@ -329,14 +322,8 @@ void __vgic_v3_deactivate_traps(struct vgic_v3_cpu_if *cpu_if)
> cpu_if->vgic_vmcr = read_gicreg(ICH_VMCR_EL2);
> }
>
> - /*
> - * Can be dropped in the future when GICv5 spec is relaxed. See comment
> - * above.
> - */
> - if (!cpus_have_final_cap(ARM64_HAS_GICV5_CPUIF)) {
> - val = read_gicreg(ICC_SRE_EL2);
> - write_gicreg(val | ICC_SRE_EL2_ENABLE, ICC_SRE_EL2);
> - }
> + val = read_gicreg(ICC_SRE_EL2);
> + write_gicreg(val | ICC_SRE_EL2_ENABLE, ICC_SRE_EL2);
Same here. That's two back-to-back traps for values that cannot
realistically change on non-v2-compat systems (i.e. relatively modern
machines).
No need to respin for that, but I may end-up posting a follow-up to
clean this up.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-08-28 14:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-28 10:59 [PATCH 0/5] KVM: arm64: GICv5 legacy (GCIE_LEGACY) NV enablement and cleanup Sascha Bischoff
2025-08-28 10:59 ` [PATCH 4/5] KVM: arm64: Use ARM64_HAS_GICV5_LEGACY for GICv5 probing Sascha Bischoff
2025-08-28 10:59 ` [PATCH 1/5] KVM: arm64: Allow ICC_SRE_EL2 accesses on a GICv5 host Sascha Bischoff
2025-08-28 14:05 ` Marc Zyngier [this message]
2025-09-17 16:23 ` Marc Zyngier
2025-08-28 10:59 ` [PATCH 2/5] KVM: arm64: Enable nested for GICv5 host with FEAT_GCIE_LEGACY Sascha Bischoff
2025-08-28 10:59 ` [PATCH 3/5] arm64: cpucaps: Add GICv5 Legacy vCPU interface (GCIE_LEGACY) capability Sascha Bischoff
2025-09-02 8:23 ` Suzuki K Poulose
2025-08-28 10:59 ` [PATCH 5/5] irqchip/gic-v5: Drop has_gcie_v3_compat from gic_kvm_info Sascha Bischoff
2025-09-03 12:07 ` Thomas Gleixner
2025-09-04 7:57 ` [PATCH 0/5] KVM: arm64: GICv5 legacy (GCIE_LEGACY) NV enablement and cleanup Oliver Upton
2025-09-17 16:42 ` Marc Zyngier
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=86a53jee3k.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=Joey.Gouly@arm.com \
--cc=Sascha.Bischoff@arm.com \
--cc=Suzuki.Poulose@arm.com \
--cc=Timothy.Hayes@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=nd@arm.com \
--cc=oliver.upton@linux.dev \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.