From: Lu Baolu <baolu.lu@linux.intel.com>
To: John Garry <john.garry@huawei.com>,
Joerg Roedel <joro@8bytes.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bjorn Helgaas <bhelgaas@google.com>
Cc: kevin.tian@intel.com, ashok.raj@intel.com,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
jacob.jun.pan@intel.com, Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH 0/4] iommu: Per-group default domain type
Date: Tue, 21 Jan 2020 08:43:52 +0800 [thread overview]
Message-ID: <f417cd0b-1bf7-7da2-3a64-b8b74b03da02@linux.intel.com> (raw)
In-Reply-To: <ba7a7e6a-8b23-fca0-a8bb-72c4dbfa8390@huawei.com>
Hi John,
On 1/20/20 5:44 PM, John Garry wrote:
> On 01/01/2020 05:26, Lu Baolu wrote:
>> An IOMMU group represents the smallest set of devices that are considered
>> to be isolated. All devices belonging to an IOMMU group share a default
>> domain for DMA APIs. There are two types of default domain:
>> IOMMU_DOMAIN_DMA
>> and IOMMU_DOMAIN_IDENTITY. The former means IOMMU translation, while the
>> latter means IOMMU by-pass.
>>
>> Currently, the default domain type for the IOMMU groups is determined
>> globally. All IOMMU groups use a single default domain type. The global
>> default domain type can be adjusted by kernel build configuration or
>> kernel parameters.
>>
>> More and more users are looking forward to a fine grained default domain
>> type. For example, with the global default domain type set to
>> translation,
>> the OEM verndors or end users might want some trusted and fast-speed
>> devices
>> to bypass IOMMU for performance gains. On the other hand, with global
>> default domain type set to by-pass, some devices with limited system
>> memory addressing capability might want IOMMU translation to remove the
>> bounce buffer overhead.
>
> Hi Lu Baolu,
>
> Do you think that it would be a more common usecase to want
> kernel-managed devices to be passthrough for performance reasons and
> some select devices to be in DMA domain, like those with limited address
> cap or whose drivers request huge amounts of memory?
>
> I just think it would be more manageable to set kernel commandline
> parameters for this, i.e. those select few which want DMA domain.
>
It's just two sides of a coin. Currently, iommu subsystem make DMA
domain by default, that's the reason why I selected to let user set
which devices are willing to use identity domains.
> Thanks,
> John
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com>
To: John Garry <john.garry@huawei.com>,
Joerg Roedel <joro@8bytes.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Bjorn Helgaas <bhelgaas@google.com>
Cc: baolu.lu@linux.intel.com, kevin.tian@intel.com,
ashok.raj@intel.com, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, jacob.jun.pan@intel.com,
Robin Murphy <robin.murphy@arm.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [RFC PATCH 0/4] iommu: Per-group default domain type
Date: Tue, 21 Jan 2020 08:43:52 +0800 [thread overview]
Message-ID: <f417cd0b-1bf7-7da2-3a64-b8b74b03da02@linux.intel.com> (raw)
In-Reply-To: <ba7a7e6a-8b23-fca0-a8bb-72c4dbfa8390@huawei.com>
Hi John,
On 1/20/20 5:44 PM, John Garry wrote:
> On 01/01/2020 05:26, Lu Baolu wrote:
>> An IOMMU group represents the smallest set of devices that are considered
>> to be isolated. All devices belonging to an IOMMU group share a default
>> domain for DMA APIs. There are two types of default domain:
>> IOMMU_DOMAIN_DMA
>> and IOMMU_DOMAIN_IDENTITY. The former means IOMMU translation, while the
>> latter means IOMMU by-pass.
>>
>> Currently, the default domain type for the IOMMU groups is determined
>> globally. All IOMMU groups use a single default domain type. The global
>> default domain type can be adjusted by kernel build configuration or
>> kernel parameters.
>>
>> More and more users are looking forward to a fine grained default domain
>> type. For example, with the global default domain type set to
>> translation,
>> the OEM verndors or end users might want some trusted and fast-speed
>> devices
>> to bypass IOMMU for performance gains. On the other hand, with global
>> default domain type set to by-pass, some devices with limited system
>> memory addressing capability might want IOMMU translation to remove the
>> bounce buffer overhead.
>
> Hi Lu Baolu,
>
> Do you think that it would be a more common usecase to want
> kernel-managed devices to be passthrough for performance reasons and
> some select devices to be in DMA domain, like those with limited address
> cap or whose drivers request huge amounts of memory?
>
> I just think it would be more manageable to set kernel commandline
> parameters for this, i.e. those select few which want DMA domain.
>
It's just two sides of a coin. Currently, iommu subsystem make DMA
domain by default, that's the reason why I selected to let user set
which devices are willing to use identity domains.
> Thanks,
> John
Best regards,
baolu
next prev parent reply other threads:[~2020-01-21 0:45 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-01 5:26 [RFC PATCH 0/4] iommu: Per-group default domain type Lu Baolu
2020-01-01 5:26 ` Lu Baolu
2020-01-01 5:26 ` [RFC PATCH 1/4] driver core: Add iommu_passthrough to struct device Lu Baolu
2020-01-01 5:26 ` Lu Baolu
2020-01-01 5:26 ` [RFC PATCH 2/4] PCI: Add "pci=iommu_passthrough=" parameter for iommu passthrough Lu Baolu
2020-01-01 5:26 ` Lu Baolu
2020-01-18 0:18 ` Bjorn Helgaas
2020-01-18 0:18 ` Bjorn Helgaas
2020-01-18 2:04 ` Lu Baolu
2020-01-18 2:04 ` Lu Baolu
2020-01-21 14:17 ` Bjorn Helgaas
2020-01-21 14:17 ` Bjorn Helgaas
2020-01-22 4:49 ` Lu Baolu
2020-01-22 4:49 ` Lu Baolu
2020-01-01 5:26 ` [RFC PATCH 3/4] iommu: Preallocate iommu group when probing devices Lu Baolu
2020-01-01 5:26 ` Lu Baolu
2020-01-17 10:21 ` Joerg Roedel
2020-01-17 10:21 ` Joerg Roedel
2020-01-18 2:18 ` Lu Baolu
2020-01-18 2:18 ` Lu Baolu
2020-01-19 6:29 ` Lu Baolu
2020-01-19 6:29 ` Lu Baolu
2020-01-21 12:45 ` Robin Murphy
2020-01-21 12:45 ` Robin Murphy
2020-01-22 5:39 ` Lu Baolu
2020-01-22 5:39 ` Lu Baolu
2020-01-23 14:55 ` Robin Murphy
2020-01-23 14:55 ` Robin Murphy
2020-01-01 5:26 ` [RFC PATCH 4/4] iommu: Determine default domain type before allocating domain Lu Baolu
2020-01-01 5:26 ` Lu Baolu
2020-01-20 9:44 ` [RFC PATCH 0/4] iommu: Per-group default domain type John Garry
2020-01-20 9:44 ` John Garry
2020-01-21 0:43 ` Lu Baolu [this message]
2020-01-21 0:43 ` Lu Baolu
2020-01-21 10:14 ` John Garry
2020-01-21 10:14 ` John Garry
2020-01-22 4:58 ` Lu Baolu
2020-01-22 4:58 ` 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=f417cd0b-1bf7-7da2-3a64-b8b74b03da02@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=john.garry@huawei.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@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.