Documentation/devicetree/bindings/arm/xen.txt
Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/arm/xen.txt
File Facts
- System
- Linux kernel
- Corpus path
Documentation/devicetree/bindings/arm/xen.txt- Extension
.txt- Size
- 2953 bytes
- Lines
- 63
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
Xen ARM virtual platforms shall have a top-level "hypervisor" node with
the following properties:
- compatible:
compatible = "xen,xen-<version>", "xen,xen";
where <version> is the version of the Xen ABI of the platform.
- reg: specifies the base physical address and size of the regions in memory
where the special resources should be mapped to, using an HYPERVISOR_memory_op
hypercall.
Region 0 is reserved for mapping grant table, it must be always present.
The memory region is large enough to map the whole grant table (it is larger
or equal to gnttab_max_grant_frames()).
Regions 1...N are extended regions (unused address space) for mapping foreign
GFNs and grants, they might be absent if there is nothing to expose.
- interrupts: the interrupt used by Xen to inject event notifications.
A GIC node is also required.
To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
under /hypervisor with following parameters:
________________________________________________________________________________
Name | Size | Description
================================================================================
xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
| | Table.
--------------------------------------------------------------------------------
xen,uefi-mmap-start | 64-bit | Guest physical address of the UEFI memory
| | map.
--------------------------------------------------------------------------------
xen,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map
| | pointed to in previous entry.
--------------------------------------------------------------------------------
xen,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI
| | memory map.
--------------------------------------------------------------------------------
xen,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format.
--------------------------------------------------------------------------------
Example (assuming #address-cells = <2> and #size-cells = <2>):
hypervisor {
compatible = "xen,xen-4.3", "xen,xen";
reg = <0 0xb0000000 0 0x20000>;
interrupts = <1 15 0xf08>;
uefi {
xen,uefi-system-table = <0xXXXXXXXX>;
xen,uefi-mmap-start = <0xXXXXXXXX>;
xen,uefi-mmap-size = <0xXXXXXXXX>;
xen,uefi-mmap-desc-size = <0xXXXXXXXX>;
xen,uefi-mmap-desc-ver = <0xXXXXXXXX>;
};
};
The format and meaning of the "xen,uefi-*" parameters are similar to those in
Documentation/arch/arm/uefi.rst, which are provided by the regular UEFI stub. However
they differ because they are provided by the Xen hypervisor, together with a set
of UEFI runtime services implemented via hypercalls, see
http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.