From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: VMX: Host NMI triggering on NMI vmexit Date: Tue, 23 Sep 2008 10:59:58 +0200 Message-ID: <48D8B00E.9080706@siemens.com> References: <48CF97F1.9090004@siemens.com> <200809231334.27219.sheng.yang@intel.com> <48D8AD3A.1040509@siemens.com> <200809231657.02002.sheng.yang@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Avi Kivity , kvm-devel To: "Yang, Sheng" Return-path: Received: from gecko.sbs.de ([194.138.37.40]:18087 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751686AbYIWJBL (ORCPT ); Tue, 23 Sep 2008 05:01:11 -0400 In-Reply-To: <200809231657.02002.sheng.yang@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Yang, Sheng wrote: > 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? >=20 > 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 bug= s > in kvm's and my own NMI code that were triggered by such a scenario > (sigh...)." ? >=20 > If it's not related to this one. That's fine. :) Nope, the actual issues were related to guests facing "NMI storms" (and should be fixed by my series). That made me wonder what would happen on the host side if int 2 wasn't safe. But it is, as we know now. Jan --=20 Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux