Re: [PATCH v4] drivers/hv: remove deposited pages from direct map

[Wei Liu]

On Wed, Oct 28, 2026 at 07:44:14PM +0100, Thorsten Leemhuis wrote:
> On 10/28/26 19:31, Wei Liu wrote:
> > On Wed, Oct 28, 2026 at 07:28:15PM +0100, Thorsten Leemhuis wrote:
> >> On 9/30/26 14:10, Magnus Kulke wrote:
> >>> hv_call_deposit_pages() donates pages (deposit) to hypervisor for L2
> >>> guest on L1VH systems via HVCALL_DEPOSIT_MEMORY. The hypervisor takes
> >>> ownership of those pages and per contract revokes root partition
> >>> access to them, raising a #GP on access from the L1VH root partition.
> >>>
> >>> However, the pages remain mapped in the kernel direct map, so kernel
> >>> code may still access them even though the hypervisor has revoked
> >>> access.
> >>
> >> Wei, Magnus, this patch showed up in -next today and broke my daily
> >> Fedora builds on x86_64 and arm64 which use the rawhide config as base.
> >> Reverting it made the build succeed.
> > 
> > Can you share the kconfig?
> 
> Sadly can't access it directly, but it should be the attached one after
> running it through "make olddefconfig".
> 
> Ciao, Thorsten
> 
> >> """
> >>> drivers/hv/hv_proc.c: In function ‘hv_deposit_update_direct_map’:
> >>> drivers/hv/hv_proc.c:32:23: error: implicit declaration of function ‘set_direct_map_valid_noflush’; did you mean ‘set_direct_map_invalid_noflush’? [-Wimplicit-function-declaration]
> >>>    32 |                 err = set_direct_map_valid_noflush(pfn_to_page(pfns[i]),
> >>>       |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>>       |                       set_direct_map_invalid_noflush

I didn't end up building the kernel. I see why by purely inspecting the
linux-next tree.

That function was removed by Mike Rapoport in 37fb25b34cd92.

I will rework this in my branch -- we should follow what MM tree does.
Hopefully it will be a straightforward change.

Thanks for your report.

Wei

======

commit 37fb25b34cd9273cb987b80a46a13a1e3f0a534f
Author:     Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
AuthorDate: Thu Sep 3 12:28:32 2026 +0300
Commit:     Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
CommitDate: Thu Sep 10 20:20:09 2026 -0700

    Revert "arch: introduce set_direct_map_valid_noflush()"

    Commit 0c6378a71574 ("arch: introduce set_direct_map_valid_noflush()")
    added set_direct_map_valid_noflush() to allow updating the direct map for
    a physically contiguous range in execmem.

    As Brendan recently pointed out [1], this API is confusing because on
    arm64 it means that is sets VALID bit in ptes, while on other
    architectures it is an analog of set_direct_map_default_noflush().

    The only user of set_direct_map_valid_noflush() was execmem's ROX cache
    freeing path and it was switched to utilize VM_FLUSH_RESET_PERMS for
    resetting permissions of the direct map alias.

    With the last user gone and with
    set_direct_map_{invalid,default}_noflush() accepting number of pages as a
    parameter, set_direct_map_valid_noflush() become a copy of
    set_memory_valid() on arm64 and a duplicate of
    set_direct_map_{invalid,default}_noflush() on other architecture, it is
    safe to remove set_direct_map_valid_noflush().

    Also drop a stale comment in arm64::__kernel_map_pages() that Linus
    bothered to add when merging changes containing
    set_direct_map_valid_noflush() to his tree.

    This reverts commit 0c6378a71574daa6cd1534ad42a956e3262756c7.