Re: [PATCH v1 5/6] xen: move domain_use_host_layout() to common header

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

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.

> > (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)))

~ Oleksii