> -----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. If we use trap, we will need the list of patched IPs in the kernel. ehpriv avoids the need for that. 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
