From: Yuho Choi <oss.patchbox@gmail.com>
To: Wei Liu <wei.liu@kernel.org>,
Haiyang Zhang <haiyangz@microsoft.com>,
Dexuan Cui <decui@microsoft.com>,
Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Cc: Nuno Das Neves <nunodasneves@linux.microsoft.com>,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
Yuho Choi <oss.patchbox@gmail.com>
Subject: [Question] mshv: unpopulated parts of a movable region after removal
Date: Thu, 12 Nov 2026 14:23:38 -0500 [thread overview]
Message-ID: <20261112192341.1412177-2-oss.patchbox@gmail.com> (raw)
Hi,
I have a question about how a movable memory region is unmapped when it
is removed (mainline 067c5c24cef2), and would appreciate your view.
When a movable region is created, mshv_map_user_memory() maps its whole
GPA range with HV_MAP_GPA_NO_ACCESS. mshv_region_range_fault() later
fills in the page array and remaps the faulted pages with access, and
mshv_region_interval_invalidate() remaps invalidated pages with no
access again and clears their entries in the page array.
When the region is destroyed, mshv_region_destroy() calls
mshv_region_unmap(), which goes through mshv_region_process_range().
That walk skips the entries that have no page, so only the parts that
currently have pages are unmapped. The parts that were never faulted in,
or were invalidated, are not unmapped. Before commit abceb4297bf8
("mshv: Fix huge page handling in memory region traversal"), the whole
GPA range was unmapped with one hv_call_unmap_gpa_pages() call.
If I read this correctly, the hypervisor keeps those GPAs mapped with no
access after the region is removed. A guest access to them would then
come back as HVMSG_GPA_INTERCEPT rather than HVMSG_UNMAPPED_GPA, and the
mappings would stay until the GPAs are mapped again or the partition is
destroyed.
Is this intended, for example because the hypervisor treats a no-access
mapping like an unmapped GPA? Or should mshv_region_destroy() unmap
these parts as well? If so, does the unmap need to follow how they were
mapped: 4K pages when the region is created, and large pages when an
invalidated range covered a huge page?
I found this during in-house security research and have not reproduced it.
Thanks,
Yuho
reply other threads:[~2026-11-12 19:23 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261112192341.1412177-2-oss.patchbox@gmail.com \
--to=oss.patchbox@gmail.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nunodasneves@linux.microsoft.com \
--cc=skinsburskii@linux.microsoft.com \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®