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