From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: VMX: Host NMI triggering on NMI vmexit Date: Mon, 22 Sep 2008 14:00:38 +0300 Message-ID: <48D77AD6.8030008@redhat.com> References: <48CF97F1.9090004@siemens.com> <48D429B1.6090105@redhat.com> <48D7795E.5080002@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: "Yang, Sheng" , kvm-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([66.187.233.31]:52306 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754354AbYIVLAo (ORCPT ); Mon, 22 Sep 2008 07:00:44 -0400 In-Reply-To: <48D7795E.5080002@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: >> Maybe the answer is to generate the local nmi via an IPI-to-self command >> to the local apic. >> > > Going this way leaves me with a few questions: Will it be OK for the > related mainainers to export the required service? If we can make a case for it (I think we can), then I don't see why not. Sheng, can you confirm that 'int 2' is problematic, and that nmi-via-lapic is the best workaround? > And is it safe to > assume VMX == LAPIC available and usable? > > Yes. > However, this is how it would look like. I'd define a send_nmi_self() instead, to allow the implementation to change (x2apic/etc). > Yet untested, /me has to > replace his host kernel first... > You could test it in a VM, if someone implements nested vmx :) btw, looks like svm is not affected by this. -- error compiling committee.c: too many arguments to function