On Tue, 9 Nov 2010 19:26:25 +0100 Alexander Graf <ag...@suse.de> wrote:
> > On 09.11.2010, at 19:17, Scott Wood wrote: > > > On Tue, 9 Nov 2010 18:14:31 +0100 > > Alexander Graf <ag...@suse.de> 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. :-) > 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. -Scott -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
