In IOMMU-capable system hypervisor usually takes over IOMMU control. Generally guest domains don't need to care about IOMMU management and take any extra actions. Yet in some cases a knowledge about which device is protected may be useful for privileged domain. In compliance with iommu bindings this can be achieved with device-level iommus property specified with dummy Xen iommu device. Signed-off-by: Sergiy Kibrik <Sergiy_Kibrik@xxxxxxxx> --- Documentation/devicetree/bindings/arm/xen.txt | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt index db5c56db30ec..98efa95c0d1b 100644 --- a/Documentation/devicetree/bindings/arm/xen.txt +++ b/Documentation/devicetree/bindings/arm/xen.txt @@ -58,3 +58,29 @@ Documentation/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. + +* XEN IOMMU device + +In compliance with iommu bindings Xen virtual IOMMU device node represents +hypervisor-managed IOMMU [1]. Platform devices specified as IOMMU masters of +this xen-iommu device are protected by hypervisor-managed platform IOMMU. + +Required properties: + +- compatible: Should be "xen,iommu-el2-v1" +- #iommu-cells: must be 0 + +Example: + +xen-iommu { + compatible = "xen,iommu-el2-v1"; + #iommu-cells = <0>; +}; + +video@fe001000 { + ... + /* this platform device is IOMMU-protected by hypervisor */ + iommus = <&xen-iommu 0x0>; +}; + +[1] Documentation/devicetree/bindings/iommu/iommu.txt -- 2.25.1
