On 18.02.2026 15:38, Oleksii Kurochko wrote:
> On 2/18/26 2:12 PM, Jan Beulich wrote:
>> On 18.02.2026 13:58, Oleksii Kurochko wrote:
>>> On 2/17/26 8:34 AM, Jan Beulich wrote:
>>>> On 16.02.2026 19:42, Stefano Stabellini wrote:
>>>>> On Mon, 16 Feb 2026, Jan Beulich wrote:
>>>>>> On 12.02.2026 17:21, Oleksii Kurochko wrote:
>>>>>>> domain_use_host_layout() is generic enough to be moved to the
>>>>>>> common header xen/domain.h.
>>>>>> Maybe, but then something DT-specific, not xen/domain.h. Specifically,
>>>>>> ...
>>>>>>
>>>>>>> --- a/xen/include/xen/domain.h
>>>>>>> +++ b/xen/include/xen/domain.h
>>>>>>> @@ -62,6 +62,22 @@ void domid_free(domid_t domid);
>>>>>>> #define is_domain_direct_mapped(d) ((d)->cdf & CDF_directmap)
>>>>>>> #define is_domain_using_staticmem(d) ((d)->cdf & CDF_staticmem)
>>>>>>>
>>>>>>> +/*
>>>>>>> + * Is the domain using the host memory layout?
>>>>>>> + *
>>>>>>> + * Direct-mapped domain will always have the RAM mapped with GFN ==
>>>>>>> MFN.
>>>>>>> + * To avoid any trouble finding space, it is easier to force using the
>>>>>>> + * host memory layout.
>>>>>>> + *
>>>>>>> + * The hardware domain will use the host layout regardless of
>>>>>>> + * direct-mapped because some OS may rely on a specific address ranges
>>>>>>> + * for the devices.
>>>>>>> + */
>>>>>>> +#ifndef domain_use_host_layout
>>>>>>> +# define domain_use_host_layout(d) (is_domain_direct_mapped(d) || \
>>>>>>> + is_hardware_domain(d))
>>>>>> ... is_domain_direct_mapped() isn't something that I'd like to see
>>>>>> further
>>>>>> proliferate in common (non-DT) code.
>>>>> Hi Jan, we have a requirement for 1:1 mapped Dom0 (I should say hardware
>>>>> domain) on x86 as well. In fact, we already have a working prototype,
>>>>> although it is not suitable for upstream yet.
>>>>>
>>>>> In addition to the PSP use case that we discussed a few months ago,
>>>>> where the PSP is not behind an IOMMU and therefore exchanged addresses
>>>>> must be 1:1 mapped, we also have a new use case. We are running the full
>>>>> Xen-based automotive stack on an Azure instance where SVM (vmentry and
>>>>> vmexit) is available, but an IOMMU is not present. All virtual machines
>>>>> are configured as PVH.
>>>> Hmm. Then adjustments need making, for commentary and macro to be correct
>>>> on x86. First and foremost none of what is there is true for PV.
>>> As is_domain_direct_mapped() returns always false for x86, so
>>> domain_use_host_layout macro will return incorrect value for non-hardware
>>> domains (dom0?). And as PV domains are not auto_translated domains so are
>>> always direct-mapped, so technically is_domain_direct_mapped() (or
>>> domain_use_host_layout()) should return true in such case.
>> Hmm? PV domains aren't direct-mapped. Direct-map was introduced by Arm for
>> some special purpose (absence of IOMMU iirc).
>
> I made such conclusion because of the comments in the code mentioned below:
> -
> https://elixir.bootlin.com/xen/v4.21.0/source/tools/libs/guest/xg_dom_x86.c#L1880
> -
> https://elixir.bootlin.com/xen/v4.21.0/source/xen/include/public/features.h#L107
>
> Also, in the comment where it is introduced (d66bf122c0a "xen: introduce
> XENFEAT_direct_mapped and XENFEAT_not_direct_mapped")
> is mentioned that:
> XENFEAT_direct_mapped is always set for not auto-translated guests.
Hmm, this you're right with, and XENVER_get_features handling indeed has
if ( !paging_mode_translate(d) || is_domain_direct_mapped(d) )
fi.submap |= (1U << XENFEAT_direct_mapped);
Which now I have a vague recollection of not having been happy with back at
the time. Based solely on the GFN == MFN statement this may be correct, but
"GFN" is a questionable term for PV in the first place. See how e.g.
common/memory.c resorts to using GPFN and GMFN, in line with commentary in
public/memory.h.
What the above demonstrates quite well though is that there's no direct
relationship between XENFEAT_direct_mapped and is_domain_direct_mapped().
>>> (I assume it is also true for every domain except HVM according to the
>>> comment
>>> /* HVM guests are translated. PV guests are not. */ in xc_dom_translated
>>> and
>>> the comment above definition of XENFEAT_direct_mapped: /* ...not
>>> auto_translated
>>> domains (x86 only) are always direct-mapped*/).
>>>
>>> Is my understanding correct?
>>>
>>> Then isn't that a problem of how is_domain_direct_mapped() is defined
>>> for x86? Shouldn't it be defined like:
>>> #define is_domain_direct_mapped(d) (!paging_mode_translate(d) ||
>>> ((d)->cdf & CDF_directmap))
>>>
>>> Would it be better to move "!paging_mode_translate(d) || " to the definition
>>> of domain_use_host_layout()?
>>>
>>> Could you please explain what is wrong with the comment? Probably, except:
>>> * To avoid any trouble finding space, it is easier to force using the
>>> * host memory layout.
>>> everything else should be true for x86.
>> "The hardware domain will use ..." isn't true for PV Dom0.
>
> And then just pure is_hardware_domain(d) inside macros isn't correct too,
> right?
> So it should be (... || (!is_pv_domain(d) && is_hardware_domain(d)))
Stefano, please can you guide Oleksii to put there something which is both
correct and will cover your intended use case as well?
Jan
