vm/pmap.h has always included machine/pmap.h, so there is no need for both includes.

Otherwise, I'm fine with this change.

Otherwise, I think that this is ready to commit.

Please go ahead and commit the changes to tree.3.

In D25672#817019, @kib wrote:

In D25672#816160, @alc wrote:

Do you want to resume work on this, and finish some pieces and commit them?

I hope so, but I am not sure I can do anything that large ATM. Do you have specific proposals about already useful pieces?

Since callers to iommu_gas_map_region() provide the entry, assert that the entry was actually allocated for the domain in which the mapping is about to be created.

Add comments.

Do you want to resume work on this, and finish some pieces and commit them?

Add a couple comments.

Fix arm64. I previously added the new parameter to the wrong function.

Redo using the queued invalidation mechanism.

In D35878#814735, @kib wrote:

I think we need to force entry through the qi. From the Intel® Virtualization Technology for Directed I/O Architecture Specification, Rev. 4.0, Order Number: D51397-015

6.5.1 Register-based Invalidation Interface

Register-based invalidation has the following limitations:
• Register-based invalidation can be used only when queued-invalidations are not enabled.

I remember that the requirement was there from the start.

Concretely, here is what I'm suggesting:

In D35869#814571, @kib wrote:

In D35869#814447, @alc wrote:

Kostik, I have another related concerned. What guarantee do we have that dmar_qi_task() is actually finished with the entry when it is freed here or in domain_init_rmrr()?

You mean, that the entry range must still be flushed from the TLB and the entry waited by the qi mechanism? It probably should be done for correctness.

Kostik, I have another related concerned. What guarantee do we have that dmar_qi_task() is actually finished with the entry when it is freed here or in domain_init_rmrr()?

In D35440#811299, @dougm wrote:

Remove 'entry' from the iommu params struct and pass it directly.

In D35722#810749, @glebius wrote:

Good point. Maybe /2 of the result of the difference.

The effects of these changes extend to arm64 as well. vm_phys.o's vm_phys_fictitious_reg_range() and vm_phys_fictitious_unreg_range() are together 140 bytes smaller.

Give me a patch that only updates "insert color". I fully understand that part, and I'm ready to approve it after a little testing.