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 :). 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
