On 05.09.2013, at 22:25, Paul Mackerras wrote: > From: Michael Ellerman <mich...@ellerman.id.au> > > This means that if we do happen to get a trap that we don't know > about, we abort the guest rather than crashing the host kernel. > > Signed-off-by: Michael Ellerman <mich...@ellerman.id.au> > Signed-off-by: Paul Mackerras <pau...@samba.org> > --- > arch/powerpc/kvm/book3s_hv.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c > index 0bb23a9..731e46e 100644 > --- a/arch/powerpc/kvm/book3s_hv.c > +++ b/arch/powerpc/kvm/book3s_hv.c > @@ -709,8 +709,7 @@ static int kvmppc_handle_exit(struct kvm_run *run, struct > kvm_vcpu *vcpu, > printk(KERN_EMERG "trap=0x%x | pc=0x%lx | msr=0x%llx\n", > vcpu->arch.trap, kvmppc_get_pc(vcpu), > vcpu->arch.shregs.msr); > - r = RESUME_HOST; > - BUG(); > + r = -EINVAL;
This should probably tell user space what's going on. The way x86 handles this is through the kvm_run structure and I think we should try to stay as compatible as possible here: arch/x86/kvm/svm.c:3489 arch/x86/kvm/vmx.c:6800 Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
