Page MenuHomeFreeBSD

rename dmar->iommu

Authored by br on Jul 6 2020, 6:26 PM.



As part of splitting-out DMAR busdma backend, rename:

dmar_unit -> iommu_unit
dmar_domain -> iommu_domain
dmar_ctx -> iommu_device
dmar_test_boundary -> iommu_test_boundary
ctx_tag -> device_tag
dmar_get_requester -> iommu_get_requester
dmar_bus_dma_is_dev_disabled -> iommu_bus_dma_is_dev_disabled
dmar_instantiate_ctx -> iommu_instantiate_device
dmar_bus_* -> iommu_bus_*
bus_dma_tag_dmar -> bus_dma_tag_iommu
bus_dmamap_dmar -> bus_dmamap_iommu
dmar_init_busdma -> iommu_init_busdma
dmar_fini_busdma -> iommu_fini_busdma
dmar_map_entries_tailq -> iommu_map_entries_tailq
bus_dma_dmar_impl -> bus_dma_iommu_impl

Test Plan

amd64 build and run with dmar enabled on X1 Carbon

Diff Detail

Lint Skipped
Unit Tests Skipped

Event Timeline

br requested review of this revision.Jul 6 2020, 6:26 PM
br created this revision.
br edited the summary of this revision. (Show Details)

I am not sure this would work out. You intent is to provide the arch-specific iommu_unit on armv8, right ?

I do not request you to do this, just discuss. IMO iommu_unit should be MI, and this x86 structure still being called dmar_unit. dmar_unit would embed iommu_unit as the first member, so you can trivially convert iommu_unit to dmar_unit. iommu_unit would contain something common to all implementations, perhaps lock, unit number, might be device.

Significant number of chunks in this patch then would be not needed, when passing dmar_unit to x86 DMAR code.

This is actually useful on x86 too, since there is AMD with its IOMMU which is not DMAR, but currently not supported.


Yes, the intent is to provide the arch-specific iommu_unit, iommu_domain and iommu_device.

There is a small iommu framework/interface in arm64/iommu/ that defines struct iommu_unit, struct iommu_domain and struct iommu_device. The framework has no idea about SMMU. That allows us to keep SMMU driver small and simple, and to not overload if with unnecessary matters like busdma, etc.
The original idea was to use the framework on all platforms, but apparently everything is different on amd64, so I left it on arm64 only. It is used for VA space, devices and policies management on arm64, as well as busdma interactions.
So with that iommu framework/interface, the SMMU driver does not require to know about iommu_unit at all.

We already do the similar way that you proposed with smmu_domain. So smmu_domain embeds iommu_domain as a first member (see 'struct smmu_domain {' in

So I think the idea you described does not fit well arm64 because of the framework, i.e. we already have another layer of abstraction on arm64 that keeps MMU drivers small. So renaming iommu_unit to smmu_unit may not be possible, unless we remove the framework.

For x86 it could be possible, let me check

Make the struct iommu_unit to be the first member of struct dmar_unit

Move IOMMU_LOCK macroses to busdma_dmar.h


So here is an updated patch with struct iommu_unit as the first member of dmar_unit.
I moved a few members from dmar_unit to iommu_unit as needed by dmar_busdma.c.
It looks good I think (although it is the same size).
What do you think?


I do not think that the whole content of dmar_domain is relevant to other hw. For instance, mgaw/agaw/pglvl/awlvl are definitely dmar-specific.


Why this rename ? It is very strange. I would never call dmar context (this is hw-defined term) an iommu_device. In fact context is dmar-specific thing, it is some laziness on my part that currently it maps 1:1 to requestor, but I have unpublished patches that make context multi-device, which allows to use dmar driver from x86/iommu in bhyve.

54 ↗(On Diff #74169)

This is hw-specific register, I see no point of renaming anything in intel_reg.h.

Rename: iommu_device_entry_t -> dmar_ctx_entry_t

br marked an inline comment as done.Jul 8 2020, 1:31 PM
br added inline comments.

I can try to do similar change with dmar_ctx and dmar_domain as we did with dmar_unit.
(I.e. using iommu_device, iommu_domain as the first member)

54 ↗(On Diff #74169)

Agree, fixed.

br marked an inline comment as done.

dmar_ctx and dmar_domain restored:
iommu_device and iommu_domain are first members of structs

restore M_DMAR_DOMAIN malloc define after sed

instead of renaming dmar functions, add wrappers for dmar_find(), dmar_domain_unload(), dmar_get_ctx_for_dev()


You moved structures' definitions together with the locking annotations, but did not copied the legend.

Also I do not like the move of iommu_unit/devce (still device ?) into bsudma_dmar.h. I think this part deserves a new header in sys/sys.


I t is not a device, I already commented on this. It is still iommu translation context.


iommu_map_entry is a good candidate to move together with iommu_unit etc. Together with flags definitions.


This is the locking annotations I mentioned earlier.

Restore dmar_unit member in struct dmar_domain. This makes patch smaller

Rename struct iommu_device to struct iommu_ctx

Move iommu ctx/domain/unit to sys/iommu.h
Move iommu_map_entry to sys/iommu.h

br marked 4 inline comments as done.Jul 9 2020, 9:28 PM
br added inline comments.

I had to change struct bus_dma_tag_iommu to struct bus_dma_tag_iommu * in sys/iommu.h, otherwise it wont build


Agree, device renamed to ctx!


Agree, moved!

br marked 3 inline comments as done.

Move some prototypes to sys/iommu.h

add some iommu wrappers for gas functions: dmar_gas_map(), dmar_gas_map_region(), dmar_gas_alloc_entry, etc

o Check if a device is disabled using "iommu" string
o Rename busdma taskqueue
o Use both "hw.iommu.dma" and "hw.dmar.dma" tunables

Rename DMAR_CTX_ flags to IOMMU_CTX_
Move to sys/iommu.h

kib added inline comments.

I suggest to include <sys/queue.h> explicitly instead of relying on the namespace pollution, if you include from includes anyway. Also you should add sys/types.h.

This revision is now accepted and ready to land.Jul 13 2020, 8:35 PM