18c2ecf20Sopenharmony_ci===================== 28c2ecf20Sopenharmony_ciDAWR issues on POWER9 38c2ecf20Sopenharmony_ci===================== 48c2ecf20Sopenharmony_ci 58c2ecf20Sopenharmony_ciOn POWER9 the Data Address Watchpoint Register (DAWR) can cause a checkstop 68c2ecf20Sopenharmony_ciif it points to cache inhibited (CI) memory. Currently Linux has no way to 78c2ecf20Sopenharmony_cidisinguish CI memory when configuring the DAWR, so (for now) the DAWR is 88c2ecf20Sopenharmony_cidisabled by this commit:: 98c2ecf20Sopenharmony_ci 108c2ecf20Sopenharmony_ci commit 9654153158d3e0684a1bdb76dbababdb7111d5a0 118c2ecf20Sopenharmony_ci Author: Michael Neuling <mikey@neuling.org> 128c2ecf20Sopenharmony_ci Date: Tue Mar 27 15:37:24 2018 +1100 138c2ecf20Sopenharmony_ci powerpc: Disable DAWR in the base POWER9 CPU features 148c2ecf20Sopenharmony_ci 158c2ecf20Sopenharmony_ciTechnical Details: 168c2ecf20Sopenharmony_ci================== 178c2ecf20Sopenharmony_ci 188c2ecf20Sopenharmony_ciDAWR has 6 different ways of being set. 198c2ecf20Sopenharmony_ci1) ptrace 208c2ecf20Sopenharmony_ci2) h_set_mode(DAWR) 218c2ecf20Sopenharmony_ci3) h_set_dabr() 228c2ecf20Sopenharmony_ci4) kvmppc_set_one_reg() 238c2ecf20Sopenharmony_ci5) xmon 248c2ecf20Sopenharmony_ci 258c2ecf20Sopenharmony_ciFor ptrace, we now advertise zero breakpoints on POWER9 via the 268c2ecf20Sopenharmony_ciPPC_PTRACE_GETHWDBGINFO call. This results in GDB falling back to 278c2ecf20Sopenharmony_cisoftware emulation of the watchpoint (which is slow). 288c2ecf20Sopenharmony_ci 298c2ecf20Sopenharmony_cih_set_mode(DAWR) and h_set_dabr() will now return an error to the 308c2ecf20Sopenharmony_ciguest on a POWER9 host. Current Linux guests ignore this error, so 318c2ecf20Sopenharmony_cithey will silently not get the DAWR. 328c2ecf20Sopenharmony_ci 338c2ecf20Sopenharmony_cikvmppc_set_one_reg() will store the value in the vcpu but won't 348c2ecf20Sopenharmony_ciactually set it on POWER9 hardware. This is done so we don't break 358c2ecf20Sopenharmony_cimigration from POWER8 to POWER9, at the cost of silently losing the 368c2ecf20Sopenharmony_ciDAWR on the migration. 378c2ecf20Sopenharmony_ci 388c2ecf20Sopenharmony_ciFor xmon, the 'bd' command will return an error on P9. 398c2ecf20Sopenharmony_ci 408c2ecf20Sopenharmony_ciConsequences for users 418c2ecf20Sopenharmony_ci====================== 428c2ecf20Sopenharmony_ci 438c2ecf20Sopenharmony_ciFor GDB watchpoints (ie 'watch' command) on POWER9 bare metal , GDB 448c2ecf20Sopenharmony_ciwill accept the command. Unfortunately since there is no hardware 458c2ecf20Sopenharmony_cisupport for the watchpoint, GDB will software emulate the watchpoint 468c2ecf20Sopenharmony_cimaking it run very slowly. 478c2ecf20Sopenharmony_ci 488c2ecf20Sopenharmony_ciThe same will also be true for any guests started on a POWER9 498c2ecf20Sopenharmony_cihost. The watchpoint will fail and GDB will fall back to software 508c2ecf20Sopenharmony_ciemulation. 518c2ecf20Sopenharmony_ci 528c2ecf20Sopenharmony_ciIf a guest is started on a POWER8 host, GDB will accept the watchpoint 538c2ecf20Sopenharmony_ciand configure the hardware to use the DAWR. This will run at full 548c2ecf20Sopenharmony_cispeed since it can use the hardware emulation. Unfortunately if this 558c2ecf20Sopenharmony_ciguest is migrated to a POWER9 host, the watchpoint will be lost on the 568c2ecf20Sopenharmony_ciPOWER9. Loads and stores to the watchpoint locations will not be 578c2ecf20Sopenharmony_citrapped in GDB. The watchpoint is remembered, so if the guest is 588c2ecf20Sopenharmony_cimigrated back to the POWER8 host, it will start working again. 598c2ecf20Sopenharmony_ci 608c2ecf20Sopenharmony_ciForce enabling the DAWR 618c2ecf20Sopenharmony_ci======================= 628c2ecf20Sopenharmony_ciKernels (since ~v5.2) have an option to force enable the DAWR via:: 638c2ecf20Sopenharmony_ci 648c2ecf20Sopenharmony_ci echo Y > /sys/kernel/debug/powerpc/dawr_enable_dangerous 658c2ecf20Sopenharmony_ci 668c2ecf20Sopenharmony_ciThis enables the DAWR even on POWER9. 678c2ecf20Sopenharmony_ci 688c2ecf20Sopenharmony_ciThis is a dangerous setting, USE AT YOUR OWN RISK. 698c2ecf20Sopenharmony_ci 708c2ecf20Sopenharmony_ciSome users may not care about a bad user crashing their box 718c2ecf20Sopenharmony_ci(ie. single user/desktop systems) and really want the DAWR. This 728c2ecf20Sopenharmony_ciallows them to force enable DAWR. 738c2ecf20Sopenharmony_ci 748c2ecf20Sopenharmony_ciThis flag can also be used to disable DAWR access. Once this is 758c2ecf20Sopenharmony_cicleared, all DAWR access should be cleared immediately and your 768c2ecf20Sopenharmony_cimachine once again safe from crashing. 778c2ecf20Sopenharmony_ci 788c2ecf20Sopenharmony_ciUserspace may get confused by toggling this. If DAWR is force 798c2ecf20Sopenharmony_cienabled/disabled between getting the number of breakpoints (via 808c2ecf20Sopenharmony_ciPTRACE_GETHWDBGINFO) and setting the breakpoint, userspace will get an 818c2ecf20Sopenharmony_ciinconsistent view of what's available. Similarly for guests. 828c2ecf20Sopenharmony_ci 838c2ecf20Sopenharmony_ciFor the DAWR to be enabled in a KVM guest, the DAWR needs to be force 848c2ecf20Sopenharmony_cienabled in the host AND the guest. For this reason, this won't work on 858c2ecf20Sopenharmony_ciPOWERVM as it doesn't allow the HCALL to work. Writes of 'Y' to the 868c2ecf20Sopenharmony_cidawr_enable_dangerous file will fail if the hypervisor doesn't support 878c2ecf20Sopenharmony_ciwriting the DAWR. 888c2ecf20Sopenharmony_ci 898c2ecf20Sopenharmony_ciTo double check the DAWR is working, run this kernel selftest: 908c2ecf20Sopenharmony_ci 918c2ecf20Sopenharmony_ci tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c 928c2ecf20Sopenharmony_ci 938c2ecf20Sopenharmony_ciAny errors/failures/skips mean something is wrong. 94