All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
	Ashok Raj <ashok.raj@intel.com>, Joerg Roedel <joro@8bytes.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will.deacon@arm.com>, Christoph Hellwig <hch@lst.de>
Subject: Re: [Patch V8 1/3] iommu: Add support to change default domain of an iommu group
Date: Fri, 20 Nov 2020 21:09:23 +0800	[thread overview]
Message-ID: <2bac8484-735d-db63-edef-3f0295417d9c@linux.intel.com> (raw)
In-Reply-To: <243ce89c33fe4b9da4c56ba35acebf81@huawei.com>

Hi Shameer,

On 2020/11/20 19:27, Shameerali Kolothum Thodi wrote:
> Hi Baolu/Ashok,
> 
>> -----Original Message-----
>> From: iommu [mailto:iommu-bounces@lists.linux-foundation.org] On Behalf Of
>> Ashok Raj
>> Sent: 25 September 2020 20:06
>> To: Joerg Roedel <joro@8bytes.org>; iommu@lists.linux-foundation.org
>> Cc: Ashok Raj <ashok.raj@intel.com>; Will Deacon <will.deacon@arm.com>;
>> Robin Murphy <robin.murphy@arm.com>; Christoph Hellwig <hch@lst.de>
>> Subject: [Patch V8 1/3] iommu: Add support to change default domain of an
>> iommu group
>>
>> From: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
>>
>> 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
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2020-11-20 13:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 19:06 [Patch V8 0/3] iommu: Add support to change default domain of an iommu group Ashok Raj
2020-09-25 19:06 ` [Patch V8 1/3] " Ashok Raj
2020-11-18 13:51   ` Will Deacon
2020-11-19  2:18     ` Lu Baolu
2020-11-19  8:53       ` Will Deacon
2020-11-20  2:11         ` Lu Baolu
2020-11-20 11:03           ` Will Deacon
2020-11-20 11:27   ` Shameerali Kolothum Thodi
2020-11-20 13:09     ` Lu Baolu [this message]
2020-09-25 19:06 ` [Patch V8 2/3] iommu: Take lock before reading iommu group default domain type Ashok Raj
2020-09-25 19:06 ` [Patch V8 3/3] iommu: Document usage of "/sys/kernel/iommu_groups/<grp_id>/type" file Ashok Raj
2020-11-18 13:51   ` Will Deacon
2020-11-19  2:32     ` Lu Baolu
2020-11-19  8:55       ` Will Deacon
2020-11-20  2:13         ` Lu Baolu
2020-10-01 12:58 ` [Patch V8 0/3] iommu: Add support to change default domain of an iommu group Joerg Roedel
2020-10-01 13:51   ` Raj, Ashok
2020-11-18 13:52 ` Will Deacon
2020-11-19  2:36   ` Lu Baolu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2bac8484-735d-db63-edef-3f0295417d9c@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.