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