drm/bridge: tc358764: Fix build error
[linux-2.6-block.git] / Documentation / powerpc / DAWR-POWER9.txt
CommitLineData
c6bef2e9
MN
1DAWR issues on POWER9
2============================
3
29b861ea
JS
4On POWER9 the Data Address Watchpoint Register (DAWR) can cause a checkstop
5if it points to cache inhibited (CI) memory. Currently Linux has no way to
6disinguish CI memory when configuring the DAWR, so (for now) the DAWR is
7disabled by this commit:
c6bef2e9
MN
8
9 commit 9654153158d3e0684a1bdb76dbababdb7111d5a0
10 Author: Michael Neuling <mikey@neuling.org>
11 Date: Tue Mar 27 15:37:24 2018 +1100
12 powerpc: Disable DAWR in the base POWER9 CPU features
13
14Technical Details:
15============================
16
17DAWR has 6 different ways of being set.
181) ptrace
192) h_set_mode(DAWR)
203) h_set_dabr()
214) kvmppc_set_one_reg()
225) xmon
23
24For ptrace, we now advertise zero breakpoints on POWER9 via the
25PPC_PTRACE_GETHWDBGINFO call. This results in GDB falling back to
26software emulation of the watchpoint (which is slow).
27
28h_set_mode(DAWR) and h_set_dabr() will now return an error to the
29guest on a POWER9 host. Current Linux guests ignore this error, so
30they will silently not get the DAWR.
31
32kvmppc_set_one_reg() will store the value in the vcpu but won't
33actually set it on POWER9 hardware. This is done so we don't break
34migration from POWER8 to POWER9, at the cost of silently losing the
35DAWR on the migration.
36
37For xmon, the 'bd' command will return an error on P9.
38
39Consequences for users
40============================
41
42For GDB watchpoints (ie 'watch' command) on POWER9 bare metal , GDB
43will accept the command. Unfortunately since there is no hardware
44support for the watchpoint, GDB will software emulate the watchpoint
45making it run very slowly.
46
47The same will also be true for any guests started on a POWER9
48host. The watchpoint will fail and GDB will fall back to software
49emulation.
50
51If a guest is started on a POWER8 host, GDB will accept the watchpoint
52and configure the hardware to use the DAWR. This will run at full
53speed since it can use the hardware emulation. Unfortunately if this
54guest is migrated to a POWER9 host, the watchpoint will be lost on the
55POWER9. Loads and stores to the watchpoint locations will not be
56trapped in GDB. The watchpoint is remembered, so if the guest is
57migrated back to the POWER8 host, it will start working again.
58
c1fe190c
MN
59Force enabling the DAWR
60=============================
61Kernels (since ~v5.2) have an option to force enable the DAWR via:
62
63 echo Y > /sys/kernel/debug/powerpc/dawr_enable_dangerous
64
65This enables the DAWR even on POWER9.
66
67This is a dangerous setting, USE AT YOUR OWN RISK.
68
69Some users may not care about a bad user crashing their box
70(ie. single user/desktop systems) and really want the DAWR. This
71allows them to force enable DAWR.
72
73This flag can also be used to disable DAWR access. Once this is
74cleared, all DAWR access should be cleared immediately and your
75machine once again safe from crashing.
76
77Userspace may get confused by toggling this. If DAWR is force
78enabled/disabled between getting the number of breakpoints (via
79PTRACE_GETHWDBGINFO) and setting the breakpoint, userspace will get an
80inconsistent view of what's available. Similarly for guests.
81
82For the DAWR to be enabled in a KVM guest, the DAWR needs to be force
83enabled in the host AND the guest. For this reason, this won't work on
84POWERVM as it doesn't allow the HCALL to work. Writes of 'Y' to the
85dawr_enable_dangerous file will fail if the hypervisor doesn't support
86writing the DAWR.
87
88To double check the DAWR is working, run this kernel selftest:
89 tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
90Any errors/failures/skips mean something is wrong.