Thanks for info
See inline
On Wed, Nov 28, 2018 at 8:56 PM Alex Williamson
wrote:
> On Wed, 28 Nov 2018 20:21:02 +0530
> gokul cg wrote:
>
> > Hi Folks,
> >
> > Please excuse me , I just writing to you as i could see you had made
> > changes regarding iommu and I thought you could give help me
The amount of DMA mappings from Hisilicon HNS ethernet devices is huge,
so it could trigger "DMA-API: debugging out of memory - disabling".
hnae_get_handle [1]
hnae_init_queue
hnae_init_ring
hnae_alloc_buffers [2]
debug_dma_map_page
dma_entry_alloc
[1] for (i = 0; i
On Thu, Nov 29, 2018 at 4:52 PM Mika Westerberg
wrote:
>
> A malicious PCI device may use DMA to attack the system. An external
> Thunderbolt port is a convenient point to attach such a device. The OS
> may use IOMMU to defend against DMA attacks.
>
> Recent BIOSes with Thunderbolt ports mark
On Thu, Nov 29, 2018 at 10:53:32AM -0800, Linus Torvalds wrote:
> Most of the high-performance IO is already using SG lists anyway, no?
> Disk/networking/whatever.
Networking basically never uses S/G lists. Block I/O mostly uses it,
and graphics / media seems to have a fair amount of S/G uses,
On Thu, Nov 29, 2018 at 10:31 AM Christoph Hellwig wrote:
>
> > Or, better yet, plan on removing the single-page dma mappign entirely
> > at a later date, and make the issue moot.
>
> What would be the replacement? Build a S/G list for every single page
> mapping? Not sure that would create a
On Thu, Nov 29, 2018 at 09:44:05AM -0800, Linus Torvalds wrote:
> No. Really. If there's no iotlb, then you just mark that one page
> reserved. It simply doesn't get used. It doesn't mean you suddenly
> need a swiotlb.
Sure, we could just skip that page entirely based on dma_to_phys.
> But
On Thu, Nov 29, 2018 at 8:23 AM Christoph Hellwig wrote:
>
> We can. At least in theory. The problem is that depending on the
> crazy mapping from physical and kernel virtual address to dma addresses
> these might be pages at pretty random places. Look at fun like
>
ping, any comments?
On Fri, Nov 09, 2018 at 10:00:06AM +0100, Christoph Hellwig wrote:
> Remove leftovers, and switch the default on enabling SG chaining.
> ___
> iommu mailing list
> iommu@lists.linux-foundation.org
>
On Thu, Nov 29, 2018 at 01:05:23PM +0100, Christian Zigotzky wrote:
> I compiled a test kernel from the following Git today.
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4
>
> Command: git clone git://git.infradead.org/users/hch/misc.git -b
> powerpc-dma.4 a
>
>
> > Please don't apply the new DMA mapping code if you don't be sure if it
> > works on all supported PowerPC machines. Is the new DMA mapping code
> > really necessary? It's not really nice, to rewrote code if the old code
> > works perfect. We must not forget, that we work for the end users.
On Wed, Nov 28, 2018 at 10:05:19PM +1100, Michael Ellerman wrote:
> Is the plan that you take these via the dma-mapping tree or that they go
> via powerpc?
In principle either way is fine with me. If it goes through the powerpc
tree we might run into a few minor conflicts with the dma-mapping
On Wed, Nov 28, 2018 at 11:19:15AM -0800, Linus Torvalds wrote:
> Let me just paste it back in here:
>
> "Which is what we ALREADY do for these exact reasons. If the DMA
> mappings means that you'd need to add one more page to that list of
> reserved pages, then so be it."
>
> So no, I'm not
A malicious PCI device may use DMA to attack the system. An external
Thunderbolt port is a convenient point to attach such a device. The OS
may use IOMMU to defend against DMA attacks.
Recent BIOSes with Thunderbolt ports mark these externally facing root
ports with this ACPI _DSD [1]:
Name
Recent systems with Thunderbolt ports may be utilizing IOMMU to prevent DMA
attacks. This is different from the previous security level based scheme
because the connected device cannot access system memory outside of the
regions allocated for it by the driver.
When enabled the BIOS makes sure no
Recent systems with Thunderbolt ports may support IOMMU natively. In
practice this means that Thunderbolt connected devices are placed behind
an IOMMU during the whole time it is connected (including during boot)
making Thunderbolt security levels redundant. This is called Kernel DMA
protection
From: Lu Baolu
Intel VT-d spec added a new DMA_CTRL_PLATFORM_OPT_IN_FLAG flag in DMAR
ACPI table [1] for BIOS to report compliance about platform initiated
DMA restricted to RMRR ranges when transferring control to the OS. This
means that during OS boot, before it enables IOMMU none of the
On 29 November 2018 at 1:05PM, Christian Zigotzky wrote:
On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
Christoph Hellwig writes:
Any comments? I'd like to at least get the ball moving on the easy
bits.
Nothing specific yet.
I'm a bit worried it might break one of the many old
On Wed, Nov 28, 2018 at 10:07 PM Robin Murphy wrote:
>
> On 28/11/2018 16:24, Stephen Boyd wrote:
> > Quoting Vivek Gautam (2018-11-27 02:11:41)
> >> @@ -1966,6 +1970,23 @@ static const struct of_device_id
> >> arm_smmu_of_match[] = {
> >> };
> >> MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
On Mon 2018-11-26 13:57:09, Sergey Senozhatsky wrote:
> On (11/23/18 12:48), Petr Mladek wrote:
> [..]
> > > This should make serial consoles re-entrant.
> > > So printk->console_driver_write() hopefully will not deadlock.
> >
> > Is the re-entrance safe? Some risk might be acceptable in
On 28 November 2018 at 12:05PM, Michael Ellerman wrote:
Christoph Hellwig writes:
Any comments? I'd like to at least get the ball moving on the easy
bits.
Nothing specific yet.
I'm a bit worried it might break one of the many old obscure platforms
we have that aren't well tested.
There's
On Wed, Nov 28, 2018 at 09:23:36AM +, Yoshihiro Shimoda wrote:
> To avoid adding copy and pasted strcmp codes in the future,
> this patch adds an array "rcar_gen3_slave_whitelist" to check
> whether the device can work with the IPMMU or not.
>
> Signed-off-by: Yoshihiro Shimoda
>
On Wed, Nov 28, 2018 at 09:23:36AM +, Yoshihiro Shimoda wrote:
> Some R-Car Gen3 SoCs has hardware restrictions on the IPMMU. So,
> to check whether this R-Car Gen3 SoC can use the IPMMU correctly,
> this patch modifies the ipmmu_slave_whitelist().
>
> Signed-off-by: Yoshihiro Shimoda
>
From: Geert Uytterhoeven
[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for
From: Geert Uytterhoeven
[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for
From: Lu Baolu
[ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ]
When handling page request without pasid event, go to "no_pasid"
branch instead of "bad_req". Otherwise, a NULL pointer deference
will happen there.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu
From: Geert Uytterhoeven
[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for
From: Pan Bian
[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
Signed-off-by: Pan Bian
Signed-off-by: Joerg Roedel
Signed-off-by:
From: Pan Bian
[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
Signed-off-by: Pan Bian
Signed-off-by: Joerg Roedel
Signed-off-by:
From: Lu Baolu
[ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ]
When handling page request without pasid event, go to "no_pasid"
branch instead of "bad_req". Otherwise, a NULL pointer deference
will happen there.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu
From: Lu Baolu
[ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ]
When handling page request without pasid event, go to "no_pasid"
branch instead of "bad_req". Otherwise, a NULL pointer deference
will happen there.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu
From: Filippo Sironi
[ Upstream commit ab99be4683d9db33b100497d463274ebd23bd67e ]
This register should have been programmed with the physical address
of the memory location containing the shadow tail pointer for
the guest virtual APIC log instead of the base address.
Fixes: 8bda0cfbdc1a
From: Pan Bian
[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
Signed-off-by: Pan Bian
Signed-off-by: Joerg Roedel
Signed-off-by:
From: Pan Bian
[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
memunmap() should be used to free the return of memremap(), not
iounmap().
Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
Signed-off-by: Pan Bian
Signed-off-by: Joerg Roedel
Signed-off-by:
From: Geert Uytterhoeven
[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for
From: Filippo Sironi
[ Upstream commit ab99be4683d9db33b100497d463274ebd23bd67e ]
This register should have been programmed with the physical address
of the memory location containing the shadow tail pointer for
the guest virtual APIC log instead of the base address.
Fixes: 8bda0cfbdc1a
From: Geert Uytterhoeven
[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
called, leading to a crash, as the domain was only partially
initialized:
ipmmu-vmsa e67b.mmu: Cannot accommodate DMA translation for
From: Lu Baolu
[ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ]
When handling page request without pasid event, go to "no_pasid"
branch instead of "bad_req". Otherwise, a NULL pointer deference
will happen there.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Sohil Mehta
Signed-off-by: Lu
37 matches
Mail list logo
