Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751880AbdIMOkD (ORCPT ); Wed, 13 Sep 2017 10:40:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49554 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751581AbdIMOkA (ORCPT ); Wed, 13 Sep 2017 10:40:00 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E33D07E427 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=rkrcmar@redhat.com Date: Wed, 13 Sep 2017 16:39:56 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: changbin.du@intel.com Cc: pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RESEND][PATCH] kvm: x86: Do not handle MMIO request in fast_page_fault Message-ID: <20170913143955.GB2673@flask> References: <1504607862-8497-1-git-send-email-changbin.du@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1504607862-8497-1-git-send-email-changbin.du@intel.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 13 Sep 2017 14:40:00 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1697 Lines: 50 2017-09-05 18:37+0800, changbin.du@intel.com: > From: Changbin Du > > If it is a MMIO request, it should be handled by slow path. This patch > actually fixed below warning when mmu debug is enabled. > > WARNING: CPU: 5 PID: 2282 at arch/x86/kvm/mmu.c:226 fast_page_fault+0x41b/0x520 > CPU: 5 PID: 2282 Comm: qemu-system-x86 Not tainted 4.13.0-rc6+ #34 > task: ffff9b47f5286000 task.stack: ffffb18d03b28000 > RIP: 0010:fast_page_fault+0x41b/0x520 > Call Trace: > tdp_page_fault+0xfb/0x290 > kvm_mmu_page_fault+0x61/0x120 > handle_ept_misconfig+0x1ba/0x1c0 > vmx_handle_exit+0xb8/0xd70 > ? kvm_arch_vcpu_ioctl_run+0x9b6/0x18e0 > kvm_arch_vcpu_ioctl_run+0xa5a/0x18e0 > ? kvm_arch_vcpu_load+0x62/0x230 > kvm_vcpu_ioctl+0x340/0x6c0 > ? kvm_vcpu_ioctl+0x340/0x6c0 > ? lock_acquire+0xf5/0x1f0 > do_vfs_ioctl+0xa2/0x670 > ? __fget+0x107/0x200 > SyS_ioctl+0x79/0x90 > entry_SYSCALL_64_fastpath+0x23/0xc2 > > Signed-off-by: Changbin Du > --- > arch/x86/kvm/mmu.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c > index 9d3f275..63c3360 100644 > --- a/arch/x86/kvm/mmu.c > +++ b/arch/x86/kvm/mmu.c > @@ -3180,6 +3180,9 @@ static bool fast_page_fault(struct kvm_vcpu *vcpu, gva_t gva, int level, > iterator.level < level) > break; > > + if (is_mmio_spte(spte)) > + break; Hm, handle_ept_misconfig() calls kvm_mmu_page_fault with error_code = PFERR_RSVD_MASK. This error_code gets propagated and checked at the beginning of page_fault_can_be_fast(), where it should break the function execution. How did the execution get all the way to the loop? Thanks.