Hi Shameer,
On 2020/11/20 19:27, Shameerali Kolothum Thodi wrote:
Hi Baolu/Ashok,
-----Original Message-----
From: iommu [mailto:[email protected]] On Behalf Of
Ashok Raj
Sent: 25 September 2020 20:06
To: Joerg Roedel <[email protected]>; [email protected]
Cc: Ashok Raj <[email protected]>; Will Deacon <[email protected]>;
Robin Murphy <[email protected]>; Christoph Hellwig <[email protected]>
Subject: [Patch V8 1/3] iommu: Add support to change default domain of an
iommu group
From: Sai Praneeth Prakhya <[email protected]>
Presently, the default domain of an iommu group is allocated during boot
time and it cannot be changed later. So, the device would typically be
either in identity (also known as pass_through) mode or the device would be
in DMA mode as long as the machine is up and running. There is no way to
change the default domain type dynamically i.e. after booting, a device
cannot switch between identity mode and DMA mode.
But, assume a use case wherein the user trusts the device and believes that
the OS is secure enough and hence wants *only* this device to bypass IOMMU
(so that it could be high performing) whereas all the other devices to go
through IOMMU (so that the system is protected). Presently, this use case
is not supported. It will be helpful if there is some way to change the
default domain of an iommu group dynamically. Hence, add such support.
A privileged user could request the kernel to change the default domain
type of a iommu group by writing to
"/sys/kernel/iommu_groups/<grp_id>/type" file. Presently, only three values
are supported
1. identity: all the DMA transactions from the device in this group are
*not* translated by the iommu
2. DMA: all the DMA transactions from the device in this group are
translated by the iommu
3. auto: change to the type the device was booted with
Note:
1. Default domain of an iommu group with two or more devices cannot be
changed.
2. The device in the iommu group shouldn't be bound to any driver.
3. The device shouldn't be assigned to user for direct access.
4. The vendor iommu driver is required to add def_domain_type() callback.
The change request will fail if the request type conflicts with that
returned from the callback.
Currently Arm SMMUv3 driver doesn't provide the def_doman_type() callback.
And I have sent a patch[1] based on this series to just add that. But Robin made
couple of suggestions there which can be incorporated into this series so that
the
vendor driver no more required to provide the callback for this feature to work.
1. Include a generic checking for
if (dev_is_pci(dev)) {
if (pci_dev->untrusted)
return IOMMU_DOMAIN_DMA;
}
To be honest, I have the same idea. Okay! I can do this in the next
version.
2. Also if there is no def_doman_type() callback provided by vendor driver,
assume
that the dev supports both IDENTITY and DMA domain types.
It's true for boot case. I will assume this in this series.
If you plan to respin this series, could you please consider the above as well?
Please let me know.
Sure!
Thanks,
Shameer
Best regards,
baolu
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
