Message-ID: <20090907232010.GA6312@nowhere>
Date:	Tue, 8 Sep 2009 01:20:13 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Jan Kiszka <jan.kiszka@...mens.com>
Cc:	"K.Prasad" <prasad@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>, Avi Kivity <avi@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jason Wessel <jason.wessel@...driver.com>
Subject: Re: HW breakpoints vs. KVM context switches

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?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists