Re: [PATCH kernel] powerpc/iommu: Add iommu_ops to report capabilities and allow blocking domains
From: Alexey Kardashevskiy <hidden>
Date: 2022-07-09 02:56:52
Also in:
kvm
On 08/07/2022 21:55, Jason Gunthorpe wrote:
On Fri, Jul 08, 2022 at 04:34:55PM +1000, Alexey Kardashevskiy wrote:quoted
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