From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] KVM: nVMX: Rework event injection and recovery Date: Wed, 20 Feb 2013 18:24:02 +0100 Message-ID: <512506B2.2020300@siemens.com> References: <5124C93B.50902@siemens.com> <20130220141452.GA11902@fermat.math.technion.ac.il> <5124DFBF.3070109@siemens.com> <20130220170159.GT3600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Nadav Har'El" , Marcelo Tosatti , kvm , "Nakajima, Jun" To: Gleb Natapov Return-path: Received: from goliath.siemens.de ([192.35.17.28]:22355 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756474Ab3BTRYX (ORCPT ); Wed, 20 Feb 2013 12:24:23 -0500 In-Reply-To: <20130220170159.GT3600@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2013-02-20 18:01, Gleb Natapov wrote: > On Wed, Feb 20, 2013 at 03:37:51PM +0100, Jan Kiszka wrote: >> On 2013-02-20 15:14, Nadav Har'El wrote: >>> Hi, >>> >>> By the way, if you haven't seen my description of why the current code >>> did what it did, take a look at >>> http://www.mail-archive.com/kvm@vger.kernel.org/msg54478.html >>> Another description might also come in handy: >>> http://www.mail-archive.com/kvm@vger.kernel.org/msg54476.html >>> >>> On Wed, Feb 20, 2013, Jan Kiszka wrote about "[PATCH] KVM: nVMX: Rework event injection and recovery": >>>> This aligns VMX more with SVM regarding event injection and recovery for >>>> nested guests. The changes allow to inject interrupts directly from L0 >>>> to L2. >>>> >>>> One difference to SVM is that we always transfer the pending event >>>> injection into the architectural state of the VCPU and then drop it from >>>> there if it turns out that we left L2 to enter L1. >>> >>> Last time I checked, if I'm remembering correctly, the nested SVM code did >>> something a bit different: After the exit from L2 to L1 and unnecessarily >>> queuing the pending interrupt for injection, it skipped one entry into L1, >>> and as usual after the entry the interrupt queue is cleared so next time >>> around, when L1 one is really entered, the wrong injection is not attempted. >>> >>>> 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. >>> >>>> To avoid that we incorrectly leak an event into the architectural VCPU >>>> state that L1 wants to inject, we skip cancellation on nested run. >>> >>> I didn't understand this last point. >> >> - prepare_vmcs02 sets event to be injected into L2 >> - while trying to enter L2, a cancel condition is met >> - we call vmx_cancel_interrupts but should now avoid filling L1's event >> into the arch event queues - it's kept in vmcs12 >> > But what if we put it in arch event queue? It will be reinjected during > next entry attempt, so nothing bad happens and we have one less if() to explain, > or do I miss something terrible that will happen? I started without that if but ran into troubles with KVM-on-KVM (L1 locks up). Let me dig out the instrumentation and check the event flow again. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux