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