On Thursday 12 November 2015 10:28 AM, Daniel Axtens wrote: > >> So, IIUC. Once the qemu pieces are in place as well it shouldn't >> change this behaviour: KVM will exit to qemu, qemu will log the error >> information (new), then reinject the MC to the guest which can still >> handle it as you describe above. > > Ah, that makes *much* more sense now! Thanks for the explanation: I > don't really follow qemu development. > >> >> But, there could be a problem if you have a new kernel with an old >> qemu, in that case qemu might not understand the new exit type and >> treat it as a fatal error, even though the guest could actually cope >> with it. >> >> Aravinda, do we need to change this so that qemu has to explicitly >> enable the new NMI behaviour? Or have I missed something that will >> make that case work already. > > <puts on CAPI hat>Yeah, it would be good not to break this.</hat> I am not familiar with CAPI. Does this affect CAPI? Regards, Aravinda > > Regards, > Daniel > > >> -- >> David Gibson | I'll have my music baroque, and my code >> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ >> | _way_ _around_! >> http://www.ozlabs.org/~dgibson > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@xxxxxxxxxxxxxxxx > https://lists.ozlabs.org/listinfo/linuxppc-dev > -- Regards, Aravinda -- 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
