HW breakpoints vs. KVM context switches

HW breakpoints vs. KVM context switches

[Jan Kiszka]

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

Re: HW breakpoints vs. KVM context switches

[Frederic Weisbecker]

On Mon, Sep 07, 2009 at 07:22:24PM +0200, Jan Kiszka wrote:
> 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?


Well, I'm about to post a patchset that refactores the breakpoint API
on top of perf counter instances.

If the approach is agreed and that hits mainline, that may make it
easier for you (more explanations follow).

 
> 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.


Indeed.


> 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).



Yeah in the current implementation in -tip, we have user breakpoints and
kernel breakpoints. The former records debug registers in the thread_struct
across sched switch events, so the approach is correct for them, but the latter
doesn't need to do that as it deals with global wide breakpoints, so it induces
some corner cases.

 
> 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.


So, if the new implementation on top of perfcounter makes its way, you won't
anymore need to deal with the various possible breakpoints context in use
(kernel wide and user), instead you'll need to check the current active
perf counter context in a given cpu and list its breakpoint counters to disable
their pmu.

Well, actually I think this is something that should be handled by perfcounter
itself. It should be able to handle the hardware register scheduling while
switching between host and guest. The problem then overlaps the single
breakpoint circle and also involves every kind of counters that handle
hardware registers.

I'm not sure but, perf already handles that right? If it does, then the
breakpoints save/restore issue won't be a problem anymore.


> 
> 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.


It depends if perf already supports the switches between guest/host using
tunable parameters in its counters. IIRC, it can, but I don't know much
about this perf area.

Ingo, Peter?