From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Fri, 2 Aug 2024 12:32:09 -0700 Subject: [PATCH v12 64/84] KVM: LoongArch: Mark "struct page" pfns dirty only in "slow" page fault path In-Reply-To: References: <20240726235234.228822-1-seanjc@google.com> <20240726235234.228822-65-seanjc@google.com> Message-ID: List-Id: To: kvm-riscv@lists.infradead.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Fri, Aug 02, 2024, maobibo wrote: > On 2024/7/27 ??7:52, Sean Christopherson wrote: > > Mark pages/folios dirty only the slow page fault path, i.e. only when > > mmu_lock is held and the operation is mmu_notifier-protected, as marking a > > page/folio dirty after it has been written back can make some filesystems > > unhappy (backing KVM guests will such filesystem files is uncommon, and > > the race is minuscule, hence the lack of complaints). > > > > See the link below for details. > > > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes at gmail.com > > Signed-off-by: Sean Christopherson > > --- > > arch/loongarch/kvm/mmu.c | 18 ++++++++++-------- > > 1 file changed, 10 insertions(+), 8 deletions(-) > > > > diff --git a/arch/loongarch/kvm/mmu.c b/arch/loongarch/kvm/mmu.c > > index 2634a9e8d82c..364dd35e0557 100644 > > --- a/arch/loongarch/kvm/mmu.c > > +++ b/arch/loongarch/kvm/mmu.c > > @@ -608,13 +608,13 @@ static int kvm_map_page_fast(struct kvm_vcpu *vcpu, unsigned long gpa, bool writ > > if (kvm_pte_young(changed)) > > kvm_set_pfn_accessed(pfn); > > - if (kvm_pte_dirty(changed)) { > > - mark_page_dirty(kvm, gfn); > > - kvm_set_pfn_dirty(pfn); > > - } > > if (page) > > put_page(page); > > } > > + > > + if (kvm_pte_dirty(changed)) > > + mark_page_dirty(kvm, gfn); > > + > > return ret; > > out: > > spin_unlock(&kvm->mmu_lock); > > @@ -915,12 +915,14 @@ static int kvm_map_page(struct kvm_vcpu *vcpu, unsigned long gpa, bool write) > > else > > ++kvm->stat.pages; > > kvm_set_pte(ptep, new_pte); > > - spin_unlock(&kvm->mmu_lock); > > - if (prot_bits & _PAGE_DIRTY) { > > - mark_page_dirty_in_slot(kvm, memslot, gfn); > > + if (writeable) > Is it better to use write or (prot_bits & _PAGE_DIRTY) here? writable is > pte permission from function hva_to_pfn_slow(), write is fault action. Marking folios dirty in the slow/full path basically necessitates marking the folio dirty if KVM creates a writable SPTE, as KVM won't mark the folio dirty if/when _PAGE_DIRTY is set. Practically speaking, I'm 99.9% certain it doesn't matter. The folio is marked dirty by core MM when the folio is made writable, and cleaning the folio triggers an mmu_notifier invalidation. I.e. if the page is mapped writable in KVM's stage-2 PTEs, then its folio has already been marked dirty. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E5661ABEAF for ; Fri, 2 Aug 2024 19:32:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722627133; cv=none; b=TbQmEJNOchSx+ui/cF44vMQPvWe6ZSTNixgj8FzNin5iszIA9D4qLCrdBDiCvhiBxIV/KwIf4c/LC1IjE0WmCgaCS8htCOLIRUDLEf9g5s8FdXtS6A5ra+3A0lIl9Hh/StXJQ19KPLHT5ZFSxn8pJ/4HLld8Hi05hOsEzAv65vU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722627133; c=relaxed/simple; bh=csd0MkbfiRZ32mkpXZ9twM9kRQL1vy8OM+kdMsU6aRQ=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=crJAAE4gOgeMtKEnD5PNvyI+hxx4KBvcGuifyT+88g8GjBDIKP4iaQsRUFqKXp9f6x8oODuBMQECw9pWMs858rV+cYGGd4rXLomW2IGBHdX6yZSM0Wr0Te9lwp/flPG1Vd22fmnr7hIoGGVDERIK9ghFO+hGHuDJ3cChpUrROH0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=iNmJ+tal; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="iNmJ+tal" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2cfe9270d82so2854032a91.3 for ; Fri, 02 Aug 2024 12:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722627130; x=1723231930; darn=lists.linux.dev; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=TTqa7oavJrWkxSTFWtVmMnGsBDrmN4Dgl5PSeoZtRS0=; b=iNmJ+talcLKvuEHChjLnAk72W65Z9sdjrj8B3sFMPPDTx6js2H94XAp9aFOpyxNOJx pe8HbMqzjT1wfVn6uOkA8gfQ1pFFM+U4Seg9LsTgI9vW+hlzBj4gNOvNa0ktNXxy57XI kOuyOI7mhUFZIbdPbcKhXFXnu2yC1c9yMHZsS15MlnCrDiPEwYFD7eEUA+51nlBwgE6r DA9ET2i7HN3WQwrOdKzPtvL20dx5sORUmp3bvQp0VN4P5s9ZjfYphKE45csPdiW9CMgL ojl1fs0hDJX5fjr/qP6f4E9Typ8+U8gYCLrWtaEhGECr8SPoTx8WbBDAqmpSLVQGRA1x LwOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722627130; x=1723231930; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=TTqa7oavJrWkxSTFWtVmMnGsBDrmN4Dgl5PSeoZtRS0=; b=dndWPpSus2wf3bFFlJ69GnHiNdK0Ppljdlig7+JM5X1aLv3Ai+ULS/cgzD1Q7Br32p 8eLifXqjtHmW4ZnicQOKKgSLIB+zraQjpnATXSPO87eVs27/CrDTxvH/jTFbC7ujQXC5 10Lu7G2yB+LCo98F1msJTVj6yqN+kATaFyV3dsn3DdLSoP7daX/jT1ENNdAhEcY7GHSh fEDIkherzEH/8s8GonoRpwRcczwfh5i7da0epUQ/6iSbtWeV9tPSTUFsQcd339KgF8k8 veAPfQZz+aQ05BAysjrMC4iCOiA2KoA8vimDBcE5DjqHANousOPAYY2LjvtZeK9Jatsk 3jzQ== X-Forwarded-Encrypted: i=1; AJvYcCUhxQKWLG9ucAB1bPNTXySOQPlOOgkD2yXemlWhvQLLUdrEdVdJRFNmZwoJpDLlZVSshQJLUSfd3ssEhqkjuRGd+oGHGhhI X-Gm-Message-State: AOJu0Yz7QHykZFksnNGe6Ib3Yk0hTOJKF0loNhdkqsrrd6CCxvbqEaCz BI1KSs/Y+qutL9k5V2zL/8tFgKK04TYmyks4QDB8V2JzawCdUFVzII4RM17PMxWjdgg9gotpKqT bew== X-Google-Smtp-Source: AGHT+IHxpD4UvI3cH5YcMAfSn5X/q5FbzhvcZwiTnoiXfWEKupcq/mKgFqqrl+E4nqq+ftOi/sOAAYuzYXs= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:50cf:b0:2c9:61f9:9b27 with SMTP id 98e67ed59e1d1-2cff9526286mr68117a91.5.1722627130434; Fri, 02 Aug 2024 12:32:10 -0700 (PDT) Date: Fri, 2 Aug 2024 12:32:09 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240726235234.228822-1-seanjc@google.com> <20240726235234.228822-65-seanjc@google.com> Message-ID: Subject: Re: [PATCH v12 64/84] KVM: LoongArch: Mark "struct page" pfns dirty only in "slow" page fault path From: Sean Christopherson To: maobibo Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Tianrui Zhao , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, David Matlack , David Stevens Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 02, 2024, maobibo wrote: > On 2024/7/27 =E4=B8=8A=E5=8D=887:52, Sean Christopherson wrote: > > Mark pages/folios dirty only the slow page fault path, i.e. only when > > mmu_lock is held and the operation is mmu_notifier-protected, as markin= g a > > page/folio dirty after it has been written back can make some filesyste= ms > > unhappy (backing KVM guests will such filesystem files is uncommon, and > > the race is minuscule, hence the lack of complaints). > >=20 > > See the link below for details. > >=20 > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.c= om > > Signed-off-by: Sean Christopherson > > --- > > arch/loongarch/kvm/mmu.c | 18 ++++++++++-------- > > 1 file changed, 10 insertions(+), 8 deletions(-) > >=20 > > diff --git a/arch/loongarch/kvm/mmu.c b/arch/loongarch/kvm/mmu.c > > index 2634a9e8d82c..364dd35e0557 100644 > > --- a/arch/loongarch/kvm/mmu.c > > +++ b/arch/loongarch/kvm/mmu.c > > @@ -608,13 +608,13 @@ static int kvm_map_page_fast(struct kvm_vcpu *vcp= u, unsigned long gpa, bool writ > > if (kvm_pte_young(changed)) > > kvm_set_pfn_accessed(pfn); > > - if (kvm_pte_dirty(changed)) { > > - mark_page_dirty(kvm, gfn); > > - kvm_set_pfn_dirty(pfn); > > - } > > if (page) > > put_page(page); > > } > > + > > + if (kvm_pte_dirty(changed)) > > + mark_page_dirty(kvm, gfn); > > + > > return ret; > > out: > > spin_unlock(&kvm->mmu_lock); > > @@ -915,12 +915,14 @@ static int kvm_map_page(struct kvm_vcpu *vcpu, un= signed long gpa, bool write) > > else > > ++kvm->stat.pages; > > kvm_set_pte(ptep, new_pte); > > - spin_unlock(&kvm->mmu_lock); > > - if (prot_bits & _PAGE_DIRTY) { > > - mark_page_dirty_in_slot(kvm, memslot, gfn); > > + if (writeable) > Is it better to use write or (prot_bits & _PAGE_DIRTY) here? writable is > pte permission from function hva_to_pfn_slow(), write is fault action. Marking folios dirty in the slow/full path basically necessitates marking t= he folio dirty if KVM creates a writable SPTE, as KVM won't mark the folio dir= ty if/when _PAGE_DIRTY is set. Practically speaking, I'm 99.9% certain it doesn't matter. The folio is ma= rked dirty by core MM when the folio is made writable, and cleaning the folio tr= iggers an mmu_notifier invalidation. I.e. if the page is mapped writable in KVM's stage-2 PTEs, then its folio has already been marked dirty. 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3AF34C3DA4A for ; Fri, 2 Aug 2024 19:32:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=prku8r3Aq+mDYo4pt9gjl4pRl9y3DvU1rgl9wbt4kQ8=; b=AcrbIi64b+1ZBFyiiTBp4fEe8x mNiUicXC9JQ6S+RL3iSmiYcb8G+08AmMCJyTuL5wCViHxhIO/ecF2rvcGOi0jbHgaJueMGN+M+hkA qosDH1OxuqusjwQrF5uhP3aAM5LwqGkkeRDDf2OIs91vZztN+OedMrbSQ+fSN1I4r9HgzW1ABVxiZ wmmPT3mo8H6OT5pzHmjX30t/AkBIuG3nk+h++xUrwYQ5ffcEQwvsG2E9MXFlIfzZYgn/e2Q+/8q9E NI+THblcvAhNWgjOdPjNO91+EYRu4QIETWdFlAnWm8/ZlVDRwlxeOVKtgODVNFTv2R1WyaBrVXhnv n9uQ0tjw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZy0j-00000009sgt-2mvW; Fri, 02 Aug 2024 19:32:21 +0000 Received: from mail-pj1-x1049.google.com ([2607:f8b0:4864:20::1049]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZy0a-00000009sdu-1Msp for linux-riscv@lists.infradead.org; Fri, 02 Aug 2024 19:32:14 +0000 Received: by mail-pj1-x1049.google.com with SMTP id 98e67ed59e1d1-2cb685d5987so10521508a91.2 for ; Fri, 02 Aug 2024 12:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722627130; x=1723231930; darn=lists.infradead.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=TTqa7oavJrWkxSTFWtVmMnGsBDrmN4Dgl5PSeoZtRS0=; b=qK+csV+A+AF7bZWtakH9Rfx/kKgYZ19CMbJ/tjFre18EtPOdbGmpitpI5NMc4gbEJt BFJLIMOZ30WxLjLEvGqTWN5mV3VuWFX/uGPVjbHaHKtefyqi5+Tk83wgkbHG2Dw+PfXP +8huhYOayWEZeiS7qN8CxtGtFFNEEqvNpUJ+G+U+rKplS+8TB2MQho2PQFO5SH+q0uIH kEBQV+FXhnjT/CcIzKipojL/gbuGlnQLPZ98mW4s59kQgRfty12UGbRvSc+qL3tAdm1J iW4O1GcSCtgEA7GX7facql0n5xodq8ikMIz8tbuEn/tD6nug2Y6VS7Q5I0Ft0cq8oxLV 6y+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722627130; x=1723231930; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=TTqa7oavJrWkxSTFWtVmMnGsBDrmN4Dgl5PSeoZtRS0=; b=NC9WvaFLiMMo7OBBfN25E6OFd7H3utkp5fQ8J/cKOnM0dkyUW6yQJLtVqsUYBBZx8c 9EeicpTE4dqrYFG0Owu9JdJtjwXi1bguyIBUUPi+fC8ad6bXFfAKIf5prw07NLGwePuY EI5FVpiRKCt3TDRMLbKLNsOZU7HvXxsSec+6WdgQPNJCWquryc5vVTgFPwiNXyww8IH8 Soyt17UtXbj7PG5CmF5a5IYL2S4FhIXR+Li+zDcM7TgUlikCcJFghcVVjpeq69joOUqn +hM7030gE7Ux22C/74i7EqUTjo1dcTWyDdV7gDBqnag6PvZAfGRO7KXysrY77JEjCJC9 VPMQ== X-Forwarded-Encrypted: i=1; AJvYcCVbld9OCdd7BahYSyprPFeCrOTUwqFZvDs3+w8L3RWQFTCfZ5rOmrEtg0/ivNiywIkAqYGDbnUJr/YS8DXpmksRfhQCgqX39qMDXoKdoeuK X-Gm-Message-State: AOJu0Yy88w4bjmjiXc4ubh3E0cFaVYL/pkTDEPsAvLbG8AM/KumY+KMC FIb1y/9FVdzoLaOCr9jN4w6ImVeSqTUQMfehGNNjNV66Q7/E1/elC/NMaCwb6mZU9wQGN6o/FmZ bhw== X-Google-Smtp-Source: AGHT+IHxpD4UvI3cH5YcMAfSn5X/q5FbzhvcZwiTnoiXfWEKupcq/mKgFqqrl+E4nqq+ftOi/sOAAYuzYXs= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:50cf:b0:2c9:61f9:9b27 with SMTP id 98e67ed59e1d1-2cff9526286mr68117a91.5.1722627130434; Fri, 02 Aug 2024 12:32:10 -0700 (PDT) Date: Fri, 2 Aug 2024 12:32:09 -0700 In-Reply-To: Mime-Version: 1.0 References: <20240726235234.228822-1-seanjc@google.com> <20240726235234.228822-65-seanjc@google.com> Message-ID: Subject: Re: [PATCH v12 64/84] KVM: LoongArch: Mark "struct page" pfns dirty only in "slow" page fault path From: Sean Christopherson To: maobibo Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Tianrui Zhao , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, David Matlack , David Stevens X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240802_123212_445789_57810722 X-CRM114-Status: GOOD ( 19.40 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org T24gRnJpLCBBdWcgMDIsIDIwMjQsIG1hb2JpYm8gd3JvdGU6Cj4gT24gMjAyNC83LzI3IOS4iuWN iDc6NTIsIFNlYW4gQ2hyaXN0b3BoZXJzb24gd3JvdGU6Cj4gPiBNYXJrIHBhZ2VzL2ZvbGlvcyBk aXJ0eSBvbmx5IHRoZSBzbG93IHBhZ2UgZmF1bHQgcGF0aCwgaS5lLiBvbmx5IHdoZW4KPiA+IG1t dV9sb2NrIGlzIGhlbGQgYW5kIHRoZSBvcGVyYXRpb24gaXMgbW11X25vdGlmaWVyLXByb3RlY3Rl ZCwgYXMgbWFya2luZyBhCj4gPiBwYWdlL2ZvbGlvIGRpcnR5IGFmdGVyIGl0IGhhcyBiZWVuIHdy aXR0ZW4gYmFjayBjYW4gbWFrZSBzb21lIGZpbGVzeXN0ZW1zCj4gPiB1bmhhcHB5IChiYWNraW5n IEtWTSBndWVzdHMgd2lsbCBzdWNoIGZpbGVzeXN0ZW0gZmlsZXMgaXMgdW5jb21tb24sIGFuZAo+ ID4gdGhlIHJhY2UgaXMgbWludXNjdWxlLCBoZW5jZSB0aGUgbGFjayBvZiBjb21wbGFpbnRzKS4K PiA+IAo+ID4gU2VlIHRoZSBsaW5rIGJlbG93IGZvciBkZXRhaWxzLgo+ID4gCj4gPiBMaW5rOiBo dHRwczovL2xvcmUua2VybmVsLm9yZy9hbGwvY292ZXIuMTY4MzA0NDE2Mi5naXQubHN0b2FrZXNA Z21haWwuY29tCj4gPiBTaWduZWQtb2ZmLWJ5OiBTZWFuIENocmlzdG9waGVyc29uIDxzZWFuamNA Z29vZ2xlLmNvbT4KPiA+IC0tLQo+ID4gICBhcmNoL2xvb25nYXJjaC9rdm0vbW11LmMgfCAxOCAr KysrKysrKysrLS0tLS0tLS0KPiA+ICAgMSBmaWxlIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKyks IDggZGVsZXRpb25zKC0pCj4gPiAKPiA+IGRpZmYgLS1naXQgYS9hcmNoL2xvb25nYXJjaC9rdm0v bW11LmMgYi9hcmNoL2xvb25nYXJjaC9rdm0vbW11LmMKPiA+IGluZGV4IDI2MzRhOWU4ZDgyYy4u MzY0ZGQzNWUwNTU3IDEwMDY0NAo+ID4gLS0tIGEvYXJjaC9sb29uZ2FyY2gva3ZtL21tdS5jCj4g PiArKysgYi9hcmNoL2xvb25nYXJjaC9rdm0vbW11LmMKPiA+IEBAIC02MDgsMTMgKzYwOCwxMyBA QCBzdGF0aWMgaW50IGt2bV9tYXBfcGFnZV9mYXN0KHN0cnVjdCBrdm1fdmNwdSAqdmNwdSwgdW5z aWduZWQgbG9uZyBncGEsIGJvb2wgd3JpdAo+ID4gICAJCWlmIChrdm1fcHRlX3lvdW5nKGNoYW5n ZWQpKQo+ID4gICAJCQlrdm1fc2V0X3Bmbl9hY2Nlc3NlZChwZm4pOwo+ID4gLQkJaWYgKGt2bV9w dGVfZGlydHkoY2hhbmdlZCkpIHsKPiA+IC0JCQltYXJrX3BhZ2VfZGlydHkoa3ZtLCBnZm4pOwo+ ID4gLQkJCWt2bV9zZXRfcGZuX2RpcnR5KHBmbik7Cj4gPiAtCQl9Cj4gPiAgIAkJaWYgKHBhZ2Up Cj4gPiAgIAkJCXB1dF9wYWdlKHBhZ2UpOwo+ID4gICAJfQo+ID4gKwo+ID4gKwlpZiAoa3ZtX3B0 ZV9kaXJ0eShjaGFuZ2VkKSkKPiA+ICsJCW1hcmtfcGFnZV9kaXJ0eShrdm0sIGdmbik7Cj4gPiAr Cj4gPiAgIAlyZXR1cm4gcmV0Owo+ID4gICBvdXQ6Cj4gPiAgIAlzcGluX3VubG9jaygma3ZtLT5t bXVfbG9jayk7Cj4gPiBAQCAtOTE1LDEyICs5MTUsMTQgQEAgc3RhdGljIGludCBrdm1fbWFwX3Bh Z2Uoc3RydWN0IGt2bV92Y3B1ICp2Y3B1LCB1bnNpZ25lZCBsb25nIGdwYSwgYm9vbCB3cml0ZSkK PiA+ICAgCWVsc2UKPiA+ICAgCQkrK2t2bS0+c3RhdC5wYWdlczsKPiA+ICAgCWt2bV9zZXRfcHRl KHB0ZXAsIG5ld19wdGUpOwo+ID4gLQlzcGluX3VubG9jaygma3ZtLT5tbXVfbG9jayk7Cj4gPiAt CWlmIChwcm90X2JpdHMgJiBfUEFHRV9ESVJUWSkgewo+ID4gLQkJbWFya19wYWdlX2RpcnR5X2lu X3Nsb3Qoa3ZtLCBtZW1zbG90LCBnZm4pOwo+ID4gKwlpZiAod3JpdGVhYmxlKQo+IElzIGl0IGJl dHRlciB0byB1c2Ugd3JpdGUgb3IgKHByb3RfYml0cyAmIF9QQUdFX0RJUlRZKSBoZXJlPyAgd3Jp dGFibGUgaXMKPiBwdGUgcGVybWlzc2lvbiBmcm9tIGZ1bmN0aW9uIGh2YV90b19wZm5fc2xvdygp LCB3cml0ZSBpcyBmYXVsdCBhY3Rpb24uCgpNYXJraW5nIGZvbGlvcyBkaXJ0eSBpbiB0aGUgc2xv dy9mdWxsIHBhdGggYmFzaWNhbGx5IG5lY2Vzc2l0YXRlcyBtYXJraW5nIHRoZQpmb2xpbyBkaXJ0 eSBpZiBLVk0gY3JlYXRlcyBhIHdyaXRhYmxlIFNQVEUsIGFzIEtWTSB3b24ndCBtYXJrIHRoZSBm b2xpbyBkaXJ0eQppZi93aGVuIF9QQUdFX0RJUlRZIGlzIHNldC4KClByYWN0aWNhbGx5IHNwZWFr aW5nLCBJJ20gOTkuOSUgY2VydGFpbiBpdCBkb2Vzbid0IG1hdHRlci4gIFRoZSBmb2xpbyBpcyBt YXJrZWQKZGlydHkgYnkgY29yZSBNTSB3aGVuIHRoZSBmb2xpbyBpcyBtYWRlIHdyaXRhYmxlLCBh bmQgY2xlYW5pbmcgdGhlIGZvbGlvIHRyaWdnZXJzCmFuIG1tdV9ub3RpZmllciBpbnZhbGlkYXRp b24uICBJLmUuIGlmIHRoZSBwYWdlIGlzIG1hcHBlZCB3cml0YWJsZSBpbiBLVk0ncwpzdGFnZS0y IFBURXMsIHRoZW4gaXRzIGZvbGlvIGhhcyBhbHJlYWR5IGJlZW4gbWFya2VkIGRpcnR5LgoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtcmlzY3Yg bWFpbGluZyBsaXN0CmxpbnV4LXJpc2N2QGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3Rz LmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1yaXNjdgo= 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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 86494C3DA4A for ; Fri, 2 Aug 2024 19:32:57 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=WBeUDsaA; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4WbGFh0QmMz3fSs for ; Sat, 3 Aug 2024 05:32:56 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20230601 header.b=WBeUDsaA; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::1049; helo=mail-pj1-x1049.google.com; envelope-from=3ojstzgykdjmf1xa6z3bb381.zb985ahkccz-01i85fgf.bm8xyf.be3@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-pj1-x1049.google.com (mail-pj1-x1049.google.com [IPv6:2607:f8b0:4864:20::1049]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4WbGDv1krLz3dVR for ; Sat, 3 Aug 2024 05:32:13 +1000 (AEST) Received: by mail-pj1-x1049.google.com with SMTP id 98e67ed59e1d1-2cb685d5987so10521513a91.2 for ; Fri, 02 Aug 2024 12:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722627131; x=1723231931; darn=lists.ozlabs.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=TTqa7oavJrWkxSTFWtVmMnGsBDrmN4Dgl5PSeoZtRS0=; b=WBeUDsaA7pazQTXyYic+rUpptuN268E3T97BUZsJ2qKITmPWfJEBnwZpvcn/0w+tOJ zvbUT+e1VNgGCrXYQD3YFEwE4AY/mESZkubAVjqJgk6m5MHIlwKxLabYZNPJdzZIw9DX uLn31/966dzOruhYPTwKMcyNS4CVrGmTwz/bfLCzddB8cONkAwjdGmgUzLctqeY1Sk5b 1/qYUMXyC7rD7myyjy1gF1U9vXTeMFsAfwRkbF72jimP/M5qU29k+/42AM1zoN3SEFUt ReQ12snfK4hzbC3jC61H8mFeKuUo78otFZXKcz5Vc/yIHndB73HopiLQ/m4cTZPVzMJW K3wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722627131; x=1723231931; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=TTqa7oavJrWkxSTFWtVmMnGsBDrmN4Dgl5PSeoZtRS0=; b=sO85BcCrDpnzvHYxU2N+IYiR0yLCsuTtfZcycOzgNxZLUc+QkL/XNrP5+HaaCSCmkT rjO19WRXCGaCXcuCQZIWHvP07Uw9fMxfgNoPgXS8ZkwbqoC9IwsZvx9EB4T1ELszUMiP 0kv3KzyW/j5gkJ3HfyojdP/CoPt5DJY3CLGLyGOYrA/Catw6CPMXfRY6hW76hx1hrX89 mMDmzv65S2UUTye8TnwrJPsvcs76YZWhZuXk07GYkCP/jHJU6rvZlQvwezXuGrCX0s3+ UuFIGxtfJI4S71ciufoJLezvTiDxw28xKqST3xXn+hPliu3zTW8fjT0PEueifdVuurNf HyAQ== X-Forwarded-Encrypted: i=1; AJvYcCU3MzNhSQemfxjO4YBignMJqLKqtB3OtY4EkcD20uJ8Qw4uE9YNWxdsu0qcCeBS0F2uk1NYa43tv2obvrd4mbJK2zEyB2VuMwXXR5B+hw== X-Gm-Message-State: AOJu0Yy+F6WAZfph9nT39lv0JYiuuOjHWmCoQd7HVsDylMl8JLWrH6ce QX2i3MlMV1Cb17P4Hy/qAJJGWlrXRq7Go+fx6erGyQzgXOIzlFZGgTzeZZIYv8WDxBzfC4/k+mW WeA== X-Google-Smtp-Source: AGHT+IHxpD4UvI3cH5YcMAfSn5X/q5FbzhvcZwiTnoiXfWEKupcq/mKgFqqrl+E4nqq+ftOi/sOAAYuzYXs= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90b:50cf:b0:2c9:61f9:9b27 with SMTP id 98e67ed59e1d1-2cff9526286mr68117a91.5.1722627130434; Fri, 02 Aug 2024 12:32:10 -0700 (PDT) Date: Fri, 2 Aug 2024 12:32:09 -0700 In-Reply-To: Mime-Version: 1.0 References: <20240726235234.228822-1-seanjc@google.com> <20240726235234.228822-65-seanjc@google.com> Message-ID: Subject: Re: [PATCH v12 64/84] KVM: LoongArch: Mark "struct page" pfns dirty only in "slow" page fault path From: Sean Christopherson To: maobibo Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, David Matlack , linux-riscv@lists.infradead.org, Claudio Imbrenda , Marc Zyngier , Janosch Frank , Huacai Chen , Christian Borntraeger , Albert Ou , loongarch@lists.linux.dev, Paul Walmsley , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, Oliver Upton , Palmer Dabbelt , David Stevens , kvm-riscv@lists.infradead.org, Anup Patel , Paolo Bonzini , Tianrui Zhao , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Aug 02, 2024, maobibo wrote: > On 2024/7/27 =E4=B8=8A=E5=8D=887:52, Sean Christopherson wrote: > > Mark pages/folios dirty only the slow page fault path, i.e. only when > > mmu_lock is held and the operation is mmu_notifier-protected, as markin= g a > > page/folio dirty after it has been written back can make some filesyste= ms > > unhappy (backing KVM guests will such filesystem files is uncommon, and > > the race is minuscule, hence the lack of complaints). > >=20 > > See the link below for details. > >=20 > > Link: https://lore.kernel.org/all/cover.1683044162.git.lstoakes@gmail.c= om > > Signed-off-by: Sean Christopherson > > --- > > arch/loongarch/kvm/mmu.c | 18 ++++++++++-------- > > 1 file changed, 10 insertions(+), 8 deletions(-) > >=20 > > diff --git a/arch/loongarch/kvm/mmu.c b/arch/loongarch/kvm/mmu.c > > index 2634a9e8d82c..364dd35e0557 100644 > > --- a/arch/loongarch/kvm/mmu.c > > +++ b/arch/loongarch/kvm/mmu.c > > @@ -608,13 +608,13 @@ static int kvm_map_page_fast(struct kvm_vcpu *vcp= u, unsigned long gpa, bool writ > > if (kvm_pte_young(changed)) > > kvm_set_pfn_accessed(pfn); > > - if (kvm_pte_dirty(changed)) { > > - mark_page_dirty(kvm, gfn); > > - kvm_set_pfn_dirty(pfn); > > - } > > if (page) > > put_page(page); > > } > > + > > + if (kvm_pte_dirty(changed)) > > + mark_page_dirty(kvm, gfn); > > + > > return ret; > > out: > > spin_unlock(&kvm->mmu_lock); > > @@ -915,12 +915,14 @@ static int kvm_map_page(struct kvm_vcpu *vcpu, un= signed long gpa, bool write) > > else > > ++kvm->stat.pages; > > kvm_set_pte(ptep, new_pte); > > - spin_unlock(&kvm->mmu_lock); > > - if (prot_bits & _PAGE_DIRTY) { > > - mark_page_dirty_in_slot(kvm, memslot, gfn); > > + if (writeable) > Is it better to use write or (prot_bits & _PAGE_DIRTY) here? writable is > pte permission from function hva_to_pfn_slow(), write is fault action. Marking folios dirty in the slow/full path basically necessitates marking t= he folio dirty if KVM creates a writable SPTE, as KVM won't mark the folio dir= ty if/when _PAGE_DIRTY is set. Practically speaking, I'm 99.9% certain it doesn't matter. The folio is ma= rked dirty by core MM when the folio is made writable, and cleaning the folio tr= iggers an mmu_notifier invalidation. I.e. if the page is mapped writable in KVM's stage-2 PTEs, then its folio has already been marked dirty.