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