On 05/12/15 at 01:57pm, Dave Young wrote:
> On 05/11/15 at 12:11pm, Joerg Roedel wrote:
> > On Thu, May 07, 2015 at 09:56:00PM +0800, Dave Young wrote:
> > > Joreg, I can not find the last reply from you, so just reply here about
> > > my worries here.
> > >
> > > I said that the patchset will cau
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
> This patchset is an update of Bill Sumner's patchset, implements a fix for:
> If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
> when a panic happens, the kdump kernel will boot with these faults:
Test passed on my local wor
On 05/11/15 at 12:11pm, Joerg Roedel wrote:
> On Thu, May 07, 2015 at 09:56:00PM +0800, Dave Young wrote:
> > Joreg, I can not find the last reply from you, so just reply here about
> > my worries here.
> >
> > I said that the patchset will cause more problems, let me explain about
> > it more her
On Mon, 2015-05-11 at 11:40 +0100, Will Deacon wrote:
> On Mon, May 11, 2015 at 11:13:09AM +0100, Joerg Roedel wrote:
> > On Tue, May 05, 2015 at 06:05:41PM +0100, Will Deacon wrote:
> > > I think the MT8173 IOMMU [1] uses this format and, since it's part of
> > > the ARM architecture, the ARM SMMU
> -Original Message-
> From: Mark Hounschell [mailto:ma...@compro.net]
> Sent: Friday, May 08, 2015 3:46 PM
> To: Konrad Rzeszutek Wilk; William Davis
> Cc: linux-...@vger.kernel.org; iommu@lists.linux-foundation.org;
> jgli...@redhat.com; John Hubbard;
> Terence Ripperda
> Subject: Re:
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Friday, May 08, 2015 3:22 PM
> To: William Davis
> Cc: j...@8bytes.org; jgli...@redhat.com; linux-...@vger.kernel.org;
> iommu@lists.linux-foundation.org;
> John Hubbard; Terence Ripperda
> Subject
On 05/07/2015 02:11 PM, Jerome Glisse wrote:
On Thu, May 07, 2015 at 12:16:30PM -0500, Bjorn Helgaas wrote:
On Thu, May 7, 2015 at 11:23 AM, William Davis wrote:
From: Bjorn Helgaas [mailto:bhelg...@google.com]
Sent: Thursday, May 7, 2015 8:13 AM
To: Yijing Wang
Cc: William Davis; Joerg Roedel
Hi Linus,
The following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22:
Linux 4.1-rc2 (2015-05-03 19:22:23 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v4.1-rc3
for you to fetch changes up to 5d
On Fri, May 08, 2015 at 05:05:44PM -0700, Dmitry Torokhov wrote:
> From: Colin Cross
>
> The pointers to the 2nd level page tables are converted to 1st level
> page table entries, which means kmemleak can't find them and assumes
> they have been leaked. Call kmemleak_ignore on the 2nd level page
On Fri, May 08, 2015 at 05:44:22PM +0100, Will Deacon wrote:
> Hi Joerg,
>
> I only have this one fix pending for arm-smmu, so please could you pick
> it up for 4.1? I can send a pull if you'd prefer, but it feels a bit
> OTT.
>
> Will
>
> drivers/iommu/arm-smmu.c | 30 ++---
Hello Marek,
On Mon, May 4, 2015 at 10:15 AM, Marek Szyprowski
wrote:
> Hello Everyone,
>
> This is yet another attempt to get Exynos SYSMMU driver with integrated
> with IOMMU & DMA-mapping subsystems. The main change from previous
> version is addition of the patches to define iommu-mapping, wh
On Mon, May 11, 2015 at 9:30 AM, Konrad Rzeszutek Wilk
wrote:
> On Thu, May 07, 2015 at 10:19:05AM -0500, Bjorn Helgaas wrote:
>> [+cc Dave for sparc64, Yinghai]
>>
>> On Fri, May 01, 2015 at 01:32:15PM -0500, wda...@nvidia.com wrote:
>> > From: Will Davis
>> >
>> > Simply route these through to
From: Colin Cross
The pointers to the 2nd level page tables are converted to 1st level
page table entries, which means kmemleak can't find them and assumes
they have been leaked. Call kmemleak_ignore on the 2nd level page
tables to prevent them from showing up in kmemleak reports.
Signed-off-by
On Fri, May 08, 2015 at 04:46:17PM -0400, Mark Hounschell wrote:
> On 05/08/2015 04:21 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, May 01, 2015 at 01:32:12PM -0500, wda...@nvidia.com wrote:
> >>From: Will Davis
> >>
> >>Hi,
> >>
> >>This patch series adds DMA APIs to map and unmap a struct resourc
On Thu, May 07, 2015 at 10:19:05AM -0500, Bjorn Helgaas wrote:
> [+cc Dave for sparc64, Yinghai]
>
> On Fri, May 01, 2015 at 01:32:15PM -0500, wda...@nvidia.com wrote:
> > From: Will Davis
> >
> > Simply route these through to the new dma_(un)map_resource APIs.
> >
> > Signed-off-by: Will Davis
On Mon, May 11, 2015 at 11:13:09AM +0100, Joerg Roedel wrote:
> On Tue, May 05, 2015 at 06:05:41PM +0100, Will Deacon wrote:
> > I think the MT8173 IOMMU [1] uses this format and, since it's part of
> > the ARM architecture, the ARM SMMU can make use of it too if the
> > implementation supports it.
Hi Gregor,
On Wed, May 06, 2015 at 12:44:33PM +0100, Gregor Dick wrote:
> On 05/05/15 16:33, Joerg Roedel wrote:
> >Okay, I'll have a look into the SLES12 kernel sources to check there.
> >Can you reproduce this with a recent upstream kernel?
>
> I've done some more tests this morning and can rep
On Tue, May 05, 2015 at 06:05:41PM +0100, Will Deacon wrote:
> I think the MT8173 IOMMU [1] uses this format and, since it's part of
> the ARM architecture, the ARM SMMU can make use of it too if the
> implementation supports it.
I think it makes more sense to merge this with a driver actually usi
On Thu, May 07, 2015 at 09:56:00PM +0800, Dave Young wrote:
> Joreg, I can not find the last reply from you, so just reply here about
> my worries here.
>
> I said that the patchset will cause more problems, let me explain about
> it more here:
>
> Suppose page table was corrupted, ie. original m
Functions to copy the irte data from the old kernel into the kdump kernel.
Signed-off-by: Li, Zhen-Hua
---
drivers/iommu/intel_irq_remapping.c | 68 +
include/linux/intel-iommu.h | 4 +++
2 files changed, 72 insertions(+)
diff --git a/drivers/iommu/i
Add some functions to copy the data from old kernel.
These functions are used to copy context tables and page tables.
To avoid calling iounmap between spin_lock_irqsave and spin_unlock_irqrestore,
use a link here, store the pointers , and then use iounmap to free them in
another place.
Li, Zhen-h
Populate it with support functions to copy iommu translation tables from
from the panicked kernel into the kdump kernel in the event of a crash.
Functions:
Use old root entry table, and load the old data to root_entry as cache.
Malloc new context table and copy old context table to the new
Add functions to load root entry table from old kernel, and to save updated
root entry table.
Add two member in struct intel_iommu, to store the RTA in old kernel, and
the mapped virt address of it.
We use the old RTA in dump kernel, and when the iommu->root_entry is used as
a cache in kdump kerne
Fix the intr-remapping fault.
[1.594890] dmar: DRHD: handling fault status reg 2
[1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d
[1.594894] INTR-REMAP:[fault reason 34] Present field in the IRTE entry
is clear
Use old irte in second kernel, do not disable and re-enable inter
When a device driver issues the first dma_map command for a device, we
assign a new and empty page-table, thus removing all mappings from the
old kernel for the device.
Signed-off-by: Li, Zhen-Hua
---
drivers/iommu/intel-iommu.c | 58 ++---
1 file changed,
This patchset is an update of Bill Sumner's patchset, implements a fix for:
If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
when a panic happens, the kdump kernel will boot with these faults:
dmar: DRHD: handling fault status reg 102
dmar: DMAR:[DMA Read] Reque
Add context entry functions needed for kdump.
Bill Sumner:
Original version;
Li, Zhenhua:
Changed the name of new functions, make them consistent with current
context get/set functions.
Remove the structure dve which is not used in new version.
Signed-off-by: Bill Sumner
Signed-
Modify the operation of the following functions when called during crash dump:
iommu_context_addr
free_context_table
get_domain_for_dev
init_dmars
intel_iommu_init
Bill Sumner:
Original version.
Zhenhua:
The name of new calling functions.
Do not disable and re-enab
Interface for when a new domain in the old kernel needs some
values from the panicked kernel's context entries.
Signed-off-by: Li, Zhen-Hua
---
drivers/iommu/intel-iommu.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/int
Allow specification of the domain-id for the new domain.
This patch only adds a new function iommu_attach_domain_with_id, it is like
the function iommu_attach_domain(), only adding a parameter "did".
Bill Sumner:
(In older versions) Add new 'did' parameter to iommu_attach_domain();
The cal
On Fri, May 08, 2015 at 08:30:00PM +0100, Stuart Yoder wrote:
> On Fri, May 8, 2015 at 10:49 AM, Will Deacon wrote:
> > On Thu, May 07, 2015 at 06:49:32PM +0100, Stuart Yoder wrote:
> >> The FSL LS2085A SoC has an actual RID->SID mapping table in the PCI
> >> controller, but it is not static in th
31 matches
Mail list logo
