On 09.11.2010, at 17:36, Scott Wood wrote: > On Tue, 9 Nov 2010 13:14:47 +0100 > Alexander Graf <[email protected]> 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.
It doesn't mentioned undefined values. It only mentions LEV=0 and LEV=1. But I don't like the idea of hard overloading a specific LEV value either way :). I'd rather use an undefined instruction for it. > >>> 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. Same thing for x86, but somehow it works out ;-). > 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. There are no hypervisor privileged debug registers? Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
