[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AE55B1B.2030006@web.de>
Date: Mon, 26 Oct 2009 09:17:31 +0100
From: Jan Kiszka <jan.kiszka@....de>
To: Frederic Weisbecker <fweisbec@...il.com>
CC: Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
Prasad <prasad@...ux.vnet.ibm.com>,
Alan Stern <stern@...land.harvard.edu>,
Peter Zijlstra <peterz@...radead.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Jiri Slaby <jirislaby@...il.com>,
Li Zefan <lizf@...fujitsu.com>, Avi Kivity <avi@...hat.com>,
Paul Mackerras <paulus@...ba.org>,
Mike Galbraith <efault@....de>,
Masami Hiramatsu <mhiramat@...hat.com>,
Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH 4/6] hw-breakpoints: Rewrite the hw-breakpoints layer
on top of perf events
Frederic Weisbecker wrote:
> 2009/10/24 Jan Kiszka <jan.kiszka@....de>:
>> Since commit 3d53c27d05, KVM uses current->thread.debugregs for
>> restoring the host state in case the guest played with breakpoints. We
>> need an equivalent interface to restore ptrace breakpoints and all
>> others currently in use.
>>
>> Jan
>
>
> Well, dr6 is still stored in the current thread.
> dr7 has a per cpu variable containing its value.
>
> So what remains is to have a per cpu variable for dr0-3
> which is updated when perf schedules in/out a profiled context.
> I can do that in a v3.
Sounds great. Maybe you can stuff all this into some function kvm can
call to avoid that it has to peek into various internal structures.
Jan
Download attachment "signature.asc" of type "application/pgp-signature" (258 bytes)
Powered by blists - more mailing lists