From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH v2 2/5] KVM: nVMX: Rework event injection and recovery Date: Sun, 17 Mar 2013 17:19:41 +0200 Message-ID: <20130317151941.GO11223@redhat.com> References: <20130317134504.GI11223@redhat.com> <5145DAEF.6000400@web.de> <20130317151451.GN11223@redhat.com> <5145DE7F.9000200@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marcelo Tosatti , kvm , Paolo Bonzini , "Nadav Har'El" To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:18252 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932565Ab3CQPTp (ORCPT ); Sun, 17 Mar 2013 11:19:45 -0400 Content-Disposition: inline In-Reply-To: <5145DE7F.9000200@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Mar 17, 2013 at 04:17:19PM +0100, Jan Kiszka wrote: > 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 from > >>>> there if it turns out that we left L2 to enter L1. > >>>> > >>>> VMX and SVM are now identical in how they recover event injections from > >>>> unperformed vmlaunch/vmresume: We detect that VM_ENTRY_INTR_INFO_FIELD > >>>> 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_pending > >>> thing that prevents #vmexit emulation from happening without vmlaunch. > >>> 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, also > >> 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 inject > >>>> into L2. Likely, this case is still broken in SVM. For VMX, the function > >>>> vmcs12_save_pending_events deals with transferring pending L0 events > >>>> into the queue of L1. That is mandatory as L1 may decide to switch the > >>>> guest state completely, invalidating or preserving the pending events > >>>> for later injection (including on a different node, once we support > >>>> migration). > >>>> > >>>> Note that we treat directly injected NMIs differently as they can hit > >>>> 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 (or, > >> 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 from > >> L1 as well. If injection triggers a vmexit, that NMI could now leak into > >> 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. > Ah, yes. I meant the same, but by leaking to L0 I was talking about L0 thinking that it needs to reinject it. -- Gleb.