From: Marc Zyngier <maz@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
Jonathan Corbet <corbet@lwn.net>,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Mark Brown <broonie@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [RFC 5/8] KVM: arm64: Explicitly handle MDSELR_EL1 traps as UNDEFINED
Date: Fri, 12 Apr 2024 12:05:59 +0100 [thread overview]
Message-ID: <86mspysuw8.wl-maz@kernel.org> (raw)
In-Reply-To: <5a2a74b3-f6cd-4cb6-8ee8-5dd7dc2bd686@arm.com>
On Fri, 12 Apr 2024 03:41:23 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>
>
> On 4/5/24 15:45, Marc Zyngier wrote:
> > On Fri, 05 Apr 2024 09:00:05 +0100,
> > Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> >>
> >> Currently read_sanitised_id_aa64dfr0_el1() caps the ID_AA64DFR0.DebugVer to
> >> ID_AA64DFR0_DebugVer_V8P8, resulting in FEAT_Debugv8p9 not being exposed to
> >> the guest. MDSELR_EL1 register access in the guest, is currently trapped by
> >> the existing configuration of the fine-grained traps.
> >
> > Please add support for the HDFGxTR2_EL2 registers in the trap routing
> > arrays, add support for the corresponding FGUs in the corresponding
>
> Afraid that I might not have enough background here to sufficiently understand
> your suggestion above, but nonetheless here is an attempt in this regard.
Thanks for at least giving it a try, this is *MUCH* appreciated.
>
> - Add HDFGRTR2_EL2/HDFGWTR2_EL2 to enum vcpu_sysreg
> enum vcpu_sysreg {
> ..........
> VNCR(HDFGRTR2_EL2),
> VNCR(HDFGWTR2_EL2),
> ..........
> }
Yes.
>
> - Add their VNCR mappings addresses
>
> #define VNCR_HDFGRTR2_EL2 0x1A0
> #define VNCR_HDFGWTR2_EL2 0x1B0
Yes.
>
> - Add HDFGRTR2_EL2/HDFGWTR2_EL2 to sys_reg_descs[]
>
> static const struct sys_reg_desc sys_reg_descs[] = {
> ..........
> EL2_REG_VNCR(HDFGRTR2_EL2, reset_val, 0),
> EL2_REG_VNCR(HDFGWTR2_EL2, reset_val, 0),
> ..........
> }
Yes
>
> - Add HDFGRTR2_GROUP to enum fgt_group_id
> - Add HDFGRTR2_GROUP to reg_to_fgt_group_id()
> - Update triage_sysreg_trap() for HDFGRTR2_GROUP
> - Update __activate_traps_hfgxtr() both for HDFGRTR2_EL2 and HDFGWTR2_EL2
> - Updated __deactivate_traps_hfgxtr() both for HDFGRTR2_EL2 and HDFGWTR2_EL2
Yes. Don't miss check_fgt_bit() though. You also need to update
kvm_init_nv_sysregs() to ensure that these new registers have the
correct RES0/RES1 behaviour depending on the supported feature set for
the guest.
>
> > structure, and condition the UNDEF on the lack of *guest* support for
> > the feature.
>
> Does something like the following looks OK for preventing guest access into
> MDSELR_EL1 instead ?
>
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1711,6 +1711,19 @@ static u64 read_sanitised_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
> return val;
> }
>
> +static bool trap_mdselr_el1(struct kvm_vcpu *vcpu,
> + struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 dfr0 = read_sanitised_id_aa64dfr0_el1(vcpu, r);
> + int dver = cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_DebugVer_SHIFT);
> +
> + if (dver != ID_AA64DFR0_EL1_DebugVer_V8P9)
> + return undef_access(vcpu, p, r);
This is very cumbersome, and we now have a much better infrastructure
for the stuff that is handled with FGTs, see below.
> +
> + return true;
> +}
> +
> static int set_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
> const struct sys_reg_desc *rd,
> u64 val)
> @@ -2203,7 +2216,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> { SYS_DESC(SYS_MDSCR_EL1), trap_debug_regs, reset_val, MDSCR_EL1, 0 },
> DBG_BCR_BVR_WCR_WVR_EL1(2),
> DBG_BCR_BVR_WCR_WVR_EL1(3),
> - { SYS_DESC(SYS_MDSELR_EL1), undef_access },
> + { SYS_DESC(SYS_MDSELR_EL1), trap_mdselr_el1 },
> DBG_BCR_BVR_WCR_WVR_EL1(4),
> DBG_BCR_BVR_WCR_WVR_EL1(5),
> DBG_BCR_BVR_WCR_WVR_EL1(6),
>
> I am sure this is rather incomplete, but will really appreciate if you could
> provide some details and pointers.
What is missing is the Fine-Grained-Undef part. You need to update
kvm_init_sysreg() so that kvm->arch.fgu[HDFGRTR2_GROUP] has all the
correct bits set for anything that needs to UNDEF depending on the
guest configuration.
For example, in your case, I'd expect to see something like:
if (!kvm_has_feat(kvm, ID_AA64DFR0_EL1, DebugVer, V8P9))
kvm->arch.fgu[HDFGRTR2_GROUP] |= ~(HDFGRTR2_EL2_nMDSELR_EL1 | [...]);
Then allowing the feature becomes conditioned on the bit being clear,
and the trap handler only needs to deal with the actual emulation, and
not the feature checking.
I appreciate that this is a lot to swallow, but I'd be very happy to
review patches implementing this and provide guidance. It is all
pretty simple, just that there is a lot of parts all over the place.
In the end, this is only about following the architecture.
Thanks again,
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
Jonathan Corbet <corbet@lwn.net>,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Mark Brown <broonie@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [RFC 5/8] KVM: arm64: Explicitly handle MDSELR_EL1 traps as UNDEFINED
Date: Fri, 12 Apr 2024 12:05:59 +0100 [thread overview]
Message-ID: <86mspysuw8.wl-maz@kernel.org> (raw)
In-Reply-To: <5a2a74b3-f6cd-4cb6-8ee8-5dd7dc2bd686@arm.com>
On Fri, 12 Apr 2024 03:41:23 +0100,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>
>
> On 4/5/24 15:45, Marc Zyngier wrote:
> > On Fri, 05 Apr 2024 09:00:05 +0100,
> > Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> >>
> >> Currently read_sanitised_id_aa64dfr0_el1() caps the ID_AA64DFR0.DebugVer to
> >> ID_AA64DFR0_DebugVer_V8P8, resulting in FEAT_Debugv8p9 not being exposed to
> >> the guest. MDSELR_EL1 register access in the guest, is currently trapped by
> >> the existing configuration of the fine-grained traps.
> >
> > Please add support for the HDFGxTR2_EL2 registers in the trap routing
> > arrays, add support for the corresponding FGUs in the corresponding
>
> Afraid that I might not have enough background here to sufficiently understand
> your suggestion above, but nonetheless here is an attempt in this regard.
Thanks for at least giving it a try, this is *MUCH* appreciated.
>
> - Add HDFGRTR2_EL2/HDFGWTR2_EL2 to enum vcpu_sysreg
> enum vcpu_sysreg {
> ..........
> VNCR(HDFGRTR2_EL2),
> VNCR(HDFGWTR2_EL2),
> ..........
> }
Yes.
>
> - Add their VNCR mappings addresses
>
> #define VNCR_HDFGRTR2_EL2 0x1A0
> #define VNCR_HDFGWTR2_EL2 0x1B0
Yes.
>
> - Add HDFGRTR2_EL2/HDFGWTR2_EL2 to sys_reg_descs[]
>
> static const struct sys_reg_desc sys_reg_descs[] = {
> ..........
> EL2_REG_VNCR(HDFGRTR2_EL2, reset_val, 0),
> EL2_REG_VNCR(HDFGWTR2_EL2, reset_val, 0),
> ..........
> }
Yes
>
> - Add HDFGRTR2_GROUP to enum fgt_group_id
> - Add HDFGRTR2_GROUP to reg_to_fgt_group_id()
> - Update triage_sysreg_trap() for HDFGRTR2_GROUP
> - Update __activate_traps_hfgxtr() both for HDFGRTR2_EL2 and HDFGWTR2_EL2
> - Updated __deactivate_traps_hfgxtr() both for HDFGRTR2_EL2 and HDFGWTR2_EL2
Yes. Don't miss check_fgt_bit() though. You also need to update
kvm_init_nv_sysregs() to ensure that these new registers have the
correct RES0/RES1 behaviour depending on the supported feature set for
the guest.
>
> > structure, and condition the UNDEF on the lack of *guest* support for
> > the feature.
>
> Does something like the following looks OK for preventing guest access into
> MDSELR_EL1 instead ?
>
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1711,6 +1711,19 @@ static u64 read_sanitised_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
> return val;
> }
>
> +static bool trap_mdselr_el1(struct kvm_vcpu *vcpu,
> + struct sys_reg_params *p,
> + const struct sys_reg_desc *r)
> +{
> + u64 dfr0 = read_sanitised_id_aa64dfr0_el1(vcpu, r);
> + int dver = cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_DebugVer_SHIFT);
> +
> + if (dver != ID_AA64DFR0_EL1_DebugVer_V8P9)
> + return undef_access(vcpu, p, r);
This is very cumbersome, and we now have a much better infrastructure
for the stuff that is handled with FGTs, see below.
> +
> + return true;
> +}
> +
> static int set_id_aa64dfr0_el1(struct kvm_vcpu *vcpu,
> const struct sys_reg_desc *rd,
> u64 val)
> @@ -2203,7 +2216,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> { SYS_DESC(SYS_MDSCR_EL1), trap_debug_regs, reset_val, MDSCR_EL1, 0 },
> DBG_BCR_BVR_WCR_WVR_EL1(2),
> DBG_BCR_BVR_WCR_WVR_EL1(3),
> - { SYS_DESC(SYS_MDSELR_EL1), undef_access },
> + { SYS_DESC(SYS_MDSELR_EL1), trap_mdselr_el1 },
> DBG_BCR_BVR_WCR_WVR_EL1(4),
> DBG_BCR_BVR_WCR_WVR_EL1(5),
> DBG_BCR_BVR_WCR_WVR_EL1(6),
>
> I am sure this is rather incomplete, but will really appreciate if you could
> provide some details and pointers.
What is missing is the Fine-Grained-Undef part. You need to update
kvm_init_sysreg() so that kvm->arch.fgu[HDFGRTR2_GROUP] has all the
correct bits set for anything that needs to UNDEF depending on the
guest configuration.
For example, in your case, I'd expect to see something like:
if (!kvm_has_feat(kvm, ID_AA64DFR0_EL1, DebugVer, V8P9))
kvm->arch.fgu[HDFGRTR2_GROUP] |= ~(HDFGRTR2_EL2_nMDSELR_EL1 | [...]);
Then allowing the feature becomes conditioned on the bit being clear,
and the trap handler only needs to deal with the actual emulation, and
not the feature checking.
I appreciate that this is a lot to swallow, but I'd be very happy to
review patches implementing this and provide guidance. It is all
pretty simple, just that there is a lot of parts all over the place.
In the end, this is only about following the architecture.
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-04-12 11:06 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-05 8:00 [RFC 0/8] arm64/hw_breakpoint: Enable FEAT_Debugv8p9 Anshuman Khandual
2024-04-05 8:00 ` Anshuman Khandual
2024-04-05 8:00 ` [RFC 1/8] arm64/sysreg: Add register fields for MDSELR_EL1 Anshuman Khandual
2024-04-05 8:00 ` Anshuman Khandual
2024-04-05 12:52 ` Mark Brown
2024-04-05 12:52 ` Mark Brown
2024-04-05 8:00 ` [RFC 2/8] arm64/sysreg: Add register fields for HDFGRTR2_EL2 Anshuman Khandual
2024-04-05 8:00 ` Anshuman Khandual
2024-04-05 12:59 ` Mark Brown
2024-04-05 12:59 ` Mark Brown
2024-04-05 8:00 ` [RFC 3/8] arm64/sysreg: Add register fields for HDFGWTR2_EL2 Anshuman Khandual
2024-04-05 8:00 ` Anshuman Khandual
2024-04-05 13:08 ` Mark Brown
2024-04-05 13:08 ` Mark Brown
2024-04-05 8:00 ` [RFC 4/8] arm64/sysreg: Update ID_AA64MMFR0_EL1 register Anshuman Khandual
2024-04-05 8:00 ` Anshuman Khandual
2024-04-05 13:16 ` Mark Brown
2024-04-05 13:16 ` Mark Brown
2024-04-05 8:00 ` [RFC 5/8] KVM: arm64: Explicitly handle MDSELR_EL1 traps as UNDEFINED Anshuman Khandual
2024-04-05 8:00 ` Anshuman Khandual
2024-04-05 10:15 ` Marc Zyngier
2024-04-05 10:15 ` Marc Zyngier
2024-04-12 2:41 ` Anshuman Khandual
2024-04-12 2:41 ` Anshuman Khandual
2024-04-12 11:05 ` Marc Zyngier [this message]
2024-04-12 11:05 ` Marc Zyngier
2024-04-16 5:46 ` Anshuman Khandual
2024-04-16 5:46 ` Anshuman Khandual
2024-04-16 8:15 ` Marc Zyngier
2024-04-16 8:15 ` Marc Zyngier
2024-04-05 8:00 ` [RFC 6/8] arm64/cpufeature: Add field details for ID_AA64DFR1_EL1 register Anshuman Khandual
2024-04-05 8:00 ` Anshuman Khandual
2024-04-05 8:00 ` [RFC 7/8] arm64/boot: Enable EL2 requirements for FEAT_Debugv8p9 Anshuman Khandual
2024-04-05 8:00 ` Anshuman Khandual
2024-04-05 8:00 ` [RFC 8/8] arm64/hw_breakpoint: Enable FEAT_Debugv8p9 Anshuman Khandual
2024-04-05 8:00 ` Anshuman Khandual
2024-04-05 10:26 ` Marc Zyngier
2024-04-05 10:26 ` Marc Zyngier
2024-04-16 3:13 ` Anshuman Khandual
2024-04-16 3:13 ` Anshuman Khandual
2024-04-16 3:54 ` [RFC 0/8] " Anshuman Khandual
2024-04-16 3:54 ` Anshuman Khandual
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=86mspysuw8.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.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 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.