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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.01.2026 12:24, Jan Beulich wrote:
> 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:?

Having thought about this some more, would Complements: or Supplements:
possibly better suit you?

Jan