From: Jon Derrick
The PCI devices handled by intel-iommu may have a DMA requester on
another bus, such as VMD subdevices needing to use the VMD endpoint.
The real DMA device is now used for the DMA mapping, but one case was
missed earlier: if the VMD device (and hence subdevices too) are under
I
> From: Liu, Yi L
> Sent: Friday, January 31, 2020 8:41 PM
> To: Alex Williamson
> Subject: RE: [RFC v3 1/8] vfio: Add VFIO_IOMMU_PASID_REQUEST(alloc/free)
> > > +static int vfio_iommu_type1_pasid_free(struct vfio_iommu *iommu,
> > > +unsigned int pasid)
> > > +{
>
Hi Joerg,
Thanks for doing this.
On 2020/2/18 3:38, Joerg Roedel wrote:
From: Joerg Roedel
The attachment of deferred devices needs to happen before the check
whether the device is identity mapped or not. Otherwise the check will
return wrong results, cause warnings boot failures in kdump ker
On Mon Feb 17 20, Joerg Roedel wrote:
From: Joerg Roedel
The function only has one call-site and there it is never called with
dummy or deferred devices. Simplify the check in the function to
account for that.
Signed-off-by: Joerg Roedel
Reviewed-by: Jerry Snitselaar
_
On Mon Feb 17 20, Joerg Roedel wrote:
From: Joerg Roedel
The attachment of deferred devices needs to happen before the check
whether the device is identity mapped or not. Otherwise the check will
return wrong results, cause warnings boot failures in kdump kernels, like
WARNING: CPU: 0
On Mon Feb 17 20, Joerg Roedel wrote:
From: Joerg Roedel
The function is now only a wrapper around find_domain(). Remove the
function and call find_domain() directly at the call-sites.
Signed-off-by: Joerg Roedel
Reviewed-by: Jerry Snitselaar
__
On Mon Feb 17 20, Joerg Roedel wrote:
From: Joerg Roedel
Move the code that does the deferred device attachment into a separate
helper function.
Signed-off-by: Joerg Roedel
Reviewed-by: Jerry Snitselaar
___
iommu mailing list
iommu@lists.linux-f
On Mon Feb 17 20, Joerg Roedel wrote:
From: Joerg Roedel
Implement a helper function to check whether a device's attach process
is deferred.
Signed-off-by: Joerg Roedel
Reviewed-by: Jerry Snitselaar
___
iommu mailing list
iommu@lists.linux-found
From: Joerg Roedel
The function is now only a wrapper around find_domain(). Remove the
function and call find_domain() directly at the call-sites.
Signed-off-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers
From: Joerg Roedel
The attachment of deferred devices needs to happen before the check
whether the device is identity mapped or not. Otherwise the check will
return wrong results, cause warnings boot failures in kdump kernels, like
WARNING: CPU: 0 PID: 318 at ../drivers/iommu/intel-iommu
From: Joerg Roedel
Move the code that does the deferred device attachment into a separate
helper function.
Signed-off-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers
Hi,
booting into a crashdump kernel with Intel IOMMU enabled and
configured into passthrough mode does not succeed with the current
kernel. The reason is that the check for identity mappings happen
before the check for deferred device attachments. That results in
wrong results returned from iommu_
From: Joerg Roedel
The function only has one call-site and there it is never called with
dummy or deferred devices. Simplify the check in the function to
account for that.
Signed-off-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
From: Joerg Roedel
Implement a helper function to check whether a device's attach process
is deferred.
Signed-off-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-
On 13/02/2020 9:49 pm, Rob Herring wrote:
On Thu, Jan 30, 2020 at 11:34 AM Robin Murphy wrote:
On 30/01/2020 3:06 pm, Auger Eric wrote:
Hi Rob,
On 1/17/20 10:16 PM, Rob Herring wrote:
Arm SMMUv3.2 adds support for TLB range invalidate operations.
Support for range invalidate is determined by
On Thu, Feb 13, 2020 at 02:56:00PM -0600, Rob Herring wrote:
> Similar to commit 2af2e72b18b4 ("iommu/arm-smmu-v3: Defer TLB
> invalidation until ->iotlb_sync()"), build up a list of ATC invalidation
> commands and submit them all at once to the command queue instead of
> one-by-one.
>
> As there
On 14/02/2020 8:30 pm, Liam Mark wrote:
When the IOVA framework applies IOVA alignment it aligns all
IOVAs to the smallest PAGE_SIZE order which is greater than or
equal to the requested IOVA size.
We support use cases that requires large buffers (> 64 MB in
size) to be allocated and mapped in
On 14/02/2020 11:06 pm, Isaac J. Manjarres wrote:
From: Liam Mark
Using the best-fit algorithm, instead of the first-fit
algorithm, may reduce fragmentation when allocating
IOVAs.
What kind of pathological allocation patterns make that a serious
problem? Is there any scope for simply changin
On 17/02/2020 8:01 am, Christoph Hellwig wrote:
On Fri, Feb 14, 2020 at 02:58:16PM -0800, Isaac J. Manjarres wrote:
From: Liam Mark
Some devices have a memory map which contains gaps or holes.
In order for the device to have as much IOVA space as possible,
allow its driver to inform the DMA-IO
On Sat, Feb 15, 2020 at 03:10:47PM -0600, Bjorn Helgaas wrote:
> On Thu, Feb 13, 2020 at 05:50:40PM +0100, Jean-Philippe Brucker wrote:
> > Each vendor has their own way of describing whether a host bridge
> > supports ATS. The Intel and AMD ACPI tables selectively enable or
> > disable ATS per de
On Mon Feb 17 20, Robin Murphy wrote:
On 16/02/2020 10:11 pm, Jerry Snitselaar wrote:
On Fri Feb 14 20, Robin Murphy wrote:
Hi Jerry,
On 2020-02-14 8:13 pm, Jerry Snitselaar wrote:
Hi Will,
On a gigabyte system with Cavium CN8xx, when doing a fio test against
an nvme drive we are seeing the
On 17/02/2020 1:31 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 01:22:44PM +, Robin Murphy wrote:
On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wr
On Mon, Feb 17, 2020 at 01:22:44PM +, Robin Murphy wrote:
> On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
> > On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
> > > On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
> > > > On Fri, Feb 14, 2020 at 04:57
On 17/02/2020 1:01 pm, Michael S. Tsirkin wrote:
On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
On Fri, Feb 14, 2020 at 04:57:11PM +, Robin Murphy wrote:
On 14/02/2020 4:04 pm, Jean-Philippe Brucker
On 16/02/2020 10:11 pm, Jerry Snitselaar wrote:
On Fri Feb 14 20, Robin Murphy wrote:
Hi Jerry,
On 2020-02-14 8:13 pm, Jerry Snitselaar wrote:
Hi Will,
On a gigabyte system with Cavium CN8xx, when doing a fio test against
an nvme drive we are seeing the following:
[ 637.161194] arm-smmu arm
On Mon, Feb 17, 2020 at 10:01:07AM +0100, Jean-Philippe Brucker wrote:
> On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
> > On Fri, Feb 14, 2020 at 04:57:11PM +, Robin Murphy wrote:
> > > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> > > > With the built-in topology
On Thu, Feb 13, 2020 at 12:26:46PM -0600, Rob Herring wrote:
> On Thu, Feb 13, 2020 at 10:52 AM Jean-Philippe Brucker
> wrote:
> >
> > Copy the ats-supported flag into the pci_host_bridge structure.
> >
> > Signed-off-by: Jean-Philippe Brucker
> > ---
> > drivers/pci/controller/pci-host-common.c
Right, and even worse is that it relies on the port driver even
existing at all.
All this iommu group assignment should be taken outside device driver
probe paths.
However we could still consider device links for sync'ing the SMMU and
each device probing.
Yes, we should get that for DT n
Hi Fabien,
Thanks very much for your patch.
On Mon, 2020-02-17 at 09:15 +0800, CK Hu wrote:
> +Yong.Wu.
>
> On Fri, 2020-01-03 at 17:26 +0100, Fabien Parent wrote:
> > Add support for the IOMMU on MT8167
> >
> > Signed-off-by: Fabien Parent
> > ---
> > drivers/iommu/mtk_iommu.c | 11 +
On Fri, Feb 14, 2020 at 05:03:16PM +, Robin Murphy wrote:
> On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> > Hardware platforms usually describe the IOMMU topology using either
> > device-tree pointers or vendor-specific ACPI tables. For virtual
> > platforms that don't provide a device
On Sun, Feb 16, 2020 at 04:50:33AM -0500, Michael S. Tsirkin wrote:
> On Fri, Feb 14, 2020 at 04:57:11PM +, Robin Murphy wrote:
> > On 14/02/2020 4:04 pm, Jean-Philippe Brucker wrote:
> > > With the built-in topology description in place, x86 platforms can now
> > > use the virtio-iommu.
> > >
On Fri, Feb 14, 2020 at 03:06:42PM -0800, Isaac J. Manjarres wrote:
> From: Liam Mark
>
> Using the best-fit algorithm, instead of the first-fit
> algorithm, may reduce fragmentation when allocating
> IOVAs.
As we like to say in standards groups: may also implies may not.
Please provide numbers
On Fri, Feb 14, 2020 at 02:58:16PM -0800, Isaac J. Manjarres wrote:
> From: Liam Mark
>
> Some devices have a memory map which contains gaps or holes.
> In order for the device to have as much IOVA space as possible,
> allow its driver to inform the DMA-IOMMU layer that it should
> not allocate a
33 matches
Mail list logo
