This is one draft design about the infrastructure for now, not ready for upstream yet (hence the RFC tag), thought it'd be useful to firstly start a discussion with the community.
Create one design doc for 1:1 direct-map. It aims to describe why and how we allocate 1:1 direct-map(guest physical == physical) domains. This document is partly based on Stefano Stabellini's patch serie v1: [direct-map DomUs]( https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg00707.html). Signed-off-by: Penny Zheng <[email protected]> --- For the part regarding allocating 1:1 direct-map domains with user-defined memory regions, it will be included in next design of static memory allocation. --- docs/designs/1_1_direct-map.md | 87 ++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 docs/designs/1_1_direct-map.md diff --git a/docs/designs/1_1_direct-map.md b/docs/designs/1_1_direct-map.md new file mode 100644 index 0000000000..ce3e2c77fd --- /dev/null +++ b/docs/designs/1_1_direct-map.md @@ -0,0 +1,87 @@ +# Preface + +The document is an early draft for direct-map memory map +(`guest physical == physical`) of domUs. And right now, it constrains to ARM +architecture. + +It aims to describe why and how the guest would be created as direct-map domain. + +This document is partly based on Stefano Stabellini's patch serie v1: +[direct-map DomUs]( +https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg00707.html). + +This is a first draft and some questions are still unanswered. When this is the +case, the text shall contain XXX. + +# Introduction + +## Background + +Cases where domU needs direct-map memory map: + + * IOMMU not present in the system. + * IOMMU disabled, since it doesn't cover a specific device. + * IOMMU disabled, since it doesn't have enough bandwidth. + * IOMMU disabled, since it adds too much latency. + +*WARNING: +Users should be careful that it is not always secure to assign a device without +IOMMU/SMMU protection. +Users must be aware of this risk, that guests having access to hardware with +DMA capacity must be trusted, or it could use the DMA engine to access any +other memory area. +Guests could use additional security hardware component like NOC, System MPU +to protect the memory. + +## Design + +The implementation may cover following aspects: + +### Native Address and IRQ numbers for GIC and UART(vPL011) + +Today, fixed addresses and IRQ numbers are used to map GIC and UART(vPL011) +in DomUs. And it may cause potential clash on direct-map domains. +So, Using native addresses and irq numbers for GIC, UART(vPL011), in +direct-map domains is necessary. +e.g. +For the virtual interrupt of vPL011: instead of always using `GUEST_VPL011_SPI`, +try to reuse the physical SPI number if possible. + +### Device tree option: `direct_map` + +Introduce a new device tree option `direct_map` for direct-map domains. +Then, when users try to allocate one direct-map domain(except DOM0), +`direct-map` property needs to be added under the appropriate `/chosen/domUx`. + + + chosen { + ... + domU1 { + compatible = "xen, domain"; + #address-cells = <0x2>; + #size-cells = <0x1>; + direct-map; + ... + }; + ... + }; + +If users are using imagebuilder, they can add to boot.source something like the +following: + + fdt set /chosen/domU1 direct-map + +Users could also use `xl` to create direct-map domains, just use the following +config option: `direct-map=true` + +### direct-map guest memory allocation + +Func `allocate_memory_direct_map` is based on `allocate_memory_11`, and shall +be refined to allocate memory for all direct-map domains, including DOM0. +Roughly speaking, firstly, it tries to allocate arbitrary memory chunk of +requested size from domain sub-allocator(`alloc_domheap_pages`). If fail, +split the chunk into halves, and re-try, until it succeed or bail out with the +smallest chunk size. +Then, `insert_11_bank` shall insert above allocated pages into a memory bank, +which are ordered by address, and also set up guest P2M mapping( +`guest_physmap_add_page`) to ensure `gfn == mfn`. -- 2.25.1
