-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nho/smmu gem integration #23
Merged
ho28
merged 5 commits into
Wind-River:wr-integration
from
ho28:nho/smmu_gem_integration
Jan 14, 2025
Merged
Nho/smmu gem integration #23
ho28
merged 5 commits into
Wind-River:wr-integration
from
ho28:nho/smmu_gem_integration
Jan 14, 2025
+107
−27
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Nelson Ho <Nelson.Ho@windriver.com>
ho28
force-pushed
the
nho/smmu_gem_integration
branch
from
January 9, 2025 00:26
a9f5848
to
89a328f
Compare
kay-ge
reviewed
Jan 10, 2025
smmu_translate wants to use tbu[i].as as the target address space for translation. This change allows the target as to be set via property by the machine that integrates the smmu500 and dma capable devices. Signed-off-by: Nelson Ho <Nelson.Ho@windriver.com>
The emulated smmu-500 has a configurable number of TBUs, but defaults to 16. From the system programmer's perspective, it does not matter which device is connected to which TBU, it is up to the hardware designer how the various DMA capable devices in the system are connected to the TBUs on the SMMU. As far as I can tell from the documentation, Xilinx does not tell us which devices are connected to which TBU. For now, I am planning to assign each device to a different TBU. Signed-off-by: Nelson Ho <Nelson.Ho@windriver.com>
The Cadence GEM implementation does not specify any memory transaction attributes when performing DMA scatter/gather operations. This is acceptable in non-virtualized scenarios, but when the DMA needs to go through IOMMU for translation, the IOMMU needs to know how to map the device to the memory context in which it should perform the translation. This change adds a stream-id property to the GEM device implementation, which is used to set the requester_id field of the memory transaction attributes specified by the device when performing DMA operations. The IOMMU implementation parses the requester_id field as the stream ID which it uses to map to the page table root which identifies the memory context. Signed-off-by: Nelson Ho <Nelson.Ho@windriver.com>
The Versal BSP identifies the SMMU stream ID for GEM0 and GEM1 as 0x234 and 0x235. Configure the GEM property as such. Signed-off-by: Nelson Ho <Nelson.Ho@windriver.com>
ho28
force-pushed
the
nho/smmu_gem_integration
branch
from
January 10, 2025 17:43
89a328f
to
c355487
Compare
kay-ge
approved these changes
Jan 10, 2025
ho28
pushed a commit
to ho28/wr-qemu
that referenced
this pull request
Jan 15, 2025
…et_end() In multifd_mapped_ram_fdset_end() we call qtest_qmp() but forgot to unref the response QDict we get back, which means it is leaked: Indirect leak of 4120 byte(s) in 1 object(s) allocated from: #0 0x55c0c095d318 in __interceptor_calloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/asan/tests/qtest/migration-test+0x22f318) (BuildI d: 07f667506452d6c467dbc06fd95191966d3e91b4) Wind-River#1 0x7f186f939c50 in g_malloc0 debian/build/deb/../../../glib/gmem.c:161:13 Wind-River#2 0x55c0c0ae9b01 in qdict_new qobject/qdict.c:30:13 Wind-River#3 0x55c0c0afc16c in parse_object qobject/json-parser.c:317:12 Wind-River#4 0x55c0c0afb90f in parse_value qobject/json-parser.c:545:16 Wind-River#5 0x55c0c0afb579 in json_parser_parse qobject/json-parser.c:579:14 Wind-River#6 0x55c0c0afa21d in json_message_process_token qobject/json-streamer.c:92:12 Wind-River#7 0x55c0c0bca2e5 in json_lexer_feed_char qobject/json-lexer.c:313:13 Wind-River#8 0x55c0c0bc97ce in json_lexer_feed qobject/json-lexer.c:350:9 Wind-River#9 0x55c0c0afabbc in json_message_parser_feed qobject/json-streamer.c:121:5 Wind-River#10 0x55c0c09cbd52 in qmp_fd_receive tests/qtest/libqmp.c:86:9 Wind-River#11 0x55c0c09be69b in qtest_qmp_receive_dict tests/qtest/libqtest.c:760:12 Wind-River#12 0x55c0c09bca77 in qtest_qmp_receive tests/qtest/libqtest.c:741:27 Wind-River#13 0x55c0c09bee9d in qtest_vqmp tests/qtest/libqtest.c:812:12 Wind-River#14 0x55c0c09bd257 in qtest_qmp tests/qtest/libqtest.c:835:16 Wind-River#15 0x55c0c0a87747 in multifd_mapped_ram_fdset_end tests/qtest/migration-test.c:2393:12 Wind-River#16 0x55c0c0a85eb3 in test_file_common tests/qtest/migration-test.c:1978:9 Wind-River#17 0x55c0c0a746a3 in test_multifd_file_mapped_ram_fdset tests/qtest/migration-test.c:2437:5 Wind-River#18 0x55c0c0a93237 in migration_test_wrapper tests/qtest/migration-helpers.c:458:5 Wind-River#19 0x7f186f958aed in test_case_run debian/build/deb/../../../glib/gtestutils.c:2930:15 Wind-River#20 0x7f186f958aed in g_test_run_suite_internal debian/build/deb/../../../glib/gtestutils.c:3018:16 Wind-River#21 0x7f186f95880a in g_test_run_suite_internal debian/build/deb/../../../glib/gtestutils.c:3035:18 Wind-River#22 0x7f186f95880a in g_test_run_suite_internal debian/build/deb/../../../glib/gtestutils.c:3035:18 Wind-River#23 0x7f186f95880a in g_test_run_suite_internal debian/build/deb/../../../glib/gtestutils.c:3035:18 Wind-River#24 0x7f186f95880a in g_test_run_suite_internal debian/build/deb/../../../glib/gtestutils.c:3035:18 Wind-River#25 0x7f186f95880a in g_test_run_suite_internal debian/build/deb/../../../glib/gtestutils.c:3035:18 Wind-River#26 0x7f186f958faa in g_test_run_suite debian/build/deb/../../../glib/gtestutils.c:3109:18 Wind-River#27 0x7f186f959055 in g_test_run debian/build/deb/../../../glib/gtestutils.c:2231:7 #28 0x7f186f959055 in g_test_run debian/build/deb/../../../glib/gtestutils.c:2218:1 #29 0x55c0c0a6e427 in main tests/qtest/migration-test.c:4033:11 Unref the object after we've confirmed that it is what we expect. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Connect the Cadence GEM devices to SMMU-500. HVP guests that attempt to utilize DMA capable devices configured the dma descriptor source/destination address with the guest physical address . In order for this to work properly, the SMMU must do the second level translation from guest physical address to host physical address. This changeset adds the necessary changes to enable GEM DMA to work properly.
This change also adds additional stream-id property to the GEM device implementation so that different DMA devices can be properly matched to the correct context banks within the IOMMU.