All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Robin Murphy <robin.murphy@arm.com>, Tom Murphy <tmurphy@arista.com>
Cc: baolu.lu@linux.intel.com, "Tian, Kevin" <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>, Dmitry Safonov <dima@arista.com>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	jacob.jun.pan@intel.com, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v3 1/8] iommu: Add ops entry for supported default domain type
Date: Fri, 10 May 2019 13:29:30 +0800	[thread overview]
Message-ID: <6dbbfc10-3247-744c-ae8d-443a336e0c50@linux.intel.com> (raw)
In-Reply-To: <56205a21-c72f-a460-77a2-4bb4f46f6e08@arm.com>

Hi Robin,

On 5/10/19 12:11 AM, Robin Murphy wrote:
> On 09/05/2019 03:30, Lu Baolu wrote:
>> Hi Robin,
>>
>> On 5/7/19 6:28 PM, Robin Murphy wrote:
>>> On 06/05/2019 16:32, Tom Murphy via iommu wrote:
>>>> The AMD driver already solves this problem and uses the generic
>>>> iommu_request_dm_for_dev function. It seems like both drivers have the
>>>> same problem and could use the same solution. Is there any reason we
>>>> can't have use the same solution for the intel and amd driver?
>>>>
>>>> Could we just  copy the implementation of the AMD driver? It would be
>>>> nice to have the same behavior across both drivers especially as we
>>>> move to make both drivers use more generic code.
>>>
>>> TBH I don't think the API really needs to be involved at all here. 
>>> Drivers can already not provide the requested default domain type if 
>>> they don't support it, so as long as the driver can ensure that the 
>>> device ends up with IOMMU or direct DMA ops as appropriate, I don't 
>>> see any great problem with drivers just returning a passthrough 
>>> domain when a DMA domain was requested, or vice versa (and logging a 
>>> message that the requested type was overridden). The only type that 
>>> we really do have to honour strictly is non-default (i.e. unmanaged) 
>>> domains.
>>
>> I agree with you that we only have to honor strictly the non-default
>> domains. But domain type saved in iommu_domain is consumed in iommu.c
>> and exposed to user through sysfs. It's not clean if the iommu driver
>> silently replace the default domain.
> 
> Right, I did get a bit ahead of myself there - the implicit step before 
> that is to fix default domain allocation so that the core actually 
> passes the relevant device which it has to hand, such that the IOMMU 
> drivers *can* make the right decision up-front.
> 

Yes, passing the relevant device when allocating the default domain so
that the IOMMU driver could make right decision seems to be a better
solution. Somebody can come up with a patch set to bring this up for
discussion. I won't include this in this patch set since it's not for
that purpose. I will follow the existing mechanism that is using on amd
and other iommu drivers.

Best regards,
Lu Baolu

WARNING: multiple messages have this Message-ID (diff)
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Robin Murphy <robin.murphy@arm.com>, Tom Murphy <tmurphy@arista.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>, Dmitry Safonov <dima@arista.com>,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	jacob.jun.pan@intel.com, David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH v3 1/8] iommu: Add ops entry for supported default domain type
Date: Fri, 10 May 2019 13:29:30 +0800	[thread overview]
Message-ID: <6dbbfc10-3247-744c-ae8d-443a336e0c50@linux.intel.com> (raw)
In-Reply-To: <56205a21-c72f-a460-77a2-4bb4f46f6e08@arm.com>

Hi Robin,

