Re: [PATCH v3 23/23] doc/arm: vIOMMU design document

> +Performance Impact
> +==================
> +
> +With iommu stage-1 and nested translation inclusion, performance
> +overhead is introduced comparing to existing,
> +stage-2 only usage in Xen. Once mappings are established, translations
> +should not introduce significant overhead.
> +Emulated paths may introduce moderate overhead, primarily affecting
> +device initialization and event/command handling.
> +Testing is performed on Renesas R-Car platform.

Hi Milan,

I tested this series on a TI platform. I was not able to get the DMA 
test inside a DOM1 guest

to work with nested virtualization.


On the top level, my changes are:

- Enabled CONFIG_VIRTUAL_IOMMU and CONFIG_VIRTUAL_ARM_SMMU_V3 in Xen

- Added viommu=true in xen-bootargs

- Added a "smmu" node in my DOM1 passthrough node, so that it can be 
replaced by the viommu.

- Added "iommus" for my DMA controller.


I can see that the smmuv3 is probed successfully inside of DOM1 and my 
dma-controller is added to the iommu group.

""

[    0.161594] arm-smmu-v3 4040000.iommu: probing device
[    0.162067] arm-smmu-v3 4040000.iommu: ias 48-bit, oas 48-bit 
(features 0x0000020d)
[    0.162993] arm-smmu-v3 4040000.iommu: allocated 65536 entries for cmdq
[    0.163730] arm-smmu-v3 4040000.iommu: allocated 32768 entries for evtq
[    0.164281] arm_smmu_device_reset
[    0.164559] ARM_SMMU_GBPA reg = 0
[    0.164924] smmu->evtq.q.q_base = 45a0000f
[    0.165609] platform 30100000.dma-controller: Adding to iommu group 0

""


Did you have any changes in the kernel tree as well?

Could you provide the testing setup that you used?


Best Regards,

Abhash