Re: [PATCH] KVM: arm64: Correctly handle RES0 bits PMEVTYPER<n>_EL0.evtCount

[Oliver Upton <oliver.upton@linux.dev>]

On Fri, Jul 14, 2023 at 06:46:39AM -0700, Reiji Watanabe wrote:
> On Thu, Jul 13, 2023 at 3:17 PM Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > The PMU event ID varies from 10 to 16 bits, depending on the PMU
> > version. If the PMU only supports 10 bits of event ID, bits [15:10] of
> > the evtCount field behave as RES0.
> >
> > While the actual PMU emulation code gets this right (i.e. RES0 bits are
> > masked out when programming the perf event), the sysreg emulation writes
> > an unmasked value to the in-memory cpu context. The net effect is that
> > guest reads and writes of PMEVTYPER<n>_EL0 will see non-RES0 behavior in
> > the reserved bits of the field.
> >
> > As it so happens, kvm_pmu_set_counter_event_type() already writes a
> > masked value to the in-memory context that gets overwritten by
> > access_pmu_evtyper(). Fix the issue by removing the unnecessary (and
> > incorrect) register write in access_pmu_evtyper().
> >
> > Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> 
> Reviewed-by: Reiji Watanabe <reijiw@google.com>

Thanks!

> FYI. Looking at their reset values, fortunately, the pseudo
> "unknown" reset values used by reset_pmevtyper() has the
> bits [16:11] cleared.
> I would think it's a bit fragile, but not a real problem.

Fragile indeed. I'd like to clean up the handling a bit more in the
future, because it makes no sense why we mask the value read from
__vcpu_sys_reg() for emulated reads.

-- 
Thanks,
Oliver