Re: [PATCH v5 05/15] KVM: arm64: Harvest stage-2 dirty state into the host folio account

[Tian Zheng <zhengtian10@huawei.com>]

On 10/30/2026 8:24 PM, Leonardo Bras wrote:
> On Thu, Oct 29, 2026 at 10:02:10PM +0800, Tian Zheng wrote:
>>
>>
>> On 10/27/2026 2:05 AM, Leonardo Bras wrote:
>>> 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
>>
>> Hi Leo,
>>
>> Thanks for the review. I haven't hit this in practice, and based on your
>> analysis the patch doesn't look necessary.
>>
>> Reclaim only writes back folios whose PG_dirty flag is set; a clean
>> folio is simply freed. A stage-2 write never touches the host
>> stage-1, so the folio depends entirely on kvm_release_faultin_page()
>> at fault-in to be marked as dirty; without it, the page stays clean from
>> the host's perspective and reclaim drops the data.
>>
> 
> Oh, okay. IIUC it will be enough if PG_dirty flag is set once, right?
> 
> While on HAFDBS/HDBSS we will skip the fault for marking them dirty again,
> we always take the first fault for every PTE (or prefault them), so
> PG_dirty should always be set once the page is first wroten to.
> 
> 
>> Your **RFC v1** patch 2 changed that marking from writable to dirty:
>>
>> ```
>> - kvm_release_faultin_page(kvm, s2vi->page, !!ret, writable);
>> + kvm_release_faultin_page(kvm, s2vi->page, !!ret, dirty);
>> ```
>>
>> During logging, a read fault maps the page as WC: the folio is not
>> marked PG_dirty in kvm_s2_fault_map() and hardware promotes the PTE to
>> WD on write without any fault, so reclaim frees the page without saving
>> it (the folio was treated as clean).
> 
> Ah, I see your point.
> During dirty-tracking guest reads a page, then HAFDBS promotes it to
> writable without marking it as dirty. Good catch!
> 
> But wouldn't a simpler solution be to change the conditions in the fault
> handler, so that it indeed marks it as dirty if dirty-tracking is on, even
> if it's just a read fault?
> 
> Thanks!
> Leo
> 
Hi Leo,

Yes, that's exactly the simpler fix, and it's what I already did in
HDBSS v5 patch 2 — the folio is marked dirty for any write-permitting
mapping, so a read fault on a tracked memslot also marks it.

Since patch 2 covers this, patch 5 isn't needed. I'll drop it in the 
next version.

Thanks,
Tian

>>
>> Therefore, **HDBSS v5** patch 2 reverted to marking the folio for any
>> write-permitting mapping:
>>
>> ```
>> kvm_release_faultin_page(kvm, s2vi->page, !!ret, writable);
>> ```
>>
>> Together with the v5 scheme, this makes patch 5 unnecessary:
>>
>> - kvm_s2_fault_compute_prot: always set PROT_W when map_writable
>> - stage2_set_prot_attr: PROT_W -> DBM unconditionally
>>
>>
>> ---------
>>
>> On a related note, I'd like to discuss the next version of the DBM
>> scheme, following Oliver's suggestion [1].
> 
> Just as a note for future readers: on another thread we agreed to wait for
> the discussion to reach a point we are all happy before rebasing
> everything.