| Message ID | 20230516104420.407912-1-alex.bennee@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [RFC] target/arm: add RAZ/WI handling for DBGDTR[TX|RX] | expand |
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~
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
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?
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
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,
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(-)