From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752047AbdHKGk7 (ORCPT ); Fri, 11 Aug 2017 02:40:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47684 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751299AbdHKGk5 (ORCPT ); Fri, 11 Aug 2017 02:40:57 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9998E1585EF Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=david@redhat.com Subject: Re: [PATCH] KVM: MMU: Fix guest stuck during boot due to read/write emulation against GVA To: Paolo Bonzini , Wanpeng Li , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Wanpeng Li , Brijesh Singh References: <1502431194-3636-1-git-send-email-wanpeng.li@hotmail.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Fri, 11 Aug 2017 08:40:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 11 Aug 2017 06:40:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11.08.2017 08:13, Paolo Bonzini wrote: > On 11/08/2017 07:59, Wanpeng Li wrote: >> From: Wanpeng Li >> >> Commit c016004494b0 (KVM: x86: Avoid guest page table walk when gpa_available >> is set) avoids the page table walk when cr2 has already contained a valid GPA. >> However, that is not the truth if ept == 0 and shadow page table is used. In >> this scenario cr2 can just contains a valid GVA. The commit results in guest >> stuck during boot due to read/write emulation against GVA instead of GPA of >> the guest. >> >> This patch fixes it by not setting the gpa_available flag if the shadow page table >> is used. > > Yup, I got these on my overnight tests too. A better fix that I was > going to commit today is: > > if (vcpu->arch.mmu.direct_map) { > vcpu->arch.gpa_available = true; > vcpu->arch.gpa_val = fault_address; > } > Makes sense to me. Can we add a comment? /* with shadow page tables, cr2 could contain a GVA, not a GPA */ > because AMD gets here even if npt=1. > > Paolo -- Thanks, David