102 lines · plain
1=====================2DAWR issues on POWER93=====================4 5On older POWER9 processors, the Data Address Watchpoint Register (DAWR) can6cause a checkstop if it points to cache inhibited (CI) memory. Currently Linux7has no way to distinguish CI memory when configuring the DAWR, so on affected8systems, the DAWR is disabled.9 10Affected processor revisions11============================12 13This issue is only present on processors prior to v2.3. The revision can be14found in /proc/cpuinfo::15 16 processor : 017 cpu : POWER9, altivec supported18 clock : 3800.000000MHz19 revision : 2.3 (pvr 004e 1203)20 21On a system with the issue, the DAWR is disabled as detailed below.22 23Technical Details:24==================25 26DAWR has 6 different ways of being set.271) ptrace282) h_set_mode(DAWR)293) h_set_dabr()304) kvmppc_set_one_reg()315) xmon32 33For ptrace, we now advertise zero breakpoints on POWER9 via the34PPC_PTRACE_GETHWDBGINFO call. This results in GDB falling back to35software emulation of the watchpoint (which is slow).36 37h_set_mode(DAWR) and h_set_dabr() will now return an error to the38guest on a POWER9 host. Current Linux guests ignore this error, so39they will silently not get the DAWR.40 41kvmppc_set_one_reg() will store the value in the vcpu but won't42actually set it on POWER9 hardware. This is done so we don't break43migration from POWER8 to POWER9, at the cost of silently losing the44DAWR on the migration.45 46For xmon, the 'bd' command will return an error on P9.47 48Consequences for users49======================50 51For GDB watchpoints (ie 'watch' command) on POWER9 bare metal , GDB52will accept the command. Unfortunately since there is no hardware53support for the watchpoint, GDB will software emulate the watchpoint54making it run very slowly.55 56The same will also be true for any guests started on a POWER957host. The watchpoint will fail and GDB will fall back to software58emulation.59 60If a guest is started on a POWER8 host, GDB will accept the watchpoint61and configure the hardware to use the DAWR. This will run at full62speed since it can use the hardware emulation. Unfortunately if this63guest is migrated to a POWER9 host, the watchpoint will be lost on the64POWER9. Loads and stores to the watchpoint locations will not be65trapped in GDB. The watchpoint is remembered, so if the guest is66migrated back to the POWER8 host, it will start working again.67 68Force enabling the DAWR69=======================70Kernels (since ~v5.2) have an option to force enable the DAWR via::71 72 echo Y > /sys/kernel/debug/powerpc/dawr_enable_dangerous73 74This enables the DAWR even on POWER9.75 76This is a dangerous setting, USE AT YOUR OWN RISK.77 78Some users may not care about a bad user crashing their box79(ie. single user/desktop systems) and really want the DAWR. This80allows them to force enable DAWR.81 82This flag can also be used to disable DAWR access. Once this is83cleared, all DAWR access should be cleared immediately and your84machine once again safe from crashing.85 86Userspace may get confused by toggling this. If DAWR is force87enabled/disabled between getting the number of breakpoints (via88PTRACE_GETHWDBGINFO) and setting the breakpoint, userspace will get an89inconsistent view of what's available. Similarly for guests.90 91For the DAWR to be enabled in a KVM guest, the DAWR needs to be force92enabled in the host AND the guest. For this reason, this won't work on93POWERVM as it doesn't allow the HCALL to work. Writes of 'Y' to the94dawr_enable_dangerous file will fail if the hypervisor doesn't support95writing the DAWR.96 97To double check the DAWR is working, run this kernel selftest:98 99 tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c100 101Any errors/failures/skips mean something is wrong.102