Re: [PATCH 12/24] x86/mm: get_page_from_l1e() is PV-or-shadow-only

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.08.2026 13:51, Daniel P. Smith wrote:
> On 8/3/26 6:11 AM, Jan Beulich wrote:
>> On 02.08.2026 17:55, Daniel P. Smith wrote:
>>> On 7/28/26 9:18 AM, Jan Beulich wrote:
>>>> Otherwise the function is unreachable, violating MISRA C:2012 rule 2.1.
>>>> With the function compiled out, its dedicated XSM hook also becomes
>>>> unreachable, so it is similarly guarded.
>>>>
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>> ---
>>>> It feels suspicious that the .priv_mapping() check is used for HVM guests
>>>> in shadow mode, but not for ones in HAP mode.
>>>
>>> I believe a hint to it is laying in the comment,
>>>
>>>    /*
>>>     * Let privileged domains transfer the right to map their target
>>>     * domain's pages. This is used to allow stub-domain pvfb export to
>>>     * dom0, until pvfb supports granted mappings. At that time this
>>>     * minor hack can go away.
>>>     */
>>>
>>> Correct me if I am wrong, but get_page_from_l1e() is only used by PV and
>>> HVM + Shadow. When in HVM + HAP is mapping a guest page, it is done
>>> through p2m_get_foreign() which will then be covered by
>>> xsm_map_gmfn_foreign(). So only HVM + Shadow can hit TARGET_HACK check.
>>
>> Yes, sure; that wasn't the point of my comment. The point was that I'd
>> expect _the same_ hook to be used by the other path. Aiui if you make a
>> policy, you want same situations dealt with the same. Hence there shouldn't
>> be a need to express the same thing two ways.
> 
> But it's not the same, the enforcement mechanism is different. FLASK is 
> an evaluation of Subject/Object/Predicate. In this case the mechanism 
> (software enforced access) that provides the Predicate has enough risk 
> that it warranted itself a separate check to allow fine grained 
> assignment of the operation to a specific domain which was driven by a 
> specific use case.

I don't understand this. What mode a guest is run in (HAP vs shadow)
shouldn't affect what permissions it has. Two distinct hooks means the
guest might change behavior when flipped between hap=0 and hap=1. Which
absolutely shouldn't happen, imo.

>>> I think the question is how to address the TARGET_HACK situation.
>>
>> I fear I don't really know what exactly you mean here.
> 
> Is this path still needed for the pvfb or is it now in use by other use 
> cases. If the former, then close the ability otherwise TARGET_HACK 
> should be renamed to something sensible for general case. Some code 
> documentation might be necessary to help understand why/

Only after grep-ing it has become apparent that TARGET_HACK is something
in Flask. It's entirely invisible outside of Flask, e.g. at the call site
of the hook.

I think the comment is stale in referencing only pvfb, but I'm not really
sure. It is too long ago that I last saw the log message issued there,
and hence I don't recall under what (buggy guest?) conditions it could
surface.

Jan