Documentation/powerpc/dawr-power9.rst

   1 =====================
   2 DAWR issues on POWER9
   3 =====================
   4
   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 distinguish CI memory when configuring the DAWR, so (for now) the DAWR is
   8 disabled 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
  15 Technical Details:
  16 ==================
  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
  41 ======================
  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
  60 Force enabling the DAWR
  61 =======================
  62 Kernels (since ~v5.2) have an option to force enable the DAWR via::
  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:
  90
  91   tools/testing/selftests/powerpc/ptrace/ptrace-hwbreak.c
  92
  93 Any errors/failures/skips mean something is wrong.