Hi Varuns, Stuart,
here is the reworked patch-set with the IOMMU-API changes to support the
PAMU IOMMU. It should include the results from our discussion last week.
Please have a look at it and tell me if this interface works for you. I
will merge it then into the IOMMU tree so that you have a bra
Move it to the end of the list.
Signed-off-by: Joerg Roedel
---
include/linux/iommu.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f3b99e1..7e6ce72 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
This attribute of a domain can be queried to find out if the
domain supports setting up page-tables using the iommu_map()
and iommu_unmap() functions.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c |5 +
include/linux/iommu.h |1 +
2 files changed, 6 insertions(+)
diff --git
In case the page-size bitmap is zero the code path in
iommu_map and iommu_unmap is undefined. Make it defined and
return -ENODEV in this case.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommu.c
This attribute can be used to set and get the number of
subwindows on IOMMUs that are window-based.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 33 ++---
include/linux/iommu.h |5 +
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a
Add the iommu_domain_window_enable() and iommu_domain_window_disable()
functions to the IOMMU-API. These functions will be used to setup
domains that are based on subwindows and not on paging.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 20
include/linux
On Mon, Feb 04, 2013 at 02:31:48PM +0200, Sami Liedes wrote:
> Fix tegra_smmu_probe() to initialize client_lock spinlocks in
> per-address-space structures.
>
> Signed-off-by: Sami Liedes
Applied to arm/tegra, thanks.
___
iommu mailing list
iommu@lis
On Mon, Feb 04, 2013 at 12:10:51PM -0600, Stuart Yoder wrote:
> On Mon, Feb 4, 2013 at 7:18 AM, Joerg Roedel wrote:
> > +static inline int iommu_domain_window_enable(struct iommu_domain *domain,
> > +u32 wnd_nr, ph
the read and write
functions. Use a single helper function for that check and
call it in both accessors.
Signed-off-by: Joerg Roedel
---
drivers/iommu/tegra-smmu.c | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/tegra-smmu
On Thu, Jan 31, 2013 at 12:43:08PM +0200, Hiroshi Doyu wrote:
> Theoretically TEGRA_IOMMU_SMMU depends on ARCH_TEGRA_3x_SOC and
> ARCH_TEGRA_114_SOC only. This patch allows a Tegra20 only kernel to
> enable SMMU(Tegra20 doesn't have a SMMU), which could avoid editing
> this Kconfig entry every time
Hi Stuart,
On Mon, Feb 04, 2013 at 09:37:20PM -0600, Stuart Yoder wrote:
> + DOMAIN_ATTR_ENABLE,
> + DOMAIN_ATTR_FSL_PAMUV1,
> Instead of advertising those constraints somehow, it seem easier just
> to advertise that this IOMMU is a PAMU v1. The attribute would be
> read only and woul
Hi,
On Tue, Feb 05, 2013 at 09:14:40AM +, Sethi Varun-B16395 wrote:
> In case of PAMU, geometry would be meaningless without specifying the
> number of subwindows. If the API user specifies a geometry but fails
> to specify the number of required subwindows, we would assume a
> default (max su
On Tue, Feb 05, 2013 at 10:52:03AM +, Sethi Varun-B16395 wrote:
> DOMAIN_ATTR_PAMU_ENABLE is required to enable a particular DMA window.
> My point is about the domain geometry, which is incomplete in case of
> PAMU without the number of subwindows. Geometry parameters are used
> for initializi
On Mon, Feb 04, 2013 at 05:31:51PM -0600, Stuart Yoder wrote:
> On Mon, Feb 4, 2013 at 12:56 PM, Joerg Roedel wrote:
> > On Mon, Feb 04, 2013 at 12:10:51PM -0600, Stuart Yoder wrote:
> >> On Mon, Feb 4, 2013 at 7:18 AM, Joerg Roedel wrote:
> >> > +static inline
Hi Shuah,
On Fri, Feb 01, 2013 at 11:31:59AM -0700, Shuah Khan wrote:
> Yes, 3.7 has the same window of opportunity for this race condition,
> however I couldn't figure out why it doesn't happen on 3.7. On 3.7 the
> window between amd_iommu_init_hardware() and amd_iommu_init_dma_ops()
> might actu
On Tue, Feb 05, 2013 at 07:42:09PM +0900, Hideki EIRAKU wrote:
> From: Joerg Roedel
> > Why is it necessary to call dma_map_single() for IOMMU page-tables?
> > usually the dma_* functions call into IOMMU drivers, so why are they
> > used inside an IOMMU driver?
>
>
On Mon, Feb 04, 2013 at 05:31:51PM -0600, Stuart Yoder wrote:
> On Mon, Feb 4, 2013 at 12:56 PM, Joerg Roedel wrote:
> > Okay. So if your architecture supports sizes over 2^32 then size_t
> > probably is already 64bits, right?
>
> No, on a 32-bit platform size_t would gener
t;From 2ecf57c85e67e0243b36b787d0490c0b47202ba8 Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Wed, 6 Feb 2013 12:55:23 +0100
Subject: [PATCH] iommu/amd: Initialize device table after dma_ops
When dma_ops are initialized the unity mappings are
created. The init_device_table_dma() function makes sure DMA
from all devices is bloc
On Thu, Feb 07, 2013 at 11:49:05AM +0100, Ingo Molnar wrote:
>
> * Shuah Khan wrote:
> > arch/x86/kernel/amd_iommu_init.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
>
> That file does not exist anymore, it died 2.5+ years ago:
>
> 403f81d8ee53 iommu/amd: Move miss
On Wed, Feb 06, 2013 at 01:55:17PM +0530, Sachin Kamat wrote:
> 'exynos_sysmmu_disable' is used only in this file and can be made static.
>
> Signed-off-by: Sachin Kamat
Applied to arm/exynos, thanks.
___
iommu mailing list
iommu@lists.linux-foundati
On Wed, Feb 06, 2013 at 07:38:15PM +0200, Hiroshi Doyu wrote:
> This fixes kernel crash because of BUG() in register address
> validation.
>
> Signed-off-by: Hiroshi Doyu
Applied to arm/tegra, thanks.
___
iommu mailing list
iommu@lists.linux-foundati
On Wed, Feb 06, 2013 at 09:50:10AM +0100, Hannes Reinecke wrote:
> kmemcheck complained about the use of uninitialized memory.
> So there.
>
> Cc: David Woodhouse
> Signed-off-by: Hannes Reinecke
Applied to x86/vt-d, thanks Hannes.
___
iommu mailing
On Mon, Feb 11, 2013 at 01:57:03PM -0700, Shuah Khan wrote:
> I was hoping Joerg's patch would make it into Linus's tree by now. I
> tested the original patch and did the back-port to 3.4 and 3.0 at the
> same time, before I loose the test system.
I will send the patch with the next merge window.
On Tue, Feb 12, 2013 at 05:01:50AM +0100, Cyril Roelandt wrote:
> dma_ops_domain_free on a NULL pointer is a no-op, so the NULL check in
> amd_iommu_init_dma_ops() can be removed.
>
> Signed-off-by: Cyril Roelandt
> ---
> drivers/iommu/amd_iommu.c |3 +--
> 1 file changed, 1 insertion(+), 2
VID() from pci.
Not sure who is going to merge this, it touches PCI and IOMMU code.
Personally I don't care :-) If you want to take it via your tree feel
free to add my
Reviewed-by: Joerg Roedel
Tested-by: Joerg Roedel
Acked-by: Joerg Roedel
Otherwise please Ack the PCI parts and I
On Fri, Feb 15, 2013 at 03:01:06PM -0700, Stephen Warren wrote:
> From: Stephen Warren
>
> Tegra only supports, and always enables, device tree. Remove all ifdefs
> for DT support from the driver.
>
> Signed-off-by: Stephen Warren
Applied both to arm/tegra, thanks.
__
: mach-shmobile: sh73a0: Add IPMMU device
ARM: mach-shmobile: r8a7740: Add IPMMU device
Hiroshi Doyu (3):
iommu/tegra: smmu: Support variable MMIO ranges/blocks
iommu/tegra: smmu: Change SMMU's dependency on ARCH_TEGRA
iommu/tegra: smmu: Fix incorrect mask for regba
On Tue, Feb 26, 2013 at 06:16:10AM +, Sethi Varun-B16395 wrote:
> This patch is not present in Joerg's tree and the add_device API in
> the PAMU driver requires this patch.
Will this patch be part of v3.9-rc1?
Joerg
___
iommu mailing list
On Mon, Feb 18, 2013 at 06:22:14PM +0530, Varun Sethi wrote:
> Add a new field in the device (powerpc) archdata structure for storing iommu
> domain
> information pointer. This pointer is stored when the device is attached to a
> particular
> domain.
>
>
> Signed-off-by: Varun Sethi
> ---
> -
On Mon, Feb 18, 2013 at 06:22:16PM +0530, Varun Sethi wrote:
> Macros for checking FSL PCI controller version.
>
> Signed-off-by: Varun Sethi
> ---
> arch/powerpc/include/asm/pci-bridge.h |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/p
On Mon, Feb 18, 2013 at 06:22:18PM +0530, Varun Sethi wrote:
> Added the following domain attributes for the FSL PAMU driver:
> 1. Added new iommu stash attribute, which allows setting of the
>LIODN specific stash id parameter through IOMMU API.
> 2. Added an attribute for enabling/disabling DM
Hi Ben,
On Sat, Mar 02, 2013 at 11:00:35PM +, Ben Hutchings wrote:
> I'm not convinced about this backport, because the order of
> initialisation already changed a lot after 3.2 and before the upstream
> commit. So I'm going to wait for Joerg to confirm that this makes sense
> before adding i
on top of
> 3.9-rc1?
> By when would you move the iommu git tree to 3.9-rc1?
>
> Regards
> Varun
>
> > -Original Message-
> > From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> > Sent: Thursday, February 28, 2013 9:15 PM
> > To: Sethi Varun-
On Tue, Mar 05, 2013 at 11:16:48PM +0100, Arnd Bergmann wrote:
> The OMAP IOMMU driver intentionally fails to build on OMAP1
> platforms, so we should not allow enabling it there.
>
> Signed-off-by: Arnd Bergmann
> Cc: Joerg Roedel
> Cc: iommu@lists.linux-foundation.org
&g
On Tue, Feb 26, 2013 at 04:12:05PM +0100, Nikola Pajkovsky wrote:
> commit 318fe78 ("IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround")
> added amd_iommu_erratum_746_workaround and it's marked as __init, which is
> wrong
>
> WARNING: drivers/iommu/built-in.o(.text+0x639c): Section mismatch
Hi Andreas,
On Tue, Mar 26, 2013 at 08:37:02AM +0100, Andreas Degert wrote:
> Does anyone have some advice for further debugging?
Can you please boot with amd_iommu_dump on the kernel command line and
send dmesg after boot? This will print the parsing output of the IVRS
table to dmesg which will
Hi Andreas,
thanks for the information.
On Tue, Mar 26, 2013 at 01:48:38PM +0100, Andreas Degert wrote:
> seems to be this (additionaly I have appended the full dump):
>
> device: 00:00.2 cap: 0040 seg: 0 flags: fe info 1300
> mmio-addr: feb8
>DEV_SELECT_RANGE_START de
On Thu, Mar 21, 2013 at 10:32:36AM +0900, Takao Indoh wrote:
> In this function, clearing IRE bit in iommu->gcmd and writing it to
> global command register. But initial value of iommu->gcmd is zero, so
> this writel means clearing all bits in global command register.
Seems weird. Why is the value
On Fri, Mar 08, 2013 at 10:53:16AM +0800, Andrew Cooks wrote:
> I'm hoping one of the veteran developers would give some guidance for
> the best approach to enable more devices in future.
In cases like this where a device just uses the request-id of another
device you can make use of the existing
On Tue, Mar 26, 2013 at 04:20:54PM +0100, Andreas Degert wrote:
> There is a third sound device:
>
> 04:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall
> DSP (rev 35)
>
> (at the end of the lspci listing in my first mail). This is the one that
> doesn't
> work, it's connected
On Tue, Mar 26, 2013 at 08:40:18PM +0100, Andreas Degert wrote:
> dmesg output appended. I was wrong, there are io page faults
> when I trigger dma transfer with the soundcard, like you expected.
> At the end of the dmesg output are the IO_PAGE_FAULT's from
> trying to do a playback.
Okay, thanks
e. But if
> you're still OK with them, I'll refresh the branch to add it now.
Looks still good to me. You can add my
Acked-by: Joerg Roedel
if you want.
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://l
On Wed, Mar 27, 2013 at 08:14:58AM +0100, Andreas Degert wrote:
> 2013/3/26 Joerg Roedel :
> > Okay, thanks for trying this out. I think I know where the problem is,
> > can you try the attached patch (without my debug-patch) and report me
> > whether it fixes the issue?
>
: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index c1c74e0..4647b50 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2466,18
.
Arnd Bergmann (1):
iommu: OMAP: build only on OMAP2+
Joerg Roedel (1):
iommu/amd: Make sure dma_ops are set for hotplug devices
Nikola Pajkovsky (1):
amd_iommu_init: remove __init from amd_iommu_erratum_746_workaround
Wei Yongjun (1):
x86, io_apic: remove
On Wed, Mar 27, 2013 at 02:02:44PM +0900, Takao Indoh wrote:
> The root cause of this problem is mismatch between iommu->gcmd and
> global command register in the case of kdump. At boot time, initial
> value of iommu->gcmd is zero as I wrote above, but actual global command
> register is *not* zero
On Mon, Apr 01, 2013 at 02:45:18PM +0900, Takao Indoh wrote:
>
> enable_IR
> intel_enable_irq_remapping
> iommu_disable_irq_remapping <== IRES/QIES/TES disabled here
> dmar_disable_qi <== do nothing
> dmar_enable_qi <== QIES enabled
> intel_setup_irq_r
Hi Suravee,
On Wed, Mar 27, 2013 at 06:51:23PM -0500, suravee.suthikulpa...@amd.com wrote:
> From: Suravee Suthikulpanit
>
> Add logic to decode AMD IOMMU event flag based on information from AMD IOMMU
> specification.
> This should simplify debugging IOMMU errors. Also, dump DTE information i
On Wed, Mar 27, 2013 at 06:51:34PM -0500, suravee.suthikulpa...@amd.com wrote:
> From: Suravee Suthikulpanit
>
> Add IOMMU event log injection interface for testing event flag decoding logic.
> This interface allows users to specify device id, event flag, and event types
> via debugfs.
>
> echo
On Wed, Mar 27, 2013 at 06:51:52PM -0500, suravee.suthikulpa...@amd.com wrote:
> From: Suravee Suthikulpanit
>
> Current driver does not clear the IOMMU event log interrupt bit
> in the IOMMU status register after processing an interrupt.
> This causes the IOMMU hardware to generate event log int
On Tue, Apr 02, 2013 at 04:40:37PM +0200, Borislav Petkov wrote:
> While you guys are at it, can someone fix this too pls (ASUS board with
> a PD on it).
>
> [0.220342] [Firmware Bug]: AMD-Vi: IOAPIC[9] not in IVRS table
> [0.220398] [Firmware Bug]: AMD-Vi: IOAPIC[10] not in IVRS table
> [
On Fri, Mar 29, 2013 at 01:23:59AM +0530, Varun Sethi wrote:
> Add an iommu domain pointer to device (powerpc) archdata. Devices
> are attached to iommu domains and this pointer provides a mechanism
> to correlate between a device and the associated iommu domain. This
> field is set when a device
On Fri, Mar 29, 2013 at 01:24:01AM +0530, Varun Sethi wrote:
> +/* cache stash targets */
> +enum stash_target {
> + IOMMU_ATTR_CACHE_L1 = 1,
> + IOMMU_ATTR_CACHE_L2,
> + IOMMU_ATTR_CACHE_L3,
> +};
> +
> +/* This attribute corresponds to IOMMUs capable of generating
> + * a stash transa
On Tue, Apr 02, 2013 at 05:29:56PM +0200, Borislav Petkov wrote:
> On Tue, Apr 02, 2013 at 05:03:04PM +0200, Joerg Roedel wrote:
> Good luck trying to get ASUS to fix anything in their BIOS :(.
Hmm...
> Can't we detect the SB IOAPIC some other way in this case?
I can certainly
On Tue, Apr 02, 2013 at 10:41:25AM -0500, Suthikulpanit, Suravee wrote:
> Turning this into WARN_ON() at this point might break a lot of
> systems currently out in the field. However, users can always
> switching to use "intremap=off" but this might not be obvious.
A WARN_ON doesn't break systems
Cc'ing Alex Williamson
Alex, can you please review the iommu-group part of this patch?
My comments so far are below:
On Fri, Mar 29, 2013 at 01:24:02AM +0530, Varun Sethi wrote:
> +config FSL_PAMU
> + bool "Freescale IOMMU support"
> + depends on PPC_E500MC
> + select IOMMU_API
> +
On Fri, Mar 29, 2013 at 01:23:57AM +0530, Varun Sethi wrote:
> This patchset provides the Freescale PAMU (Peripheral Access Management Unit)
> driver
> and the corresponding IOMMU API implementation. PAMU is the IOMMU present on
> Freescale
> QorIQ platforms. PAMU can authorize memory access, rem
On Tue, Apr 02, 2013 at 06:17:57PM +0200, Borislav Petkov wrote:
> On Tue, Apr 02, 2013 at 06:04:00PM +0200, Joerg Roedel wrote:
> > I can certainly write a patch that works around your particular BIOS
> > bug. The problem is that such a fix will most certainly break ot
On Tue, Apr 02, 2013 at 09:32:40PM +0200, Borislav Petkov wrote:
> On Tue, Apr 02, 2013 at 06:33:18PM +0200, Joerg Roedel wrote:
> > Okay, in theory I could implement a feedback loop between timer-setup
> > and intremap code and try fixups until it works. But that seems not to
>
On Tue, Apr 02, 2013 at 02:05:14PM -0500, Suthikulpanit, Suravee wrote:
> From: Suravee Suthikulpanit
> +static const char * const _type_field_encodings[] = {
> + /* 00 */"Reserved",
> + /* 01 */"Master Abort",
> + /* 10 */"Target Abort",
> + /* 11 */"Data Error",
In these arrays,
On Wed, Apr 03, 2013 at 05:21:16AM +, Sethi Varun-B16395 wrote:
> > I would prefer these PAMU specific enum and struct to be in a pamu-
> > specific iommu-header.
> >
>
> [Sethi Varun-B16395] But, these would be used by the IOMMU API users
> (e.g. VFIO), they shouldn't depend on PAMU specific
On Wed, Apr 03, 2013 at 09:24:39AM +0100, David Woodhouse wrote:
> On Wed, 2013-04-03 at 16:11 +0900, Takao Indoh wrote:
> > Yeah, you are right. I forgot such a case.
>
> If you disable translation and there's some device still doing DMA, it's
> going to scribble over random areas of memory. You
On Tue, Apr 02, 2013 at 07:06:50PM -0500, Suthikulpanit, Suravee wrote:
> From: Suravee Suthikulpanit
>
> Add logic to decode AMD IOMMU event flag based on information from AMD IOMMU
> specification.
> This should simplify debugging IOMMU errors. Also, dump DTE information in
> additional case
On Wed, Apr 03, 2013 at 06:19:04PM -0500, Suthikulpanit, Suravee wrote:
> In the system with multiple IOMMU,this handling scheme complicates the
> synchronization of the IOMMU data structures and status registers as
> there could be multiple threads competing for the same IOMMU while
> the other IO
On Tue, Apr 09, 2013 at 09:22:58AM -0500, Suthikulpanit, Suravee wrote:
> The reason I implemented the "per-thread IOMMU handling" and the
> "workaround" together in one patch
> is because it simplifies the synchronization of clearing and
> checking the interrupt enabling bits.
> In the previous im
On Tue, Apr 09, 2013 at 10:12:13AM -0500, Suthikulpanit, Suravee wrote:
> These messages are not "high volumn". What I am trying to achieve
> is for users to be able to just send the errors to developers once
> they are encountered without having to tell them to go back and
> reboot with the "amd_
Hi,
this patch-set contains some cleanups and patches for the
AMD IOMM driver. The most important part is a workaround
that can be used to get interrupt remapping working even the
the IVRS table provided by the BIOS is broken.
Joerg
Joerg Roedel (9):
iommu/amd: Remove map_sg_no_iommu
This function was intended as a fall-back if the map_sg
function is called for a device not mapped by the IOMMU.
Since the AMD IOMMU driver uses per-device dma_ops this can
never happen. So this function isn't needed anymore.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c |
This patch extends the devid_map data structure to allow
ioapic and hpet entries in ivrs to be overridden on the
kernel command line.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu_init.c | 28 +++-
drivers/iommu/amd_iommu_types.h |1 +
2 files changed
The function is only called by other __init functions, so it
can be moved to __init too.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu_init.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index
For compatibility reasons the irq remapping code for the AMD
IOMMU used the same per-irq data structure as the Intel
implementation. Now that support for the AMD specific data
structure is upstream we can use this one instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 54
This is needed in a later patch were ioapic_map and hpet_map
entries are created before the slab allocator is initialized
(and thus add_special_device() can't be used).
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu_init.c | 38 ++
1 file ch
Fixes a lockdep warning.
Cc: sta...@vger.kernel.org # >= v3.7
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 72fa570..33900b5 100644
--- a/drivers/iommu/amd_iomm
: Joerg Roedel
---
drivers/iommu/amd_iommu_init.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 030d6ab..9767941 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu
Document the new kernel commandline parameters in the
appropriate file.
Signed-off-by: Joerg Roedel
---
Documentation/kernel-parameters.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index
Add two new kernel commandline parameters ivrs_ioapic and
ivrs_hpet to override the Id->DeviceId mapping from the IVRS
ACPI table. This can be used to work around broken BIOSes to
get interrupt remapping working on AMD systems.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu_ini
On Tue, Apr 09, 2013 at 10:13:02PM +0200, Joerg Roedel wrote:
> Add two new kernel commandline parameters ivrs_ioapic and
> ivrs_hpet to override the Id->DeviceId mapping from the IVRS
> ACPI table. This can be used to work around broken BIOSes to
> get interrupt remapping working
On Tue, Apr 09, 2013 at 01:22:15AM +, Yoder Stuart-B08248 wrote:
> > What happens if a normal unmap call is done on the MSI iova? Do we
> > need a separate unmap?
>
> I was thinking a normal unmap on an MSI windows would be an error...but
> I'm not set on that. I put the msi unmap there to
On Thu, Apr 11, 2013 at 04:40:07PM -0500, Suthikulpanit, Suravee wrote:
> On 4/9/2013 3:29 PM, Joerg Roedel wrote:
> >On Tue, Apr 09, 2013 at 10:13:02PM +0200, Joerg Roedel wrote:
> >>Add two new kernel commandline parameters ivrs_ioapic and
> >>ivrs_hpet to override th
Hi Shuah,
On Wed, Apr 10, 2013 at 10:06:02AM -0600, Shuah Khan wrote:
> On Tue, Apr 9, 2013 at 2:12 PM, Joerg Roedel wrote:
> > Documentation/kernel-parameters.txt | 14
> > drivers/iommu/amd_iommu.c | 79 +++---
> > drivers/iommu/amd_iom
On Sat, Apr 13, 2013 at 11:06:22PM +0800, Andrew Cooks wrote:
> On Fri, Apr 12, 2013 at 4:06 PM, Joerg Roedel wrote:
> > Oh, that's sad. You were the only one having a machine wich actually has
> > unity-mapped ranges defined in the BIOS table. The code for those
> &
On Mon, Apr 15, 2013 at 06:00:13PM +0900, Takao Indoh wrote:
> On DMAR initialization during kdump boot, do you guys agree to change
> order like this?
>
> Current order:
> (1) Disable translation
> (2) PCI initialization
> (3) Make pgtable and enable translation.
>
> Order I'm proposing:
> (1) P
On Mon, Apr 15, 2013 at 12:42:00AM +0530, Varun Sethi wrote:
> swap_pci_ref function is used by the IOMMU API code for swapping pci device
> pointers, while determining the iommu group for the device.
> Currently this function was being implemented for different IOMMU drivers.
> This patch moves th
ch has a much
smaller diff and does the same. Please rebase your second patch on-top
of this one and send it again.
>From 4ba052102863da02db79c03d2483b6ad905737ad Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Thu, 18 Apr 2013 17:55:04 +0200
Subject: [PATCH] iommu/amd: Workaround for ERBT1
9 Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Thu, 18 Apr 2013 17:55:04 +0200
Subject: [PATCH] iommu/amd: Workaround for ERBT1312
Work around an IOMMU hardware bug where clearing the
EVT_INT or PPR_INT bit in the status register may race with
the hardware trying to set it again. When not ha
On Thu, Apr 18, 2013 at 11:59:58AM -0500, Suthikulpanit, Suravee wrote:
> One last concern I have for this patch is the case when we re-enable
> the interrupt, then another interrupt happens while we processing
> the log and set the bit. If the interrupt thread doesn't check this
> right before th
On Thu, Apr 18, 2013 at 01:56:42PM -0500, Suthikulpanit, Suravee wrote:
> On 4/18/2013 1:35 PM, Joerg Roedel wrote:
> According to the "kernel/irq/handle.c:irq_wake_thread()", I thought
> that for the threaded IRQ, if the system getting a new interrupt
> from the devi
On Mon, Apr 22, 2013 at 04:32:34PM -0500, suravee.suthikulpa...@amd.com wrote:
> drivers/iommu/amd_iommu.c | 82
>
> drivers/iommu/amd_iommu_init.c |2 +-
> 2 files changed, 34 insertions(+), 50 deletions(-)
Applied to x86/amd, thanks.
__
On Tue, Apr 23, 2013 at 10:47:44AM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return -ENOMEM int the memory alloc error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/iommu/amd_iommu_init.c | 1 +
> 1 file changed,
On Tue, Apr 23, 2013 at 05:35:03PM +0900, Takao Indoh wrote:
> This patch disables translation(dma-remapping) before its initialization
> if it is already enabled.
>
> This is needed for kexec/kdump boot. If dma-remapping is enabled in the
> first kernel, it need to be disabled before initializing
On Tue, Apr 23, 2013 at 10:05:24AM +0530, Varun Sethi wrote:
> +#ifndef __PCI_H
> +#define __PCI_H
Using __PCI_H is not a wise choice, it has certainly a high risk of a
collision. Anyway, I changed it to __IOMMU_PCI_H and applied the patch.
Joerg
___
On Tue, Apr 23, 2013 at 10:05:25AM +0530, Varun Sethi wrote:
> Added the following domain attributes for the FSL PAMU driver:
> 1. Added new iommu stash attribute, which allows setting of the
>LIODN specific stash id parameter through IOMMU API.
> 2. Added an attribute for enabling/disabling DM
On Tue, Apr 23, 2013 at 09:22:45AM -0400, Don Dutile wrote:
> Given other threads on this mail list (and I've seen crashes with same
> problem)
> where this type of logging during a flood of IOMMU errors will lock up the
> machine,
> is there something that can be done to break the do-while loop
On Tue, Apr 23, 2013 at 02:10:25PM +, Sethi Varun-B16395 wrote:
> I think it's fine to have the header under linux, actually I also the
> intel-iommu header under linux.
Yes, the difference is that VT-d runs on x86 and on ia64. So there is no
single arch where the header could be placed. The a
On Tue, Apr 23, 2013 at 04:13:00PM +, Yoder Stuart-B08248 wrote:
> We're aware of the obvious limitations-- no protection,
> DMA'able memory must be physically contiguous and will
> have no iova->phy translation. But there are use cases
> where all OSes involved are trusted and customers can
>
On Mon, Mar 25, 2013 at 10:23:49AM +1100, Alexey Kardashevskiy wrote:
> As IOMMU groups are exposed to the user space by their numbers,
> the user space can use them in various kernel APIs so the kernel
> might need an API to find a group by its ID.
>
> As an example, QEMU VFIO on PPC64 platform n
On Tue, Apr 30, 2013 at 09:56:22AM -0500, Suthikulpanit, Suravee wrote:
> This sounds more like issue with the order of how things are
> initialized in the system.
No, the problem is that almost all BIOS-provided IVRS tables are buggy
because they do not define a unity-mapped region for devices t
On Thu, Apr 11, 2013 at 09:19:44AM +0530, Varun Sethi wrote:
> Fix printk formats for dma_addr_t:
>
>drivers/iommu/tegra-smmu.c: In function 'smmu_iommu_iova_to_phys':
> >> drivers/iommu/tegra-smmu.c:774:2: warning: format '%lx' expects argument
> >> of type 'long unsigned int', but argument
-
Alexey Kardashevskiy (1):
iommu: Add a function to find an iommu group by id
Joerg Roedel (12):
iommu/amd: Remove map_sg_no_iommu()
iommu/amd: Use AMD specific data structure for irq remapping
iommu/amd: Properly initialize irq-table lock
iommu: Fi
Hi Peter,
On Tue, May 21, 2013 at 03:52:31PM +0200, Peter Zijlstra wrote:
> OK, I'll take them and will push them to Ingo.
Please wait with that until I had a look at the IOMMU pieces.
Thanks,
Joerg
___
iommu mailing list
iommu@lists.linux-f
301 - 400 of 3797 matches
Mail list logo
