From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Roedel, Joerg" Subject: Re: [PATCH 2/3] KVM: SVM: Restore correct registers after sel_cr0 intercept emulation Date: Thu, 2 Sep 2010 18:29:34 +0200 Message-ID: <20100902162934.GD1964@amd.com> References: <1283441387-7378-1-git-send-email-joerg.roedel@amd.com> <1283441387-7378-3-git-send-email-joerg.roedel@amd.com> <4C7FCA7A.1020809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Marcelo Tosatti , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "stable@kernel.org" To: Avi Kivity Return-path: Content-Disposition: inline In-Reply-To: <4C7FCA7A.1020809@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Thu, Sep 02, 2010 at 12:02:02PM -0400, Avi Kivity wrote: > On 09/02/2010 06:29 PM, Joerg Roedel wrote: > > This patch implements restoring of the correct rip, rsp, and > > rax after the svm emulation in KVM injected a selective_cr0 > > write intercept into the guest hypervisor. The problem was > > that the vmexit is emulated in the instruction emulation > > which later commits the registers right after the write-cr0 > > instruction. So the l1 guest will continue to run with the > > l2 rip, rsp and rax resulting in unpredictable behavior. > > Please post a unit test for this. Will do. Should be an easy test. > > This patch is not the final word, it is just an easy patch > > to fix the issue. The real fix will be done when the > > instruction emulator is made aware of nested virtualization. > > Until this is done this patch fixes the issue and provides > > an easy way to fix this in -stable too. > > I agree. We can probably use X86EMUL_PROPAGATE_FAULT to abort > emulation, but looking at the code, it will take some refactoring. I thought of an X86EMUL_INTERCEPTED. An architecture specific function is called after instruction decoding which checks if an intercept is necessary. If it returns X86EMUL_INTERCEPTED then the instruction emulation is discarded and kvm goes straight back into the guest. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632