All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: prasad@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org,
	Alan Stern <stern@rowland.harvard.edu>,
	Roland McGrath <roland@redhat.com>,
	akpm@linux-foundation.org, mingo@elte.hu,
	jason.wessel@windriver.com, richardj_moore@uk.ibm.com
Subject: Re: [RFC Patch 0/9] Hardware Breakpoint interfaces
Date: Tue, 07 Oct 2008 16:36:54 +0200	[thread overview]
Message-ID: <48EB7406.1010509@redhat.com> (raw)
In-Reply-To: <20081007143217.GA3774@in.ibm.com>

K.Prasad wrote:
> On Tue, Oct 07, 2008 at 02:29:05PM +0200, Avi Kivity wrote:
>   
>> K.Prasad wrote:
>>     
>>> - Enable KGDB and KVM to use the register_kernel_hw_breakpoint()
>>>   interface for their HW Breakpoint usage, in the absence of which
>>>   they will be broken during simultaneous use.
>>>   
>>>       
>> KVM conceptually isn't a kernel use of the debug registers.  KVM  
>> modifies the debug registers while the guest is running, and restores  
>> them after the guest returns.
>>
>> Right now, as an optimization, KVM defers restoring the debug registers  
>> until after the next context switch out of the kvm task, or until the  
>> next exit to userspace (whichever comes earlier); we should change this  
>> to avoid the deferral if kernel breakpoints are in effect.  This will  
>> allow simultaneous use of KVM breakpoints and kernel breakpoints.
>>
>>     
> The patch posted provides interface for using HW breakpoints on both
> user- and kernel-space breakpoints. KVM's user-space address breakpoint
> requirements, after code-modification, should be made to use
> register_user_hw_breakpoint() interface (presently un-exported but will
> be changed subsequently) to help maintain a system-wide consistent view on the
> availability of HW Breakpoint registers.
>
>   

Correcting myself, actually kvm breakpoints are in a third namespace.  
You could have kernel breakpoints, user breakpoints, and guest 
breakpoints coexisting.

> Presently I find plenty of set_debugreg() calls from kvm/ which will
> modify the registers directly and break the breakpoint register
> management brought-in through the patch.
>   

If kvm restores the registers, should there be any problem?

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2008-10-07 14:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 11:38 [RFC Patch 0/9] Hardware Breakpoint interfaces K.Prasad
2008-10-07 11:40 ` [RFC Patch 1/9] Introducing generic hardware breakpoint handler interfaces K.Prasad
2008-10-07 15:21   ` Alan Stern
2008-10-07 16:49     ` K.Prasad
2008-10-07 11:41 ` [RFC Patch 2/9] x86 architecture implementation of Hardware Breakpoint interfaces K.Prasad
2008-10-07 15:36   ` Alan Stern
2008-10-07 17:23     ` K.Prasad
2008-10-07 17:38       ` Alan Stern
2008-10-07 17:28     ` K.Prasad
2008-10-07 11:42 ` [RFC Patch 3/9] Modifying generic debug exception to use virtual debug registers K.Prasad
2008-10-07 11:43 ` [RFC Patch 4/9] Modify kprobe exception handler to recognise single-stepping by HW Breakpoint handler K.Prasad
2008-10-07 11:44 ` [RFC Patch 5/9] Use wrapper routines around debug registers in processor related functions K.Prasad
2008-10-07 11:44 ` [RFC Patch 6/9] Use virtual debug registers in process/thread handling code K.Prasad
2008-10-07 15:40   ` Alan Stern
2008-10-07 17:48     ` K.Prasad
2008-10-07 11:45 ` [RFC Patch 7/9] Modify signal handling code to refrain from re-enabling HW Breakpoints K.Prasad
2008-10-07 11:46 ` [RFC Patch 8/9] Modify Ptrace to use wrapper routines to access breakpoint registers K.Prasad
2008-10-07 11:46 ` [RFC Patch 9/9] Cleanup HW Breakpoint registers before kexec K.Prasad
2008-10-07 12:29 ` [RFC Patch 0/9] Hardware Breakpoint interfaces Avi Kivity
2008-10-07 14:32   ` K.Prasad
2008-10-07 14:36     ` Avi Kivity [this message]
2008-10-07 16:45       ` K.Prasad
2008-10-07 16:52         ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48EB7406.1010509@redhat.com \
    --to=avi@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=jason.wessel@windriver.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=prasad@linux.vnet.ibm.com \
    --cc=richardj_moore@uk.ibm.com \
    --cc=roland@redhat.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.