On 27 April 2015 at 21:04, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > On Thu, Apr 23, 2015 at 03:26:53PM +0100, Alex Bennée wrote: >> >> Christoffer Dall <christoffer.dall@xxxxxxxxxx> writes: >> >> > On Tue, Mar 31, 2015 at 04:08:04PM +0100, Alex Bennée wrote: >> >> + * just need to report the PC and the HSR values to userspace. >> >> + * Userspace may decide to re-inject the exception and deliver it to >> >> + * the guest if it wasn't for the host to deal with. >> > >> > now I'm confused - does userspace setup the guest to receive an >> > exception or does it tell KVM to emulate an exception for the guest or >> > do we execute the breakpoint without trapping the debug exception? >> >> I've made it all go through userspace as we may have to translate the >> hypervisor visible exception code to what the guest was expecting to see. >> > > ok, so I think you should re-phrase something like: > > "Userspace may decide that this exception is caused by the guest using > debugging itself, and may in that case emulate the guest debug exception > in userspace before resuming KVM." > > But does that really work? Given that we don't support KVM-TCG > migration, this sounds a little strange. Did we test it? The QEMU patches have a TODO note at the point where you'd want to do this... Design-wise you can do the reinjection in the kernel or in userspace (ppc QEMU does this in userspace, for instance) because it's pretty much just setting registers to fake up the exception-entry into EL1. Code-wise QEMU's ARM code isn't set up to do it right now, but it shouldn't be too difficult to persuade the TCG exception-entry code to work for this case too. Does the kernel already have a conveniently implemented "inject exception into guest" lump of code? If so it might be less effort to do it that way round, maybe. -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
