Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755081AbdGWAaC (ORCPT ); Sat, 22 Jul 2017 20:30:02 -0400 Received: from mail-oi0-f41.google.com ([209.85.218.41]:33033 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752038AbdGWAaA (ORCPT ); Sat, 22 Jul 2017 20:30:00 -0400 MIME-Version: 1.0 In-Reply-To: References: <1496460115-12654-1-git-send-email-wanpeng.li@hotmail.com> <2ba5e53d-14f4-14a1-0084-a8b521a3ec3e@redhat.com> From: Wanpeng Li Date: Sun, 23 Jul 2017 08:29:58 +0800 Message-ID: Subject: Re: [PATCH] KVM: nVMX: Fix exception injection To: Jim Mattson Cc: Paolo Bonzini , "linux-kernel@vger.kernel.org" , kvm , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Wanpeng Li Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v6N0U8ve007163 Content-Length: 2742 Lines: 59 2017-07-22 22:25 GMT+08:00 Jim Mattson : > On Fri, Jul 21, 2017 at 1:39 AM, Wanpeng Li wrote: >> Hi Jim, >> 2017-07-21 3:16 GMT+08:00 Jim Mattson : >>> On Wed, Jul 19, 2017 at 7:31 PM, Wanpeng Li wrote: >>>> Hi Jim, >>>> 2017-07-19 2:47 GMT+08:00 Jim Mattson : >>>>> Why do we expect the VM_EXIT_INTR_INFO and EXIT_QUALIFICATION fields >>>>> of the VMCS to have the correct values for the injected exception? >>>> >>>> Good point, I think we should synthesize VM_EXIT_INTR_INFO and >>>> EXIT_QUALIFICATION manually, I will post a patch for it. Btw, how >>>> about setting EXIT_QULIFICATION to vcpu->arch.cr2 for the page fault >>>> exception and 0 for other exceptions? >>> >>> From the SDM, section 27.1: >>> >>> If an event causes a VM exit directly, it does not update >> >> I mentioned this in the patch description: >> >>> However, there is no guarantee the exit reason is exception currently, when there is an external interrupt occurred on host, maybe a time interrupt for host which should not be injected to guest, and somewhere queues an exception, then the function nested_vmx_check_exception() will be called and the vmexit emulation codes will try to emulate the "Acknowledge interrupt on exit" behavior, the warning is triggered. >> >> If you think the scenario is correct, then it should be an event >> causes a VM exit indirectly. So if both the scenario which I mentioned >> and "This function >> assumes it is called with the exit reason in vmcs02 being a #PF >> exception" can happen, then maybe we should figure out how to fix both >> scenarios suitable. > > In the situation you describe, the #PF causes a synthesized VM-exit > from L2 to L1 directly, not indirectly. From the SDM: > > An exception causes a VM exit directly if the bit corresponding to > that exception is set in the exception bitmap. > > Hence, CR2 should not be set yet. Any idea how to synthesize exit qualification for page fault and debug exception? Regards, Wanpeng Li > >> >>> architectural state as it would have if it had it not caused the VM >>> exit: >>> - A debug exception does not update DR6, DR7.GD, or >>> IA32_DEBUGCTL.LBR. (Information about the nature of the debug >>> exception is saved in the exit qualification field.) >>> - A page fault does not update CR2. (The linear address causing >>> the page fault is saved in the exit-qualification field.) >>> >>> This means that vcpu->arch.cr2 should not be set at this point for a >>> #PF injection (and vcpu->arch.dr6 should not be set at this point for >>> a #DB injection). For all other exceptions, yes, the exit >>> qualification should be cleared. >>>