From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Nadav Har'El" Subject: Re: [PATCH 18/24] Exiting from L2 to L1 Date: Sun, 12 Sep 2010 21:51:17 +0200 Message-ID: <20100912195117.GA11002@fermat.math.technion.ac.il> References: <1276431753-nyh@il.ibm.com> <201006131231.o5DCVlKB013102@rice.haifa.ibm.com> <4C161AB8.4060905@redhat.com> <20100912140530.GA26346@fermat.math.technion.ac.il> <4C8CE3E2.7060708@redhat.com> <20100912170503.GA7828@fermat.math.technion.ac.il> <4C8D0C19.4050003@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, Sheng Yang To: Avi Kivity Return-path: Received: from mailgw12.technion.ac.il ([132.68.225.12]:24327 "EHLO mailgw12.technion.ac.il" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751817Ab0ILTvZ (ORCPT ); Sun, 12 Sep 2010 15:51:25 -0400 Content-Disposition: inline In-Reply-To: <4C8D0C19.4050003@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Sep 12, 2010, Avi Kivity wrote about "Re: [PATCH 18/24] Exiting from L2 to L1": > >>>>>+ vmcs12->vm_entry_intr_info_field = > >>>>>+ vmcs_read32(VM_ENTRY_INTR_INFO_FIELD); >... > prepare_vmcs12() is called in response for a 2->1 vmexit which is first > trapped by 0, yes? Because it's called immediately after a vmexit, > VM_ENTRY_INTR_INFO_FIELD is guaranteed to have been cleared by the > processor. Indeed - it is cleared in the real vmcs, i.e., vmcs02, but we also need to clear it in the emulated vmcs that L1 sees for L2, i.e., vmcs12. The original code (quoted above) just copied the vmcs02 value to vmcs12, which was (mostly) fine because the vmcs02 value has a correctly-cleared bit - but you asked to avoid the vmread. So the second option is to just explicitly remove the valid bit from vmcs12->vm_entry_intro_info_field, which I do now. vmcs12->vm_entry_intro_info_field was set by L1 before it entered L2, and now that L2 is exiting back to L1, we need to clear the valid bit. The more I think about it, the more I become convinced that the second option is indeed better than the first option (the original code in the patch). > There are two cases where VM_ENTRY_INTR_INFO_FIELD can potentially not > be cleared by hardware: >... > If neither of these are valid, the code can be removed. If only the > second, we might make it conditional. Again, unless I'm misunderstanding what you mean, the hardware only modified vmcs02 (the hardware vmcs), not vmcs12. We need to modify vmcs12 as well, to remove the "valid" bit. If we don't, when L1 enters into the same L2 again, the same old value will be copied again from vmcs12 to vmcs02, and cause an injection of the same interrupt again. And by the way, I haven't said this enough, but thanks for your continued reviews and all your very useful corrections for these patches! Nadav. -- Nadav Har'El | Sunday, Sep 12 2010, 5 Tishri 5771 nyh@math.technion.ac.il |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |I before E except after C. We live in a http://nadav.harel.org.il |weird society!