On Mon, 2026-06-15 at 10:16 +1000, Balbir Singh wrote: > On Thu, Jun 11, 2026 at 09:11:00AM +0530, Aboorva Devarajan wrote: > > From: Sayali Patil <[email protected]> > > > > The HMM compound testcase currently assumes only PMD-level mappings and > > fails on systems where default_hugepagesz=1G is set, because the region > > is then reported by the device at PUD level. > > > > Determine the mapping level (PMD or PUD) the device reports for the first > > page of the range and require every page to match that level exactly via > > ASSERT_EQ(). This accepts PUD-level mappings while preserving the > > expected/observed protection values printed on failure, and rejects a > > fragmented mapping that mixes PMD- and PUD-level entries within the same > > range (which a per-page OR check would have let pass). > > > > PUD is not supported with zone device private folios, the fix should > be really around default_huge_page_size(), using the default pmd size. > > Balbir
Thanks Balbir for the review. IIUC, PUD not-supported restriction applies to the migration path (device-private folios top out at PMD), which the migrate_* tests cover but compound is purely a snapshot of the CPU page tables, where a 1G hugetlb page can shows up at PUD. I guess HMM_DMIRROR_PROT_PUD was in fact added in e478425bec93 (the same commit this patch Fixes:) to express PUD-sized snapshot entries, so handling it here is using the bit for its original purpose. I verified the v3 patch passes on a default_hugepagesz=1G boot (m[i] == WRITE|PUD), and fails without it. But if you'd still prefer to keep this test-case strictly PMD-only, please let us know. Regards, Aboorva
