Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752506AbdGaPoy (ORCPT ); Mon, 31 Jul 2017 11:44:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59514 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752059AbdGaPox (ORCPT ); Mon, 31 Jul 2017 11:44:53 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3C297162256 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=pbonzini@redhat.com Subject: Re: [PATCH v2 1/3] kvm: svm: Add support for additional SVM NPF error codes To: Brijesh Singh , kvm@vger.kernel.org Cc: thomas.lendacky@amd.com, rkrcmar@redhat.com, joro@8bytes.org, x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de, bp@suse.de References: <147992048887.27638.17559991037474542240.stgit@brijesh-build-machine> <147992049856.27638.17076562184960611399.stgit@brijesh-build-machine> From: Paolo Bonzini Message-ID: <21b9f4db-f929-80f6-6ad2-6fa3b77f82c0@redhat.com> Date: Mon, 31 Jul 2017 17:44:44 +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.25]); Mon, 31 Jul 2017 15:44:53 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2043 Lines: 49 On 31/07/2017 15:30, Brijesh Singh wrote: > Hi Paolo, > > On 07/27/2017 11:27 AM, Paolo Bonzini wrote: >> On 23/11/2016 18:01, Brijesh Singh wrote: >>> + /* >>> + * Before emulating the instruction, check if the error code >>> + * was due to a RO violation while translating the guest page. >>> + * This can occur when using nested virtualization with nested >>> + * paging in both guests. If true, we simply unprotect the page >>> + * and resume the guest. >>> + * >>> + * Note: AMD only (since it supports the PFERR_GUEST_PAGE_MASK used >>> + * in PFERR_NEXT_GUEST_PAGE) >>> + */ >>> + if (error_code == PFERR_NESTED_GUEST_PAGE) { >>> + kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(cr2)); >>> + return 1; >>> + } >> >> >> What happens if L1 is mapping some memory that is read only in L0? That >> is, the L1 nested page tables make it read-write, but the L0 shadow >> nested page tables make it read-only. >> >> Accessing it would cause an NPF, and then my guess is that the L1 guest >> would loop on the failing instruction instead of just dropping the write. >> > > > Not sure if I am able to follow your use case. Could you please explain me > in bit detail. > > The purpose of the code above was really for when we resume from the L2 guest > back to the L1 guest. The L1 page tables are marked RO when in the L2 guest > (for shadow paging) as I recall, so when we come back to the L1 guest, it can > get a fault since its page tables are not marked writeable at L0 as they > need to be. There can be different cases where an L0->L2 shadow nested page table is marked read only, in particular when a page is read only in L1's nested page tables. If such a page is accessed by L2 while walking page tables it will cause a nested page fault (page table walks are write accesses). However, after kvm_mmu_unprotect_page you will get another page fault, and again in an endless stream. Instead, emulation would have caused a nested page fault vmexit, I think. Paolo