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:47:54 +0200 Message-ID: <48D8AD3A.1040509@siemens.com> References: <48CF97F1.9090004@siemens.com> <48D7795E.5080002@siemens.com> <48D77AD6.8030008@redhat.com> <200809231334.27219.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]:22864 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751424AbYIWIsM (ORCPT ); Tue, 23 Sep 2008 04:48:12 -0400 In-Reply-To: <200809231334.27219.sheng.yang@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 c= ommand >>>> to the local apic. >>> Going this way leaves me with a few questions: Will it be OK for th= e >>> 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? >=20 > Just back from vacation... :) >=20 > Jan said is true, "int 2" itself won't block subsequent NMIs. But I t= hink it's=20 > too obviously as a hardware issue when using with NMI exiting=3D1 in = vmx=20 > nonroot mode, so I have checked it with my colleague, finally found t= hese in=20 > SDM 3B 23-2: >=20 > The following bullets detail when architectural state is and is not u= pdated in=20 > response to VM exits: > =E2=80=A2 If an event causes a VM exit *directly*, it does not upda= te architectural=20 > 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 aft= er the VM exit > completes. >=20 > So we needn't worry about that, and this shouldn't cause any trouble = AFAIK... =46ine, problems--. :) >=20 > Jan, seems we need to do more investigating on the issues you met... Sorry, which one do you mean now? Jan --=20 Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux