Re: [PATCH] KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context

[Suzuki K Poulose <suzuki.poulose@arm.com>]

On 03/03/2026 10:36, Leo Yan wrote:
> On Fri, Feb 27, 2026 at 06:07:44PM +0000, Will Deacon wrote:
>> On Wed, Feb 25, 2026 at 12:09:56PM +0000, Leo Yan wrote:
>>> [ + Yabin ]
>>>
>>> Thanks for Suzuki's reminding, I should mention that Yabin reported
>>> another lockup issue caused by missing CPU PM support in TRBE driver.
>>>
>>> We have a patch series to fix the issue:
>>> https://lore.kernel.org/linux-arm-kernel/20251119-arm_coresight_path_power_management_improvement-v5-16-f615a301ad0b@arm.com/
>>
>> Two nits on that series:
>>
>> 1. It seems a bit weird to me for the ETE driver to manage TRFCR but for
>>     the TRBE driver to manage the other registers
> 
> TRFCR_ELx is introduced by FEAT_TRF, which is a separate feature from
> TRBE, and it can be used for other sinks (like ETR).  I think this is
> the main reason that it is implemented in ETE driver rather than TRBE
> driver.

Thats correct. TRFCR is more tied to the ETE/ETM (e.g., filter traces 
for various ELs depending on the event configuration and also for
changing the ETM/ETE states). That said, we use that to prohibit
trace while we do maintenance on the TRBE.

> 
>> 2. Are you sure you don't need to save/restore the TRBE state when
>>     LIMITR.E is clear? Maybe the driver is fine with that, but I'm worried
>>     that we could suspend in a half-programmed state and lose some of that
>>     configuration.
> 
> If the TRBLIMITR_EL1.E bit is cleared during the CPU is idle, then the
> next time the TRBE trace buffer is re-enabled, trbe_enable_hw() must be
> called to reconfigure the TRBE registers (including TRBSR_EL1).

We don't leave the registers in  a half baked state. We always program
all the TRBE registers when we enable them. But, that said, we do have
a case now with the fix for Disabling the TRBE (TRBLIMITR.E == 0) for
nVHE, while the rest of the TRBE registers are retained. The chances
of us going in to Idle, without restoring the TRBLIMITR to the host
value doesn't exist. But we could save/restore the registers to be
safe.


Suzuki

> 
> One concern is that after a CPU power cycle, some fields in the TRBE
> registers may be in the following state:
> 
>    "On a cold reset, this field resets to an architecturally UNKNOWN value."
> 
> I will change to always save/restore TRBE state.  Thanks for
> suggestions.
> 
>>> Besides your fix the translation regime issue, I'd also suggest applying
>>> the CoreSight PM patch series to fix lockup caused by CPU idle.
>>
>> Yes, we definitely need something like that in the android kernel trees.
>> I've previously bodged a hack into the ETE PM notifiers, but if you have
>> backports of your series to 6.12, 6.6 and 6.1 then we should merge them
>> into Android. As it stands, I don't have a TRBE-capable device running
>> mainline.
> 
> Let us first merge the series on the master :)
> 
> After that, we can consider backporting (I assume Yabin already has a
> plan for this).  I'd be happy to help with backporting to v6.12.
> However, I cannot commit to backporting to v6.6 or v6.1 at this stage,
> as many dependencies are likely to be involved.
> 
> Thanks,
> Leo