On 5/10/19 12:11 AM, Robin Murphy wrote:
> On 09/05/2019 03:30, Lu Baolu wrote:
>> Hi Robin,
>>
>> On 5/7/19 6:28 PM, Robin Murphy wrote:
>>> On 06/05/2019 16:32, Tom Murphy via iommu wrote:
>>>> The AMD driver already solves this problem and uses the generic
>>>> iommu_request_dm_for_dev function. It seems like both drivers have the
>>>> same problem and could use the same solution. Is there any reason we
>>>> can't have use the same solution for the intel and amd driver?
>>>>
>>>> Could we just  copy the implementation of the AMD driver? It would be
>>>> nice to have the same behavior across both drivers especially as we
>>>> move to make both drivers use more generic code.
>>>
>>> TBH I don't think the API really needs to be involved at all here. 
>>> Drivers can already not provide the requested default domain type if 
>>> they don't support it, so as long as the driver can ensure that the 
>>> device ends up with IOMMU or direct DMA ops as appropriate, I don't 
>>> see any great problem with drivers just returning a passthrough 
>>> domain when a DMA domain was requested, or vice versa (and logging a 
>>> message that the requested type was overridden). The only type that 
>>> we really do have to honour strictly is non-default (i.e. unmanaged) 
>>> domains.
>>
>> I agree with you that we only have to honor strictly the non-default
>> domains. But domain type saved in iommu_domain is consumed in iommu.c
>> and exposed to user through sysfs. It's not clean if the iommu driver
>> silently replace the default domain.
> 
> Right, I did get a bit ahead of myself there - the implicit step before 
> that is to fix default domain allocation so that the core actually 
> passes the relevant device which it has to hand, such that the IOMMU 
> drivers *can* make the right decision up-front.
> 

Yes, passing the relevant device when allocating the default domain so
that the IOMMU driver could make right decision seems to be a better
solution. Somebody can come up with a patch set to bring this up for
discussion. I won't include this in this patch set since it's not for
that purpose. I will follow the existing mechanism that is using on amd
and other iommu drivers.

Best regards,
Lu Baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2019-05-10  5:36 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-29  2:09 [PATCH v3 0/8] iommu/vt-d: Delegate DMA domain to generic iommu Lu Baolu
2019-04-29  2:09 ` Lu Baolu
2019-04-29  2:09 ` [PATCH v3 1/8] iommu: Add ops entry for supported default domain type Lu Baolu
2019-04-29  2:09   ` Lu Baolu
2019-05-06 15:32   ` Tom Murphy
2019-05-06 15:32     ` Tom Murphy via iommu
2019-05-07 10:28     ` Robin Murphy
2019-05-07 10:28       ` Robin Murphy
2019-05-09  2:30       ` Lu Baolu
2019-05-09  2:30         ` Lu Baolu
2019-05-09 16:11         ` Robin Murphy
2019-05-09 16:11           ` Robin Murphy
2019-05-10  5:29           ` Lu Baolu [this message]
2019-05-10  5:29             ` Lu Baolu
2019-05-09  2:22     ` Lu Baolu
2019-05-09  2:22       ` Lu Baolu
2019-04-29  2:09 ` [PATCH v3 2/8] iommu/vt-d: Implement apply_resv_region iommu ops entry Lu Baolu
2019-04-29  2:09   ` Lu Baolu
2019-04-29  2:09 ` [PATCH v3 3/8] iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions Lu Baolu
2019-04-29  2:09   ` Lu Baolu
2019-04-29  2:09 ` [PATCH v3 4/8] iommu/vt-d: Enable DMA remapping after rmrr mapped Lu Baolu
2019-04-29  2:09   ` Lu Baolu
2019-04-29  2:09 ` [PATCH v3 5/8] iommu/vt-d: Implement def_domain_type iommu ops entry Lu Baolu
2019-04-29  2:09   ` Lu Baolu
2019-04-29 20:03   ` Christoph Hellwig
2019-04-29 20:03     ` Christoph Hellwig
2019-04-30  2:11     ` Lu Baolu
2019-04-30  2:11       ` Lu Baolu
2019-05-06 15:25       ` Tom Murphy
2019-05-06 15:25         ` Tom Murphy via iommu
2019-05-09  4:31         ` Lu Baolu
2019-05-09  4:31           ` Lu Baolu
2019-04-29  2:09 ` [PATCH v3 6/8] iommu/vt-d: Allow DMA domains to be allocated by iommu ops Lu Baolu
2019-04-29  2:09   ` Lu Baolu
2019-04-29  2:09 ` [PATCH v3 7/8] iommu/vt-d: Remove lazy allocation of domains Lu Baolu
2019-04-29  2:09   ` Lu Baolu
2019-04-29  2:09 ` [PATCH v3 8/8] iommu/vt-d: Implement is_attach_deferred iommu ops entry Lu Baolu
2019-04-29  2:09   ` 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=6dbbfc10-3247-744c-ae8d-443a336e0c50@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=ashok.raj@intel.com \
    --cc=dima@arista.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=tmurphy@arista.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.