On Tue, 9 Nov 2010 13:14:47 +0100 Alexander Graf <agraf@xxxxxxx> wrote: > On 09.11.2010, at 04:40, Liu Yu-B13201 wrote: > > > Software breakpoint is a instruction which should make guest exit. > > We replace guest code with software breakpoint instruction so that we can stop at anywhere we want. > > > > In my previous guest debug patches for e500, I used instruction (sc 64) as software breakpoint. > > Seem this was not good, since (sc 64) maybe defined in future. > > That's always the case with overloading instructions :). > > > also this instruction has uncertain effective on E.HV platform such as e500mc. > > Not sure if the hardware or other hypervisors break the spec, but according to 2.06 page 908 only LEV=0 and LEV=1 are defined. Does it say whether undefined values trap? Maybe it only looks at the low bit of LEV, or checks != 0, etc. > > Another choice is to use trap instruction. > > In order to distinguish between real guest trap and software breakpoint trap. > > It's needed to trace software breakpoint addressed in kernel, > > and we need to create ioctls to add/remove software point. > > That's another way to do this, yes. X86 also uses the normal trap instruction (int 3). Once the first breakpoint is set from external gdb, traps always go to gdb, even if they were not used for software breakpoints. > > See target-i386/kvm.c:kvm_arch_update_guest_debug() and kvm-all.c:kvm_update_guest_debug(). > > I'd say we should model it the same way for now. I agree. > If possible, the real solution for later would be to use hardware breakpoints using IAC registers. IAC has its own issues, as they're a limited resource -- made worse by the possibility of the guest wanting to use them. There are also some fun issues regarding MSR[DE] with E.HV -- there are two modes, either the guest can control it directly (and shut down KVM's debug events) or the guest does not have access to debug resources at all and guest changes to MSR[DE] are ignored. MSR writes never trap. -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
