HW breakpoints vs. KVM context switches

[Jan Kiszka <jan.kiszka@siemens.com>]

Hi,

as we currently face some abstraction issue around hardware breakpoints
in kvm, I had a look again at the state of your work. I assume it's on a
good way towards mainline, right?

So far kvm (on x86) switches debug registers between host and guest
fairly conservatively: If the guest has some breakpoint in use, the host
registers are read from the hardware and restored to it on return. This
is not really optimal, specifically as dr6/dr7 are currently touched
unconditionally.

Now Avi's idea is to skip saving the registers as we could also restore
them from current->thread.debugregX whenever required. IIUC this will no
longer be true when hw-breakpoints hit mainline. It is already wrong for
kgdb as that breakpoint user touches the registers without asking anyone
(or at least informing others).

My question is now if we could extend the hw-breakpoint interface in a
way, either arch-specific or even generic, that kvm could easily use it
to restore the host's debug register state if required.

Moreover, I think we also need some interface extension for kgdb. I
guess it wants ultimate access to the registers on all CPUs, and it
likely don't want to debate about this with the kernel (==acquire
locks). Still the hw-breakpoint layer would likely want to know if kgdb
is claiming the hardware so that it can step back from touching them.
Also kvm would like to hear about this + access to their (cached)
content for proper restoration.

So far the theory. Before starting to craft any prototypes, I would like
to hear your opinion on this.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux