> -----Original Message----- > From: Alexander Graf [mailto:agraf@xxxxxxx] > Sent: Tuesday, November 09, 2010 9:39 PM > To: Yoder Stuart-B08248 > Cc: Wood Scott-B07421; Hollis Blanchard; Liu Yu-B13201; kvm- > ppc@xxxxxxxxxxxxxxx; Jan Kiszka > Subject: Re: Software breakpoint in kvmppc guest debug > > > On 10.11.2010, at 04:31, Yoder Stuart-B08248 wrote: > > > > > > >> -----Original Message----- > >> From: kvm-ppc-owner@xxxxxxxxxxxxxxx > > [mailto:kvm-ppc-owner@xxxxxxxxxxxxxxx] > >> On Behalf Of Alexander Graf > >> Sent: Tuesday, November 09, 2010 12:50 PM > >> To: Wood Scott-B07421 > >> Cc: Hollis Blanchard; Liu Yu-B13201; kvm-ppc@xxxxxxxxxxxxxxx; Jan > > Kiszka > >> Subject: Re: Software breakpoint in kvmppc guest debug > >> > >> > >> On 09.11.2010, at 19:43, Scott Wood wrote: > >> > >>> On Tue, 9 Nov 2010 19:26:25 +0100 > >>> Alexander Graf <agraf@xxxxxxx> wrote: > >>> > >>>> > >>>> On 09.11.2010, at 19:17, Scott Wood wrote: > >>>> > >>>>> On Tue, 9 Nov 2010 18:14:31 +0100 > >>>>> Alexander Graf <agraf@xxxxxxx> wrote: > >>>>> > >>>>>> Now, if we can get away with not using an undefined instruction > > (be it > >> sc 64 or trap) I don't know. I'm not even sure we can get away with > > trap. > >> Basically, WARN_ON should also trigger a trap, so you'd end up in gdb > > for > >> that when having a breakpoint defined. > >>>>> > >>>>> There'd need to be a way for qemu/gdb to have KVM reflect the > >>>>> exception to the guest if it doesn't have a breakpoint on file for > > that > >> address. > >>>> > >>>> Yes, but that piece is missing for every KVM target right now. I'd > > like > >> to see something generic emerge here that we can reuse across > > different > >> architectures :). > >>> > >>> We should try to define something that will make sense on other > >>> architectures, to whatever extent is practical -- but that doesn't > >>> mean we need to wait for them to act first. :-) > >> > >> Oh, I agree. I'm saying we should have Jan in the discussion :). > >> > >>>> Trap seems very tricky too though. According to page 1082 of the > > 2.06 > >> spec, trap can issue a debug or a program interrupt depending on > > MSR_DE. I > >> don't see any mentioning in the spec that we intercept program or > > debug > >> interrupts. So I guess we'd have to override the offset vectors and > > handle > >> _every_ interrupt ourselves. Bleks. > >>> > >>> Program and debug interrupts always go to the hypervisor. Only the > >>> exceptions for which GIVORs are defined (DSI, ISI, external IRQ, > >>> syscall, TLB miss) can go directly to the guest, and even those are > >>> generally optional based on EPCR. > >> > >> Ah, so it's a positive list. I guess I missed that part :). Thanks > >> for > > the > >> clarification. > >> > >> So making it a trap instruction for now should be ok. Let's align the > > code > >> to the same x86 looks like for now. In the meanwhile, let's discuss > > with > >> Jan on how to get a list of patched IPs into the kernel and implement > > that > >> on top of the code we'll have aligned with x86 by then :). > > > > What about using the ehpriv instruction (defined in 2.06)? > > We could define a unique "qemu software breakpoint", and the > > hypervisor's ehpriv handler will be able to easily distinguish them. > > > > On e500v2, this would be an illegal instruction. > > > > We don't need to worry about a conflict with future opcodes and it > > seems like the whole point of ehpriv being defined-- to let a > > hypervisor define special opcodes for stuff like this. > > Yes, it even states so in the little box below the description. Very good > catch! > > > If we use trap, we will need the list of patched IPs in > > the kernel. ehpriv avoids the need for that. > > Well, the way it's handled on x86 now is that the kernel asks user space if > it knows about the breakpoint and if not user space reinjects the debug > interrupt into the guest. > > Is there anything that ensures us BookS won't use 31/270? I will check with the Freescale instruction set architect. Stuart -- 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
