[RFC PATCH] target/arm: add RAZ/WI handling for DBGDTR[TX|RX]

[RFC PATCH] target/arm: add RAZ/WI handling for DBGDTR[TX|RX]

[Alex Bennée]

The commit b3aa2f2128 (target/arm: provide stubs for more external
debug registers) was added to handle HyperV's unconditional usage of
Debug Communications Channel. It turns out that Linux will similarly
break if you enable CONFIG_HVC_DCC "ARM JTAG DCC console".

Extend the registers we RAZ/WI set to avoid this.

Cc: Anders Roxell <anders.roxell@linaro.org>
Cc: Evgeny Iakovlev <eiakovlev@linux.microsoft.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 target/arm/debug_helper.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/target/arm/debug_helper.c b/target/arm/debug_helper.c
index dfc8b2a1a5..d41cc643b1 100644
--- a/target/arm/debug_helper.c
+++ b/target/arm/debug_helper.c
@@ -949,8 +949,10 @@ static const ARMCPRegInfo debug_cp_reginfo[] = {
       .access = PL0_R, .accessfn = access_tdcc,
       .type = ARM_CP_CONST, .resetvalue = 0 },
     /*
-     * OSDTRRX_EL1/OSDTRTX_EL1 are used for save and restore of DBGDTRRX_EL0.
-     * It is a component of the Debug Communications Channel, which is not implemented.
+     * These registers belong to the Debug Communications Channel,
+     * which is not implemented. However we implement RAZ/WI behaviour
+     * with trapping to prevent spurious SIGILLs if the guest OS does
+     * access them as the support cannot be probed for.
      */
     { .name = "OSDTRRX_EL1", .state = ARM_CP_STATE_BOTH, .cp = 14,
       .opc0 = 2, .opc1 = 0, .crn = 0, .crm = 0, .opc2 = 2,
@@ -960,6 +962,11 @@ static const ARMCPRegInfo debug_cp_reginfo[] = {
       .opc0 = 2, .opc1 = 0, .crn = 0, .crm = 3, .opc2 = 2,
       .access = PL1_RW, .accessfn = access_tdcc,
       .type = ARM_CP_CONST, .resetvalue = 0 },
+    /* DBGDTRTX_EL0/DBGDTRRX_EL0 depend on direction */
+    { .name = "DBGDTR_EL0", .state = ARM_CP_STATE_BOTH, .cp = 14,
+      .opc0 = 2, .opc1 = 3, .crn = 0, .crm = 5, .opc2 = 0,
+      .access = PL0_RW, .accessfn = access_tdcc,
+      .type = ARM_CP_CONST, .resetvalue = 0 },
     /*
      * OSECCR_EL1 provides a mechanism for an operating system
      * to access the contents of EDECCR. EDECCR is not implemented though,
-- 
2.39.2

Re: [RFC PATCH] target/arm: add RAZ/WI handling for DBGDTR[TX|RX]

[Richard Henderson]

On 5/16/23 03:44, Alex Bennée wrote:
> The commit b3aa2f2128 (target/arm: provide stubs for more external
> debug registers) was added to handle HyperV's unconditional usage of
> Debug Communications Channel. It turns out that Linux will similarly
> break if you enable CONFIG_HVC_DCC "ARM JTAG DCC console".
> 
> Extend the registers we RAZ/WI set to avoid this.
> 
> Cc: Anders Roxell<anders.roxell@linaro.org>
> Cc: Evgeny Iakovlev<eiakovlev@linux.microsoft.com>
> Signed-off-by: Alex Bennée<alex.bennee@linaro.org>
> ---
>   target/arm/debug_helper.c | 11 +++++++++--
>   1 file changed, 9 insertions(+), 2 deletions(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [RFC PATCH] target/arm: add RAZ/WI handling for DBGDTR[TX|RX]

[Peter Maydell]

On Tue, 16 May 2023 at 11:44, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> The commit b3aa2f2128 (target/arm: provide stubs for more external
> debug registers) was added to handle HyperV's unconditional usage of
> Debug Communications Channel. It turns out that Linux will similarly
> break if you enable CONFIG_HVC_DCC "ARM JTAG DCC console".
>
> Extend the registers we RAZ/WI set to avoid this.

Applied to target-arm.next, thanks.

(In theory we could implement the DCC and wire it up to a
chardev, which might be a cute way of getting early debug.)

-- PMM

Re: [RFC PATCH] target/arm: add RAZ/WI handling for DBGDTR[TX|RX]

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> On Tue, 16 May 2023 at 11:44, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> The commit b3aa2f2128 (target/arm: provide stubs for more external
>> debug registers) was added to handle HyperV's unconditional usage of
>> Debug Communications Channel. It turns out that Linux will similarly
>> break if you enable CONFIG_HVC_DCC "ARM JTAG DCC console".
>>
>> Extend the registers we RAZ/WI set to avoid this.
>
> Applied to target-arm.next, thanks.
>
> (In theory we could implement the DCC and wire it up to a
> chardev, which might be a cute way of getting early debug.)

I wondered about that - does DCC give you anything that you can't get
with semihosting (which I think also can support earlycon)?

I found it a little unclear if this is an always available feature.
Should you expect any modern Cortex/Arm chip to support DCC when
attached to jtag?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [RFC PATCH] target/arm: add RAZ/WI handling for DBGDTR[TX|RX]

[Peter Maydell]

On Thu, 18 May 2023 at 12:11, Alex Bennée <alex.bennee@linaro.org> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Tue, 16 May 2023 at 11:44, Alex Bennée <alex.bennee@linaro.org> wrote:
> >>
> >> The commit b3aa2f2128 (target/arm: provide stubs for more external
> >> debug registers) was added to handle HyperV's unconditional usage of
> >> Debug Communications Channel. It turns out that Linux will similarly
> >> break if you enable CONFIG_HVC_DCC "ARM JTAG DCC console".
> >>
> >> Extend the registers we RAZ/WI set to avoid this.
> >
> > Applied to target-arm.next, thanks.
> >
> > (In theory we could implement the DCC and wire it up to a
> > chardev, which might be a cute way of getting early debug.)
>
> I wondered about that - does DCC give you anything that you can't get
> with semihosting (which I think also can support earlycon)?

It gets you a debug console without having to trust the guest
not to scribble all over your host filesystem :-) I'm not sure
this really justifies the effort of the implementation, though.
(Also, as usual the awkward part is the UI and how you'd let
the user specify the chardev to connect up.)

> I found it a little unclear if this is an always available feature.
> Should you expect any modern Cortex/Arm chip to support DCC when
> attached to jtag?

My guess is if you can attach to it over jtag at all then
the DCC channel will be there.

-- PMM