All of lore.kernel.org
 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:06 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 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.