From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v2 2/5] KVM: nVMX: Rework event injection and recovery Date: Sun, 17 Mar 2013 16:17:19 +0100 Message-ID: <5145DE7F.9000200@web.de> References: <20130317134504.GI11223@redhat.com> <5145DAEF.6000400@web.de> <20130317151451.GN11223@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2RRKQQMIEKIOVNQFGHNMJ" Cc: Marcelo Tosatti , kvm , Paolo Bonzini , Nadav Har'El To: Gleb Natapov Return-path: Received: from mout.web.de ([212.227.17.11]:49291 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932316Ab3CQPRV (ORCPT ); Sun, 17 Mar 2013 11:17:21 -0400 In-Reply-To: <20130317151451.GN11223@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2RRKQQMIEKIOVNQFGHNMJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-03-17 16:14, Gleb Natapov wrote: > On Sun, Mar 17, 2013 at 04:02:07PM +0100, Jan Kiszka wrote: >> On 2013-03-17 14:45, Gleb Natapov wrote: >>> On Sat, Mar 16, 2013 at 11:23:16AM +0100, Jan Kiszka wrote: >>>> From: Jan Kiszka >>>> >>>> The basic idea is to always transfer the pending event injection on >>>> vmexit into the architectural state of the VCPU and then drop it fro= m >>>> there if it turns out that we left L2 to enter L1. >>>> >>>> VMX and SVM are now identical in how they recover event injections f= rom >>>> unperformed vmlaunch/vmresume: We detect that VM_ENTRY_INTR_INFO_FIE= LD >>>> still contains a valid event and, if yes, transfer the content into = L1's >>>> idt_vectoring_info_field. >>>> >>> But how this can happens with VMX code? VMX has this nested_run_pendi= ng >>> thing that prevents #vmexit emulation from happening without vmlaunch= =2E >>> This means that VM_ENTRY_INTR_INFO_FIELD should never be valid during= >>> #vmexit emulation since it is marked invalid during vmlaunch. >> >> Now that nmi/interrupt_allowed is strict /wrt nested_run_pending again= , >> it may indeed no longer happen. It was definitely a problem before, al= so >> with direct vmexit on pending INIT. Requires a second thought, maybe >> also a WARN_ON(vmx->nested.nested_run_pending) in nested_vmx_vmexit. >> >>> >>>> However, we differ on how to deal with events that L0 wanted to inje= ct >>>> into L2. Likely, this case is still broken in SVM. For VMX, the func= tion >>>> vmcs12_save_pending_events deals with transferring pending L0 events= >>>> into the queue of L1. That is mandatory as L1 may decide to switch t= he >>>> guest state completely, invalidating or preserving the pending event= s >>>> for later injection (including on a different node, once we support >>>> migration). >>>> >>>> Note that we treat directly injected NMIs differently as they can hi= t >>>> both L1 and L2. In this case, we let L0 try to injection again also = over >>>> L1 after leaving L2. >>>> >>> Hmm, where SDM says NMI behaves this way? >> >> NMIs are only blocked in root mode if we took an NMI-related vmexit (o= r, >> of course, an NMI is being processed). Thus, every arriving NMI can >> either hit the guest or the host - pure luck. >> >> However, I have missed the fact that an NMI may have been injected fro= m >> L1 as well. If injection triggers a vmexit, that NMI could now leak in= to >> L1. So we have to process them as well in vmcs12_save_pending_events. >> > You mean "should not leak into L0" not L1? No, L1. If we keep the NMI in the architectural queue, L0 will try to reinject it over L1 after the vmexit to it. Jan ------enig2RRKQQMIEKIOVNQFGHNMJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFF3n8ACgkQitSsb3rl5xSjrQCeOKyv0rx9wsellInP2x/tXnPN D9UAn18MJZAxVOm1HB9CRH8yabNuuBHI =R2wf -----END PGP SIGNATURE----- ------enig2RRKQQMIEKIOVNQFGHNMJ--