Messages in this thread | | | Date | Tue, 07 Oct 2008 16:36:54 +0200 | From | Avi Kivity <> | Subject | Re: [RFC Patch 0/9] Hardware Breakpoint interfaces |
| |
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
| |