All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sricharan" <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: 'Will Deacon' <will.deacon-5wv7dgnIgG8@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: RE: [PATCH 0/5] Implement SMMU passthrough using the default domain
Date: Fri, 3 Feb 2017 22:03:09 +0530	[thread overview]
Message-ID: <017701d27e3b$381d24d0$a8576e70$@codeaurora.org> (raw)
In-Reply-To: <20170202161047.GG13839-5wv7dgnIgG8@public.gmane.org>

Hi Will, Rob,

>-----Original Message-----
>From: linux-arm-kernel [mailto:linux-arm-kernel-bounces-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org] On Behalf Of Will Deacon
>Sent: Thursday, February 02, 2017 9:41 PM
>To: Sricharan <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; 'Rob Clark' <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>; 'Joerg Roedel' <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
>foundation.org
>Subject: Re: [PATCH 0/5] Implement SMMU passthrough using the default domain
>
>On Thu, Feb 02, 2017 at 09:15:19PM +0530, Sricharan wrote:
>> Hi Rob,
>>
>> >-----Original Message-----
>> >From: linux-arm-kernel [mailto:linux-arm-kernel-bounces-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org] On Behalf Of Rob Clark
>> >Sent: Thursday, February 02, 2017 8:33 PM
>> >To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
>> >Cc: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Sricharan <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>; linux-arm-
>> >kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> >Subject: Re: [PATCH 0/5] Implement SMMU passthrough using the default domain
>> >
>> >On Thu, Jan 26, 2017 at 12:18 PM, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote:
>> >> On Tue, Jan 24, 2017 at 08:42:23PM +0530, Sricharan wrote:
>> >>> Thanks for this series. We had a case with the GPU.
>> >>> The GPU's iommu was setup by kernel and the GPU
>> >>> also does dynamic updates for on-the-fly switching between
>> >>> process pagetables.  GPU driver was not using DMA domain and
>> >>> the GPU's firmware was always expecting to run out  of contextbank
>> >>>  '0' (although not correct) , which was not the case after the DMA domain
>> >>> was made default  as '0' was getting allocated for DMA domain and
>> >>> there were concerns about reusing the DMA domain as well.
>> >>> Now with this series, looks there is an way out of that that can be tried.
>> >>>
>> >>> So should the default domain not be per device specific selectable ?
>> >>
>> >> Note that iommu-drivers can request direct-mapping for any given device
>> >> on its initializtion. This is used on x86 for devices that need a 1-1
>> >> mapping for some reason.
>> >>
>> >> Also device drivers can use the iommu-api and assign their own domain to
>> >> a device, which allows them to manage the dma address space on their
>> >> own.
>> >
>> >Part of the problem is that dev->archdata.dma_ops gets wired up to
>> >iommu_dma_ops.  Which isn't so bad on it's own, except that cache ops
>> >are not exposed to drivers, forcing us to use dma-mapping API
>> >(dma_map_sg, etc) for cache operations.
>> >
>> >Possibly we should just expose cache op's to drivers bypass this abuse
>> >of dma-mapping.
>> >
>> [1], with this, when the default domain in not DOMAIN_DMA, then
>> dev->archdata.dma_ops is not set to iommu_dma_ops , instead remains
>> to be swiotlb_ops. Is that not correct for gpu's unmanaged domain case ?
>>
>> https://www.spinics.net/lists/arm-kernel/msg556209.html
>>
>> >btw, Will, we definitely want this to *not* rely on kcmdline for the
>> >gpu with it's own private iommu case..
>>
>> Ya, that changes behavior for all devices and some might want
>> DMA_DOMAIN and some UNMANAGED.
>
>My patch changes the *default* domain. When would this ever be UNMANAGED?
>
>If you're using an UNMANAGED domain, I think you need to take care of the
>DMA ops yourself. There are likely missing functions to do that, but they
>should be added in a separate series.

Sorry, i should have said DOMAIN_DMA or DOMAIN_IDENTITY is set as
*default* domains from your patchset. So i have not tested this series
yet. But the requirement that i thought for the gpu was
    * a context bank (specially '0') should not be reserved for DOMAIN_DMA
   * dma_ops should not be set to iommu_dma_ops for the gpu device.

I was seeing that both of that are satisfied in this series, if we choose
IDENTITY_DOMAIN as default and later gpu attaches it own
*UNMANAGED* domain.

The only thing i was thinking was, since we are changing the default domain
for all device from command line, some device which require DOMAIN_DMA
and some which require DOMAIN_IDENTITY as default was not possible.

