On 08/07/2022 21:55, Jason Gunthorpe wrote:
On Fri, Jul 08, 2022 at 04:34:55PM +1000, Alexey Kardashevskiy wrote:
For now I'll add a comment in spapr_tce_iommu_attach_dev() that it is fine
to do nothing as tce_iommu_take_ownership() and
tce_iommu_take_ownership_ddw() take care of not having active DMA mappings.
That will still cause a security problem because
tce_iommu_take_ownership()/etc are called too late. This is the moment
in the flow when the ownershift must change away from the DMA API that
power implements and to VFIO, not later.
Trying to do that.
vfio_group_set_container:
iommu_group_claim_dma_owner
driver->ops->attach_group
iommu_group_claim_dma_owner sets a domain to a group. Good. But it
attaches devices, not groups. Bad.
driver->ops->attach_group on POWER attaches a group so VFIO claims
ownership over a group, not devices. Underlying API
(pnv_ioda2_take_ownership()) does not need to keep track of the state,
it is one group, one ownership transfer, easy.
What is exactly the reason why iommu_group_claim_dma_owner() cannot stay
inside Type1 (sorry if it was explained, I could have missed)?
Also, from another mail, you said iommu_alloc_default_domain() should
fail on power but at least IOMMU_DOMAIN_BLOCKED must be supported, or
the whole iommu_group_claim_dma_owner() thing falls apart.
And iommu_ops::domain_alloc() is not told if it is asked to create a
default domain, it only takes a type.
--
Alexey
