Re: [RFC PATCH] KVM: arm64: Restrict CNTP_CVAL/CNTHP_CVAL save/reload when ptimer is used

[Marc Zyngier <maz@kernel.org>]

On Mon, 21 Sep 2026 12:18:40 +0100,
Zhou Wang <wangzhou1@hisilicon.com> wrote:
> 
> A guest's physical timer may be used in nested guest or directly used in
> VHE mode. We can check above cases to avoid useless CNTP_CVAL/CNTHP_CVAL save
> and reload.

Why useless? What cases?

> 
> Use lazy detection to determine whether a non-nested VHE guest actually uses
> the physical timer.
> 
> timer_set_traps() initially traps CNTP_CTL_EL0 writes for non-nested guests.
> On the first write that sets CNTP_CTL.ENABLE=1, the trap handler records
> ptimer_used and clears the trap in CNTHCTL_EL2, allowing the guest direct
> access thereafter.

I really don't want to go into these micro optimisation to paper over
the bad state of the architecture.

The options are:

- Don't use any offset (offsets always set to 0), and there will not
  be any trap

- Use CNTPOFF, which will work just fine for an L1 guest, without
  traps

- For nested guests, there is no solution that matches the
  architecture (CNTPOFF doesn't nest), and you must trap.

So where is the cost in your case?

> 
> A test result from KUT in HiSilicon HIP12 is:
> 
>                     nopatch        patch
>  hvc                758            624
>  mmio_read_user     3647           3479
>  mmio_read_vgic     949            817
>  eoi                29             29
>  ipi                2534           2302
>  lpi                2684           2442
>  timer_10ms         2393           2168

I don't know what these numbers are. There is no unit, no indication
of how this is run (L1, L2, Ln...), no base kernel version...

Can you please explain what you are actually trying to do? Are you
saying that accessing the physical timer (two registers) is that
expensive?

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.