[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH v2 0/6] direct-map memory map
Cases where domU needs direct-map memory map: * IOMMU not present in the system. * IOMMU disabled if it doesn't cover a specific device and all the guests are trusted. Thinking a mixed scenario, where a few devices with IOMMU and a few without, then guest DMA security still could not be totally guaranteed. So users may want to disable the IOMMU, to at least gain some performance improvement from IOMMU disabled. * IOMMU disabled as a workaround when it doesn't have enough bandwidth. To be specific, in a few extreme situation, when multiple devices do DMA concurrently, these requests may exceed IOMMU's transmission capacity. * IOMMU disabled when it adds too much latency on DMA. For example, TLB may be missing in some IOMMU hardware, which may bring latency in DMA progress, so users may want to disable it in some realtime scenario. *WARNING: Users should be aware that it is not always secure to assign a DMA-capable device without IOMMU protection. When the device is not protected by the IOMMU, the administrator should make sure that: 1. The device is assigned to a trusted guest. 2. Users have additional security mechanism on the platform. Requesting direct-map memory mapping for the domain, when IOMMU is absent from the system or it is disabled (status = "disabled" in device tree), In which case, "direct-map" property is added under the appropriate domain node. Right now, direct-map is only supported when domain on Static Allocation, that is, "xen,static-mem" is also necessary in the domain configuration. Looking into related [design link]( https://lists.xenproject.org/archives/html/xen-devel/2021-05/msg00882.html) for more details. The whole design is about Static Allocation and direct-map, and this Patch Serie only covers parts of it, which are direct-map memory map. Other features will be delievered through different patch series. See https://lists.xenproject.org/archives/html/xen-devel/2021-09/msg00855.html for Domain on Static Allocation. This patch serie is based on https://lists.xenproject.org/archives/html/xen-devel/2021-10/msg00822.html --- v2 changes: - remove the introduce of internal flag - Refine is_domain_direct_mapped to check whether the flag XEN_DOMCTL_CDF_directmap is set - reword "1:1 direct-map" to just "direct-map" - split the common codes into two helpers: parse_static_mem_prop and acquire_static_memory_bank to deduce complexity. - introduce a new helper allocate_static_memory_11 for allocating static memory for direct-map guests - remove panic action since it is fine to assign a non-DMA capable device when IOMMU and direct-map both off - remove redistributor accessor - introduce new helper "is_domain_use_host_layout()" - explain why vpl011 initialization before creating its device tree node - error out if the domain is direct-mapped and the IRQ is not found - harden the code and add a check/comment when the hardware UART region is smaller than CUEST_VPL011_SIZE. Stefano Stabellini (6): xen: introduce XEN_DOMCTL_CDF_directmap xen/arm: introduce direct-map for domUs xen/arm: if direct-map domain use native addresses for GICv2 xen/arm: if direct-map domain use native addresses for GICv3 xen/arm: if direct-map domain use native UART address and IRQ number for vPL011 xen/docs: add a document to explain how to do passthrough without IOMMU docs/misc/arm/device-tree/booting.txt | 10 + docs/misc/arm/passthrough-noiommu.txt | 54 +++++ xen/arch/arm/domain.c | 3 +- xen/arch/arm/domain_build.c | 316 ++++++++++++++++++++------ xen/arch/arm/vgic-v2.c | 26 ++- xen/arch/arm/vgic-v3.c | 20 +- xen/arch/arm/vgic/vgic-v2.c | 27 ++- xen/arch/arm/vpl011.c | 54 ++++- xen/common/domain.c | 3 +- xen/include/asm-arm/domain.h | 7 +- xen/include/asm-arm/new_vgic.h | 10 + xen/include/asm-arm/vgic.h | 12 +- xen/include/asm-arm/vpl011.h | 2 + xen/include/public/domctl.h | 4 +- 14 files changed, 449 insertions(+), 99 deletions(-) create mode 100644 docs/misc/arm/passthrough-noiommu.txt -- 2.25.1
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |