All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörg Rödel" <joro@8bytes.org>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	"Raj, Ashok" <ashok.raj@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"rafael@kernel.org" <rafael@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Cornelia Huck <cohuck@redhat.com>, Will Deacon <will@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Diana Craciun <diana.craciun@oss.nxp.com>
Subject: Re: [PATCH 01/11] iommu: Add device dma ownership set/release interfaces
Date: Fri, 19 Nov 2021 16:06:12 +0100	[thread overview]
Message-ID: <20211119150612.jhsvsbzisvux2lga@8bytes.org> (raw)
In-Reply-To: <75100dfd-9cfe-9f3d-531d-b4d30de03e76@linux.intel.com>

On Fri, Nov 19, 2021 at 07:14:10PM +0800, Lu Baolu wrote:
> The singleton group requirement for iommu_attach/detach_device() was
> added by below commit:
> 
> commit 426a273834eae65abcfc7132a21a85b3151e0bce
> Author: Joerg Roedel <jroedel@suse.de>
> Date:   Thu May 28 18:41:30 2015 +0200
> 
>     iommu: Limit iommu_attach/detach_device to devices with their own group
> 
>     This patch changes the behavior of the iommu_attach_device
>     and iommu_detach_device functions. With this change these
>     functions only work on devices that have their own group.
>     For all other devices the iommu_group_attach/detach
>     functions must be used.
> 
>     Signed-off-by: Joerg Roedel <jroedel@suse.de>
> 
> Joerg,can you please shed some light on the background of this
> requirement? Does above idea of transition from singleton group
> to group with single driver bound make sense to you?

This change came to be because the iommu_attach/detach_device()
interface doesn't fit well into a world with iommu-groups. Devices
within a group are by definition not isolated between each other, so
they must all be in the same address space (== iommu_domain). So it
doesn't make sense to allow attaching a single device within a group to
a different iommu_domain.

I know that in theory it is safe to allow devices within a group to be
in different domains because there iommu-groups catch multiple
non-isolation cases:

	1) Devices behind a non-ACS capable bridge or multiple functions
	   of a PCI device. Here it is safe to put the devices into
	   different iommu-domains as long as all affected devices are
	   controlled by the same owner.

	2) Devices which share a single request-id and can't be
	   differentiated by the IOMMU hardware. These always need to be
	   in the same iommu_domain.

To lift the single-domain-per-group requirement the iommu core code
needs to learn the difference between the two cases above.

Regards,

	Joerg

WARNING: multiple messages have this Message-ID (diff)
From: "Jörg Rödel" <joro@8bytes.org>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	"Raj, Ashok" <ashok.raj@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"rafael@kernel.org" <rafael@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Cornelia Huck <cohuck@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"Pan, Jacob jun" <jacob.jun.pan@intel.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Will Deacon <will@kernel.org>,
	Diana Craciun <diana.craciun@oss.nxp.com>
Subject: Re: [PATCH 01/11] iommu: Add device dma ownership set/release interfaces
Date: Fri, 19 Nov 2021 16:06:12 +0100	[thread overview]
Message-ID: <20211119150612.jhsvsbzisvux2lga@8bytes.org> (raw)
In-Reply-To: <75100dfd-9cfe-9f3d-531d-b4d30de03e76@linux.intel.com>

On Fri, Nov 19, 2021 at 07:14:10PM +0800, Lu Baolu wrote:
> The singleton group requirement for iommu_attach/detach_device() was
> added by below commit:
> 
> commit 426a273834eae65abcfc7132a21a85b3151e0bce
> Author: Joerg Roedel <jroedel@suse.de>
> Date:   Thu May 28 18:41:30 2015 +0200
> 
>     iommu: Limit iommu_attach/detach_device to devices with their own group
> 
>     This patch changes the behavior of the iommu_attach_device
>     and iommu_detach_device functions. With this change these
>     functions only work on devices that have their own group.
>     For all other devices the iommu_group_attach/detach
>     functions must be used.
> 
>     Signed-off-by: Joerg Roedel <jroedel@suse.de>
> 
> Joerg,can you please shed some light on the background of this
> requirement? Does above idea of transition from singleton group
> to group with single driver bound make sense to you?

