[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZvwLRWOKpggCvmH4@linux.dev>
Date: Tue, 1 Oct 2024 07:46:29 -0700
From: Oliver Upton <oliver.upton@...ux.dev>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-kernel@...r.kernel.org, kvmarm@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, maz@...nel.org,
James Morse <james.morse@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH 47/47] KVM: arm64: nv: Add trap forwarding for FEAT_FGT2
described registers
Hi Anshuman,
On Tue, Oct 01, 2024 at 08:13:56AM +0530, Anshuman Khandual wrote:
> +#define check_cntr_accessible(num) \
> +static enum trap_behaviour check_cntr_accessible_##num(struct kvm_vcpu *vcpu) \
> +{ \
> + u64 mdcr_el2 = __vcpu_sys_reg(vcpu, MDCR_EL2); \
> + int cntr = FIELD_GET(MDCR_EL2_HPMN_MASK, mdcr_el2); \
> + \
> + if (num >= cntr) \
> + return BEHAVE_FORWARD_ANY; \
> + return BEHAVE_HANDLE_LOCALLY; \
> +} \
> +
> +check_cntr_accessible(0)
> +check_cntr_accessible(1)
> +check_cntr_accessible(2)
> +check_cntr_accessible(3)
> +check_cntr_accessible(4)
> +check_cntr_accessible(5)
> +check_cntr_accessible(6)
> +check_cntr_accessible(7)
> +check_cntr_accessible(8)
> +check_cntr_accessible(9)
> +check_cntr_accessible(10)
> +check_cntr_accessible(11)
> +check_cntr_accessible(12)
> +check_cntr_accessible(13)
> +check_cntr_accessible(14)
> +check_cntr_accessible(15)
> +check_cntr_accessible(16)
> +check_cntr_accessible(17)
> +check_cntr_accessible(18)
> +check_cntr_accessible(19)
> +check_cntr_accessible(20)
> +check_cntr_accessible(21)
> +check_cntr_accessible(22)
> +check_cntr_accessible(23)
> +check_cntr_accessible(24)
> +check_cntr_accessible(25)
> +check_cntr_accessible(26)
> +check_cntr_accessible(27)
> +check_cntr_accessible(28)
> +check_cntr_accessible(29)
> +check_cntr_accessible(30)
I'd rather we not use templates for this problem. It bloats the kernel text
as well as the trap encoding space.
I have a patch in the nested PMU series that uses a single complex trap
ID to evaluate HPMN, and derives the index from ESR_EL2. I think it
could also be extended to the PMEVCNTSVR<n> range as well.
Also, keep in mind that the HPMN trap is annoying since it affects Host
EL0 in addition to 'guest' ELs.
[*]: https://lore.kernel.org/kvmarm/20240827002235.1753237-9-oliver.upton@linux.dev/
--
Thanks,
Oliver
Powered by blists - more mailing lists