On Tue, Mar 15, 2022 at 09:36:08AM -0400, Matthew Rosato wrote:
> > If we do try to stick this into VFIO it should probably use the
> > VFIO_TYPE1_NESTING_IOMMU instead - however, we would like to delete
> > that flag entirely as it was never fully implemented, was never used,
> > and isn't part of
On Tue, Mar 15, 2022 at 09:49:01AM -0400, Matthew Rosato wrote:
> The rationale for splitting steps 1 and 2 are that VFIO_SET_IOMMU doesn't
> have a mechanism for specifying more than the type as an arg, no? Otherwise
> yes, you could specify a kvm fd at this point and it would have some other
>
On Mon, Mar 14, 2022 at 10:07:09PM -0700, Jacob Pan wrote:
> DMA mapping API is the de facto standard for in-kernel DMA. It operates
> on a per device/RID basis which is not PASID-aware.
>
> Some modern devices such as Intel Data Streaming Accelerator, PASID is
> required for certain work submissi
On Mon, Mar 14, 2022 at 10:07:07PM -0700, Jacob Pan wrote:
> + /*
> + * Each domain could have multiple devices attached with shared or per
> + * device PASIDs. At the domain level, we keep track of unique PASIDs
> and
> + * device user count.
> + * E.g. If a domain has two
On Tue, Mar 15, 2022 at 11:16:41AM +, Robin Murphy wrote:
> On 2022-03-15 05:07, Jacob Pan wrote:
> > DMA mapping API is the de facto standard for in-kernel DMA. It operates
> > on a per device/RID basis which is not PASID-aware.
> >
> > Some modern devices such as Intel Data Streaming Acceler
On Tue, Mar 08, 2022 at 01:44:10PM +0800, Lu Baolu wrote:
> Hi folks,
>
> The iommu group is the minimal isolation boundary for DMA. Devices in
> a group can access each other's MMIO registers via peer to peer DMA
> and also need share the same I/O address space.
Joerg, are we good for the coming
On Mon, Mar 14, 2022 at 04:50:33PM -0600, Alex Williamson wrote:
> > +/*
> > + * The KVM_IOMMU type implies that the hypervisor will control the mappings
> > + * rather than userspace
> > + */
> > +#define VFIO_KVM_IOMMU 11
>
> Then why is this hosted in the type1 code that ex
On Mon, Mar 14, 2022 at 03:44:48PM -0400, Matthew Rosato wrote:
> The DTSM, or designation type supported mask, indicates what IOAT formats
> are available to the guest. For an interpreted device, userspace will not
> know what format(s) the IOAT assist supports, so pass it via the
> capability ch
On Mon, Mar 14, 2022 at 03:44:41PM -0400, Matthew Rosato wrote:
> +int kvm_s390_pci_zpci_start(struct kvm *kvm, struct zpci_dev *zdev)
> +{
> + struct vfio_device *vdev;
> + struct pci_dev *pdev;
> + int rc;
> +
> + rc = kvm_s390_pci_dev_open(zdev);
> + if (rc)
> + r
On Mon, Mar 14, 2022 at 03:44:34PM -0400, Matthew Rosato wrote:
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 9394aa9444c1..0bec97077d61 100644
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -77,6 +77,7 @@ struct vfio_iommu {
> bool
On Mon, Mar 14, 2022 at 03:44:33PM -0400, Matthew Rosato wrote:
> s390x will introduce an additional domain type that is used for
> managing IOMMU owned by KVM. Define the type here and add an
> interface for allocating a specified type vs the default type.
>
> Signed-off-by: Matthew Rosato
> --
On Mon, Feb 14, 2022 at 10:57:02AM +0800, Lu Baolu wrote:
> This removes unnecessary commented code.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/iommu.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
Assuming you don't want to uncomment
paghetti in the first place.. Looks like putting the
'for_each_active_dev_scope' into another function would do the trick.
Anyhow, this is more consistent with kernel style:
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@l
On Mon, Feb 14, 2022 at 10:57:00AM +0800, Lu Baolu wrote:
> Some prototypes in iommu.c are unnecessary. Delete them.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/iommu.c | 5 -
> 1 file changed, 5 deletions(-)
Reviewed-by: Jason
letions(-)
Are we sorting includes alphabetically now?
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
gt; + struct dmar_domain *domain = info->domain;
It might be nice to someday call 'struct device_domain_info' something
clearer since it is now the dev_iommu_priv..
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux
d-by: Christoph Hellwig
> ---
> drivers/iommu/intel/iommu.c | 104 ++--
> 1 file changed, 5 insertions(+), 99 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
h
eletions(-)
Reviewed-by: Jason Gunthorpe
Jasno
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Baolu
> Reviewed-by: Christoph Hellwig
> ---
> drivers/iommu/intel/iommu.c | 21 -
> 1 file changed, 21 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://l
; Signed-off-by: Lu Baolu
> Reviewed-by: Christoph Hellwig
> ---
> include/linux/intel-iommu.h | 1 -
> drivers/iommu/intel/iommu.c | 68 ++---
> 2 files changed, 3 insertions(+), 66 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
_
On Wed, Feb 23, 2022 at 06:20:36PM +, Robin Murphy wrote:
> On 2022-02-23 18:02, Jason Gunthorpe via iommu wrote:
> > On Wed, Feb 23, 2022 at 06:00:06PM +, Robin Murphy wrote:
> >
> > > ...and equivalently just set owner_cnt directly to 0 here. I don't see a
On Wed, Feb 23, 2022 at 12:00:56PM -0600, Bjorn Helgaas wrote:
> > static int pci_dma_configure(struct device *dev)
> > {
> > + struct pci_driver *driver = to_pci_driver(dev->driver);
> > struct device *bridge;
> > int ret = 0;
> >
> > + if (!driver->no_kernel_api_dma) {
>
> Ugh.
On Wed, Feb 23, 2022 at 06:00:06PM +, Robin Murphy wrote:
> ...and equivalently just set owner_cnt directly to 0 here. I don't see a
> realistic use-case for any driver to claim the same group more than once,
> and allowing it in the API just feels like opening up various potential
> corners f
On Wed, Feb 23, 2022 at 10:09:01AM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 23, 2022 at 03:06:35PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 23, 2022 at 09:46:27AM -0400, Jason Gunthorpe wrote:
> > > On Wed, Feb 23, 2022 at 01:04:00PM +, Robin Murphy wrote:
>
On Wed, Feb 23, 2022 at 03:06:35PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 23, 2022 at 09:46:27AM -0400, Jason Gunthorpe wrote:
> > On Wed, Feb 23, 2022 at 01:04:00PM +, Robin Murphy wrote:
> >
> > > 1 - tmp->driver is non-NULL because tmp is already bound.
&
On Wed, Feb 23, 2022 at 01:04:00PM +, Robin Murphy wrote:
> 1 - tmp->driver is non-NULL because tmp is already bound.
> 1.a - If tmp->driver->driver_managed_dma == 0, the group must currently be
> DMA-API-owned as a whole. Regardless of what driver dev has unbound from,
> its removal does no
On Tue, Feb 22, 2022 at 09:18:23PM +, Robin Murphy wrote:
> > Still not sure I see what you are thinking though..
>
> What part of "How hard is it to hold group->mutex when reading or writing
> group->owner?" sounded like "complex lockless algorithm", exactly?
group->owner is not the issue,
On Tue, Feb 22, 2022 at 10:58:37AM +, Robin Murphy wrote:
> On 2022-02-21 23:48, Jason Gunthorpe wrote:
> > On Mon, Feb 21, 2022 at 08:43:33PM +, Robin Murphy wrote:
> > > On 2022-02-19 07:32, Christoph Hellwig wrote:
> > > > So we are back to the callback m
On Mon, Feb 21, 2022 at 08:43:33PM +, Robin Murphy wrote:
> On 2022-02-19 07:32, Christoph Hellwig wrote:
> > So we are back to the callback madness instead of the nice and simple
> > flag? Sigh.
>
> TBH, I *think* this part could be a fair bit simpler. It looks like this
> whole callback mes
up. This allows
> userspace to indirectly attack any kernel owned device and it's driver.
This series has changed quite a lot since v1 - but I couldn't spot
anything wrong with this. It is a small incremental step and I think
it is fine now, so
Reviewed-by: Jason Gunthorpe
On Wed, Feb 16, 2022 at 02:28:09PM +0800, Lu Baolu wrote:
> It seems everyone agrees that for device assignment (where the I/O
> address is owned by the user-space application), the iommu_group-based
> APIs should always be used. Otherwise, the isolation and protection are
> not guaranteed.
This
On Tue, Feb 15, 2022 at 10:11:01AM +0100, Joerg Roedel wrote:
> > But, then, the requirement is that nobody is using the dma API when we
> > make this change?
>
> That is the tricky part. DMA-API keeps working after the change is made,
> because the new domain is also direct mapped. The new domai
On Tue, Feb 15, 2022 at 09:58:13AM +0100, Joerg Roedel wrote:
> On Mon, Feb 14, 2022 at 11:46:26AM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 14, 2022 at 03:18:31PM +, Robin Murphy wrote:
> >
> > > Arguably, iommu_attach_device() could b
On Mon, Feb 14, 2022 at 04:38:23PM +, Robin Murphy wrote:
> > This works better because the iommu code can hold the internal group
> > while it finds the bus/device and then invokes the driver op. We don't
> > have a lifetime problem anymore under that lock.
>
> That's certainly one of the cl
On Mon, Feb 14, 2022 at 03:18:31PM +, Robin Murphy wrote:
> Arguably, iommu_attach_device() could be renamed something like
> iommu_attach_group_for_dev(), since that's effectively the semantic that all
> the existing API users want anyway (even VFIO at the high level - the group
> is the mean
On Mon, Feb 14, 2022 at 03:23:07PM +0100, Joerg Roedel wrote:
> Device drivers calling into iommu_attach_device() is seldom a good
> idea. In this case the sound device has some generic hardware
> interface so that an existing sound driver can be re-used. Making this
> driver call iommu-specific
On Mon, Feb 14, 2022 at 02:10:19PM +, Robin Murphy wrote:
> On 2022-02-14 12:45, Jason Gunthorpe wrote:
> > On Mon, Feb 14, 2022 at 12:09:36PM +, Robin Murphy wrote:
> > > On 2022-01-06 02:20, Lu Baolu wrote:
> > > > Expose an interface to replace th
On Mon, Feb 14, 2022 at 02:40:56PM +0100, Joerg Roedel wrote:
> On Mon, Feb 14, 2022 at 09:15:44AM -0400, Jason Gunthorpe wrote:
> > But how does the sound device know that this has been done to it?
> >
> > eg how do we know the sound device hasn't been bound to VFI
On Mon, Feb 14, 2022 at 10:57:03AM +0800, Lu Baolu wrote:
> Replace the existing global device_domain_list with an array so that it
> could be rapidly searched. The index of the array is composed by the PCI
> segment, bus and devfn. Use RCU for lock protection.
>
> Signed-off-by: Lu Baolu
> incl
On Mon, Feb 14, 2022 at 02:39:18PM +0100, Greg Kroah-Hartman wrote:
> > A driver that sets this flag can still decide to enable the dma API on
> > its own. eg tegra drivers do this.
>
> So you are just forcing the driver to manage this all on their own, so
> how about, "driver_managed_dma", or ev
On Mon, Feb 14, 2022 at 02:37:15PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 14, 2022 at 09:18:53AM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 14, 2022 at 10:59:50AM +0100, Greg Kroah-Hartman wrote:
> >
> > > > + if (ret
On Mon, Feb 14, 2022 at 09:55:37AM +0800, Lu Baolu wrote:
> This converts all the feasible instances of dev->bus->iommu_ops to
> dev_iommu_ops() in order to make the operation of obtaining iommu_ops
> from a device consistent. The dev_iommu_ops() warns on NULL ops, so
> we don't need to keep the co
On Mon, Feb 14, 2022 at 10:59:50AM +0100, Greg Kroah-Hartman wrote:
> > + if (ret && !drv->no_kernel_api_dma)
> > + iommu_device_unuse_dma_api(dev);
>
> So you are now going to call this for every platform driver _unless_
> they set this flag?
Yes, it is necessary because VFIO suppor
On Mon, Feb 14, 2022 at 12:27:05PM +0100, Joerg Roedel wrote:
> On Thu, Jan 06, 2022 at 10:33:45AM -0400, Jason Gunthorpe wrote:
> > But I'm not sure how this can work with multi-device groups - this
> > seems to assigns a domain setup for direct map, so perhaps this only
>
On Mon, Feb 14, 2022 at 01:51:06PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 14, 2022 at 08:38:42AM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
&g
On Mon, Feb 14, 2022 at 12:39:36PM +0100, Joerg Roedel wrote:
> This extends iommu_attach_device() to behave as iommu_attach_group(),
> changing the domain for the whole group.
Of course, the only action to take is to change the domain of a
group..
> Wouldn't it be better to scrap the iommu_att
On Mon, Feb 14, 2022 at 12:09:36PM +, Robin Murphy wrote:
> On 2022-01-06 02:20, Lu Baolu wrote:
> > Expose an interface to replace the domain of an iommu group for frameworks
> > like vfio which claims the ownership of the whole iommu group.
>
> But if the underlying point is the new expectat
On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> > Multiple PCI devices may be placed in the same IOMMU group because
> > they cannot be isolated from each other. These devices must either be
> > entirely under kernel
On Mon, Feb 07, 2022 at 02:41:32PM +0800, Lu Baolu wrote:
> Hi folks,
>
> After a long time of evolution, the drivers/iommu/intel/iommu.c becomes
> fat and a bit messy. This series tries to cleanup and refactor the
> driver to make it more concise. Your comments are very appreciated.
I wanted to
tion of domain_alloc,
> > are IOMMU API internals.
>
> I can't say I like the default_domain_ops concept all that much, but
> the split itself looks like a good idea and done nicely.
I agree, but don't think it is worth aruging ab
On Tue, Feb 08, 2022 at 09:25:58AM +0800, Lu Baolu wrote:
> Convert all the feasible instances of dev->bus->iommu_ops to
> dev_iommu_ops() in order to making the operation of obtaining
> iommu_ops from a device consistent.
Why are there two patches doing this conversion? Roll this into the
prior p
rtions(+), 17 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
IOMMU subsystem itself, so we should be able to trust
> + * ourselves not to misuse the helper.
> + */
> + WARN_ON(!dev || !dev->iommu || !dev->iommu->iommu_dev ||
> + !dev->iommu->iommu_dev->ops);
IMHO this is overzealous. The kernel wi
s://lore.kernel.org/r/20211218074546.1772553-1-baolu...@linux.intel.com
> Reviewed-by: Christoph Hellwig
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
IMHO it is weird that the ops have a pgsize_bitmap at all.
Rev
;s
> no driver using this anymore. Remove it to avoid dead code.
>
> Suggested-by: Robin Murphy
> Signed-off-by: Lu Baolu
> ---
> include/linux/iommu.h | 4
> drivers/iommu/iommu.c | 3 ---
> 2 files changed, 7 deletions(-)
ned-off-by: Lu Baolu
> Reviewed-by: Christoph Hellwig
> ---
> include/linux/iommu.h | 29 ---
> drivers/iommu/iommu.c | 46 ---
> 2 files changed, 75 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
__
gt; drivers/iommu/intel/debugfs.c | 3 +-
> drivers/iommu/intel/iommu.c | 309 +-
> 3 files changed, 3 insertions(+), 326 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@li
ned-off-by: Lu Baolu
> Reviewed-by: Christoph Hellwig
> ---
> include/linux/iommu.h | 44
> include/uapi/linux/iommu.h | 181
> drivers/iommu/iommu.c | 210 -
> 3 files changed, 435 dele
--
> 6 files changed, 604 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Jan 27, 2022 at 05:26:12PM -0700, Logan Gunthorpe wrote:
> When P2PDMA pages are passed to userspace, they will need to be
> reference counted properly and returned to their genalloc after their
> reference count returns to 1. This is accomplished with the existing
It is reference count re
On Thu, Jan 27, 2022 at 05:25:52PM -0700, Logan Gunthorpe wrote:
> From: Ralph Campbell
>
> ZONE_DEVICE struct pages have an extra reference count that complicates the
> code for put_page() and several places in the kernel that need to check the
> reference count to see that a page is not being u
On Wed, Jan 26, 2022 at 09:51:36AM +0800, Lu Baolu wrote:
> > > they are fundamentally different things in their own right, and the ideal
> > > API should give us the orthogonality to also bind a device to an SVA
> > > domain
> > > without PASID (e.g. for KVM stage 2, or userspace assignment of s
On Tue, Jan 25, 2022 at 02:48:02PM +, Robin Murphy wrote:
> Agreed, certainly an IOMMU_DOMAIN_SVA type that can both encapsulate the mm
> and effectively replace iommu_sva seems like a logical and fairly small next
> step. We already have the paradigm of different domain types supporting
> di
On Tue, Jan 25, 2022 at 02:23:52PM +, Robin Murphy wrote:
> On 2022-01-25 06:27, Lu Baolu wrote:
> Where it's just about which operations are valid for which domains, it's
> even simpler for the core interface wrappers to validate the domain type,
> rather than forcing drivers to implement mul
On Tue, Jan 25, 2022 at 12:59:14PM +0800, Lu Baolu wrote:
> On 1/24/22 5:58 PM, Tian, Kevin wrote:
> > > From: Lu Baolu
> > > Sent: Monday, January 24, 2022 3:11 PM
> > > +/**
> > > + * struct domain_ops - per-domain ops
> > > + * @attach_dev: attach an iommu domain to a device
> > > + * @detach_d
On Mon, Jan 24, 2022 at 03:11:02PM +0800, Lu Baolu wrote:
> - int (*enable_nesting)(struct iommu_domain *domain);
Perhaps for another series, but enable_nesting looks like dead code
too, AFAICT.
Or at the very least I can't figure how out VFIO_TYPE1_NESTING_IOMMU
is supposed to work, or find
On Mon, Jan 24, 2022 at 09:46:26AM +, Tian, Kevin wrote:
> > From: Lu Baolu
> > Sent: Monday, January 24, 2022 3:11 PM
> >
> > Hi,
> >
> > The guest pasid and aux-domain related code are dead code in current
> > iommu subtree. As we have reached a consensus that all these features
> > should
On Mon, Jan 24, 2022 at 03:11:01PM +0800, Lu Baolu wrote:
> The common iommu_ops is hooked to both device and domain. When a helper
> has both device and domain pointer, the way to get the iommu_ops looks
> messy in iommu core. This sorts out the way to get iommu_ops. The device
> related helpers g
On Mon, Jan 24, 2022 at 01:37:21AM -0800, Christoph Hellwig wrote:
> On Mon, Jan 24, 2022 at 03:11:02PM +0800, Lu Baolu wrote:
> > Add a domain specific callback set, domain_ops, for vendor iommu driver
> > to provide domain specific operations. Move domain-specific callbacks
> > from iommu_ops to
On Mon, Jan 24, 2022 at 09:58:18AM +, Tian, Kevin wrote:
> > From: Lu Baolu
> > Sent: Monday, January 24, 2022 3:11 PM
> > +/**
> > + * struct domain_ops - per-domain ops
> > + * @attach_dev: attach an iommu domain to a device
> > + * @detach_dev: detach an iommu domain from a device
>
> What
On Mon, Jan 24, 2022 at 10:16:07AM +, Jean-Philippe Brucker wrote:
> On Mon, Jan 24, 2022 at 09:58:18AM +, Tian, Kevin wrote:
> > > From: Lu Baolu
> > > Sent: Monday, January 24, 2022 3:11 PM
> > > +/**
> > > + * struct domain_ops - per-domain ops
> > > + * @attach_dev: attach an iommu dom
On Fri, Jan 07, 2022 at 09:14:38AM +0800, Lu Baolu wrote:
> > Once we know our calling context we can always automatic switch from
> > DMA API mode to another domain without any trouble or special
> > counters:
> >
> > if (!dev->driver->no_kernel_api_dma) {
> > if (group->owner_cnt > 1 || gr
On Fri, Jan 07, 2022 at 08:35:34AM +0800, Lu Baolu wrote:
> On 1/6/22 11:35 PM, Jason Gunthorpe wrote:
> > On Thu, Jan 06, 2022 at 10:20:51AM +0800, Lu Baolu wrote:
> > > Ordinary drivers should use iommu_attach/detach_device() for domain
> > > attaching and detaching.
the same address space" is still guaranteed.
>
> For multiple devices belonging to a same group, iommu_device_use_dma_api()
> and iommu_attach_device() are exclusive. Therefore, when drivers decide to
> use iommu_attach_domain(), they cannot call iommu_device_use_dma_api() at
>
On Thu, Jan 06, 2022 at 10:20:46AM +0800, Lu Baolu wrote:
> Expose an interface to replace the domain of an iommu group for frameworks
> like vfio which claims the ownership of the whole iommu group.
>
> Signed-off-by: Lu Baolu
> include/linux/iommu.h | 10 ++
> drivers/iommu/iommu.c | 3
On Thu, Jan 06, 2022 at 11:54:06AM +0800, Lu Baolu wrote:
> On 1/5/22 3:23 AM, Jason Gunthorpe wrote:
> > > > > The device driver oriented interfaces are,
> > > > >
> > > > > int iommu_device_use_dma_api(struct device *dev);
> > > >
On Thu, Jan 06, 2022 at 10:20:51AM +0800, Lu Baolu wrote:
> Ordinary drivers should use iommu_attach/detach_device() for domain
> attaching and detaching.
>
> Signed-off-by: Lu Baolu
> drivers/gpu/host1x/dev.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/
On Thu, Jan 06, 2022 at 10:20:50AM +0800, Lu Baolu wrote:
> The individual device driver should use iommu_attach/detach_device()
> for domain attachment/detachment.
>
> Signed-off-by: Lu Baolu
> drivers/iommu/amd/iommu_v2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --
On Tue, Jan 04, 2022 at 01:51:30PM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 04, 2022 at 03:26:14PM -0400, Jason Gunthorpe wrote:
> > On Tue, Jan 04, 2022 at 11:06:31AM -0600, Bjorn Helgaas wrote:
> >
> > > > The existing vfio framework allows the portdrv driver to be
On Tue, Jan 04, 2022 at 11:06:31AM -0600, Bjorn Helgaas wrote:
> > The existing vfio framework allows the portdrv driver to be bound
> > to the bridge while its downstream devices are assigned to user space.
>
> I.e., the existing VFIO framework allows a switch to be in the same
> IOMMU group as
On Tue, Jan 04, 2022 at 10:41:00AM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 04, 2022 at 02:08:00AM -0800, Christoph Hellwig wrote:
> > On Tue, Jan 04, 2022 at 09:56:31AM +0800, Lu Baolu wrote:
> > > Multiple devices may be placed in the same IOMMU group because they
> > > cannot be isolated from e
On Tue, Jan 04, 2022 at 09:56:30AM +0800, Lu Baolu wrote:
> v5:
> - Move kernel dma ownership auto-claiming from driver core to bus
> callback. (Greg)
> - Refactor the iommu interfaces to make them more specific.
> (Jason/Robin)
> - Simplify the dma ownership implementation by removi
On Tue, Jan 04, 2022 at 02:08:36AM -0800, Christoph Hellwig wrote:
> All these bus callouts still looks horrible and just create tons of
> boilerplate code.
Yes, Lu - Greg asked questions then didn't respond to their answers
meaning he accepts them, you should stick with the v4 version.
Jason
___
On Fri, Dec 31, 2021 at 09:10:43AM +0800, Lu Baolu wrote:
> We still need to call iommu_device_use_dma_api() in bus dma_configure()
> callback. But we can call iommu_device_unuse_dma_api() in the .probe()
> of vfio (and vfio-approved) drivers, so that we don't need the new flag
> anymore.
No, we
On Thu, Dec 30, 2021 at 04:24:14PM -0600, Bjorn Helgaas wrote:
> I was speculating that maybe the DMA ownership claiming must be done
> *before* the driver's .probe() method?
This is correct.
> If DMA ownership could be claimed by the .probe() method, we
> wouldn't need the new flag in struct
On Thu, Dec 23, 2021 at 03:23:54PM +0800, Lu Baolu wrote:
> > If this is a bug in the existing kernel, please submit it as a separate
> > patch so that it can be properly backported to all affected kernels.
> > Never bury it in an unrelated change that will never get sent to older
> > kernels.
>
On Fri, Dec 24, 2021 at 11:19:44AM +0800, Lu Baolu wrote:
> Let me summarize what I've got from above comments.
>
> 1. Essentially we only need below interfaces for device drivers to
>manage the I/O address conflict in iommu layer:
>
> int iommu_device_set/release/query_kernel_dma(struct dev
On Fri, Dec 24, 2021 at 09:30:17AM +0800, Lu Baolu wrote:
> Hi Jason,
>
> On 12/23/21 10:03 PM, Jason Gunthorpe wrote:
> > > > I think it would be clear why iommu_group_set_dma_owner(), which
> > > > actually does detatch, is not the
On Thu, Dec 23, 2021 at 01:53:24PM +0800, Lu Baolu wrote:
> > This series is going in the direction of eliminating
> > iommu_attach_group() as part of the driver
> > interface. iommu_attach_group() is repurposed to only be useful for
> > VFIO.
>
> We can also remove iommu_attach_group() in VFIO b
On Wed, Dec 22, 2021 at 08:26:34PM +, Robin Murphy wrote:
> On 21/12/2021 6:46 pm, Jason Gunthorpe wrote:
> > On Tue, Dec 21, 2021 at 04:50:56PM +, Robin Murphy wrote:
> >
> > > this proposal is the worst of both worlds, in that drivers still have to
> &g
On Wed, Dec 22, 2021 at 01:47:34PM +0100, Greg Kroah-Hartman wrote:
> Right now we only have 4 different "busses" that care about this. Out
> of the following callbacks:
> fsl_mc_dma_configure
> host1x_dma_configure
> pci_dma_configure
> platform_dma_configure
>
> Which o
On Tue, Dec 21, 2021 at 04:50:56PM +, Robin Murphy wrote:
> this proposal is the worst of both worlds, in that drivers still have to be
> just as aware of groups in order to know whether to call the _shared
> interface or not, except it's now entirely implicit and non-obvious.
Drivers are not
; ---
> V2: Handle the INTx case directly instead of trying to be overly smart - Marc
> ---
> drivers/pci/msi/msi.c | 25 +
> 1 file changed, 5 insertions(+), 20 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
_
> 2 files changed, 38 insertions(+)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
c: "Cédric Le Goater"
> Cc: linuxppc-...@lists.ozlabs.org
>
> ---
> V2: Remove it completely - Cedric
> ---
> arch/powerpc/platforms/pseries/msi.c | 33 -
> 1 file changed, 8 insertions
_enabled - Jason
> ---
> arch/powerpc/platforms/pseries/msi.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe
> --- a/arch/powerpc/platforms/pseries/msi.c
> +++ b/arch/powerpc/platforms/pseries/msi.c
> @@ -448,8 +4
lists.ozlabs.org
> ---
> V3: Use pci_dev property - Jason
> V2: Invoke the function with the correct number of arguments - Andy
> ---
> arch/powerpc/platforms/cell/axon_msi.c |5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
> kernel/irq/msi.c | 17 ++---
> 1 file changed, 2 insertions(+), 15 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
d.
> ---
> arch/x86/pci/xen.c |9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
301 - 400 of 1012 matches
Mail list logo
