Re: [PATCH] x86/altp2m: altp2m_get_effective_entry() should honor ap2m->default_access

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.01.2026 19:28, Petr Beneš wrote:
> From: Petr Beneš <w1benny@xxxxxxxxx>
> 
> Commit 7e5b662 fixed p2m_altp2m_get_or_propagate() to use the altp2m's
> default_access when propagating entries from the host p2m. However, the same
> fix was not applied to altp2m_get_effective_entry(), which has the same issue.
> 
> When altp2m_get_effective_entry() prepopulates a superpage from the host
> p2m, it incorrectly uses the host p2m's access permissions instead of
> the altp2m's default_access. This causes problems when the superpage is
> later split (e.g., when setting mem_access on a specific 4K page): all
> 512 entries inherit the host p2m's access rights instead of the altp2m's
> default_access.
> 
> This issue became apparent after commit 50baf2d, which causes the host p2m
> to use superpages more frequently. Before that commit, the host p2m
> typically had 4K entries after VM restore, so the prepopulate branch was
> rarely taken.
> 
> Symptoms include memory-access events firing for unexpected pages when
> using VMI tools with altp2m, particularly after VM resume.
> The issue can be worked around by booting with "hap_1gb=0 hap_2mb=0".
> 
> Fixes: 7e5b662 ("x86/altp2m: p2m_altp2m_get_or_propagate() should honor 
> ap2m->default_access")

You didn't even Cc Tamas, who I think once again will need to ack this.
Already with the referenced change I didn't quite understand the
reasoning.

However, two formal points: Please use 12-digit hashes, as demanded by
sending-patches.pandoc. Plus I don't think Fixes: is quite right here.
That earlier change of yours didn't mean to do more than it did, by its
title and description. We relatively recently introduced Amends:, which
may be a suitable fit here.

Jan