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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

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.

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

~ Oleksii