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 13:34:27 +0800 Message-ID: <200809231334.27219.sheng.yang@intel.com> References: <48CF97F1.9090004@siemens.com> <48D7795E.5080002@siemens.com> <48D77AD6.8030008@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jan Kiszka , "kvm-devel" To: Avi Kivity Return-path: Received: from mga14.intel.com ([143.182.124.37]:34906 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751771AbYIWFd4 convert rfc822-to-8bit (ORCPT ); Tue, 23 Sep 2008 01:33:56 -0400 In-Reply-To: <48D77AD6.8030008@redhat.com> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: 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 n= ot. > > 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 thi= nk it's=20 too obviously as a hardware issue when using with NMI exiting=3D1 in vm= x=20 nonroot mode, so I have checked it with my colleague, finally found the= se in=20 SDM 3B 23-2: The following bullets detail when architectural state is and is not upd= ated in=20 response to VM exits: =E2=80=A2 If an event causes a VM exit *directly*, it does not update= 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 after= the VM exit completes. So we needn't worry about that, and this shouldn't cause any trouble AF= AIK... Jan, seems we need to do more investigating on the issues you met... --=20 regards Yang, Sheng > > And is it safe to > > assume VMX =3D=3D 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