[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: abhash <a-kumar2@xxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Milan Djokic <milan_djokic@xxxxxxxx>
  • Date: Wed, 29 Jul 2026 13:23:56 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=HCs+d5r6l/l0DXBIutJNU2EOOviDvM5NMF+cJAGeEzs=; b=Z8F2OkJvkdjDwaXvYtg1mLMRkiJ3lFZBlRgt1TBSsED47U+2uWRPHS+tmHSyLzFG+oAmpDpqmCuuJfZS70gkA4cm7r+ym5edPMAMlETsucwFkupuprCOcp3vFKydSktHdKORoDjxrwVns7drxmfCd8qXSjuktIl7OXQtf/gOUpMo0Y5mqYuwauimx/LU3qflofd1fpBgQZHKN7WqG3gnunHlKrL9G0+L/8lcU1uBOHsNzlI8/kNMV6i0bEolrsjLTP5nwJNVUAZOUHGKcPdBZwusysjre5umaytUcd6+1PL1ASL+kFLnV75gWIa+YvypJBPzwLIXb0y377a7vJHbiQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=H56pu+WYC0SKcCRXbIlhiCFZ15GEM7McuEQAJPleYyyoMzqNnEsmhgS2ZwUI8SpBaHsgyHbxIcPJisbLQngbVhMJhoCWKFgNgd+CQsZ50SRsBrNzu2AJGG4fjQeo+o/D4IpLWNgC/PVpAxH3/W36i6paXBpTHLt0TqKKQp2fDQHvBOMbEOkVysigJLTxwbqbPzS1Vl1yexaP2YRTirwhLpNa1lrgfytOwEMUN3FMjq2KVkqxvQKDKN5Tr2EbdQ54W+61YT/srPtnRBBAznv0v7356+C+WqtOwyVJNNmv9AM4Wpf7soSFawBurxDV/DbWhMjmpkK6bLG+ZtH6hf9M2g==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Wed, 29 Jul 2026 11:24:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Abhash,

On 7/28/26 12:58, abhash wrote:
[You don't often get email from a-kumar2@xxxxxx. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

+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.


Xen inserts the emulated "smmu" node into the domain device tree automatically, so there is no need to add it manually. I'm not sure whether this is the cause of the DMA failure, but I suspect that the device tree node could be overwritten during domain creation. Could you try removing the manually added "smmu" node?

- 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?


There are no changes in the kernel tree. The mainline SMMUv3 driver is expected to handle the emulated IOMMU device without any issues.

So far, we have tested this feature on the QEMU virt machine and the Renesas Gen5 board.

Just as a note, I will be uploading a reworked version of this patch series updated according to maintainers suggestions, as well as additional fixes identified during more extensive testing. I expect to post it sometime next week.

In any case, DMA should work for DomU with the current revision. If you still encounter issues after applying the change I suggested, feel free to contact me directly.


Best Regards,

Abhash


Best regards,
Milan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.