On Wed, Nov 27, 2019 at 08:56:25AM +0200, Mike Rapoport wrote:
> Maybe we'll simply force bottom up allocation before calling
> swiotlb_init()? Anyway, it's the last memblock allocation.
That should work, but I don't think it is the proper fix. The underlying
issue here is that ZONE_DMA/DMA32
On 26/11/2019 20:27, Saravana Kannan wrote:
On Tue, Nov 26, 2019 at 1:13 AM John Garry wrote:
On 21/11/2019 11:49, Will Deacon wrote:
Forcefully unbinding the Arm SMMU drivers is a pretty dangerous operation,
since it will likely lead to catastrophic failure for any DMA devices
mastering
On 27/11/2019 11:04, John Garry wrote:
On 26/11/2019 20:27, Saravana Kannan wrote:
On Tue, Nov 26, 2019 at 1:13 AM John Garry wrote:
On 21/11/2019 11:49, Will Deacon wrote:
Forcefully unbinding the Arm SMMU drivers is a pretty dangerous
operation,
since it will likely lead to catastrophic
On 25/11/2019 16:04, Lorenzo Pieralisi wrote:
On Fri, Nov 22, 2019 at 06:41:25PM +0100, Ard Biesheuvel wrote:
Add support for SMMU drivers built as modules to the ACPI/IORT device
probing path, by deferring the probe of the master if the SMMU driver is
known to exist but has not been loaded
On 27/11/2019 2:16 pm, Thierry Reding wrote:
[...]
Nevermind that, I figured out that I was missingthe initialization of
some of the S2CR variables. I've got something that I think is working
now, though I don't know yet how to go about cleaning up the initial
mapping and "recycling" it.
I'll
On Wed, Nov 27, 2019 at 01:16:54PM +0100, Thierry Reding wrote:
> On Tue, Sep 17, 2019 at 06:59:50PM +0100, Will Deacon wrote:
> > On Mon, Sep 02, 2019 at 04:52:45PM +0200, Thierry Reding wrote:
> > > On Mon, Sep 02, 2019 at 03:22:35PM +0100, Robin Murphy wrote:
> > > > On 29/08/2019 12:14,
This function isn't used in the fast path, and moving it out of line
will reduce include clutter with the next change.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-mapping.h | 14 +-
kernel/dma/mapping.c| 15 +++
2 files changed, 16 insertions(+), 13
Hi all,
this little series fixes dma_addressing_limited to return true for
systems that use bounce buffers due to memory encryption.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Devices that are forced to DMA through unencrypted bounce buffers
need to be treated as if they are addressing limited.
Signed-off-by: Christoph Hellwig
---
kernel/dma/mapping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index
On 27 November 2019 at 07:56 am, Mike Rapoport wrote:
Maybe we'll simply force bottom up allocation before calling
swiotlb_init()? Anyway, it's the last memblock allocation.
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 62f74b1b33bd..771e6cf7e2b9 100644
---
The PLX PEX NTB forwards DMA transactions using Requester ID's that
don't exist as PCI devices. The devfn for a transaction is used as an
index into a lookup table storing the origin of a transaction on the
other side of the bridge.
This patch aliases all possible devfn's to the NTB device so
pci_add_dma_alias can now be used to create a dma alias for a range of
devfns.
Signed-off-by: James Sewart
---
drivers/pci/pci.c| 21 -
drivers/pci/quirks.c | 14 +++---
include/linux/pci.h | 2 +-
3 files changed, 24 insertions(+), 13 deletions(-)
diff --git
> On Nov 27, 2019, at 1:01 PM, John Garry wrote:
>
> I haven't gone into the details, but this patch alone is giving this:
>
> root@(none)$ [ 123.857024] kmemleak: 8 new suspected memory leaks (see
> /sys/kernel/debug/kmemleak)
>
> root@(none)$ cat /sys/kernel/debug/kmemleak
>
Hi Bjorn,
On Tue, 2019-11-26 at 15:50 -0600, Bjorn Helgaas wrote:
> On Tue, Nov 26, 2019 at 10:19:38AM +0100, Nicolas Saenz Julienne wrote:
> > This series aims at providing support for Raspberry Pi 4's PCIe
> > controller, which is also shared with the Broadcom STB family of
> > devices.
> > Jim
On Wed, 2019-11-27 at 18:06 +, Robin Murphy wrote:
> On 26/11/2019 12:51 pm, Leon Romanovsky wrote:
> > On Tue, Nov 26, 2019 at 10:19:39AM +0100, Nicolas Saenz Julienne wrote:
> > > Some users need to make sure their rounding function accepts and returns
> > > 64bit long variables regardless
On 27/11/2019 6:24 pm, Nicolas Saenz Julienne wrote:
On Wed, 2019-11-27 at 18:06 +, Robin Murphy wrote:
On 26/11/2019 12:51 pm, Leon Romanovsky wrote:
On Tue, Nov 26, 2019 at 10:19:39AM +0100, Nicolas Saenz Julienne wrote:
Some users need to make sure their rounding function accepts and
On Wed, 2019-11-27 at 19:06 +, Robin Murphy wrote:
> On 27/11/2019 6:24 pm, Nicolas Saenz Julienne wrote:
> > On Wed, 2019-11-27 at 18:06 +, Robin Murphy wrote:
> > > On 26/11/2019 12:51 pm, Leon Romanovsky wrote:
> > > > On Tue, Nov 26, 2019 at 10:19:39AM +0100, Nicolas Saenz Julienne
Hi,
On Wed, 2019-11-27 at 15:40 +0100, Christoph Hellwig wrote:
> Devices that are forced to DMA through unencrypted bounce buffers
> need to be treated as if they are addressing limited.
>
> Signed-off-by: Christoph Hellwig
> ---
> kernel/dma/mapping.c | 2 ++
> 1 file changed, 2
On Wed, Nov 27, 2019 at 07:06:12PM +, Robin Murphy wrote:
> On 27/11/2019 6:24 pm, Nicolas Saenz Julienne wrote:
> > On Wed, 2019-11-27 at 18:06 +, Robin Murphy wrote:
> > > On 26/11/2019 12:51 pm, Leon Romanovsky wrote:
> > > > On Tue, Nov 26, 2019 at 10:19:39AM +0100, Nicolas Saenz
On Tue, 2019-11-26 at 10:19 +0100, Nicolas Saenz Julienne wrote:
> Some users need to make sure their rounding function accepts and returns
> 64bit long variables regardless of the architecture. Sadly
> roundup/rounddown_pow_two() takes and returns unsigned longs. Create a
> new generic 64bit
On 21/11/2019 00:13, Cong Wang wrote:
The IOVA cache algorithm implemented in IOMMU code does not
exactly match the original algorithm described in the paper.
Particularly, it doesn't need to free the loaded empty magazine
when trying to put it back to global depot.
This patch makes it exactly
On 2019-11-27 6:27 a.m., James Sewart wrote:
> * This helper encodes an 8-bit devfn as a bit number in dma_alias_mask
> * which is used to program permissible bus-devfn source addresses for DMA
> @@ -5873,8 +5874,12 @@ int pci_set_vga_state(struct pci_dev *dev, bool decode,
> * cannot be
On 26/11/2019 12:51 pm, Leon Romanovsky wrote:
On Tue, Nov 26, 2019 at 10:19:39AM +0100, Nicolas Saenz Julienne wrote:
Some users need to make sure their rounding function accepts and returns
64bit long variables regardless of the architecture. Sadly
roundup/rounddown_pow_two() takes and
On Wed, Nov 27, 2019 at 02:11:28PM -0800, David Rientjes wrote:
> So we're left with making dma_pool_alloc(GFP_ATOMIC) actually be atomic
> even when the DMA needs to be unencrypted for SEV. Christoph's suggestion
> was to wire up dmapool in kernel/dma/remap.c for this. Is that necessary
> to
On Wed, Nov 27, 2019 at 06:22:57PM +, Thomas Hellstrom wrote:
> > bool dma_addressing_limited(struct device *dev)
> > {
> > + if (force_dma_unencrypted(dev))
> > + return true;
> > return min_not_zero(dma_get_mask(dev), dev->bus_dma_limit) <
> >
Hi, I am interested in writing a program to verify BIOS integrity via
SHA512. Most modern BIOS'es seem to be accessible through IOMMU. I'm
wondering if there is a device driver for IOMMU or whether one could
be created for the purposes of accessing BIOS memory.
If anyone has any leads or advice
On Wed, 18 Sep 2019, Christoph Hellwig wrote:
> On Tue, Sep 17, 2019 at 06:41:02PM +, Lendacky, Thomas wrote:
> > > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> > > --- a/drivers/nvme/host/pci.c
> > > +++ b/drivers/nvme/host/pci.c
> > > @@ -1613,7 +1613,8 @@ static int
This checks whether a domain should use first level page table
for map/unmap. And if so, we should attach the domain to the
device in first level translation mode.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Cc: Sanjay Kumar
Signed-off-by: Lu Baolu
---
This adds functions to manipulate first level page tables
which could be used by a scalale mode capable IOMMU unit.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Signed-off-by: Lu Baolu
---
drivers/iommu/Makefile | 2 +-
drivers/iommu/intel-iommu.c
This adds the implementation of page table callbacks for
the second level page table.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 81 +
1 file changed, 81 insertions(+)
Intel VT-d in scalable mode supports two types of page talbes
for DMA translation: the first level page table and the second
level page table. The first level page table uses the same
format as the CPU page table, while the second level page table
keeps compatible with previous formats. The
So that it could be used in other source files as well.
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 7 ---
include/linux/intel-iommu.h | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index
This applies per domain page table ops to various domain
mapping and unmapping interfaces.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 118
1 file changed, 52 insertions(+), 66 deletions(-)
diff
The Intel VT-d in scalable mode supports two types of
page talbes for DMA translation: the first level page
table and the second level page table. The IOMMU driver
is able to choose one of them for DMA remapping according
to the use case. The first level page table uses the same
format as the CPU
This adds the Intel VT-d specific callback of setting
DOMAIN_ATTR_NESTING domain attribution. It is necessary
to let the VT-d driver know that the domain represents
a virutual machine which requires the IOMMU hardware to
support nested translation mode. Return success if the
IOMMU hardware suports
This adds the implementation of page table callbacks for
the first level page table.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Liu Yi L
Cc: Yi Sun
Signed-off-by: Lu Baolu
---
drivers/iommu/intel-iommu.c | 56 +
1 file changed, 56 insertions(+)
diff
On Tue, Sep 17, 2019 at 06:59:50PM +0100, Will Deacon wrote:
> On Mon, Sep 02, 2019 at 04:52:45PM +0200, Thierry Reding wrote:
> > On Mon, Sep 02, 2019 at 03:22:35PM +0100, Robin Murphy wrote:
> > > On 29/08/2019 12:14, Thierry Reding wrote:
> > > > From: Thierry Reding
> > > >
> > > > For
37 matches
Mail list logo
