mbox series

[v2,0/6] KVM: arm64: EL2 PMU handling fixes

Message ID 20250409160106.6445-1-maz@kernel.org (mailing list archive)
Headers show
Series KVM: arm64: EL2 PMU handling fixes | expand

Message

Marc Zyngier April 9, 2025, 4:01 p.m. UTC
Joey reports that some of his PMU tests do not behave quite as
expected:

- MDCR_EL2.HPMN is set to 0 out of reset

- PMCR_EL0.P should reset all the counters when written from EL2

Oliver points out that setting PMCR_EL0.N from userspace by writing to
the register is silly with NV, and that we need a new PMU attribute
instead.

On top of that, I figured out that we had a number of little gotchas:

- It is possible for a guest to write an HPMN value that is out of
  bound, and it seems valuable to limit it

- PMCR_EL0.N should be the maximum number of counters when read from
  EL2, and MDCR_EL2.HPMN when read from EL0/EL1

- Prevent userspace from updating PMCR_EL0.N when EL2 is available

I haven't added any Cc stable, as NV is not functional upstream yet.

* From v1 [1]:

  - Added patch for the new PMU attribute
  - Added fix for HPMN limit
  - Prevent update of PMCR_EL0.N with NV
  - Fix kvm_vcpu_read_pmcr()
  - Rebased on 6.15-rc1

[1] https://lore.kernel.org/r/20250217112412.3963324-1-maz@kernel.org

Marc Zyngier (6):
  KVM: arm64: Fix MDCR_EL2.HPMN reset value
  KVM: arm64: Contextualise the handling of PMCR_EL0.P writes
  KVM: arm64: Allow userspace to limit the number of PMU counters for
    EL2 VMs
  KVM: arm64: Don't let userspace write to PMCR_EL0.N when the vcpu has
    EL2
  KVM: arm64: Handle out-of-bound write to HDCR_EL2.HPMN
  KVM: arm64: Let kvm_vcpu_read_pmcr() return an EL-dependent value for
    PMCR_EL0.N

 Documentation/virt/kvm/devices/vcpu.rst | 24 ++++++++++++
 arch/arm64/include/uapi/asm/kvm.h       |  9 +++--
 arch/arm64/kvm/pmu-emul.c               | 51 ++++++++++++++++++++++---
 arch/arm64/kvm/sys_regs.c               | 43 ++++++++++++++++-----
 4 files changed, 107 insertions(+), 20 deletions(-)

Comments

Oliver Upton April 9, 2025, 8:31 p.m. UTC | #1
On Wed, Apr 09, 2025 at 05:01:00PM +0100, Marc Zyngier wrote:
> Joey reports that some of his PMU tests do not behave quite as
> expected:
> 
> - MDCR_EL2.HPMN is set to 0 out of reset
> 
> - PMCR_EL0.P should reset all the counters when written from EL2
> 
> Oliver points out that setting PMCR_EL0.N from userspace by writing to
> the register is silly with NV, and that we need a new PMU attribute
> instead.
> 
> On top of that, I figured out that we had a number of little gotchas:
> 
> - It is possible for a guest to write an HPMN value that is out of
>   bound, and it seems valuable to limit it
> 
> - PMCR_EL0.N should be the maximum number of counters when read from
>   EL2, and MDCR_EL2.HPMN when read from EL0/EL1
> 
> - Prevent userspace from updating PMCR_EL0.N when EL2 is available
> 
> I haven't added any Cc stable, as NV is not functional upstream yet.

Similarly, I don't see a compelling reason for this to go in as a fix
for 6.15, especially since you're adding new UAPI. Do you mind grabbing
it for the next merge window?

With the comments addressed:

Reviewed-by: Oliver Upton <oliver.upton@linux.dev>

Thanks,
Oliver
Marc Zyngier April 11, 2025, noon UTC | #2
On Wed, 09 Apr 2025 21:31:31 +0100,
Oliver Upton <oliver.upton@linux.dev> wrote:
> 
> On Wed, Apr 09, 2025 at 05:01:00PM +0100, Marc Zyngier wrote:
> > Joey reports that some of his PMU tests do not behave quite as
> > expected:
> > 
> > - MDCR_EL2.HPMN is set to 0 out of reset
> > 
> > - PMCR_EL0.P should reset all the counters when written from EL2
> > 
> > Oliver points out that setting PMCR_EL0.N from userspace by writing to
> > the register is silly with NV, and that we need a new PMU attribute
> > instead.
> > 
> > On top of that, I figured out that we had a number of little gotchas:
> > 
> > - It is possible for a guest to write an HPMN value that is out of
> >   bound, and it seems valuable to limit it
> > 
> > - PMCR_EL0.N should be the maximum number of counters when read from
> >   EL2, and MDCR_EL2.HPMN when read from EL0/EL1
> > 
> > - Prevent userspace from updating PMCR_EL0.N when EL2 is available
> > 
> > I haven't added any Cc stable, as NV is not functional upstream yet.
> 
> Similarly, I don't see a compelling reason for this to go in as a fix
> for 6.15, especially since you're adding new UAPI. Do you mind grabbing
> it for the next merge window?
> 
> With the comments addressed:
> 
> Reviewed-by: Oliver Upton <oliver.upton@linux.dev>

Thanks. I'll repost the whole thing next week and queue it for 6.16.

	M.