From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37139 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQasi-00074p-Kt for qemu-devel@nongnu.org; Thu, 09 Dec 2010 02:25:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQasg-0005ks-Up for qemu-devel@nongnu.org; Thu, 09 Dec 2010 02:25:36 -0500 Received: from goliath.siemens.de ([192.35.17.28]:16604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQasg-0005kk-It for qemu-devel@nongnu.org; Thu, 09 Dec 2010 02:25:34 -0500 Message-ID: <4D00845F.9000503@siemens.com> Date: Thu, 09 Dec 2010 08:25:19 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4D007E2C.4070308@cn.fujitsu.com> In-Reply-To: <4D007E2C.4070308@cn.fujitsu.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 1/6] qemu, kvm: Enable NMI support for user space irqchip List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Lai Jiangshan Cc: Avi Kivity , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" Am 09.12.2010 07:58, Lai Jiangshan wrote: > > Make use of the new KVM_NMI IOCTL to send NMIs into the KVM guest if the > user space APIC emulation or some other source raised them. In that light, the subject is not absolutely correct. > > Signed-off-by: Lai Jiangshan > --- > diff --git a/target-i386/kvm.c b/target-i386/kvm.c > index 7dfc357..c4ebe28 100644 > --- a/target-i386/kvm.c > +++ b/target-i386/kvm.c > @@ -1417,6 +1417,14 @@ int kvm_arch_get_registers(CPUState *env) > > int kvm_arch_pre_run(CPUState *env, struct kvm_run *run) > { > +#ifdef KVM_CAP_USER_NMI > + if (env->interrupt_request & CPU_INTERRUPT_NMI) { > + env->interrupt_request &= ~CPU_INTERRUPT_NMI; > + DPRINTF("injected NMI\n"); > + kvm_vcpu_ioctl(env, KVM_NMI); > + } > +#endif > + > /* Try to inject an interrupt if the guest can accept it */ > if (run->ready_for_interrupt_injection && > (env->interrupt_request & CPU_INTERRUPT_HARD) && Actually, we already depend on KVM_CAP_DESTROY_MEMORY_REGION_WORKS which was introduced with 2.6.29 as well. I would suggest to simply extend the static configure check and avoid new #ifdefs in the code. Thanks for pushing this! Was obviously so trivial that it was forgotten... Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux