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