Hello,
On 3/30/21 12:12 PM, Suzuki K Poulose wrote:
> Hi Marc
>
> On 30/03/2021 11:12, Marc Zyngier wrote:
>> Hi Suzuki,
>>
>> [+ Alex]
>>
>> On Tue, 23 Mar 2021 12:06:35 +0000,
>> Suzuki K Poulose <suzuki.poul...@arm.com> wrote:
>>> [..]
>>
>>> #define MDCR_EL2_TTRF (1 << 19)
>>> #define MDCR_EL2_TPMS (1 << 14)
>>> #define MDCR_EL2_E2PB_MASK (UL(0x3))
>>> diff --git a/arch/arm64/include/asm/kvm_host.h
>>> b/arch/arm64/include/asm/kvm_host.h
>>> index 3d10e6527f7d..80d0a1a82a4c 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -315,6 +315,8 @@ struct kvm_vcpu_arch {
>>> struct kvm_guest_debug_arch regs;
>>> /* Statistical profiling extension */
>>> u64 pmscr_el1;
>>> + /* Self-hosted trace */
>>> + u64 trfcr_el1;
>>> } host_debug_state;
>>> /* VGIC state */
>>> diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
>>> index 5eccbd62fec8..05d25e645b46 100644
>>> --- a/arch/arm64/kernel/hyp-stub.S
>>> +++ b/arch/arm64/kernel/hyp-stub.S
>>> @@ -115,9 +115,10 @@ SYM_CODE_START_LOCAL(mutate_to_vhe)
>>> mrs_s x0, SYS_VBAR_EL12
>>> msr vbar_el1, x0
>>> - // Use EL2 translations for SPE and disable access from EL1
>>> + // Use EL2 translations for SPE & TRBE and disable access from EL1
>>> mrs x0, mdcr_el2
>>> bic x0, x0, #(MDCR_EL2_E2PB_MASK << MDCR_EL2_E2PB_SHIFT)
>>> + bic x0, x0, #(MDCR_EL2_E2TB_MASK << MDCR_EL2_E2TB_SHIFT)
>>> msr mdcr_el2, x0
>>> // Transfer the MM state from EL1 to EL2
>>> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
>>> index dbc890511631..7b16f42d39f4 100644
>>> --- a/arch/arm64/kvm/debug.c
>>> +++ b/arch/arm64/kvm/debug.c
>>> @@ -89,7 +89,7 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu)
>>> * - Debug ROM Address (MDCR_EL2_TDRA)
>>> * - OS related registers (MDCR_EL2_TDOSA)
>>> * - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB)
>>> - * - Self-hosted Trace Filter controls (MDCR_EL2_TTRF)
>>> + * - Self-hosted Trace (MDCR_EL2_TTRF/MDCR_EL2_E2TB)
>>
>> For the record, this is likely to conflict with [1], although that
>> patch still has some issues.
>
> Thanks for the heads up. I think that patch will also conflict with my fixes
> that is queued in kvmarm/fixes.
How should I proceed with the patch [1]? For the next iteration, should I rebase
it on top of kvmarm/fixes or on top of kvmarm/fixes + this series?
[1] https://lore.kernel.org/r/20210323180057.263356-1-alexandru.eli...@arm.com
Thanks,
Alex