Regards,
 Sricharan

WARNING: multiple messages have this Message-ID (diff)
From: sricharan@codeaurora.org (Sricharan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] Implement SMMU passthrough using the default domain
Date: Fri, 3 Feb 2017 22:03:09 +0530	[thread overview]
Message-ID: <017701d27e3b$381d24d0$a8576e70$@codeaurora.org> (raw)
In-Reply-To: <20170202161047.GG13839@arm.com>

Hi Will, Rob,

>-----Original Message-----
>From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Will Deacon
>Sent: Thursday, February 02, 2017 9:41 PM
>To: Sricharan <sricharan@codeaurora.org>
>Cc: linux-arm-kernel at lists.infradead.org; 'Rob Clark' <robdclark@gmail.com>; 'Joerg Roedel' <joro@8bytes.org>; iommu at lists.linux-
>foundation.org
>Subject: Re: [PATCH 0/5] Implement SMMU passthrough using the default domain
>
>On Thu, Feb 02, 2017 at 09:15:19PM +0530, Sricharan wrote:
>> Hi Rob,
>>
>> >-----Original Message-----
>> >From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Rob Clark
>> >Sent: Thursday, February 02, 2017 8:33 PM
>> >To: Joerg Roedel <joro@8bytes.org>
>> >Cc: Will Deacon <will.deacon@arm.com>; iommu at lists.linux-foundation.org; Sricharan <sricharan@codeaurora.org>; linux-arm-
>> >kernel at lists.infradead.org
>> >Subject: Re: [PATCH 0/5] Implement SMMU passthrough using the default domain
>> >
>> >On Thu, Jan 26, 2017 at 12:18 PM, Joerg Roedel <joro@8bytes.org> wrote:
>> >> On Tue, Jan 24, 2017 at 08:42:23PM +0530, Sricharan wrote:
>> >>> Thanks for this series. We had a case with the GPU.
>> >>> The GPU's iommu was setup by kernel and the GPU
>> >>> also does dynamic updates for on-the-fly switching between
>> >>> process pagetables.  GPU driver was not using DMA domain and
>> >>> the GPU's firmware was always expecting to run out  of contextbank
>> >>>  '0' (although not correct) , which was not the case after the DMA domain
>> >>> was made default  as '0' was getting allocated for DMA domain and
>> >>> there were concerns about reusing the DMA domain as well.
>> >>> Now with this series, looks there is an way out of that that can be tried.
>> >>>
>> >>> So should the default domain not be per device specific selectable ?
>> >>
>> >> Note that iommu-drivers can request direct-mapping for any given device
>> >> on its initializtion. This is used on x86 for devices that need a 1-1
>> >> mapping for some reason.
>> >>
>> >> Also device drivers can use the iommu-api and assign their own domain to
>> >> a device, which allows them to manage the dma address space on their
>> >> own.
>> >
>> >Part of the problem is that dev->archdata.dma_ops gets wired up to
>> >iommu_dma_ops.  Which isn't so bad on it's own, except that cache ops
>> >are not exposed to drivers, forcing us to use dma-mapping API
>> >(dma_map_sg, etc) for cache operations.
>> >
>> >Possibly we should just expose cache op's to drivers bypass this abuse
>> >of dma-mapping.
>> >
>> [1], with this, when the default domain in not DOMAIN_DMA, then
>> dev->archdata.dma_ops is not set to iommu_dma_ops , instead remains
>> to be swiotlb_ops. Is that not correct for gpu's unmanaged domain case ?
>>
>> https://www.spinics.net/lists/arm-kernel/msg556209.html
>>
>> >btw, Will, we definitely want this to *not* rely on kcmdline for the
>> >gpu with it's own private iommu case..
>>
>> Ya, that changes behavior for all devices and some might want
>> DMA_DOMAIN and some UNMANAGED.
>
>My patch changes the *default* domain. When would this ever be UNMANAGED?
>
>If you're using an UNMANAGED domain, I think you need to take care of the
>DMA ops yourself. There are likely missing functions to do that, but they
>should be added in a separate series.

Sorry, i should have said DOMAIN_DMA or DOMAIN_IDENTITY is set as
*default* domains from your patchset. So i have not tested this series
yet. But the requirement that i thought for the gpu was
    * a context bank (specially '0') should not be reserved for DOMAIN_DMA
   * dma_ops should not be set to iommu_dma_ops for the gpu device.

I was seeing that both of that are satisfied in this series, if we choose
IDENTITY_DOMAIN as default and later gpu attaches it own
*UNMANAGED* domain.

