From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754310AbdEJXVe (ORCPT ); Wed, 10 May 2017 19:21:34 -0400 Received: from mga02.intel.com ([134.134.136.20]:5056 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751096AbdEJXVc (ORCPT ); Wed, 10 May 2017 19:21:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,321,1491289200"; d="scan'208";a="99977572" Subject: Re: [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging To: Bandan Das , Paolo Bonzini References: <20170505192515.27833-1-bsd@redhat.com> <20170505192515.27833-3-bsd@redhat.com> <85f58713-67f6-fb06-9426-8d03809cea07@linux.intel.com> <9a3fb181-6bba-9488-114d-fd0fcdd6c92a@redhat.com> Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org From: "Huang, Kai" Message-ID: <54ec213c-ef9f-23ed-4de8-4a1eeb50aca0@linux.intel.com> Date: Thu, 11 May 2017 11:21:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/11/2017 4:00 AM, Bandan Das wrote: > Paolo Bonzini writes: > ... >>> Is the purpose of returning 1 to make upper layer code to inject PML >>> full VMEXIt to L1 in nested_ept_inject_page_fault? >> >> Yes, it triggers a fault >>>> + >>>> + gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS) & ~0xFFFull; >>>> + >>>> + page = nested_get_page(vcpu, vmcs12->pml_address); >>>> + if (!page) >>>> + return 0; >>> >>> If PML is enabled in L1, I think nested_get_page should never return a >>> NULL PML page (unless L1 does something wrong)? Probably better to >>> return 1 rather than 0, and handle error in nested_ept_inject_page_fault >>> according to vmcs12->pml_address? >> >> This happens if the PML address is invalid (where on real hardware, the >> write would just be "eaten") or MMIO (where we expect to diverge from > > Yes, that was my motivation. On real hardware, the hypervisor would still > run except that the PML buffer is corrupt. Right. Fine to me. :) > > Bandan > >> real hardware behavior). >> >>>> + >>>> + pml_address = kmap(page); >>>> + pml_address[vmcs12->guest_pml_index--] = gpa; >>> >>> This gpa is L2 guest's GPA. Do we also need to mark L1's GPA (which is >>> related to L2 guest's GPA above) in to dirty-log? Or has this already >>> been done? >> >> L1's PML contains L1 host physical addresses, i.e. L0 guest physical >> addresses. This GPA comes from vmcs02 and hence it is L0's GPA. Do you mean pml_address? I was talking about gpa got from vmcs_read64(GUEST_PHYSICAL_ADDRESS). From hardware's point of view, PML always logs "GPA" into PML buffer so I was saying the gpa from vmcs_read64(GUEST_PHYSICAL_ADDRESS) should be L2 guest's PA. Anyway this is not important now. :) >> >> L0's HPA is marked by hardware through PML, as usual. If L0 has EPT A/D >> but not PML, it can still provide emulated PML to L1, but L0's HPA will >> be marked as dirty via write protection. Yes this is what I was thinking. For L0 PML takes care of L1 hpyervisor's dirty page, while write protection takes care of dirty page from L2. No problem. Thanks, -Kai >> >> Paolo >