From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793037953; b=PtnnrmW+mcy2YoYJAyWENL7uZb/h6gUL0UhodSf3iS5YOnv4H1AMwEytSjTbL/7GXyM7 VLXz46IbHDq02LjDQ/1B7QaaX/a5OeJydwaFCLX9t7N2Uwhb9nP5vdxYSOk3IS9FkEy0X n4Kc/H3T2tTnH2yn5HhKaIe1OqogvoqddL7j/+j4+yjhCRz0uTFZI/DBgbI+waUxbyIoh Mw9Mx4w500/AD61KMFoJtF3QBPEPT+Aqcq5nu8/MxVdADGQVeP1rTdyYR03ZY9s7/pcpf gCUdIdsjIgWLp9BTKz7U1p9R5Mm+2wsaNaI6UejTGTfYCZ/MrYok/gGhNEyvmicxs5g== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793037953; h=DMARC-Filter:Received:Received:DKIM-Signature:From:To:Cc:Subject: Date:Message-ID:X-Mailer:In-Reply-To:References:MIME-Version: Content-Type:Content-Disposition:Content-Transfer-Encoding; bh=Dazdfuswvplzd+nZxkdJ2Trb6gBuPhP20O43N/pReRw=; b=yfW6kNMSSbjV1JIDbakCHJJKdOq/eSYIc0dk0yc98KDF7Fy12IdGq985MV2rag0XYNaF iNqGUVw+k5s4/3rCkebrdFF7VtlqLWvVOewYBLk9++ydb7kFLZ1vBrIbBk3CPsxTm7KLy p23XVy3D82phWw+4BDCwBt8DLNqiMGtLf3lQdBs9OWloh99Gi4Il9RWEvWmjoc3K+sJtU MDK0xsdm7dJ572nRriFunnN7Y9ydiJy5UUeWD/jgGK5z8rZNTV8U3VLC9qd4VHWVrZxuV mYWwRjDTEeTRLdRjO0xT0kBsFTDdkRtPXIfnrjSSbv7IRugRsu9AZIG3GbQapnPzGYQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=foss header.b=oiB7p4FK; arc=none smtp.remote-ip=217.140.110.172 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A3E30606A31D; Mon, 26 Oct 2026 18:05:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org A3E30606A31D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=foss header.b=oiB7p4FK Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7783D19F6; Mon, 26 Oct 2026 11:05:47 -0700 (PDT) Received: from LeoBrasDK.cambridge.arm.com (LeoBrasDK.cambridge.arm.com [10.2.212.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E9D403F7B4; Mon, 26 Oct 2026 11:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1793037950; bh=0Fm//jObvS8Sn73p6wEdeeyE1A5W+WdjYk5R853HCAU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oiB7p4FKmQfYPhak2KyREhmAxzj21VR9bO/7IkVcr4vAhuyPU4BxeGZVArbjZCBEd 7nzK9K8tzkV9r//ANLZIfuLWdMzOrAyY3poD5DzLJ8uSGtE5kCj10S9IqZQr1/eDt6 WhdNQVWRU4yJS35XoSMSRo4NhGpvYUfZQjEkElRo= From: Leonardo Bras To: Tian Zheng Cc: Leonardo Bras , maz@kernel.org, oupton@kernel.org, catalin.marinas@arm.com, will@kernel.org, corbet@lwn.net, pbonzini@redhat.com, yuzenghui@huawei.com, wangzhou1@hisilicon.com, yangjinqian1@huawei.com, caijian11@h-partners.com, liuyonglong@huawei.com, tangchengchang@huawei.com, yezhenyu2@huawei.com, yubihong@huawei.com, linuxarm@huawei.com, joey.gouly@arm.com, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, seiden@linux.ibm.com, suzuki.poulose@arm.com, fuad.tabba@linux.dev, mark.rutland@arm.com, seanjc@google.com, rdunlap@infradead.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, skhan@linuxfoundation.org Subject: Re: [PATCH v5 05/15] KVM: arm64: Harvest stage-2 dirty state into the host folio account Date: Mon, 26 Oct 2026 18:05:38 +0000 Message-ID: X-Mailer: git-send-email 2.56.0 In-Reply-To: <20260929103655.85107-6-zhengtian10@huawei.com> References: <20260929103655.85107-1-zhengtian10@huawei.com> <20260929103655.85107-6-zhengtian10@huawei.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi Tian, Sorry for the delay in reviewing... On Tue, Sep 29, 2026 at 06:36:45PM +0800, Tian Zheng wrote: > With VTCR_EL2.HD set, hardware promotes writable-clean descriptors to > writable-dirty without any VM exit, and the only record of the write > is the S2AP[1] bit in the stage-2 PTE. The write never passed through > the host stage-1, and no unmap path reads the bit, so the record dies > with the PTE and reclaim may discard written guest data (silent > corruption). Sorry, I didn't get what you are trying to achieve here. On your patch, I see you marking backing pages dirty at wrprotect and unmap walkers, and it's very confusing to me on why you are doing this. IIUC, what you are trying to do is make sure a page does not lose it's contents in case it is reclaimed by the OS. IIUC, when a page is reclaimed, it will unmap the S2 PTE, and save it's contents to swap, so when the guest read or write to that page will cause it to fault. The page can never be just unmaped, as if there was a single write to it, the backing pages should be writable, and the contents need to be saved somewhere. So, if I was able to understand your suggestion, we don't need to worry about this, and this patch wouldn't be necessary. Did you hit this issue? Can you please expand on your issue, if I could not describe it above? Thanks! Leo