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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.01.2026 12:18, Andrew Cooper wrote:
> On 12/01/2026 11:09 am, Jan Beulich wrote:
>> 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.
> 
> I beg your pardon?  Fixes are and Amends are synonyms.

This is news to me. To me a "fix" addresses a bug in the referenced commit.
Whereas making a related change which isn't strictly a bugfix to the
referenced earlier change is what Amends: was introduced for. If both were
synonyms, why would you not have objected to the introduction of Amends:?

>  You cannot use
> them like this, and you absolutely cannot expect contributors to know
> your personal interpretation of the words.

"My personal interpretation of the words" has become the community's with
the committing of the change introducing Amends:. And I think I can expect
contributors to read sending-patches.pandoc?

Jan