All of lore.kernel.org
 help / color / mirror / Atom feed
From: <nobuhiro1.iwamatsu@toshiba.co.jp>
To: <jgg@nvidia.com>, <baolu.lu@linux.intel.com>
Cc: <joro@8bytes.org>, <will@kernel.org>, <robh+dt@kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<iommu@lists.linux-foundation.org>,
	<yuji2.ishikawa@toshiba.co.jp>,
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH 1/3] iommu: Add Visconti5 IOMMU driver
Date: Mon, 20 Jun 2022 05:49:13 +0000	[thread overview]
Message-ID: <TYWPR01MB9420F74E27D8513CD2C2D27592B09@TYWPR01MB9420.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <20220525182644.GF1343366@nvidia.com>

Hi,

Thanks for your review.

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Thursday, May 26, 2022 3:27 AM
> To: Baolu Lu <baolu.lu@linux.intel.com>
> Cc: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
> <nobuhiro1.iwamatsu@toshiba.co.jp>; Joerg Roedel <joro@8bytes.org>; Will
> Deacon <will@kernel.org>; Rob Herring <robh+dt@kernel.org>;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> iommu@lists.linux-foundation.org; ishikawa yuji(石川 悠司 ○RDC□AIT
> C○EA開) <yuji2.ishikawa@toshiba.co.jp>;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 1/3] iommu: Add Visconti5 IOMMU driver
> 
> On Wed, May 25, 2022 at 02:26:37PM +0800, Baolu Lu wrote:
> > On 2022/5/25 09:31, Nobuhiro Iwamatsu wrote:
> > > +static const struct iommu_ops visconti_atu_ops = {
> > > +	.domain_alloc = visconti_atu_domain_alloc,
> > > +	.probe_device = visconti_atu_probe_device,
> > > +	.release_device = visconti_atu_release_device,
> > > +	.device_group = generic_device_group,
> > > +	.of_xlate = visconti_atu_of_xlate,
> > > +	.pgsize_bitmap = ATU_IOMMU_PGSIZE_BITMAP,
> > > +	.default_domain_ops = &(const struct iommu_domain_ops) {
> > > +		.attach_dev = visconti_atu_attach_device,
> > > +		.detach_dev = visconti_atu_detach_device,
> >
> > The detach_dev callback is about to be deprecated. The new drivers
> > should implement the default domain and blocking domain instead.
> 
> Yes please, new drivers need to use default_domains.
> 
> It is very strange that visconti_atu_detach_device() does nothing.  It is not
> required that a domain is fully unmapped before being destructed, I think
> detach should set ATU_AT_EN to 0.

I see, I rethink implementation.

> 
> What behavior does the HW have when ATU_AT_ENTRY_EN == 0? If DMA is
> rejected then this driver should have a IOMMU_DOMAIN_BLOCKING and
> return that from ops->def_domain_type().

If ATU_AT_ENTRY_EN is 0, nothing happens. It does not work with IOMMU,
it works with the memory space set in device tree.
Also, I investigate about IOMMU_DOMAIN_BLOCKING.

> 
> Attaching a the blocking domain should set ATU_AT_ENTRY_EN = 0
> 
> Also, if I surmise how this works properly, it is not following the iommu API to
> halt all DMA during map/unmap operations. Should at least document this and
> explain why it is OK..

I see, I will check DMA during map and unmap operations.

> 
> I'm feeling like these "special" drivers need some kind of handshake with their
> only users because they don't work with things like VFIO..

Since the devices that utilize this IOMMU function are fixed, I do not think that a special handshake is required.
Could you you tell me where you thought you needed a handshake?

Best regards,
  Nobuhiro

> 
> Jason


WARNING: multiple messages have this Message-ID (diff)
From: <nobuhiro1.iwamatsu@toshiba.co.jp>
To: <jgg@nvidia.com>, <baolu.lu@linux.intel.com>
Cc: devicetree@vger.kernel.org, yuji2.ishikawa@toshiba.co.jp,
	linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	robh+dt@kernel.org, will@kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: RE: [PATCH 1/3] iommu: Add Visconti5 IOMMU driver
Date: Mon, 20 Jun 2022 05:49:13 +0000	[thread overview]
Message-ID: <TYWPR01MB9420F74E27D8513CD2C2D27592B09@TYWPR01MB9420.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <20220525182644.GF1343366@nvidia.com>

Hi,

Thanks for your review.

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Thursday, May 26, 2022 3:27 AM
> To: Baolu Lu <baolu.lu@linux.intel.com>
> Cc: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
> <nobuhiro1.iwamatsu@toshiba.co.jp>; Joerg Roedel <joro@8bytes.org>; Will
> Deacon <will@kernel.org>; Rob Herring <robh+dt@kernel.org>;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> iommu@lists.linux-foundation.org; ishikawa yuji(石川 悠司 ○RDC□AIT
> C○EA開) <yuji2.ishikawa@toshiba.co.jp>;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 1/3] iommu: Add Visconti5 IOMMU driver
> 
> On Wed, May 25, 2022 at 02:26:37PM +0800, Baolu Lu wrote:
> > On 2022/5/25 09:31, Nobuhiro Iwamatsu wrote:
> > > +static const struct iommu_ops visconti_atu_ops = {
> > > +	.domain_alloc = visconti_atu_domain_alloc,
> > > +	.probe_device = visconti_atu_probe_device,
> > > +	.release_device = visconti_atu_release_device,
> > > +	.device_group = generic_device_group,
> > > +	.of_xlate = visconti_atu_of_xlate,
> > > +	.pgsize_bitmap = ATU_IOMMU_PGSIZE_BITMAP,
> > > +	.default_domain_ops = &(const struct iommu_domain_ops) {
> > > +		.attach_dev = visconti_atu_attach_device,
> > > +		.detach_dev = visconti_atu_detach_device,
> >
> > The detach_dev callback is about to be deprecated. The new drivers
> > should implement the default domain and blocking domain instead.
> 
> Yes please, new drivers need to use default_domains.
> 
> It is very strange that visconti_atu_detach_device() does nothing.  It is not
> required that a domain is fully unmapped before being destructed, I think
> detach should set ATU_AT_EN to 0.

I see, I rethink implementation.

> 
> What behavior does the HW have when ATU_AT_ENTRY_EN == 0? If DMA is
> rejected then this driver should have a IOMMU_DOMAIN_BLOCKING and
> return that from ops->def_domain_type().

If ATU_AT_ENTRY_EN is 0, nothing happens. It does not work with IOMMU,
it works with the memory space set in device tree.
Also, I investigate about IOMMU_DOMAIN_BLOCKING.

> 
> Attaching a the blocking domain should set ATU_AT_ENTRY_EN = 0
> 
> Also, if I surmise how this works properly, it is not following the iommu API to
> halt all DMA during map/unmap operations. Should at least document this and
> explain why it is OK..

I see, I will check DMA during map and unmap operations.

> 
> I'm feeling like these "special" drivers need some kind of handshake with their
> only users because they don't work with things like VFIO..

Since the devices that utilize this IOMMU function are fixed, I do not think that a special handshake is required.
Could you you tell me where you thought you needed a handshake?

Best regards,
  Nobuhiro

> 
> Jason

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: <nobuhiro1.iwamatsu@toshiba.co.jp>
To: <jgg@nvidia.com>, <baolu.lu@linux.intel.com>
Cc: <joro@8bytes.org>, <will@kernel.org>, <robh+dt@kernel.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<iommu@lists.linux-foundation.org>,
	<yuji2.ishikawa@toshiba.co.jp>,
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH 1/3] iommu: Add Visconti5 IOMMU driver
Date: Mon, 20 Jun 2022 05:49:13 +0000	[thread overview]
Message-ID: <TYWPR01MB9420F74E27D8513CD2C2D27592B09@TYWPR01MB9420.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <20220525182644.GF1343366@nvidia.com>

Hi,

Thanks for your review.

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Thursday, May 26, 2022 3:27 AM
> To: Baolu Lu <baolu.lu@linux.intel.com>
> Cc: iwamatsu nobuhiro(岩松 信洋 □SWC◯ACT)
> <nobuhiro1.iwamatsu@toshiba.co.jp>; Joerg Roedel <joro@8bytes.org>; Will
> Deacon <will@kernel.org>; Rob Herring <robh+dt@kernel.org>;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> iommu@lists.linux-foundation.org; ishikawa yuji(石川 悠司 ○RDC□AIT
> C○EA開) <yuji2.ishikawa@toshiba.co.jp>;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH 1/3] iommu: Add Visconti5 IOMMU driver
> 
> On Wed, May 25, 2022 at 02:26:37PM +0800, Baolu Lu wrote:
> > On 2022/5/25 09:31, Nobuhiro Iwamatsu wrote:
> > > +static const struct iommu_ops visconti_atu_ops = {
> > > +	.domain_alloc = visconti_atu_domain_alloc,
> > > +	.probe_device = visconti_atu_probe_device,
> > > +	.release_device = visconti_atu_release_device,
> > > +	.device_group = generic_device_group,
> > > +	.of_xlate = visconti_atu_of_xlate,
> > > +	.pgsize_bitmap = ATU_IOMMU_PGSIZE_BITMAP,
> > > +	.default_domain_ops = &(const struct iommu_domain_ops) {
> > > +		.attach_dev = visconti_atu_attach_device,
> > > +		.detach_dev = visconti_atu_detach_device,
> >
> > The detach_dev callback is about to be deprecated. The new drivers
> > should implement the default domain and blocking domain instead.
> 
> Yes please, new drivers need to use default_domains.
> 
> It is very strange that visconti_atu_detach_device() does nothing.  It is not
> required that a domain is fully unmapped before being destructed, I think
> detach should set ATU_AT_EN to 0.

I see, I rethink implementation.

> 
> What behavior does the HW have when ATU_AT_ENTRY_EN == 0? If DMA is
> rejected then this driver should have a IOMMU_DOMAIN_BLOCKING and
> return that from ops->def_domain_type().

If ATU_AT_ENTRY_EN is 0, nothing happens. It does not work with IOMMU,
it works with the memory space set in device tree.
Also, I investigate about IOMMU_DOMAIN_BLOCKING.

> 
> Attaching a the blocking domain should set ATU_AT_ENTRY_EN = 0
> 
> Also, if I surmise how this works properly, it is not following the iommu API to
> halt all DMA during map/unmap operations. Should at least document this and
> explain why it is OK..

I see, I will check DMA during map and unmap operations.

> 
> I'm feeling like these "special" drivers need some kind of handshake with their
> only users because they don't work with things like VFIO..

Since the devices that utilize this IOMMU function are fixed, I do not think that a special handshake is required.
Could you you tell me where you thought you needed a handshake?

Best regards,
  Nobuhiro

> 
> Jason


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-06-20  5:50 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-25  1:31 [PATCH 0/3] Add Visconti5 IOMMU driver Nobuhiro Iwamatsu
2022-05-25  1:31 ` Nobuhiro Iwamatsu
2022-05-25  1:31 ` Nobuhiro Iwamatsu
2022-05-25  1:31 ` [PATCH 1/3] iommu: " Nobuhiro Iwamatsu
2022-05-25  1:31   ` Nobuhiro Iwamatsu
2022-05-25  1:31   ` Nobuhiro Iwamatsu
2022-05-25  4:45   ` kernel test robot
2022-05-25  4:45     ` kernel test robot
2022-05-25  4:45     ` kernel test robot
2022-05-25  6:09   ` kernel test robot
2022-05-25  6:09     ` kernel test robot
2022-05-25  6:09     ` kernel test robot
2022-05-25  6:26   ` Baolu Lu
2022-05-25  6:26     ` Baolu Lu
2022-05-25  6:26     ` Baolu Lu
2022-05-25 18:26     ` Jason Gunthorpe
2022-05-25 18:26       ` Jason Gunthorpe
2022-05-25 18:26       ` Jason Gunthorpe via iommu
2022-05-26  0:43       ` Tian, Kevin
2022-05-26  0:43         ` Tian, Kevin
2022-05-26  0:43         ` Tian, Kevin
2022-05-26  1:40         ` Jason Gunthorpe
2022-05-26  1:40           ` Jason Gunthorpe
2022-05-26  1:40           ` Jason Gunthorpe via iommu
2022-06-20  5:49       ` nobuhiro1.iwamatsu [this message]
2022-06-20  5:49         ` nobuhiro1.iwamatsu
2022-06-20  5:49         ` nobuhiro1.iwamatsu
2022-06-24 13:39         ` Jason Gunthorpe
2022-06-24 13:39           ` Jason Gunthorpe
2022-06-24 13:39           ` Jason Gunthorpe via iommu
2022-06-20  2:15     ` nobuhiro1.iwamatsu
2022-06-20  2:15       ` nobuhiro1.iwamatsu
2022-06-20  2:15       ` nobuhiro1.iwamatsu
2022-05-25  9:36   ` kernel test robot
2022-05-25  9:36     ` kernel test robot
2022-05-25  9:36     ` kernel test robot
2022-05-25  1:31 ` [PATCH 2/3] iommu: bindings: Add binding documentation for Toshiba Visconti5 IOMMU device Nobuhiro Iwamatsu
2022-05-25  1:31   ` Nobuhiro Iwamatsu
2022-05-25  1:31   ` Nobuhiro Iwamatsu
2022-06-02 13:43   ` Rob Herring
2022-06-02 13:43     ` Rob Herring
2022-06-02 13:43     ` Rob Herring
2022-05-25  1:31 ` [PATCH 3/3] MAINTAINERS: Add entries for Toshiba Visconti5 IOMMU Nobuhiro Iwamatsu
2022-05-25  1:31   ` Nobuhiro Iwamatsu
2022-05-25  1:31   ` Nobuhiro Iwamatsu

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=TYWPR01MB9420F74E27D8513CD2C2D27592B09@TYWPR01MB9420.jpnprd01.prod.outlook.com \
    --to=nobuhiro1.iwamatsu@toshiba.co.jp \
    --cc=baolu.lu@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=will@kernel.org \
    --cc=yuji2.ishikawa@toshiba.co.jp \
    /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.