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