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

[Marc Zyngier <maz@kernel.org>]

On Tue, 22 Sep 2026 11:16:36 +0100,
Zhou Wang <wangzhou1@hisilicon.com> wrote:
> 
> On 2026/9/21 21:22, Marc Zyngier wrote:
> > 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?
> 
> I mean we do not use ptimer at least in current Linux kernel, however, for system
> which has ECV_CNTPOFF capability, we have to handle related logic here.
> 
> So we can detect if ptimer is been used, if it is been used, then we run into the
> related codes.

But where is the actual cost? Is it the saving of these registers?
Something else?

> 
> I am not familiar with the nested cases, so just not change related logic.
> 
> > 
> >>
> >> 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
> 
> Do you mean that in non-nested case, we can make offset always be 0, so
> related logic in __activate_traps/__deactivate_traps can be skipped?
>

The *trapping* of the physical timer/counter will be skipped.

	M.

-- 
Without deviation from the norm, progress is not possible.