From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Yang, Sheng" Subject: Re: VMX: Host NMI triggering on NMI vmexit Date: Tue, 23 Sep 2008 16:57:01 +0800 Message-ID: <200809231657.02002.sheng.yang@intel.com> References: <48CF97F1.9090004@siemens.com> <200809231334.27219.sheng.yang@intel.com> <48D8AD3A.1040509@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Avi Kivity , "kvm-devel" To: Jan Kiszka Return-path: Received: from mga01.intel.com ([192.55.52.88]:25183 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751714AbYIWI4a convert rfc822-to-8bit (ORCPT ); Tue, 23 Sep 2008 04:56:30 -0400 In-Reply-To: <48D8AD3A.1040509@siemens.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Tuesday 23 September 2008 16:47:54 Jan Kiszka wrote: > Yang, Sheng wrote: > > On Monday 22 September 2008 19:00:38 Avi Kivity wrote: > >> 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 wh= y not. > >> > >> Sheng, can you confirm that 'int 2' is problematic, and that > >> nmi-via-lapic is the best workaround? > > > > Just back from vacation... :) > > > > Jan said is true, "int 2" itself won't block subsequent NMIs. But I= think > > it's too obviously as a hardware issue when using with NMI exiting=3D= 1 in > > vmx nonroot mode, so I have checked it with my colleague, finally f= ound > > these in SDM 3B 23-2: > > > > The following bullets detail when architectural state is and is not > > updated in response to VM exits: > > =E2=80=A2 If an event causes a VM exit *directly*, it does not up= date > > architectural state as it would have if it had it not caused the VM= exit: > > [...] > > =E2=80=94 *An NMI causes subsequent NMIs to be blocked*, but only a= fter the VM > > exit completes. > > > > So we needn't worry about that, and this shouldn't cause any troubl= e > > AFAIK... > > Fine, problems--. :) > > > Jan, seems we need to do more investigating on the issues you met..= =2E > > Sorry, which one do you mean now? You said=20 "Only true until you have multiple unsynchronized NMI sources, e.g. inter-CPU NMIs of kgdb + a watchdog. I just stumbled over several bugs in kvm's and my own NMI code that were triggered by such a scenario (sigh...)." ? If it's not related to this one. That's fine. :) --=20 regards Yang, Sheng > > Jan > > -- > Siemens AG, Corporate Technology, CT SE 2 > Corporate Competence Center Embedded Linux