The pull request you sent on Fri, 8 Apr 2022 13:52:06 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fix-v5.18-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/02994fd2da76b99d3f6777f5b3bdb5d2823a0fed
Thank you!
--
On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote:
> You might consider using a linear tree instead of the topic branches,
> topics are tricky and I'm not sure it helps a small subsystem so much.
> Conflicts between topics are a PITA for everyone, and it makes
> handling conflicts
On Thu, 7 Apr 2022 12:23:45 -0300
Jason Gunthorpe wrote:
> IOMMU_CACHE means "normal DMA to this iommu_domain's IOVA should be cache
> coherent" and is used by the DMA API. The definition allows for special
> non-coherent DMA to exist - ie processing of the no-snoop flag in PCIe
> TLPs - so
On 2022-04-08 14:35, Jason Gunthorpe wrote:
On Fri, Apr 08, 2022 at 02:11:10PM +0100, Robin Murphy wrote:
However, this creates an oddball situation where the vfio_device and
it's struct device could become unplugged from the system while the
domain that the struct device spawned continues to
On Fri, Apr 08, 2022 at 05:37:16PM +0200, Joerg Roedel wrote:
> On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote:
> > You might consider using a linear tree instead of the topic branches,
> > topics are tricky and I'm not sure it helps a small subsystem so much.
> > Conflicts
On Tue, Apr 05, 2022 at 03:35:59PM +0100, Robin Murphy wrote:
> Rather than hard-coding pci_bus_type, pass the PF device through to
> usnic_uiom_alloc_pd() and retrieve its bus there. This prepares for
> iommu_domain_alloc() changing to take a device rather than a bus_type.
>
> Signed-off-by:
On Tue, Apr 05, 2022 at 01:19:59PM +0100, Robin Murphy wrote:
> Even if an IOMMU might be present for some PCI segment in the system,
> that doesn't necessarily mean it provides translation for the device(s)
> we care about. Replace iommu_present() with a more appropriate check at
> probe time,
On 2022-04-07 18:51, Dmitry Osipenko wrote:
On 4/6/22 21:06, Robin Murphy wrote:
On 2022-04-06 15:32, Dmitry Osipenko wrote:
On 4/5/22 17:19, Robin Murphy wrote:
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device,
On Thu, 7 Apr 2022 12:23:47 -0300
Jason Gunthorpe wrote:
> IOMMU_CACHE means that normal DMAs do not require any additional coherency
> mechanism and is the basic uAPI that VFIO exposes to userspace. For
> instance VFIO applications like DPDK will not work if additional coherency
> operations
On Fri, 8 Apr 2022 10:59:22 -0500
Bjorn Helgaas wrote:
> On Fri, Apr 08, 2022 at 05:37:16PM +0200, Joerg Roedel wrote:
> > On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote:
> > > You might consider using a linear tree instead of the topic branches,
> > > topics are tricky and
On Tue, Apr 05, 2022 at 03:32:50PM +0100, Robin Murphy wrote:
> Defer the IOMMU domain setup until after successfully binding
> components, so we can figure out IOMMU support directly from the VOP
> devices themselves, rather than manually inferring it from the DT (which
> also fails to account
Hello:
This patch was applied to netdev/net-next.git (master)
by Jakub Kicinski :
On Tue, 5 Apr 2022 14:40:55 +0100 you wrote:
> Even if an IOMMU might be present for some PCI segment in the system,
> that doesn't necessarily mean it provides translation for the device
> we care about. It
On Fri, Apr 08, 2022 at 10:07:50AM -0600, Alex Williamson wrote:
> On Fri, 8 Apr 2022 10:59:22 -0500
> Bjorn Helgaas wrote:
>
> > On Fri, Apr 08, 2022 at 05:37:16PM +0200, Joerg Roedel wrote:
> > > On Fri, Apr 08, 2022 at 11:17:47AM -0300, Jason Gunthorpe wrote:
> > > > You might consider
> From: Jason Gunthorpe
> Sent: Thursday, April 7, 2022 11:24 PM
>
> IOMMU_CACHE means that normal DMAs do not require any additional
> coherency
> mechanism and is the basic uAPI that VFIO exposes to userspace. For
> instance VFIO applications like DPDK will not work if additional coherency
>
On Mon, Mar 14, 2022 at 09:21:25PM -0300, Jason Gunthorpe wrote:
> Joerg, are we good for the coming v5.18 merge window now? There are
> several things backed up behind this series.
I usually don't apply bigger changes like this after -rc7, so it didn't
make it. Please re-send after -rc3 is out
> From: Jason Gunthorpe
> Sent: Thursday, April 7, 2022 11:24 PM
>
> This new mechanism will replace using IOMMU_CAP_CACHE_COHERENCY
> and
> IOMMU_CACHE to control the no-snoop blocking behavior of the IOMMU.
>
> Currently only Intel and AMD IOMMUs are known to support this
> feature. They both
> From: Jason Gunthorpe
> Sent: Thursday, April 7, 2022 11:24 PM
>
> IOMMU_CACHE means "normal DMA to this iommu_domain's IOVA should
> be cache
> coherent" and is used by the DMA API. The definition allows for special
> non-coherent DMA to exist - ie processing of the no-snoop flag in PCIe
>
On 2022-04-08 10:08, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Friday, April 8, 2022 3:08 AM
On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
On 2022-04-07 18:43, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 06:03:37PM +0100, Robin Murphy wrote:
At a glance, this all
On Thu, Apr 07, 2022 at 08:39:05AM +0300, Tony Lindgren wrote:
> Can you guys please get this fix into the -rc series? Or ack it so
> I can pick it up into my fixes branch?
Sorry for the delay, Covid catched me so I was away from email for
almost 2 week. This patch is picked-up now and I will
> From: Jason Gunthorpe
> Sent: Friday, April 8, 2022 3:08 AM
> On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
> > On 2022-04-07 18:43, Jason Gunthorpe wrote:
> > > On Thu, Apr 07, 2022 at 06:03:37PM +0100, Robin Murphy wrote:
> > > > At a glance, this all looks about the right
Hi,
* Joerg Roedel [220408 08:23]:
> On Thu, Apr 07, 2022 at 08:39:05AM +0300, Tony Lindgren wrote:
> > Can you guys please get this fix into the -rc series? Or ack it so
> > I can pick it up into my fixes branch?
>
> Sorry for the delay, Covid catched me so I was away from email for
> almost 2
(CC Jason Wang)
> From: Jason Gunthorpe
> Sent: Thursday, April 7, 2022 11:24 PM
>
> While the comment was correct that this flag was intended to convey the
> block no-snoop support in the IOMMU, it has become widely implemented
> and
> used to mean the IOMMU supports IOMMU_CACHE as a map flag.
> From: Tian, Kevin
> Sent: Friday, April 8, 2022 4:06 PM
>
> > From: Jason Gunthorpe
> > Sent: Thursday, April 7, 2022 11:24 PM
> >
> > This new mechanism will replace using IOMMU_CAP_CACHE_COHERENCY
> > and
> > IOMMU_CACHE to control the no-snoop blocking behavior of the IOMMU.
> >
> >
On Thu, Apr 07, 2022 at 08:27:05PM +0100, Robin Murphy wrote:
> On 2022-04-07 20:08, Jason Gunthorpe wrote:
> > On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
> > > On 2022-04-07 18:43, Jason Gunthorpe wrote:
> > > > On Thu, Apr 07, 2022 at 06:03:37PM +0100, Robin Murphy wrote:
> >
On Fri, Apr 08, 2022 at 08:21:55AM +, Tian, Kevin wrote:
> (CC Jason Wang)
>
> > From: Jason Gunthorpe
> > Sent: Thursday, April 7, 2022 11:24 PM
> >
> > While the comment was correct that this flag was intended to convey the
> > block no-snoop support in the IOMMU, it has become widely
On Fri, Apr 08, 2022 at 08:26:10AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 7, 2022 11:24 PM
> >
> > IOMMU_CACHE means that normal DMAs do not require any additional
> > coherency
> > mechanism and is the basic uAPI that VFIO exposes to userspace. For
> >
Hi Joerg,
On 2022/4/8 15:57, Joerg Roedel wrote:
On Mon, Mar 14, 2022 at 09:21:25PM -0300, Jason Gunthorpe wrote:
Joerg, are we good for the coming v5.18 merge window now? There are
several things backed up behind this series.
I usually don't apply bigger changes like this after -rc7, so it
Hi Linus,
The following changes since commit 3123109284176b1532874591f7c81f3837bbdc17:
Linux 5.18-rc1 (2022-04-03 14:08:21 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fix-v5.18-rc1
for you to fetch changes up to
On Fri, Apr 08, 2022 at 08:22:35PM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> On 2022/4/8 15:57, Joerg Roedel wrote:
> > On Mon, Mar 14, 2022 at 09:21:25PM -0300, Jason Gunthorpe wrote:
> > > Joerg, are we good for the coming v5.18 merge window now? There are
> > > several things backed up behind
On 2022-04-08 13:18, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 08:27:05PM +0100, Robin Murphy wrote:
On 2022-04-07 20:08, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
On 2022-04-07 18:43, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 06:03:37PM
On 2022-04-08 13:22, Jason Gunthorpe wrote:
On Fri, Apr 08, 2022 at 08:26:10AM +, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Thursday, April 7, 2022 11:24 PM
IOMMU_CACHE means that normal DMAs do not require any additional
coherency
mechanism and is the basic uAPI that VFIO exposes to
On Fri, Apr 08, 2022 at 02:11:10PM +0100, Robin Murphy wrote:
> > However, this creates an oddball situation where the vfio_device and
> > it's struct device could become unplugged from the system while the
> > domain that the struct device spawned continues to exist and remains
> > attached to
On Fri, Apr 08, 2022 at 09:23:52AM -0300, Jason Gunthorpe wrote:
> Why rc3? It has been 4 weeks now with no futher comments.
Because I start applying new code to branches based on -rc3. In the past
I used different -rc's for the topic branches (usually the latest -rc
available when I started
On Fri, Apr 08, 2022 at 02:28:02PM +0100, Robin Murphy wrote:
> > > One nit. Is it logistically more reasonable to put this patch before
> > > changing VFIO to always set IOMMU_CACHE?
> >
> > For bisectability it has to be after
> >
> > iommu: Redefine IOMMU_CAP_CACHE_COHERENCY as the cap
On Fri, Apr 08, 2022 at 04:00:31PM +0200, Joerg Roedel wrote:
> On Fri, Apr 08, 2022 at 09:23:52AM -0300, Jason Gunthorpe wrote:
> > Why rc3? It has been 4 weeks now with no futher comments.
>
> Because I start applying new code to branches based on -rc3. In the past
> I used different -rc's for
35 matches
Mail list logo
