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
