On Friday 13 November 2015 07:20 AM, David Gibson wrote: > On Thu, Nov 12, 2015 at 11:22:29PM +0530, Aravinda Prasad wrote: [...] >> >> I overlooked it. I think I need to take into consideration whether guest >> issued "ibm, nmi-register". If the guest has issued "ibm, nmi-register" >> then we should not jump to 0x200 upon UE. With the old kernel and old >> QEMU this is broken as we always jump to 0x200. >> >> However, if the guest has not issued "ibm, nmi-register" then upon UE we >> should jump to 0x200. If new kernel is used with old QEMU this >> functionality breaks as it causes guest to terminate with unhandled NMI >> exit. >> >> So thinking whether qemu should explicitly enable the new NMI >> behavior. > > So, I think the reasoning above tends towards having qemu control the > MC behaviour. If qemu does nothing, MCs are delivered direct to > 0x200, if it enables the new handling, they cause a KVM exit and qemu > will deliver the MC. This essentially requires qemu to control how KVM behaves as KVM does the actual redirection of MC either to guest's 0x200 vector or to exit guest. So, if we are running new qemu, then KVM should exit guest and if we are running old qemu, KVM should redirect MC to 0x200. Is there any way to communicate this to KVM? ioctl? However, this should not be a problem (in terms of breaking existing functionality) with old KVM as it always redirects MC to 0x200 irrespective of old or new qemu. > > Then I'd expect qemu to switch on the new-style handling from > ibm,nmi-register. > >> -- 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