This change came to be because the iommu_attach/detach_device()
interface doesn't fit well into a world with iommu-groups. Devices
within a group are by definition not isolated between each other, so
they must all be in the same address space (== iommu_domain). So it
doesn't make sense to allow attaching a single device within a group to
a different iommu_domain.

I know that in theory it is safe to allow devices within a group to be
in different domains because there iommu-groups catch multiple
non-isolation cases:

	1) Devices behind a non-ACS capable bridge or multiple functions
	   of a PCI device. Here it is safe to put the devices into
	   different iommu-domains as long as all affected devices are
	   controlled by the same owner.

	2) Devices which share a single request-id and can't be
	   differentiated by the IOMMU hardware. These always need to be
	   in the same iommu_domain.

To lift the single-domain-per-group requirement the iommu core code
needs to learn the difference between the two cases above.

Regards,

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

  reply	other threads:[~2021-11-19 15:06 UTC|newest]

Thread overview: 120+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15  2:05 [PATCH 00/11] Fix BUG_ON in vfio_iommu_group_notifier() Lu Baolu
2021-11-15  2:05 ` Lu Baolu
2021-11-15  2:05 ` [PATCH 01/11] iommu: Add device dma ownership set/release interfaces Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15 13:14   ` Christoph Hellwig
2021-11-15 13:14     ` Christoph Hellwig
2021-11-16  1:57     ` Lu Baolu
2021-11-16  1:57       ` Lu Baolu
2021-11-16 13:46       ` Jason Gunthorpe
2021-11-16 13:46         ` Jason Gunthorpe via iommu
2021-11-17  5:22         ` Lu Baolu
2021-11-17  5:22           ` Lu Baolu
2021-11-17 13:35           ` Jason Gunthorpe
2021-11-17 13:35             ` Jason Gunthorpe via iommu
2021-11-18  1:12             ` Lu Baolu
2021-11-18  1:12               ` Lu Baolu
2021-11-18 14:10               ` Jason Gunthorpe
2021-11-18 14:10                 ` Jason Gunthorpe via iommu
2021-11-18  2:39         ` Tian, Kevin
2021-11-18  2:39           ` Tian, Kevin
2021-11-18 13:33           ` Jason Gunthorpe
2021-11-18 13:33             ` Jason Gunthorpe via iommu
2021-11-19  5:44             ` Tian, Kevin
2021-11-19  5:44               ` Tian, Kevin
2021-11-19 11:14               ` Lu Baolu
2021-11-19 11:14                 ` Lu Baolu
2021-11-19 15:06                 ` Jörg Rödel [this message]
2021-11-19 15:06                   ` Jörg Rödel
2021-11-19 15:43                   ` Jason Gunthorpe
2021-11-19 15:43                     ` Jason Gunthorpe via iommu
2021-11-20 11:16                   ` Lu Baolu
2021-11-20 11:16                     ` Lu Baolu
2021-11-19 12:56               ` Jason Gunthorpe
2021-11-19 12:56                 ` Jason Gunthorpe via iommu
2021-11-15 20:38   ` Bjorn Helgaas
2021-11-15 20:38     ` Bjorn Helgaas
2021-11-16  1:52     ` Lu Baolu
2021-11-16  1:52       ` Lu Baolu
2021-11-15  2:05 ` [PATCH 02/11] driver core: Set DMA ownership during driver bind/unbind Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15  6:59   ` Greg Kroah-Hartman
2021-11-15  6:59     ` Greg Kroah-Hartman
2021-11-15 13:20     ` Christoph Hellwig
2021-11-15 13:20       ` Christoph Hellwig
2021-11-15 13:38     ` Jason Gunthorpe via iommu
2021-11-15 13:38       ` Jason Gunthorpe
2021-11-15 13:19   ` Christoph Hellwig
2021-11-15 13:19     ` Christoph Hellwig
2021-11-15 13:24     ` Jason Gunthorpe
2021-11-15 13:24       ` Jason Gunthorpe via iommu
2021-11-15 15:37       ` Robin Murphy
2021-11-15 15:37         ` Robin Murphy
2021-11-15 15:56         ` Jason Gunthorpe
2021-11-15 15:56           ` Jason Gunthorpe via iommu
2021-11-15 18:15           ` Christoph Hellwig
2021-11-15 18:15             ` Christoph Hellwig
2021-11-15 18:35           ` Robin Murphy
2021-11-15 18:35             ` Robin Murphy
2021-11-15 19:39             ` Jason Gunthorpe via iommu
2021-11-15 19:39               ` Jason Gunthorpe
2021-11-15  2:05 ` [PATCH 03/11] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15 13:21   ` Christoph Hellwig
2021-11-15 13:21     ` Christoph Hellwig
2021-11-15 13:31     ` Jason Gunthorpe via iommu
2021-11-15 13:31       ` Jason Gunthorpe
2021-11-15 15:14       ` Robin Murphy
2021-11-15 15:14         ` Robin Murphy
2021-11-15 16:17         ` Jason Gunthorpe
2021-11-15 16:17           ` Jason Gunthorpe via iommu
2021-11-15 17:54           ` Robin Murphy
2021-11-15 17:54             ` Robin Murphy
2021-11-15 18:19             ` Christoph Hellwig
2021-11-15 18:19               ` Christoph Hellwig
2021-11-15 18:44               ` Robin Murphy
2021-11-15 18:44                 ` Robin Murphy
2021-11-15 19:22             ` Jason Gunthorpe via iommu
2021-11-15 19:22               ` Jason Gunthorpe
2021-11-15 20:58               ` Robin Murphy
2021-11-15 20:58                 ` Robin Murphy
2021-11-15 21:19                 ` Jason Gunthorpe via iommu
2021-11-15 21:19                   ` Jason Gunthorpe
2021-11-15 20:48   ` Bjorn Helgaas
2021-11-15 20:48     ` Bjorn Helgaas
2021-11-15 22:17   ` Bjorn Helgaas
2021-11-15 22:17     ` Bjorn Helgaas
2021-11-16  6:05     ` Lu Baolu
2021-11-16  6:05       ` Lu Baolu
2021-11-15  2:05 ` [PATCH 04/11] PCI: portdrv: " Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15 20:44   ` Bjorn Helgaas
2021-11-15 20:44     ` Bjorn Helgaas
2021-11-16  7:24     ` Lu Baolu
2021-11-16  7:24       ` Lu Baolu
2021-11-16 20:22       ` Bjorn Helgaas
2021-11-16 20:22         ` Bjorn Helgaas
2021-11-16 20:48         ` Jason Gunthorpe
2021-11-16 20:48           ` Jason Gunthorpe via iommu
2021-11-15  2:05 ` [PATCH 05/11] iommu: Add security context management for assigned devices Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15 13:22   ` Christoph Hellwig
2021-11-15 13:22     ` Christoph Hellwig
2021-11-16  7:25     ` Lu Baolu
2021-11-16  7:25       ` Lu Baolu
2021-11-15  2:05 ` [PATCH 06/11] iommu: Expose group variants of dma ownership interfaces Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15 13:27   ` Christoph Hellwig
2021-11-15 13:27     ` Christoph Hellwig
2021-11-16  9:42     ` Lu Baolu
2021-11-16  9:42       ` Lu Baolu
2021-11-15  2:05 ` [PATCH 07/11] vfio: Use DMA_OWNER_USER to declaim passthrough devices Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15  2:05 ` [PATCH 08/11] vfio: Remove use of vfio_group_viable() Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15  2:05 ` [PATCH 09/11] vfio: Delete the unbound_list Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15  2:05 ` [PATCH 10/11] vfio: Remove iommu group notifier Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15  2:05 ` [PATCH 11/11] iommu: Remove iommu group changes notifier Lu Baolu
2021-11-15  2:05   ` 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=20211119150612.jhsvsbzisvux2lga@8bytes.org \
    --to=joro@8bytes.org \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=cohuck@redhat.com \
    --cc=diana.craciun@oss.nxp.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=jgg@nvidia.com \
    --cc=kch@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=will@kernel.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.