Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3361500pxu; Tue, 15 Dec 2020 05:22:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJyUB88BfEbDpb48uE+pPJzZyAM5dhmSx/YB02jGkHIED1qXfqgg35uXlb9Hcx1rkKnvs1x+ X-Received: by 2002:aa7:d2c9:: with SMTP id k9mr2406017edr.74.1608038558692; Tue, 15 Dec 2020 05:22:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608038558; cv=none; d=google.com; s=arc-20160816; b=06gaCMqlVCVOaCEd2NKSiZ/5dW2BsnGS+Ai1PFA0q5RMS8LoJE3WCvyGSnUsRh5Zg/ oxaxIjePSqgmrmUGWMqkudwMXl2jBrS68eycWiYEp9Hvuw6DMohHfHSE5vRox+MnCRks WbvX7y6SlWMONKkh3EXdwD6xG+5ka1R+wOhWDJ2Tqetl9DU/iMwM+S+2bmZdup4dwyZg pj1eklEKcWVMwbrVz4xlyymmf5qOl9SJyyuOmB1OwAfzw3v/Y2wk5VQjRrv5reDCHjlP RSwFWk9TKGHD/yOomj5Wj3pjoTzZYjx4PGI1TjKNHEY9rj9+WoduWFXm+PJUEncsuWPp YxMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:user-agent:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version; bh=Q392+2+gFbDfszc/4sKQ4ZmuPR6/HGj+2dbL0bFAtpk=; b=THifN6dv2f3VXYkS4hNdOm7s45g+yKxdYKL8QBrsTBlc1kIYtsNt4bF2tolhSJoEY4 wiUqbWFfHi1LMYhY//VMaUZu9UBB6z7tIDZfcxgnIGruEBrSZyCHHsVR+hzmgXLymsED zchSUiq2VF39y/Bu+HEOHTGgT9UlVsKkzcx7/pMgHScsG3xSX3wmS1eQh7icYi9y0KOg 9gcQ5pjkFvUmZbLP/8yvQP76eBCKxT89tNxUzXrfdjm9zyizV+N+Kp9pA9Ag5YI7Puhu 7L7+ioY168Qc8X7Uf3psIaY/QIJd57jnfupVE5F6HGpVhMJxgCQMasL5Yof7TTMHyhj3 SdSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id eb6si802063edb.497.2020.12.15.05.22.13; Tue, 15 Dec 2020 05:22:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727137AbgLONTS (ORCPT + 99 others); Tue, 15 Dec 2020 08:19:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:50572 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725890AbgLONTS (ORCPT ); Tue, 15 Dec 2020 08:19:18 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7D3D722225; Tue, 15 Dec 2020 13:18:37 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kpADr-001URY-9d; Tue, 15 Dec 2020 13:18:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 15 Dec 2020 13:18:35 +0000 From: Marc Zyngier To: "wangyanan (Y)" Cc: Will Deacon , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Catalin Marinas , James Morse , Julien Thierry , Suzuki K Poulose , Gavin Shan , Quentin Perret , wanghaibin.wang@huawei.com, yezengruan@huawei.com, zhukeqian1@huawei.com, yuzenghui@huawei.com, jiangkunkun@huawei.com, wangjingyi11@huawei.com, lushenming@huawei.com Subject: Re: [RFC PATCH] KVM: arm64: Add prejudgement for relaxing permissions only case in stage2 translation fault handler In-Reply-To: <2ab9323a-40a1-d223-f692-0a19207e16a9@huawei.com> References: <20201211080115.21460-1-wangyanan55@huawei.com> <20201211080115.21460-2-wangyanan55@huawei.com> <8d006755e5afce7e49b03993316c4fcc@kernel.org> <20201211100026.GA11352@willie-the-truck> <2ab9323a-40a1-d223-f692-0a19207e16a9@huawei.com> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <9a3bd48c4e69946bc4ade274ce2cc318@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: wangyanan55@huawei.com, will@kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, gshan@redhat.com, qperret@google.com, wanghaibin.wang@huawei.com, yezengruan@huawei.com, zhukeqian1@huawei.com, yuzenghui@huawei.com, jiangkunkun@huawei.com, wangjingyi11@huawei.com, lushenming@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Yanan, On 2020-12-14 07:20, wangyanan (Y) wrote: > diff --git a/arch/arm64/kvm/hyp/pgtable.c > b/arch/arm64/kvm/hyp/pgtable.c > index a74a62283012..e3c6133567c4 100644 > --- a/arch/arm64/kvm/hyp/pgtable.c > +++ b/arch/arm64/kvm/hyp/pgtable.c > @@ -45,6 +45,10 @@ > >  #define KVM_PTE_LEAF_ATTR_HI_S2_XN     BIT(54) > > +#define KVM_PTE_LEAF_ATTR_S2_PERMS (KVM_PTE_LEAF_ATTR_LO_S2_S2AP_R | \ > +        KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W | \ > + KVM_PTE_LEAF_ATTR_HI_S2_XN) > + >  struct kvm_pgtable_walk_data { >         struct kvm_pgtable                   *pgt; >         struct kvm_pgtable_walker       *walker; > @@ -473,8 +477,13 @@ static bool stage2_map_walker_try_leaf(u64 addr, > u64 end, u32 level, > >         new = kvm_init_valid_leaf_pte(phys, data->attr, level); >         if (kvm_pte_valid(old)) { > -               /* Tolerate KVM recreating the exact same mapping. */ > -               if (old == new) > +               /* > +                * Skip updating the PTE with break-before-make if we > are trying > +                * to recreate the exact same mapping or only change > the access > +                * permissions. Actually, change of permissions will be > handled > +                * through the relax_perms path next time if necessary. > +                */ > +               if (!((old ^ new) & (~KVM_PTE_LEAF_ATTR_S2_PERMS))) >                         goto out; > >                 /* There's an existing different valid leaf entry, so > perform I think there is a bit more work to do on this. One obvious issue is that we currently flag a page as dirty before handling the fault. With an early exit, we end-up having spurious dirty pages. It's not a big deal, but I'd rather mark the page dirty after the mapping or the permission update having been successful (at the moment, it cannot fails). Thanks, M. -- Jazz is not dead. It just smells funny...