Re: [PATCH] KVM/arm64: Don't emulate a PMU for 32-bit guests if feature not set

From: Oliver Upton <oupton@google.com>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: maz@kernel.org, kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] KVM/arm64: Don't emulate a PMU for 32-bit guests if feature not set
Date: Tue, 26 Apr 2022 08:05:11 +0000	[thread overview]
Message-ID: <Yment8uGahyB+wgK@google.com> (raw)
In-Reply-To: <20220425145530.723858-1-alexandru.elisei@arm.com>

Hi Alex,

On Mon, Apr 25, 2022 at 03:55:30PM +0100, Alexandru Elisei wrote:

[...]

> The root cause remains the same: kvm->arch.pmuver was never set to
> something sensible because the VCPU feature itself was never set.
> 
> The odroid-c4 is somewhat of a special case, because Linux doesn't probe
> the PMU. But the above errors can easily be reproduced on any hardware,
> with or without a PMU driver, as long as userspace doesn't set the PMU
> feature.

This note has me wondering if we could do more negative testing with
kvm-unit-tests just by selectively turning on/off features, with the
expectation that tests either skip or pass.

> Work around the fact that KVM advertises a PMU even when the VCPU feature
> is not set by gating all PMU emulation on the feature. The guest can still
> access the registers without KVM injecting an undefined exception.

We're going to need something similar even after KVM conditionally
advertises the PMU.

WDYT about wiring up sys_reg_desc::visibility for the AArch32 PMU
registers? For now just treat them as REG_RAZ (probably extend this to
imply WI too) then promote to REG_HIDDEN in a later patch.

--
Thanks,
Oliver
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm