linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org, ryan.roberts@arm.com,
	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>
Subject: Re: [PATCH V2 46/46] KVM: arm64: nv: Add trap forwarding for FEAT_FGT2 described registers
Date: Tue, 10 Dec 2024 09:05:59 +0000	[thread overview]
Message-ID: <87frmvsya0.wl-maz@kernel.org> (raw)
In-Reply-To: <20241210055311.780688-47-anshuman.khandual@arm.com>

On Tue, 10 Dec 2024 05:53:11 +0000,
Anshuman Khandual <anshuman.khandual@arm.com> wrote:
> 
> Describe remaining MDCR_EL2 register, and associate that with all FEAT_FGT2
> exposed system registers it allows to trap.

MDCR_EL2 register *bits*? How is that related to FGT2 at all?

> 
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oliver.upton@linux.dev>
> Cc: James Morse <james.morse@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: kvmarm@lists.linux.dev
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> Changes in V2:
> 
> - Dropped check_cntr_accessible_N and CGT_CNTR_ACCESSIBLE_N constructs
> - SYS_PMEVCNTSVR_EL1(N) access traps have been forwarded to CGT_MDCR_HPMN
> - Updated check_mdcr_hpmn() to handle SYS_PMEVCNTSVR_EL1(N) registers
> - Changed behaviour as BEHAVE_FORWARD_RW for CGT_MDCR_EnSPM
> 
>  arch/arm64/include/asm/kvm_host.h |   2 +
>  arch/arm64/kvm/emulate-nested.c   | 158 ++++++++++++++++++++++++++++++
>  2 files changed, 160 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index c80c07be3358..4cdce62642d1 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -441,6 +441,7 @@ enum vcpu_sysreg {
>  	PMINTENSET_EL1,	/* Interrupt Enable Set Register */
>  	PMOVSSET_EL0,	/* Overflow Flag Status Set Register */
>  	PMUSERENR_EL0,	/* User Enable Register */
> +	SPMSELR_EL0,	/* System PMU Select Register */

How could a system PMU be relevant to a VM?  What is the point of
bloating the vcpu for something that we will hopefully *never* make
visible to guests?

>  
>  	/* Pointer Authentication Registers in a strict increasing order. */
>  	APIAKEYLO_EL1,
> @@ -501,6 +502,7 @@ enum vcpu_sysreg {
>  	CNTHP_CVAL_EL2,
>  	CNTHV_CTL_EL2,
>  	CNTHV_CVAL_EL2,
> +	SPMACCESSR_EL2, /* System PMU Access Register */

Same here. It is pretty striking that these registers are never
saved/restored or handled as traps, which is a good indication that
this is pretty pointless.

>  
>  	/* Anything from this can be RES0/RES1 sanitised */
>  	MARKER(__SANITISED_REG_START__),
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index 6c63cbfc11ea..c7d6d2034f27 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -79,6 +79,7 @@ enum cgt_group_id {
>  	CGT_MDCR_TDRA,
>  	CGT_MDCR_E2PB,
>  	CGT_MDCR_TPMS,
> +	CGT_MDCR_EnSPM,
>  	CGT_MDCR_TTRF,
>  	CGT_MDCR_E2TB,
>  	CGT_MDCR_TDCC,
> @@ -125,6 +126,7 @@ enum cgt_group_id {
>  	CGT_CNTHCTL_EL1PCTEN = __COMPLEX_CONDITIONS__,
>  	CGT_CNTHCTL_EL1PTEN,
>  
> +	CGT_SPMSEL_SPMACCESS,
>  	CGT_CPTR_TTA,
>  	CGT_MDCR_HPMN,
>  
> @@ -351,6 +353,12 @@ static const struct trap_bits coarse_trap_bits[] = {
>  		.mask		= MDCR_EL2_TPMS,
>  		.behaviour	= BEHAVE_FORWARD_RW,
>  	},
> +	[CGT_MDCR_EnSPM] = {
> +		.index		= MDCR_EL2,
> +		.value		= MDCR_EL2_EnSPM,
> +		.mask		= MDCR_EL2_EnSPM,
> +		.behaviour	= BEHAVE_FORWARD_RW,
> +	},
>  	[CGT_MDCR_TTRF] = {
>  		.index		= MDCR_EL2,
>  		.value		= MDCR_EL2_TTRF,
> @@ -509,6 +517,7 @@ static enum trap_behaviour check_mdcr_hpmn(struct kvm_vcpu *vcpu)
>  	switch (sysreg) {
>  	case SYS_PMEVTYPERn_EL0(0) ... SYS_PMEVTYPERn_EL0(30):
>  	case SYS_PMEVCNTRn_EL0(0) ... SYS_PMEVCNTRn_EL0(30):
> +	case SYS_PMEVCNTSVR_EL1(0) ... SYS_PMEVCNTSVR_EL1(30):
>  		idx = (sys_reg_CRm(sysreg) & 0x3) << 3 | sys_reg_Op2(sysreg);
>  		break;
>  	case SYS_PMXEVTYPER_EL0:
> @@ -528,6 +537,22 @@ static enum trap_behaviour check_mdcr_hpmn(struct kvm_vcpu *vcpu)
>  	return BEHAVE_HANDLE_LOCALLY;
>  }
>  
> +static enum trap_behaviour check_spmsel_spmaccess(struct kvm_vcpu *vcpu)
> +{
> +	u64 spmaccessr_el2, spmselr_el2;
> +	int syspmusel;
> +
> +	if (__vcpu_sys_reg(vcpu, MDCR_EL2) & MDCR_EL2_EnSPM) {

I don't mind the test, but I don't see any sanitising of MDCR_EL2 to
make EnSPM as RES0 when FEAT_SPMU is not implemented, which will be
100% of the cases.

> +		spmselr_el2 = __vcpu_sys_reg(vcpu, SPMSELR_EL0);
> +		spmaccessr_el2 = __vcpu_sys_reg(vcpu, SPMACCESSR_EL2);

So these two values are *guaranteed* to be zero. At this stage, what
is the point?

> +		syspmusel = FIELD_GET(SPMSELR_EL0_SYSPMUSEL_MASK, spmselr_el2);
> +
> +		if (((spmaccessr_el2 >> (syspmusel * 2)) & 0x3) == 0x0)
> +			return BEHAVE_FORWARD_RW;

What about value 0b01, which causes *writes* to be trapped?

> +	}
> +	return BEHAVE_HANDLE_LOCALLY;

And then what? How do we handle this locally?

Honestly, short of any additional handling, we would be better off
just injecting an UNDEF back into the guest.

	M.

-- 
Without deviation from the norm, progress is not possible.


  reply	other threads:[~2024-12-10  9:07 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-10  5:52 [PATCH V2 00/46] KVM: arm64: Enable FGU (Fine Grained Undefined) for FEAT_FGT2 registers Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 01/46] arm64/sysreg: Update register fields for ID_AA64MMFR0_EL1 Anshuman Khandual
2024-12-11 15:48   ` Mark Brown
2024-12-18 14:40   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 02/46] arm64/sysreg: Update register fields for ID_AA64MMFR4_EL1 Anshuman Khandual
2024-12-11 16:28   ` Mark Brown
2024-12-18 14:40   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 03/46] arm64/sysreg: Update register fields for ID_AA64PFR0_EL1 Anshuman Khandual
2024-12-16 15:08   ` Mark Brown
2024-12-18 14:40   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 04/46] arm64/sysreg: Update register fields for TRBIDR_EL1 Anshuman Khandual
2024-12-16 15:12   ` Mark Brown
2024-12-18 14:40   ` Eric Auger
2024-12-19  2:48     ` Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 05/46] arm64/sysreg: Add register fields for HDFGRTR2_EL2 Anshuman Khandual
2024-12-18 14:45   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 06/46] arm64/sysreg: Add register fields for HDFGWTR2_EL2 Anshuman Khandual
2024-12-18 15:11   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 07/46] arm64/sysreg: Add register fields for HFGITR2_EL2 Anshuman Khandual
2024-12-16 15:17   ` Mark Brown
2024-12-18 15:17   ` Eric Auger
2024-12-18 15:17   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 08/46] arm64/sysreg: Add register fields for HFGRTR2_EL2 Anshuman Khandual
2024-12-16 15:20   ` Mark Brown
2024-12-18 15:19   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 09/46] arm64/sysreg: Add register fields for HFGWTR2_EL2 Anshuman Khandual
2024-12-16 20:52   ` Mark Brown
2024-12-18 15:22   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 10/46] arm64/sysreg: Add register fields for MDSELR_EL1 Anshuman Khandual
2024-12-16 20:57   ` Mark Brown
2024-12-18 15:25   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 11/46] arm64/sysreg: Add register fields for PMSIDR_EL1 Anshuman Khandual
2024-12-16 21:03   ` Mark Brown
2024-12-18 15:28   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 12/46] arm64/sysreg: Add register fields for TRBMPAM_EL1 Anshuman Khandual
2024-12-16 22:11   ` Mark Brown
2024-12-18 15:30   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 13/46] arm64/sysreg: Add register fields for PMSDSFR_EL1 Anshuman Khandual
2024-12-18 15:34   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 14/46] arm64/sysreg: Add register fields for SPMDEVAFF_EL1 Anshuman Khandual
2024-12-18 15:38   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 15/46] arm64/sysreg: Add register fields for PFAR_EL1 Anshuman Khandual
2024-12-18 15:42   ` Eric Auger
2024-12-19  3:13     ` Anshuman Khandual
2025-01-06 10:57       ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 16/46] arm64/sysreg: Add register fields for PMIAR_EL1 Anshuman Khandual
2024-12-18 15:44   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 17/46] arm64/sysreg: Add register fields for PMECR_EL1 Anshuman Khandual
2024-12-18 15:46   ` Eric Auger
2024-12-10  5:52 ` [PATCH V2 18/46] arm64/sysreg: Add register fields for PMUACR_EL1 Anshuman Khandual
2024-12-16 23:15   ` Rob Herring
2024-12-17  4:33     ` Anshuman Khandual
2024-12-17 15:32       ` Mark Brown
2024-12-17 15:30     ` Mark Brown
2024-12-17 17:02       ` Rob Herring
2024-12-10  5:52 ` [PATCH V2 19/46] arm64/sysreg: Add register fields for PMCCNTSVR_EL1 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 20/46] arm64/sysreg: Add register fields for SPMSCR_EL1 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 21/46] arm64/sysreg: Add register fields for SPMACCESSR_EL1 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 22/46] arm64/sysreg: Add register fields for PMICNTR_EL0 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 23/46] arm64/sysreg: Add register fields for PMICFILTR_EL0 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 24/46] arm64/sysreg: Add register fields for SPMCR_EL0 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 25/46] arm64/sysreg: Add register fields for SPMOVSCLR_EL0 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 26/46] arm64/sysreg: Add register fields for SPMOVSSET_EL0 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 27/46] arm64/sysreg: Add register fields for SPMINTENCLR_EL1 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 28/46] arm64/sysreg: Add register fields for SPMINTENSET_EL1 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 29/46] arm64/sysreg: Add register fields for SPMCNTENCLR_EL0 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 30/46] arm64/sysreg: Add register fields for SPMCNTENSET_EL0 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 31/46] arm64/sysreg: Add register fields for SPMSELR_EL0 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 32/46] arm64/sysreg: Add register fields for PMICNTSVR_EL1 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 33/46] arm64/sysreg: Add register fields for SPMIIDR_EL1 Anshuman Khandual
2024-12-10  5:52 ` [PATCH V2 34/46] arm64/sysreg: Add register fields for SPMDEVARCH_EL1 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 35/46] arm64/sysreg: Add register fields for SPMCFGR_EL1 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 36/46] arm64/sysreg: Add register fields for PMSSCR_EL1 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 37/46] arm64/sysreg: Add register fields for PMZR_EL0 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 38/46] arm64/sysreg: Add register fields for SPMCGCR0_EL1 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 39/46] arm64/sysreg: Add register fields for SPMCGCR1_EL1 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 40/46] arm64/sysreg: Add register fields for MDSTEPOP_EL1 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 41/46] arm64/sysreg: Add register fields for ERXGSR_EL1 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 42/46] arm64/sysreg: Add register fields for SPMACCESSR_EL2 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 43/46] arm64/sysreg: Add remaining debug registers affected by HDFGxTR2_EL2 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 44/46] KVM: arm64: nv: Add FEAT_FGT2 registers access from virtual EL2 Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 45/46] KVM: arm64: nv: Add FEAT_FGT2 registers based FGU handling Anshuman Khandual
2024-12-10  5:53 ` [PATCH V2 46/46] KVM: arm64: nv: Add trap forwarding for FEAT_FGT2 described registers Anshuman Khandual
2024-12-10  9:05   ` Marc Zyngier [this message]
2024-12-18 10:37     ` 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=87frmvsya0.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=ryan.roberts@arm.com \
    --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 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).