From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 13/15] Add NMI injection support to SVM. Date: Sun, 19 Apr 2009 11:57:18 +0300 Message-ID: <49EAE76E.5050302@redhat.com> References: <1239616545-25199-1-git-send-email-gleb@redhat.com> <1239616545-25199-14-git-send-email-gleb@redhat.com> <49E8DEC1.4030802@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm@vger.kernel.org, joerg.roedel@amd.com, sheng@linux.intel.com, Dmitry Baryshkov To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:49982 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752916AbZDSI53 (ORCPT ); Sun, 19 Apr 2009 04:57:29 -0400 In-Reply-To: <49E8DEC1.4030802@web.de> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: > First, this must return 1 (or set an exit reason, but there is no reason > to escape to user space here). And second, I think a corner case is not > handled the same way as on real iron: If there is already the next NMI > waiting, we will inject it before iret, not after its execution as it > should be. > Yes, good catch. > No easy solution for this yet. Maybe emulating iret, but there is no > implementation, specifically for protected mode. That will be a disaster, IRET is horribly complicated. > Maybe setting a > breakpoint. Or maybe enforcing a single step exception. Single step looks good, except that it may conflict with a guest debugging itself (guest debugging an NMI handler?!). > Nothing trivial > in this list. On the other hand, this may only be a slight imprecision > of the virtualization. Need to think about it. > It may cause a stack overflow if we have a huge stream of NMIs (if an NMI triggers an NMI in the handler). Of course that's a totally unrealistic scenario. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.