The only thing i was thinking was, since we are changing the default domain
for all device from command line, some device which require DOMAIN_DMA
and some which require DOMAIN_IDENTITY as default was not possible.

Regards,
 Sricharan

  parent reply	other threads:[~2017-02-03 16:33 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-19 18:19 [PATCH 0/5] Implement SMMU passthrough using the default domain Will Deacon
2017-01-19 18:19 ` Will Deacon
     [not found] ` <1484849955-1871-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2017-01-19 18:19   ` [PATCH 1/5] iommu/arm-smmu: Restrict domain attributes to UNMANAGED domains Will Deacon
2017-01-19 18:19     ` Will Deacon
     [not found]     ` <1484849955-1871-2-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2017-01-19 18:41       ` Robin Murphy
2017-01-19 18:41         ` Robin Murphy
     [not found]         ` <89d795b9-a6d7-7f41-705c-b918ee66ebf0-5wv7dgnIgG8@public.gmane.org>
2017-01-26 17:06           ` Joerg Roedel
2017-01-26 17:06             ` Joerg Roedel
2017-01-26 17:03       ` Joerg Roedel
2017-01-26 17:03         ` Joerg Roedel
     [not found]         ` <20170126170329.GB27598-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-01-26 17:57           ` Will Deacon
2017-01-26 17:57             ` Will Deacon
2017-01-19 18:19   ` [PATCH 2/5] iommu/arm-smmu: Install bypass S2CRs for IOMMU_DOMAIN_IDENTITY domains Will Deacon
2017-01-19 18:19     ` Will Deacon
2017-01-19 18:50     ` Robin Murphy
2017-01-19 18:50       ` Robin Murphy
2017-01-19 18:19   ` [PATCH 3/5] iommu/arm-smmu-v3: Install bypass STEs " Will Deacon
2017-01-19 18:19     ` Will Deacon
     [not found]     ` <1484849955-1871-4-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2017-01-19 18:56       ` Robin Murphy
2017-01-19 18:56         ` Robin Murphy
2017-01-19 18:19   ` [PATCH 4/5] arm64: dma-mapping: Only swizzle DMA ops for IOMMU_DOMAIN_DMA Will Deacon
2017-01-19 18:19     ` Will Deacon
     [not found]     ` <1484849955-1871-5-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2017-01-19 19:00       ` Robin Murphy
2017-01-19 19:00         ` Robin Murphy
2017-01-26 17:57         ` Will Deacon
2017-01-26 17:57           ` Will Deacon
2017-01-19 18:19   ` [PATCH 5/5] iommu: Allow default domain type to be set on the kernel command line Will Deacon
2017-01-19 18:19     ` Will Deacon
     [not found]     ` <1484849955-1871-6-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2017-01-26 17:15       ` Joerg Roedel
2017-01-26 17:15         ` Joerg Roedel
     [not found]         ` <20170126171555.GD27598-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-01-26 17:26           ` Robin Murphy
2017-01-26 17:26             ` Robin Murphy
2017-01-26 17:48           ` Will Deacon
2017-01-26 17:48             ` Will Deacon
2017-01-24 15:12   ` [PATCH 0/5] Implement SMMU passthrough using the default domain Sricharan
2017-01-24 15:12     ` Sricharan
2017-01-26 17:18     ` Joerg Roedel
2017-01-26 17:18       ` Joerg Roedel
     [not found]       ` <20170126171857.GE27598-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2017-02-02 15:02         ` Rob Clark
2017-02-02 15:02           ` Rob Clark
     [not found]           ` <CAF6AEGtfrrwVZ_W86_HqVsiqfcM=XFa+g2LECFYQJmvv7-JSqQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-02 15:12             ` Will Deacon
2017-02-02 15:12               ` Will Deacon
     [not found]               ` <20170202151241.GE13839-5wv7dgnIgG8@public.gmane.org>
2017-02-03 12:20                 ` Rob Clark
2017-02-03 12:20                   ` Rob Clark
2017-02-02 15:45             ` Sricharan
2017-02-02 15:45               ` Sricharan
2017-02-02 16:10               ` Will Deacon
2017-02-02 16:10                 ` Will Deacon
     [not found]                 ` <20170202161047.GG13839-5wv7dgnIgG8@public.gmane.org>
2017-02-03 16:33                   ` Sricharan [this message]
2017-02-03 16:33                     ` Sricharan

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='017701d27e3b$381d24d0$a8576e70$@codeaurora.org' \
    --to=sricharan-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    /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.