From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08CFCC04EB8 for ; Mon, 10 Dec 2018 09:00:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C90342082F for ; Mon, 10 Dec 2018 09:00:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C90342082F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726860AbeLJJAE (ORCPT ); Mon, 10 Dec 2018 04:00:04 -0500 Received: from foss.arm.com ([217.140.101.70]:48938 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726769AbeLJJAE (ORCPT ); Mon, 10 Dec 2018 04:00:04 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id ACB321596; Mon, 10 Dec 2018 01:00:03 -0800 (PST) Received: from localhost (e113682-lin.copenhagen.arm.com [10.32.144.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4648C3F575; Mon, 10 Dec 2018 01:00:03 -0800 (PST) Date: Mon, 10 Dec 2018 10:00:01 +0100 From: Christoffer Dall To: Suzuki K Poulose Cc: Anshuman Khandual , Punit Agrawal , kvmarm@lists.cs.columbia.edu, marc.zyngier@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, punitagrawal@gmail.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v9 2/8] KVM: arm/arm64: Re-factor setting the Stage 2 entry to exec on fault Message-ID: <20181210090001.GD30263@e113682-lin.lund.arm.com> References: <20181031175745.18650-1-punit.agrawal@arm.com> <20181031175745.18650-3-punit.agrawal@arm.com> <12212830-ffc6-a0e0-5de6-3e6a15ed7141@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 05, 2018 at 10:47:10AM +0000, Suzuki K Poulose wrote: > > > On 03/12/2018 13:32, Anshuman Khandual wrote: > > > > > >On 10/31/2018 11:27 PM, Punit Agrawal wrote: > >>Stage 2 fault handler marks a page as executable if it is handling an > >>execution fault or if it was a permission fault in which case the > >>executable bit needs to be preserved. > >> > >>The logic to decide if the page should be marked executable is > >>duplicated for PMD and PTE entries. To avoid creating another copy > >>when support for PUD hugepages is introduced refactor the code to > >>share the checks needed to mark a page table entry as executable. > >> > >>Signed-off-by: Punit Agrawal > >>Reviewed-by: Suzuki K Poulose > >>Cc: Christoffer Dall > >>Cc: Marc Zyngier > >>--- > >> virt/kvm/arm/mmu.c | 28 +++++++++++++++------------- > >> 1 file changed, 15 insertions(+), 13 deletions(-) > >> > >>diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c > >>index 59595207c5e1..6912529946fb 100644 > >>--- a/virt/kvm/arm/mmu.c > >>+++ b/virt/kvm/arm/mmu.c > >>@@ -1475,7 +1475,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > >> unsigned long fault_status) > >> { > >> int ret; > >>- bool write_fault, exec_fault, writable, force_pte = false; > >>+ bool write_fault, writable, force_pte = false; > >>+ bool exec_fault, needs_exec; > > > >New line not required, still within 80 characters. > > > >> unsigned long mmu_seq; > >> gfn_t gfn = fault_ipa >> PAGE_SHIFT; > >> struct kvm *kvm = vcpu->kvm; > >>@@ -1598,19 +1599,25 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > >> if (exec_fault) > >> invalidate_icache_guest_page(pfn, vma_pagesize); > >>+ /* > >>+ * If we took an execution fault we have made the > >>+ * icache/dcache coherent above and should now let the s2 > > > >Coherent or invalidated with invalidate_icache_guest_page ? > > We also do clean_dcache above if needed. So that makes sure > the data is coherent. Am I missing something here ? > I think you've got it right. We have made the icache coherent with the data/instructions in the page by invalidating the icache. I think the comment is ok either way. Thanks, Christoffer