Messages in this thread | | | Date | Mon, 07 Sep 2009 19:22:24 +0200 | From | Jan Kiszka <> | Subject | HW breakpoints vs. KVM context switches |
| |
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
| |