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? Alex -- 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
