Re: [PATCH 00/19 v4] Improve IRQ remapping abstraction in x86 core code
Hi Konrad, On Wed, Nov 28, 2012 at 04:22:05PM -0500, Konrad Rzeszutek Wilk wrote: > I looked at the patches and you can also add > Reviewed-by: Konrad Rzeszutek Wilk Thanks for your review, I added the line to the patches. > If you have a git tree I would like to test them as well. Thx. I rebased to v3.7-rc7 and pushed it to git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git ioapic-cleanups (Just pushed, may take some time to hit the mirrors) Thanks, Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] iommu: Add domain window handling functions
On Thu, Jan 31, 2013 at 09:32:26AM +, Sethi Varun-B16395 wrote:
> We need a mechanism to determine the maximum number of subwindows supported
> by PAMU. How about representing it in the iommu_domain structure:
> struct iommu_domain {
> struct iommu_ops *ops;
> void *priv;
> iommu_fault_handler_t handler;
> void *handler_token;
> struct iommu_domain_geometry geometry;
> u32 max_sub_windows; -> maximum number of sub windows supported by
> the hardware.
> }
I`ll leave that flag to the private-data of the IOMMU domain. Instead I
added a DOMAIN_ATTR_WINDOWS attribute to get/set the number of
subwindows. I'll post the updated patch-set soon.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] iommu: Implement DOMAIN_ATTR_PAGING attribute
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 a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 622360f..ab9dafd 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -869,6 +869,7 @@ int iommu_domain_get_attr(struct iommu_domain *domain,
enum iommu_attr attr, void *data)
{
struct iommu_domain_geometry *geometry;
+ bool *paging;
int ret = 0;
switch (attr) {
@@ -877,6 +878,10 @@ int iommu_domain_get_attr(struct iommu_domain *domain,
*geometry = domain->geometry;
break;
+ case DOMAIN_ATTR_PAGING:
+ paging = data;
+ *paging = (domain->ops->pgsize_bitmap != 0UL);
+ break;
default:
if (!domain->ops->domain_get_attr)
return -EINVAL;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7e6ce72..26066f5 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -59,6 +59,7 @@ struct iommu_domain {
enum iommu_attr {
DOMAIN_ATTR_GEOMETRY,
+ DOMAIN_ATTR_PAGING,
DOMAIN_ATTR_MAX,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5 v2] iommu: Support non-paging IOMMUs
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 branch to base the PAMU patches on. Thanks, Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] iommu: Make sure DOMAIN_ATTR_MAX is really the maximum
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
@@ -58,8 +58,8 @@ struct iommu_domain {
#define IOMMU_CAP_INTR_REMAP 0x2 /* isolates device intrs */
enum iommu_attr {
- DOMAIN_ATTR_MAX,
DOMAIN_ATTR_GEOMETRY,
+ DOMAIN_ATTR_MAX,
};
#ifdef CONFIG_IOMMU_API
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] iommu: Check for valid pgsize_bitmap in iommu_map/unmap
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 b/drivers/iommu/iommu.c index ddbdaca..622360f 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -734,7 +734,8 @@ int iommu_map(struct iommu_domain *domain, unsigned long iova, size_t orig_size = size; int ret = 0; - if (unlikely(domain->ops->map == NULL)) + if (unlikely(domain->ops->unmap == NULL || +domain->ops->pgsize_bitmap == 0UL)) return -ENODEV; /* find out the minimum page size supported */ @@ -808,7 +809,8 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t size) size_t unmapped_page, unmapped = 0; unsigned int min_pagesz; - if (unlikely(domain->ops->unmap == NULL)) + if (unlikely(domain->ops->unmap == NULL || +domain->ops->pgsize_bitmap == 0UL)) return -ENODEV; /* find out the minimum page size supported */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] iommu: Add domain window handling functions
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/iommu.h | 22 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ab9dafd..0fdb7db 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -852,6 +852,26 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned
long iova, size_t size)
}
EXPORT_SYMBOL_GPL(iommu_unmap);
+
+int iommu_domain_window_enable(struct iommu_domain *domain, u32 wnd_nr,
+ phys_addr_t paddr, size_t size)
+{
+ if (unlikely(domain->ops->domain_window_enable == NULL))
+ return -ENODEV;
+
+ return domain->ops->domain_window_enable(domain, wnd_nr, paddr, size);
+}
+EXPORT_SYMBOL_GPL(iommu_domain_window_enable);
+
+void iommu_domain_window_disable(struct iommu_domain *domain, u32 wnd_nr)
+{
+ if (unlikely(domain->ops->domain_window_disable == NULL))
+ return;
+
+ return domain->ops->domain_window_disable(domain, wnd_nr);
+}
+EXPORT_SYMBOL_GPL(iommu_domain_window_disable);
+
static int __init iommu_init(void)
{
iommu_group_kset = kset_create_and_add("iommu_groups",
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 26066f5..0cba2d8 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -101,6 +101,12 @@ struct iommu_ops {
enum iommu_attr attr, void *data);
int (*domain_set_attr)(struct iommu_domain *domain,
enum iommu_attr attr, void *data);
+
+ /* Window handling functions */
+ int (*domain_window_enable)(struct iommu_domain *domain, u32 wnd_nr,
+ phys_addr_t paddr, size_t size);
+ void (*domain_window_disable)(struct iommu_domain *domain, u32 wnd_nr);
+
unsigned long pgsize_bitmap;
};
@@ -158,6 +164,10 @@ extern int iommu_domain_get_attr(struct iommu_domain
*domain, enum iommu_attr,
extern int iommu_domain_set_attr(struct iommu_domain *domain, enum iommu_attr,
void *data);
+/* Window handling function prototypes */
+extern int iommu_domain_window_enable(struct iommu_domain *domain, u32 wnd_nr,
+ phys_addr_t offset, size_t size);
+extern void iommu_domain_window_disable(struct iommu_domain *domain, u32
wnd_nr);
/**
* report_iommu_fault() - report about an IOMMU fault to the IOMMU framework
* @domain: the iommu domain where the fault has happened
@@ -240,6 +250,18 @@ static inline int iommu_unmap(struct iommu_domain *domain,
unsigned long iova,
return -ENODEV;
}
+static inline int iommu_domain_window_enable(struct iommu_domain *domain,
+u32 wnd_nr, phys_addr_t paddr,
+size_t size)
+{
+ return -ENODEV;
+}
+
+static inline void iommu_domain_window_disable(struct iommu_domain *domain,
+ u32 wnd_nr)
+{
+}
+
static inline phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain,
unsigned long iova)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] iommu: Add DOMAIN_ATTR_WINDOWS domain attribute
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/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 0fdb7db..66402f7 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -891,6 +891,7 @@ int iommu_domain_get_attr(struct iommu_domain *domain,
struct iommu_domain_geometry *geometry;
bool *paging;
int ret = 0;
+ u32 *count;
switch (attr) {
case DOMAIN_ATTR_GEOMETRY:
@@ -902,6 +903,15 @@ int iommu_domain_get_attr(struct iommu_domain *domain,
paging = data;
*paging = (domain->ops->pgsize_bitmap != 0UL);
break;
+ case DOMAIN_ATTR_WINDOWS:
+ count = data;
+
+ if (domain->ops->domain_get_windows != NULL)
+ *count = domain->ops->domain_get_windows(domain);
+ else
+ ret = -ENODEV;
+
+ break;
default:
if (!domain->ops->domain_get_attr)
return -EINVAL;
@@ -916,9 +926,26 @@ EXPORT_SYMBOL_GPL(iommu_domain_get_attr);
int iommu_domain_set_attr(struct iommu_domain *domain,
enum iommu_attr attr, void *data)
{
- if (!domain->ops->domain_set_attr)
- return -EINVAL;
+ int ret = 0;
+ u32 *count;
+
+ switch (attr) {
+ case DOMAIN_ATTR_WINDOWS:
+ count = data;
+
+ if (domain->ops->domain_set_windows != NULL)
+ ret = domain->ops->domain_set_windows(domain, *count);
+ else
+ ret = -ENODEV;
- return domain->ops->domain_set_attr(domain, attr, data);
+ break;
+ default:
+ if (domain->ops->domain_set_attr == NULL)
+ return -EINVAL;
+
+ ret = domain->ops->domain_set_attr(domain, attr, data);
+ }
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_domain_set_attr);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 0cba2d8..8330df1 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -60,6 +60,7 @@ struct iommu_domain {
enum iommu_attr {
DOMAIN_ATTR_GEOMETRY,
DOMAIN_ATTR_PAGING,
+ DOMAIN_ATTR_WINDOWS,
DOMAIN_ATTR_MAX,
};
@@ -106,6 +107,10 @@ struct iommu_ops {
int (*domain_window_enable)(struct iommu_domain *domain, u32 wnd_nr,
phys_addr_t paddr, size_t size);
void (*domain_window_disable)(struct iommu_domain *domain, u32 wnd_nr);
+ /* Set the numer of window per domain */
+ int (*domain_set_windows)(struct iommu_domain *domain, u32 w_count);
+ /* Get the numer of window per domain */
+ u32 (*domain_get_windows)(struct iommu_domain *domain);
unsigned long pgsize_bitmap;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iommu/tegra: Add missing spinlock initialization
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] iommu: Add domain window handling functions
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, phys_addr_t paddr,
> > +size_t size)
> > +{
> > + return -ENODEV;
> > +}
> > +
> > +static inline void iommu_domain_window_disable(struct iommu_domain *domain,
> > + u32 wnd_nr)
> > +{
> > +}
> > +
> > static inline phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain,
> > unsigned long iova)
> > {
>
> This API looks workable. The one change we need is that the size argument in
> the enable API needs to be 64 bits. Our window sizes can exceed 4GB.
Okay. So if your architecture supports sizes over 2^32 then size_t
probably is already 64bits, right?
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] iommu: Add DOMAIN_ATTR_WINDOWS domain attribute
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 supported) value, which may be incorrect. It's going to > be really ugly. I think we should add the number of sub windows to the > domain geometry. This parameter would be used in case of a window > based iommu. So, a separate set_window API wouldn't be required. I think this can all be implemented with the interface proposed here together with a PAMU-specific DOMAIN_ATTR_PAMU_ENABLE attribute. Stuart outlined in his RFC mail how this can be done. I don't consider this ugly, it is rather a clean tradeoff between putting functionality into the generic part of the IOMMU-API and putting it into the PAMU specific part. Regards, Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] iommu: Add DOMAIN_ATTR_WINDOWS domain attribute
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 initializing the PAMU window settings. Individual subwindows can > only be enabled, once the PAMU window has been initialized using the > geometry settings. I understand that. What you do is: /* Set geometry */ set_attr(domain, DOMAIN_ATTR_GEOMETRY); /* Set number of PAMU subwindows */ set_attr(domain, DOMAIN_ATTR_WINDOWS); /* Commit changes to hardware and enable the window */ set_attr(domain, DOMAIN_ATTR_PAMU_ENABLE); And I don't see any problem with that. The domain_attr interface was introduced to cope with device specifics, we don't change global interface data structures for that. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] iommu: Add domain window handling functions
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 int iommu_domain_window_enable(struct iommu_domain
> >> > *domain,
> >> > +u32 wnd_nr, phys_addr_t
> >> > paddr,
> >> > +size_t size)
> >> > +{
> >> > + return -ENODEV;
> >> > +}
> >> > +
> >> > +static inline void iommu_domain_window_disable(struct iommu_domain
> >> > *domain,
> >> > + u32 wnd_nr)
> >> > +{
> >> > +}
> >> > +
> >> > static inline phys_addr_t iommu_iova_to_phys(struct iommu_domain
> >> > *domain,
> >> > unsigned long iova)
> >> > {
> >>
> >> This API looks workable. The one change we need is that the size
> >> argument in
> >> the enable API needs to be 64 bits. Our window sizes can exceed 4GB.
> >
> > 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 generally be 32-bits. But the PAMU
> is independent of that. I think we should just make it a u64.
Okay, I will change that. Will push the updated branch once Sethi agrees
on the interface changes.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: IO_PAGE_FAULTs on unity mapped regions during amd_iommu_init() in Linux 3.4
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 actually be wider than the window in 3.4. I think this is highly timing related. IOMMU initialization may have been moved by a few milliseconds between the kernel versions which might cause the warnings to appear or disappear. I don't think it has much value to dive deeper into the differences between the initialization sequences. As somethimes with such issues there is a simple and a more complex fix for that. I'll try to come up with a simple fix for the next merge window and implement the clean and more complex one for the next one. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/4] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
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? > > I use dma_map_single() for flushing the page table to the IOMMU > device. The dma_map_ops set by arch/arm/mm/dma-mapping.c are > per-device (unlike the intel-iommu). The dma_* functions call into > IOMMU drivers if the device is attached by arm_iommu_attach_device(), > but I am using a NULL device here, so that shouldn't happen. Okay, I applied the patches to a new arm/shmobile branch. Will push them out soon. The use of the dma_* functions is dangerous anyway (but it works for now). Please send a follow-on patch to replace the use of the dma_* functions in the driver with explicit flushing routines. This protects the code from any future changes in the dma-api implementation. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] iommu: Add domain window handling functions
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 generally be 32-bits. But the PAMU > is independent of that. I think we should just make it a u64. Okay, you can find the patches in the 'core' branch of the iommu-tree. They are also included in my next branch. You can use them now to base the PAMU patches on it. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IO_PAGE_FAULTs on unity mapped regions during amd_iommu_init() in Linux 3.4
On Tue, Feb 05, 2013 at 06:57:21AM -0700, Shuah Khan wrote: > Thanks much. I will hang on to this test system for testing your fix. Okay, here is the simple fix for v3.8-rc6. I guess it is not straighforward to port it to v3.4, but it should be doable. >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 blocked by default. This opens a short window in time where DMA to unity mapped regions is blocked by the IOMMU. Make sure this does not happen by initializing the device table after dma_ops. Signed-off-by: Joerg Roedel --- drivers/iommu/amd_iommu_init.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c index faf10ba..b6ecddb 100644 --- a/drivers/iommu/amd_iommu_init.c +++ b/drivers/iommu/amd_iommu_init.c @@ -1876,11 +1876,6 @@ static int amd_iommu_init_dma(void) struct amd_iommu *iommu; int ret; - init_device_table_dma(); - - for_each_iommu(iommu) - iommu_flush_all_caches(iommu); - if (iommu_pass_through) ret = amd_iommu_init_passthrough(); else @@ -1889,6 +1884,11 @@ static int amd_iommu_init_dma(void) if (ret) return ret; + init_device_table_dma(); + + for_each_iommu(iommu) + iommu_flush_all_caches(iommu); + amd_iommu_init_api(); amd_iommu_init_notifier(); -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] intel_iommu: Disable vfio and kvm interrupt assignment when unsafe
On Wed, Feb 06, 2013 at 07:08:24PM -0800, Andy Lutomirski wrote: > - if (x2apic_present) > - WARN(1, KERN_WARNING > - "Failed to enable irq remapping. You are vulnerable to > irq-injection attacks.\n"); > - > + irq_remapping_is_secure = 0; > return -1; > } Why do you remove this warning? It seems unrelated to the rest of the patch. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] intel_iommu: Disable vfio and kvm interrupt assignment when unsafe
On Thu, Feb 07, 2013 at 08:29:42AM -0800, Andy Lutomirski wrote: > On Thu, Feb 7, 2013 at 3:33 AM, Joerg Roedel wrote: > > On Wed, Feb 06, 2013 at 07:08:24PM -0800, Andy Lutomirski wrote: > >> - if (x2apic_present) > >> - WARN(1, KERN_WARNING > >> - "Failed to enable irq remapping. You are vulnerable > >> to irq-injection attacks.\n"); > >> - > >> + irq_remapping_is_secure = 0; > >> return -1; > >> } > > > > Why do you remove this warning? It seems unrelated to the rest of the > > patch. > > The idea is that setting irq_remapping_is_secure = 0 makes you (much > less) vulnerable to irq-injection attacks: you're vulnerable to > malicious hardware but not to attack via vfio or kvm, because those > paths are disabled. > > I'd have no problem leaving the warning in and letting whoever manages > to trigger it and get annoyed fix it. FWIW, it's actually likely to > be interesting if the warning hits. Hmm, looking into the intel_irq_remapping.c version in the tip tree makes me wonder even more. First, I wonder why the warning only hits when an x2apic is present. The function is not x2apic-specific and the vulnerability also exists in xapic mode. So that dependency can be removed. Second, I think that it should be a pr_warn instead of a full WARN. When IRQ remapping could not be enabled it's most likely because of the BIOS or the hardware. So a message in the kernel log will do and the backtrace provides no additional value. Same is true for the warning in the function iommu_set_irq_remapping(): if (sts & DMA_GSTS_CFIS) WARN(1, KERN_WARNING "Compatibility-format IRQs enabled despite intr remapping;\n" "you are vulnerable to IRQ injection.\n"); >From what I can see this condition depends only on the hardware too. So a simple pr_warn() provides the same amount of information. Regards, Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] intel_iommu: Disable vfio and kvm interrupt assignment when unsafe
On Thu, Feb 07, 2013 at 09:53:45AM -0800, Andy Lutomirski wrote: > On Thu, Feb 7, 2013 at 9:27 AM, Joerg Roedel wrote: > > Hmm, looking into the intel_irq_remapping.c version in the tip tree > > makes me wonder even more. > > Is this the version I'm based on (intel_irq_remapping: Clean up x2apic > optout security warning mess), or something else? The current tip/master branch with your previous patches included. Btw. commit af8d102f99 (which introduces the CFIS check) is also bogus. It claims to cleanup warning messages but does more, like explicitly clearing DMA_GCMD_CFI in the global command register. This should have been a seperate patch with a seperate commit-msg. Now to the two warnings. First of: if (sts & DMA_GSTS_CFIS) WARN(1, KERN_WARNING "Compatibility-format IRQs enabled despite intr remapping;\n" "you are vulnerable to IRQ injection.\n"); This one can be removed completly as it will never trigger. The CFIS bit you check here (according to the VT-d spec) has the same value as what you write into GCMD.CFI (which you set to 0 earlier in the function). The other warning: if (x2apic_present) WARN(1, KERN_WARNING "Failed to enable irq remapping. You are vulnerable to irq-injection attacks.\n"); Here you should remove the x2apic_present check as this is the error-path for xapic and x2apic. The vulnerability exists with xapic too. > What's the general rule here? If this warning hits, then my > understanding of the Intel VT-d spec is wrong, and I don't think that > firmware can cause it. A buggy hypervisor could, I suppose. A buggy hypervisor can not cause the CFIS-check warning. In my understanding only broken hardware can cause it, but that would be known already in the form of a hardware erratum. As I said above, after some reading in the VT-d spec I think the warning can go away (Even clearing GCMD.CFI can be removed as the value is never set in the VT-d driver, so the bit is always written as 0 by Linux). With this in mind, I also think that the patch this thread is about does not make much sense. It just adds more code to handle a case that could never happen. Regards, Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmar: Zero out memory
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] intel_iommu: Disable vfio and kvm interrupt assignment when unsafe
On Thu, Feb 07, 2013 at 09:02:38PM +, David Woodhouse wrote: > Backtraces add visibility and have proven to be extremely useful in the > past for getting people to actually *fix* broken BIOSes. > > When kerneloops.org was running, it also gave very good statistics which > helped to apply pressure. That is true in general, but does not apply to the two warnings in question here. One warning checks for a hypothetical hardware problem and the other warning could happen for several reasons, not only a firmware bug. It would make sense to put a warning in the respective places where a firmware problem is detected, though. The parse_ioapics_under_ir() function is a candidate where it would make sense, for example. But in the error path of the intel_enable_irq_remapping() function a pr_warn would do the same job. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IO_PAGE_FAULTs on unity mapped regions during amd_iommu_init() in Linux 3.4
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. It already has the stable-tag and should be noticed when it hits Linus' tree. Since Shuah's system is the only one I know of which actually implements IVMD entries in the IVRS table the problem seemed not to be important enough to send another pull-request for v3.8. Regards, Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] intel-iommu: Synchronize gcmd value with global command register
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_remapping<== IRES enabled But what we want to do here in the kdumo case is to disable translation too, right? Because the former kernel might have translation and irq-remapping enabled and the kdump kernel might be compiled without support for dma-remapping. So if we don't disable translation here too the kdump kernel is unable to do DMA. I agree that disabling translation should be a bit more explicit instead of the current code. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] iommu/amd: Add logic to decode AMD IOMMU event flag
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 in
> additional cases.
The patch in general makes sense to have, but I have a couple of
comments.
> +static void dump_flags(int flags, int ev_type)
> +{
> + struct _event_log_flags *p = (struct _event_log_flags *) &flags;
> + u32 err_type = p->type;
> +
> + pr_err("AMD-Vi: Flags details:\n");
> + pr_err("AMD-Vi:Guest / Nested : %u\n", p->gn);
> + pr_err("AMD-Vi:No Execute : %u\n", p->nx);
> + pr_err("AMD-Vi:User-Supervisor : %u\n", p->us);
> + pr_err("AMD-Vi:Interrupt : %u\n", p->i);
> + pr_err("AMD-Vi:Present : %u\n", p->pr);
> + pr_err("AMD-Vi:Read / Write: %u\n", p->rw);
> + pr_err("AMD-Vi:Permission : %u\n", p->pe);
> + pr_err("AMD-Vi:Reserv bit not zero / Illegal level encoding : %u\n",
> + p->rz);
> + pr_err("AMD-Vi:Translation / Transaction : %u\n",
> + p->tr);
> + pr_err("AMD-Vi:Type of error : (0x%x) ", err_type);
Printing the flags multi-line is much too noisy for IOMMU events. Just
print a char-shortcut for each flag set on the same line.
> +
> + if ((ev_type == EVENT_TYPE_DEV_TAB_ERR) ||
> + (ev_type == EVENT_TYPE_PAGE_TAB_ERR) ||
> + (ev_type == EVENT_TYPE_CMD_HARD_ERR)) {
> + /* Only supports up to 2 bits */
> + err_type &= 0x3;
> + switch (err_type) {
> + case 0:
> + pr_err("Reserved\n");
> + break;
> + case 1:
> + pr_err("Master Abort\n");
> + break;
> + case 2:
> + pr_err("Target Abort\n");
> + break;
> + case 3:
> + pr_err("Data Error\n");
> + break;
> + }
Why do you create string-arrays for other type-encodings but not for
this one?
> + } else if (ev_type == EVENT_TYPE_INV_DEV_REQ) {
> + if (p->tr == 0) {
> + if (err_type < ARRAY_SIZE(_invalid_translation_desc))
> + printk("%s\n",
> + _invalid_translation_desc[err_type]);
> + } else {
> + if (err_type < ARRAY_SIZE(_invalid_transaction_desc))
> + printk("%s\n",
> + _invalid_transaction_desc[err_type]);
pr_cont instead of printk.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] iommu/amd: Add IOMMU event log injection interface for testing event flag decoding logic
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 0x300 > /sys/kernel/debug/amd-iommu-evninj/devid // (e.g. Bus:Dev.fun > 3:0.0) > echo 0xfff > /sys/kernel/debug/amd-iommu-evninj/flags // (e.g. Specify flag > value) > echo 2 > /sys/kernel/debug/amd-iommu-evninj/type // (e.g. for > IO_PAGE_FAULT event) > > Once the event is injected, IOMMU driver will parse and print out the event > information > in kernel log (dmesg) with the various information depending on the types of > event and flag > specified. Why is this needed? I think the risk of regressions in the event-handling code is to low to justify the need for an event-injection mechanism. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] iommu/amd: Re-enable IOMMU event log interrupt after handling.
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 interrupt only once. > This has been observed in both IOMMU v1 and V2 hardware. > This patch clears the bit by writing 1 to bit 1 of the IOMMU > status register (MMIO Offset 2020h) > > Signed-off-by: Suravee Suthikulpanit Applied to x86/amd, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] iommu/amd: Add logic to decode AMD IOMMU event flag
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 > [0.220451] [Firmware Bug]: AMD-Vi: No southbridge IOAPIC found in IVRS > table > [0.220506] AMD-Vi: Disabling interrupt remapping due to BIOS Bug(s) That is actually a BIOS problem. I wonder whether it would help to turn this into a WARN_ON to get the board vendors to release working BIOSes. Opinions? Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata
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 is attached to a domain. > > Signed-off-by: Varun Sethi This patch needs to be Acked by the PPC maintainers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5 v11] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
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 transaction. A stash transaction is typically a
> + * hardware initiated prefetch of data from memory to cache.
> + * This attribute allows configuring stashig specific parameters
> + * in the IOMMU hardware.
> + */
> +
> +struct iommu_stash_attribute {
> + u32 cpu;/* cpu number */
> + u32 cache; /* cache to stash to: L1,L2,L3 */
> +};
> +
I would prefer these PAMU specific enum and struct to be in a
pamu-specific iommu-header.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] iommu/amd: Add logic to decode AMD IOMMU event flag
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 write a patch that works around your particular BIOS bug. The problem is that such a fix will most certainly break other systems. Unfortunatly there is no reliable way to fixup the IO-APIC-ID->DEVID mapping at runtime when the BIOS messed it up. The only thing I can do is to check for potential problems and disable the intremap feature then, so that the system will at least boot. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] iommu/amd: Add logic to decode AMD IOMMU event flag
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, it just creates more noise. Probably enough noise to get board vendors to fix their stuff up. But there is more to consider before making more noise, of course :) Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
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
> + select GENERIC_ALLOCATOR
> + help
> + Freescale PAMU support.
A bit lame for a help text. Can you elaborate more what PAMU is and when
it should be enabled?
> +int pamu_enable_liodn(int liodn)
> +{
> + struct paace *ppaace;
> +
> + ppaace = pamu_get_ppaace(liodn);
> + if (!ppaace) {
> + pr_err("Invalid primary paace entry\n");
> + return -ENOENT;
> + }
> +
> + if (!get_bf(ppaace->addr_bitfields, PPAACE_AF_WSE)) {
> + pr_err("liodn %d not configured\n", liodn);
> + return -EINVAL;
> + }
> +
> + /* Ensure that all other stores to the ppaace complete first */
> + mb();
> +
> + ppaace->addr_bitfields |= PAACE_V_VALID;
> + mb();
Why is it sufficient to set the bit in a variable when enabling liodn
but when disabling it set_bf needs to be called? This looks a bit
assymetric.
> +/* Derive the window size encoding for a particular PAACE entry */
> +static unsigned int map_addrspace_size_to_wse(phys_addr_t addrspace_size)
> +{
> + /* Bug if not a power of 2 */
> + BUG_ON((addrspace_size & (addrspace_size - 1)));
Please use is_power_of_2 here.
> +
> + /* window size is 2^(WSE+1) bytes */
> + return __ffs(addrspace_size >> PAMU_PAGE_SHIFT) + PAMU_PAGE_SHIFT - 1;
The PAMU_PAGE_SHIFT shifting and adding looks redundant.
> + if ((win_size & (win_size - 1)) || win_size < PAMU_PAGE_SIZE) {
> + pr_err("window size too small or not a power of two %llx\n",
> win_size);
> + return -EINVAL;
> + }
> +
> + if (win_addr & (win_size - 1)) {
> + pr_err("window address is not aligned with window size\n");
> + return -EINVAL;
> + }
Again, use is_power_of_2 instead of hand-coding.
> + if (~stashid != 0)
> + set_bf(paace->impl_attr, PAACE_IA_CID, stashid);
> +
> + smp_wmb();
> +
> + if (enable)
> + paace->addr_bitfields |= PAACE_V_VALID;
Havn't you written a helper funtion to set this bit?
> +irqreturn_t pamu_av_isr(int irq, void *arg)
> +{
> + struct pamu_isr_data *data = arg;
> + phys_addr_t phys;
> + unsigned int i, j;
> +
> + pr_emerg("fsl-pamu: access violation interrupt\n");
> +
> + for (i = 0; i < data->count; i++) {
> + void __iomem *p = data->pamu_reg_base + i * PAMU_OFFSET;
> + u32 pics = in_be32(p + PAMU_PICS);
> +
> + if (pics & PAMU_ACCESS_VIOLATION_STAT) {
> + pr_emerg("POES1=%08x\n", in_be32(p + PAMU_POES1));
> + pr_emerg("POES2=%08x\n", in_be32(p + PAMU_POES2));
> + pr_emerg("AVS1=%08x\n", in_be32(p + PAMU_AVS1));
> + pr_emerg("AVS2=%08x\n", in_be32(p + PAMU_AVS2));
> + pr_emerg("AVA=%016llx\n", make64(in_be32(p + PAMU_AVAH),
> + in_be32(p + PAMU_AVAL)));
> + pr_emerg("UDAD=%08x\n", in_be32(p + PAMU_UDAD));
> + pr_emerg("POEA=%016llx\n", make64(in_be32(p +
> PAMU_POEAH),
> + in_be32(p + PAMU_POEAL)));
> +
> + phys = make64(in_be32(p + PAMU_POEAH),
> + in_be32(p + PAMU_POEAL));
> +
> + /* Assume that POEA points to a PAACE */
> + if (phys) {
> + u32 *paace = phys_to_virt(phys);
> +
> + /* Only the first four words are relevant */
> + for (j = 0; j < 4; j++)
> + pr_emerg("PAACE[%u]=%08x\n", j,
> in_be32(paace + j));
> + }
> + }
> + }
> +
> + panic("\n");
A kernel panic seems like an over-reaction to an access violation.
Besides the device that caused the violation the system should still
work, no?
> +#define make64(high, low) (((u64)(high) << 32) | (low))
You redefined this make64 here.
> +static int map_subwins(int liodn, struct fsl_dma_domain *dma_domain)
> +{
> + struct dma_window *sub_win_ptr =
> + &dma_domain->win_arr[0];
> + int i, ret;
> + unsigned long rpn;
> +
> + for (i = 0; i < dma_domain->win_cnt; i++) {
> + if (sub_win_ptr[i].valid) {
> + rpn = sub_win_ptr[i].paddr >>
> + PAMU_PAGE_SHIFT;
> + spin_lock(&iommu_lock);
IOMMU code might run in interrupt context, so please use
spin_lock_irqsave for the iommu_lock.
> +static void detach_device(struct device *dev, struct fsl_dma_domain
> *dma_domain)
> +{
> + struct device_domain_info *info;
> + struct list_head *entr
Re: [PATCH 0/5 v11] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
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, remap the memory address, > and remap > the I/O transaction type. > > This set consists of the following patches: > 1. Make iova dma_addr_t in the iommu_iova_to_phys API. > 2. Addition of new field in the device (powerpc) archdata structure for > storing iommu domain information >pointer. > 3. Add window permission flags in the iommu_domain_window_enable API. > 4. Add domain attributes for FSL PAMU driver. > 5. PAMU driver and IOMMU API implementation. Okay, I am about to apply patches 1 and 3 to a new ppc/pamu branch in my tree. As a general question, how did you test the IOMMU driver and what will you do in the future to avoid regressions? Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] iommu/amd: Add logic to decode AMD IOMMU event flag
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 other > > systems. > > > > Unfortunatly there is no reliable way to fixup the IO-APIC-ID->DEVID > > mapping at runtime when the BIOS messed it up. The only thing I can do > > is to check for potential problems and disable the intremap feature > > then, so that the system will at least boot. > > Yeah, that could work: > > * do not issue message but try to fixup the mapping > * if it works, fine > * if it doesn't, then give up and disable intremap. I can't find out in the driver whether the fix works or not. It will be noticed later when the x86 code tries to setup the timers and finds out that they don't work, which causes a kernel panic. 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 be worth it to work around a buggy BIOS. What I actually thought about was providing an IVRS-override on the kernel command line. So that you can specify the IOAPIC_ID->DEVID mapping there and make it work this way. What do you think? > And yes, I'm very sceptical about having a WARN_ON and it starts > screaming on machines all over the place. Good luck explaining to > people that you actually wanted to prod BIOS vendors to fix their > monkey-on-crack code but they weren't listening in the first place. Yeah, that's my fear too. So we leave it better as it is... Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] iommu/amd: Add logic to decode AMD IOMMU event flag
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 > > be worth it to work around a buggy BIOS. > > Yeah, same here. It's not like we really need intremap to work - we're > only trying to fix the annoying error message currently. :-) Right :) > > What I actually thought about was providing an IVRS-override on the > > kernel command line. So that you can specify the IOAPIC_ID->DEVID > > mapping there and make it work this way. What do you think? > > I guess that is workable. I can imagine people wanting this if they want > to do the intremap thing on such b0rked BIOSen. So how do I specify this > IOAPIC_ID->DEVID mapping on the cmdline exactly? Don't know yet, probably something like ivrs_ioapic[]=0:14.2 and ivrs_hpet[]=0:14.2. But not entierly sure yet, at least parsing shouldn't require lex and yacc ;) > > Yeah, that's my fear too. So we leave it better as it is... > > Hohumm. Thus shall it be! Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] iommu/amd: Add logic to decode AMD IOMMU event flag
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, please put the comments at the end of the line and
align them nicely like this:
static const char * const _type_field_encodings[] = {
"Reserved", /* 00 */
"Master Abort", /* 01 */
"Target Abort", /* 10 */
"Data Error", /* 11 */
};
This improves readability a lot.
> +static void dump_flags(int flags, int ev_type)
> +{
> + struct _event_log_flags *p = (struct _event_log_flags *) &flags;
> + u32 err_type = p->type;
> +
> + pr_err("AMD-Vi: Flags details: %s, NX:%u, %s, %s, %s, %s, %s, %s, %s\n",
> + (p->gn ? "Use guest address" : "Use nested address"),
> + (p->nx),
> + (p->us ? "User privileges" : "Supervisor privileges"),
> + (p->i ? "Interrupt request" : "memory request"),
> + (p->pr ? "Page present or Interrupt remapped" :
> + "Page not present or Interrupt blocked"),
> + (p->rw ? "Write transaction" : "Read transaction"),
> + (p->pe ? "Does not have permission" : "Has permission"),
> + (p->rz ? "Reserv bit not zero" : "Illegal level encoding"),
> + (p->tr ? "Translation request" : "Transaction request"));
These strings are too long, please just print useful shortcuts for them,
like
"US" : "SV" instead of
"User privileges" : "Supervisor privileges"
Also the commas between the strings are not needed then.
As a general rule, in the default configuration an event-log entry
should not take more than a single line in dmesg (which is also not too
long). If you want to print more information in some cases you can
enable that by a command line parameter like 'amd_iommu=verbose' or
something like that.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5 v11] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
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 headers. Drivers that use PAMU specifics (like the PAMU specific VFIO parts) can also include the PAMU specific header. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] intel-iommu: Synchronize gcmd value with global command register
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 really want to have > translation enabled and all the page tables *cleared*, during kexec. I > think it's fair to insist that the secondary kernel should use the IOMMU > if the first one did. Do we really need to insist on that? The IOMMU initialization on x86 happens after the kernel scanned and enumerated the PCI bus. While doing this the kernel (at least it should) disables all devices it finds. So when the IOMMU init code runs we should be safe from any in-flight DMA and can either disable translation or re-initialize it for the kdump kernel. Until then translation needs to stay enabled of course, so that the old page-tables are still used and in-flight DMA doesn't corrupt any data. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] iommu: Support non-paging IOMMUs
Hi Varun, here is a patch-set that implements (what I think are) the necessary IOMMU-API extensions to support the PAMU. Please have a look at it and tell me if it fits your needs. Regards, Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] iommu: Make sure DOMAIN_ATTR_MAX is really the maximum
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
@@ -58,8 +58,8 @@ struct iommu_domain {
#define IOMMU_CAP_INTR_REMAP 0x2 /* isolates device intrs */
enum iommu_attr {
- DOMAIN_ATTR_MAX,
DOMAIN_ATTR_GEOMETRY,
+ DOMAIN_ATTR_MAX,
};
#ifdef CONFIG_IOMMU_API
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] iommu: Add domain window handling functions
Add the iommu_domain_wnd_enable() and iommu_domain_wnd_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/iommu.h | 18 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index ab9dafd..55ae3bf 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -852,6 +852,26 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned
long iova, size_t size)
}
EXPORT_SYMBOL_GPL(iommu_unmap);
+
+int iommu_domain_wnd_enable(struct iommu_domain *domain, u32 window,
+ unsigned long offset, size_t size)
+{
+ if (unlikely(domain->ops->domain_wnd_enable == NULL))
+ return -ENODEV;
+
+ return domain->ops->domain_wnd_enable(domain, window, offset, size);
+}
+EXPORT_SYMBOL_GPL(iommu_domain_wnd_enable);
+
+void iommu_domain_wnd_disable(struct iommu_domain *domain, u32 window)
+{
+ if (unlikely(domain->ops->domain_wnd_disable == NULL))
+ return;
+
+ return domain->ops->domain_wnd_disable(domain, window);
+}
+EXPORT_SYMBOL_GPL(iommu_domain_wnd_disable);
+
static int __init iommu_init(void)
{
iommu_group_kset = kset_create_and_add("iommu_groups",
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 26066f5..f01657e 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -90,6 +90,9 @@ struct iommu_ops {
phys_addr_t paddr, size_t size, int prot);
size_t (*unmap)(struct iommu_domain *domain, unsigned long iova,
size_t size);
+ int (*domain_wnd_enable)(struct iommu_domain *domain, u32 window,
+ unsigned long offset, size_t size);
+ void (*domain_wnd_disable)(struct iommu_domain *domain, u32 window);
phys_addr_t (*iova_to_phys)(struct iommu_domain *domain,
unsigned long iova);
int (*domain_has_cap)(struct iommu_domain *domain,
@@ -123,6 +126,9 @@ extern int iommu_map(struct iommu_domain *domain, unsigned
long iova,
phys_addr_t paddr, size_t size, int prot);
extern size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova,
size_t size);
+extern int iommu_domain_wnd_enable(struct iommu_domain *domain, u32 window,
+ unsigned long offset, size_t size);
+extern void iommu_domain_wnd_disable(struct iommu_domain *domain, u32 window);
extern phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain,
unsigned long iova);
extern int iommu_domain_has_cap(struct iommu_domain *domain,
@@ -240,6 +246,18 @@ static inline int iommu_unmap(struct iommu_domain *domain,
unsigned long iova,
return -ENODEV;
}
+static inline int iommu_domain_wnd_enable(struct iommu_domain *domain,
+ u32 window, unsigned long offset,
+ size_t size)
+{
+ return -ENODEV;
+}
+
+static inline void iommu_domain_wnd_disable(struct iommu_domain *domain,
+ u32 window)
+{
+}
+
static inline phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain,
unsigned long iova)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] iommu: Implement DOMAIN_ATTR_PAGING attribute
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 a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 622360f..ab9dafd 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -869,6 +869,7 @@ int iommu_domain_get_attr(struct iommu_domain *domain,
enum iommu_attr attr, void *data)
{
struct iommu_domain_geometry *geometry;
+ bool *paging;
int ret = 0;
switch (attr) {
@@ -877,6 +878,10 @@ int iommu_domain_get_attr(struct iommu_domain *domain,
*geometry = domain->geometry;
break;
+ case DOMAIN_ATTR_PAGING:
+ paging = data;
+ *paging = (domain->ops->pgsize_bitmap != 0UL);
+ break;
default:
if (!domain->ops->domain_get_attr)
return -EINVAL;
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7e6ce72..26066f5 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -59,6 +59,7 @@ struct iommu_domain {
enum iommu_attr {
DOMAIN_ATTR_GEOMETRY,
+ DOMAIN_ATTR_PAGING,
DOMAIN_ATTR_MAX,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] iommu: Check for valid pgsize_bitmap in iommu_map/unmap
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 b/drivers/iommu/iommu.c index ddbdaca..622360f 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -734,7 +734,8 @@ int iommu_map(struct iommu_domain *domain, unsigned long iova, size_t orig_size = size; int ret = 0; - if (unlikely(domain->ops->map == NULL)) + if (unlikely(domain->ops->unmap == NULL || +domain->ops->pgsize_bitmap == 0UL)) return -ENODEV; /* find out the minimum page size supported */ @@ -808,7 +809,8 @@ size_t iommu_unmap(struct iommu_domain *domain, unsigned long iova, size_t size) size_t unmapped_page, unmapped = 0; unsigned int min_pagesz; - if (unlikely(domain->ops->unmap == NULL)) + if (unlikely(domain->ops->unmap == NULL || +domain->ops->pgsize_bitmap == 0UL)) return -ENODEV; /* find out the minimum page size supported */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IO_PAGE_FAULTs on unity mapped regions during amd_iommu_init() in Linux 3.4
Hi Shuah, On Thu, Jan 31, 2013 at 11:33:30AM -0700, Shuah Khan wrote: > Access to these ranges continues to work with no errors until AMD IOMMU > driver disables and re-enables IOMMU in enable_iommus(). These faults > don't persist and appear between the enable_iommus() call and before > amd_iommu_init() gets done printing "AMD-Vi: Lazy IO/TLB flushing > enabled" message. Hmm, okay. I had a look into the v3.4 sources. This looks like a race condition. The IOMMUs are enabled in amd_iommu_init_hardware() but the unity-mapped regions are created later in amd_iommu_init_dma_ops(). This leaves a small window where the page-faults happen that you see. But I am not sure why this doesn't hit on 3.7 and above. The race is still there. Anyway, definitly something that needs to be fixed. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 05/12] iommu/exynos: support for device tree
Cho, On Wed, Jan 02, 2013 at 02:53:49PM +0900, KyongHo Cho wrote: > On Tuesday, January 1, 2013, Sylwester Nawrocki > > Cc: devicetree-disc...@lists.ozlabs.org Since patch 7 of this set is already merged, do you mind to re-post the rest of this patch-set with the latest comments addressed? I can have a look at it again then and consider it for 3.9. Thanks, Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/4] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
On Mon, Jan 21, 2013 at 07:54:26PM +0900, Hideki EIRAKU wrote:
> This is the Renesas IPMMU driver and IOMMU API implementation.
>
> The IPMMU module supports the MMU function and the PMB function. The
> MMU function provides address translation by pagetable compatible with
> ARMv6. The PMB function provides address translation including
> tile-linear translation. This patch implements the MMU function.
>
> The iommu driver does not register a platform driver directly because:
> - the register space of the MMU function and the PMB function
> have a common register (used for settings flush), so they should ideally
> have a way to appropriately share this register.
> - the MMU function uses the IOMMU API while the PMB function does not.
> - the two functions may be used independently.
>
> Signed-off-by: Hideki EIRAKU
The patch looks good in general. Just one question inline.
> +static int pgtable_alloc(struct shmobile_iommu_domain_pgtable *pgtable,
> + struct kmem_cache *cache, size_t size)
> +{
> + pgtable->pgtable = kmem_cache_zalloc(cache, GFP_ATOMIC);
> + if (!pgtable->pgtable)
> + return -ENOMEM;
> + pgtable->handle = dma_map_single(NULL, pgtable->pgtable, size,
> + DMA_TO_DEVICE);
> + return 0;
> +}
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?
Regards,
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] Renesas IPMMU driver for sh7372, sh73a0 and r8a7740
On Mon, Jan 21, 2013 at 07:54:25PM +0900, Hideki EIRAKU wrote: > Hideki EIRAKU (4): > iommu/shmobile: Add iommu driver for Renesas IPMMU modules > ARM: mach-shmobile: sh7372: Add IPMMU device > ARM: mach-shmobile: sh73a0: Add IPMMU device > ARM: mach-shmobile: r8a7740: Add IPMMU device Paul, Magnus, any opinions on patches 2-4? Can you ACK them when they are ok for you? Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] ioapic-cleanups-for-v3.9
Hi Ingo, The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/ioapic-cleanups-for-v3.9 for you to fetch changes up to 91b7344672ed72355624415e036f117782c5809c: x86, irq: Move irq_remapped out of x86 core code (2013-01-24 18:29:33 +0100) Cleanup X86 IOAPIC code from interrupt remapping details These patches move all interrupt remapping specific checks out of the x86 core code and replaces the respective call-sites with function pointers. As a result the interrupt remapping code is better abstraced from x86 core interrupt handling code. The code was rebased to v3.8-rc4 and tested on systems with AMD-Vi and Intel VT-d (both capable of interrupt remapping). The systems were tested with IOMMU enabled and with IOMMU disabled. No issues were found. Joerg Roedel (19): x86, apic: Move irq_remapping_enabled checks into IRQ-remapping code x86, apic: Mask IO-APIC and PIC unconditionally on LAPIC resume x86, io_apic: Introduce x86_io_apic_ops.disable() x86, io_apic: Introduce x86_io_apic_ops.print_entries for debugging x86, hpet: Introduce x86_msi_ops.setup_hpet_msi x86, msi: Use IRQ remapping specific setup_msi_irqs routine x86, io_apic: Introduce set_affinity function pointer x86, io_apic: Convert setup_ioapic_entry to function pointer x86, io_apic: Move irq_remapping_enabled checks out of check_timer() x86, io_apic: Remove irq_remapping_enabled check in setup_timer_IRQ0_pin x86, irq: Move irq_remapping_enabled declaration to iommu code x86, irq: Add data structure to keep AMD specific irq remapping information x86, io-apic: Move CONFIG_IRQ_REMAP code out of x86 core x86, io-apic: Remove !irq_remapped() check from __target_IO_APIC_irq() x86, irq: Move irq_remapped() check into free_remapped_irq x86, irq: Introduce setup_remapped_irq() x86, msi: Introduce x86_msi.compose_msi_msg call-back x86, io_apic: Introduce eoi_ioapic_pin call-back x86, irq: Move irq_remapped out of x86 core code arch/x86/include/asm/hpet.h |5 +- arch/x86/include/asm/hw_irq.h| 13 +- arch/x86/include/asm/io_apic.h | 28 +++ arch/x86/include/asm/irq_remapping.h | 40 ++-- arch/x86/include/asm/pci.h |2 + arch/x86/include/asm/x86_init.h | 27 ++- arch/x86/kernel/apic/apic.c | 28 ++- arch/x86/kernel/apic/io_apic.c | 370 +- arch/x86/kernel/hpet.c |2 +- arch/x86/kernel/x86_init.c | 24 ++- drivers/iommu/amd_iommu.c|8 +- drivers/iommu/dmar.c |2 + drivers/iommu/intel-iommu.c |2 + drivers/iommu/intel_irq_remapping.c | 12 ++ drivers/iommu/irq_remapping.c| 176 +++- drivers/iommu/irq_remapping.h|1 + 16 files changed, 439 insertions(+), 301 deletions(-) Please pull. Thanks, Joerg signature.asc Description: Digital signature
Re: [git pull] ioapic-cleanups-for-v3.9
On Fri, Jan 25, 2013 at 11:49:15AM +0100, Ingo Molnar wrote: > Hm, there are some not so trivial looking conflicts in > io_apic.c, due to the MSI patches I applied yesterday: > > 5ca72c4f7c41 AHCI: Support multiple MSIs > 08261d87f7d1 PCI/MSI: Enable multiple MSIs with pci_enable_msi_block_auto() > 51906e779f2b x86/MSI: Support multiple MSIs in presense of IRQ remapping > > Could you please resolve them and resend? Will do. I rebase to tip/x86/apic and test again. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iommu: omap-iommu.c: remove unnecessary null pointer check
On Fri, Jan 18, 2013 at 09:42:18PM +0100, Cong Ding wrote: > Signed-off-by: Cong Ding > --- > drivers/iommu/omap-iommu.c |4 ++-- Applied to arm/omap, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4] IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround
On Thu, Jan 24, 2013 at 01:17:53PM -0600, Suthikulpanit, Suravee wrote: > From: Suravee Suthikulpanit > Signed-off-by: Suravee Suthikulpanit > --- > Changelog: > v4: > * Fix style and spacing > > v3: > * Add proper commit message > * Change logic to avoid unnecessary indentaion > > v2: > * Fix logic that check the processor model. > * Clear write enable bit after apply workaround > * Change function name > > drivers/iommu/amd_iommu_init.c | 34 ++ > 1 file changed, 34 insertions(+) Applied to iommu/fixes, thanks guys. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
On Mon, Jan 21, 2013 at 02:20:56PM -0600, Steven L. Kinney wrote: > From: "Steven L. Kinney" > > Original code base by Andreas Herrmann at AMD with minor changes. Why is it safe to enable this feature when it was disabled by BIOS? Was it disabled for no reason? Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
On Mon, Jan 28, 2013 at 02:59:25PM +, Kinney, Steven wrote: > Testing with perf shows expected results. Can you give me an impression on how the results look like when perf is used? Since the hardware is widely available yet I can't try this myself. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] ioapic-cleanups-for-v3.9
Hi Ingo, On Fri, Jan 25, 2013 at 11:49:15AM +0100, Ingo Molnar wrote: > Hm, there are some not so trivial looking conflicts in > io_apic.c, due to the MSI patches I applied yesterday: > > 5ca72c4f7c41 AHCI: Support multiple MSIs > 08261d87f7d1 PCI/MSI: Enable multiple MSIs with pci_enable_msi_block_auto() > 51906e779f2b x86/MSI: Support multiple MSIs in presense of IRQ remapping > > Could you please resolve them and resend? Okay, I resolved the conflicts and tested the result again. Here it is: The following changes since commit 5ca72c4f7c412c2002363218901eba5516c476b1: AHCI: Support multiple MSIs (2013-01-24 17:25:13 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/ioapic-cleanups-for-tip for you to fetch changes up to a1bb20c232d066de0762f8e7cf332e5ce8385210: x86, irq: Move irq_remapped out of x86 core code (2013-01-28 12:51:52 +0100) Cleanup X86 IOAPIC code from interrupt remapping details These patches move all interrupt remapping specific checks out of the x86 core code and replaces the respective call-sites with function pointers. As a result the interrupt remapping code is better abstraced from x86 core interrupt handling code. The code was rebased to v3.8-rc4 and tested on systems with AMD-Vi and Intel VT-d (both capable of interrupt remapping). The systems were tested with IOMMU enabled and with IOMMU disabled. No issues were found. -------- Joerg Roedel (19): x86, apic: Move irq_remapping_enabled checks into IRQ-remapping code x86, apic: Mask IO-APIC and PIC unconditionally on LAPIC resume x86, io_apic: Introduce x86_io_apic_ops.disable() x86, io_apic: Introduce x86_io_apic_ops.print_entries for debugging x86, hpet: Introduce x86_msi_ops.setup_hpet_msi x86, msi: Use IRQ remapping specific setup_msi_irqs routine x86, io_apic: Introduce set_affinity function pointer x86, io_apic: Convert setup_ioapic_entry to function pointer x86, io_apic: Move irq_remapping_enabled checks out of check_timer() x86, io_apic: Remove irq_remapping_enabled check in setup_timer_IRQ0_pin x86, irq: Move irq_remapping_enabled declaration to iommu code x86, irq: Add data structure to keep AMD specific irq remapping information x86, io-apic: Move CONFIG_IRQ_REMAP code out of x86 core x86, io-apic: Remove !irq_remapped() check from __target_IO_APIC_irq() x86, irq: Move irq_remapped() check into free_remapped_irq x86, irq: Introduce setup_remapped_irq() x86, msi: Introduce x86_msi.compose_msi_msg call-back x86, io_apic: Introduce eoi_ioapic_pin call-back x86, irq: Move irq_remapped out of x86 core code arch/x86/include/asm/hpet.h |5 +- arch/x86/include/asm/hw_irq.h| 13 +- arch/x86/include/asm/io_apic.h | 28 +++ arch/x86/include/asm/irq_remapping.h | 40 ++- arch/x86/include/asm/pci.h |3 + arch/x86/include/asm/x86_init.h | 27 +- arch/x86/kernel/apic/apic.c | 28 +-- arch/x86/kernel/apic/io_apic.c | 446 +++--- arch/x86/kernel/hpet.c |2 +- arch/x86/kernel/x86_init.c | 24 +- drivers/iommu/amd_iommu.c|8 +- drivers/iommu/dmar.c |2 + drivers/iommu/intel-iommu.c |2 + drivers/iommu/intel_irq_remapping.c | 12 + drivers/iommu/irq_remapping.c| 231 +- drivers/iommu/irq_remapping.h|1 + include/linux/irq.h |3 + 17 files changed, 504 insertions(+), 371 deletions(-) Please pull. Thanks, Joerg signature.asc Description: Digital signature
[git pull] IOMMU Fixes for v3.8-rc5
Hi Linus, The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311: Linux 3.8-rc5 (2013-01-25 11:57:28 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v3.8-rc5 for you to fetch changes up to 318fe782539c4150d1b8e4e6c9dc3a896512cb8a: IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround (2013-01-28 15:26:54 +0100) IOMMU fixes for Linux v3.8-rc5 One fix for the AMD IOMMU driver to work around broken BIOSes found in the field. Some BIOSes forget to enable a workaround for a hardware problem which might cause the IOMMU to stop working under high load conditions. The fix makes sure this workaround is enabled. Suravee Suthikulpanit (1): IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround drivers/iommu/amd_iommu_init.c | 34 ++ 1 file changed, 34 insertions(+) Please pull. Regards, Joerg signature.asc Description: Digital signature
[git pull] IOMMU Updates for v3.9
Hi Linus, This time the pull-request conflicts at a few places with your tree (mostly due to other changes on ARM). The conflicts are more or less trivial, I attach my resolution diff to this pull request. Please let me know if you want me to resolve the conflicts first before you pull. Anyway, here is the pull-request: The following changes since commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200: Linux 3.8 (2013-02-18 15:58:34 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v3.9 for you to fetch changes up to 604542b824f72fa5d7fd977af277538c1e15b5f0: Merge branches 'core', 'arm/omap', 'iommu/fixes', 'arm/tegra', 'arm/shmobile', 'arm/exynos', 'x86/vt-d' and 'x86/amd' into next (2013-02-19 15:45:17 +0100) IOMMU Updates for Linux v3.9 Besides some fixes and cleanups in the code there are three more important changes to point out this time: * New IOMMU driver for the ARM SHMOBILE platform * An IOMMU-API extension for non-paging IOMMUs (required for upcoming PAMU driver) * Rework of the way the Tegra IOMMU driver accesses its registetrs - register windows are easier to extend now. There are also a few changes to non-iommu code, but that is acked by the respective maintainers. Alexey Kardashevskiy (1): iommu: moving initialization earlier Cho KyongHo (1): ARM: EXYNOS: remove system mmu initialization from exynos tree Cong Ding (1): iommu/omap: Remove unnecessary null pointer check Cyril Roelandt (1): iommu/amd: Remove redundant NULL check before dma_ops_domain_free(). Hannes Reinecke (1): iommu/vt-d: Zero out allocated memory in dmar_enable_qi Hideki EIRAKU (4): iommu/shmobile: Add iommu driver for Renesas IPMMU modules ARM: mach-shmobile: sh7372: Add IPMMU device ARM: 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 regbase Joerg Roedel (8): iommu/tegra: smmu: Use helper function to check for valid register offset iommu: Make sure DOMAIN_ATTR_MAX is really the maximum iommu: Check for valid pgsize_bitmap in iommu_map/unmap iommu: Implement DOMAIN_ATTR_PAGING attribute iommu: Add domain window handling functions iommu: Add DOMAIN_ATTR_WINDOWS domain attribute iommu/amd: Initialize device table after dma_ops Merge branches 'core', 'arm/omap', 'iommu/fixes', 'arm/tegra', 'arm/shmobile', 'arm/exynos', 'x86/vt-d' and 'x86/amd' into next Sachin Kamat (1): iommu/exynos: Make exynos_sysmmu_disable static Sami Liedes (1): iommu/tegra: Add missing spinlock initialization Stephen Warren (2): iommu/tegra: assume CONFIG_OF in gart driver iommu/tegra: assume CONFIG_OF in SMMU driver arch/arm/mach-exynos/Kconfig |5 - arch/arm/mach-exynos/Makefile |1 - arch/arm/mach-exynos/clock-exynos4.c | 41 ++- arch/arm/mach-exynos/clock-exynos4210.c|9 +- arch/arm/mach-exynos/clock-exynos4212.c| 23 +- arch/arm/mach-exynos/clock-exynos5.c | 62 +++-- arch/arm/mach-exynos/dev-sysmmu.c | 274 --- arch/arm/mach-exynos/include/mach/sysmmu.h | 66 - arch/arm/mach-exynos/mach-exynos4-dt.c | 34 +++ arch/arm/mach-exynos/mach-exynos5-dt.c | 30 +++ arch/arm/mach-shmobile/setup-r8a7740.c | 33 +++ arch/arm/mach-shmobile/setup-sh7372.c | 39 +++ arch/arm/mach-shmobile/setup-sh73a0.c | 31 +++ drivers/iommu/Kconfig | 76 +- drivers/iommu/Makefile |2 + drivers/iommu/amd_iommu.c |3 +- drivers/iommu/amd_iommu_init.c | 10 +- drivers/iommu/dmar.c |2 +- drivers/iommu/exynos-iommu.c |2 +- drivers/iommu/iommu.c | 66 - drivers/iommu/omap-iommu.c |4 +- drivers/iommu/shmobile-iommu.c | 395 drivers/iommu/shmobile-ipmmu.c | 136 ++ drivers/iommu/shmobile-ipmmu.h | 34 +++ drivers/iommu/tegra-gart.c |4 +- drivers/iommu/tegra-smmu.c | 75 +++--- include/linux/iommu.h | 30 ++- include/linux/platform_data/sh_ipmmu.h | 18 ++ 28 files changed, 1043 insertions(+), 462 deletions(-) delete mode 100644 arch/arm/mach-ex
Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
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
> ---
> - no change.
> arch/powerpc/include/asm/device.h |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/device.h
> b/arch/powerpc/include/asm/device.h
> index 77e97dd..6dc79fe 100644
> --- a/arch/powerpc/include/asm/device.h
> +++ b/arch/powerpc/include/asm/device.h
> @@ -28,6 +28,10 @@ struct dev_archdata {
> void*iommu_table_base;
> } dma_data;
>
> + /* IOMMU domain information pointer. This would be set
> + * when this device is attached to an iommu_domain.
> + */
> + void*iommu_domain;
Please Cc the PowerPC Maintainers on this, so that they can have a look
at it. This also must be put this into an #ifdef CONFIG_IOMMU_API.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] powerpc/fsl_pci: Added defines for the FSL PCI controller BRR1 register.
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/pci-bridge.h > b/arch/powerpc/include/asm/pci-bridge.h > index 025a130..c12ed78 100644 > --- a/arch/powerpc/include/asm/pci-bridge.h > +++ b/arch/powerpc/include/asm/pci-bridge.h > @@ -14,6 +14,10 @@ > > struct device_node; > > +/* FSL PCI controller BRR1 register */ > +#define PCI_FSL_BRR1 0xbf8 > +#define PCI_FSL_BRR1_VER 0x > + Please merge this patch with the one where you actually make use of these defines for the first time. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6 v8] iommu/fsl: Add addtional attributes specific to the PAMU driver.
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 DMA to a particular
>memory window.
> 3. Added domain attribute to check for PAMUV1 specific constraints.
>
>
> Signed-off-by: Varun Sethi
> ---
> include/linux/iommu.h | 33 +
> 1 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 529987c..c44e38b 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -40,6 +40,23 @@ struct notifier_block;
> typedef int (*iommu_fault_handler_t)(struct iommu_domain *,
> struct device *, unsigned long, int, void *);
>
> +/* cache stash targets */
> +#define IOMMU_ATTR_CACHE_L1 1
> +#define IOMMU_ATTR_CACHE_L2 2
> +#define IOMMU_ATTR_CACHE_L3 3
> +
> +/* This attribute corresponds to IOMMUs capable of generating
> + * a stash transaction. A stash transaction is typically a
> + * hardware initiated prefetch of data from memory to cache.
> + * This attribute allows configuring stashig specific parameters
> + * in the IOMMU hardware.
> + */
> +
> +struct iommu_stash_attribute {
> + u32 cpu;/* cpu number */
> + u32 cache; /* cache to stash to: L1,L2,L3 */
> +};
Please make the cache-attribute an enum instead of using defines.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/platform changes for v3.9
On Wed, Feb 20, 2013 at 10:02:38AM +0100, Ingo Molnar wrote: > Timers and APIC would be my leading suspect - but scheduler and > hotplug changes might be the culprits as well. > > Yesterday, while preparing the trees I wanted to mention this > x86/apic commit: > > 336224ba5e4f x86, apic: Mask IO-APIC and PIC unconditionally on LAPIC resume > > ... as a change that needs monitored because it changes the > suspend and shutdown sequence but then skipped mentioning it > because it seemed relatively old and proven. Hmm, this commit only touches the resume-path. I would wonder if this has something to do with reboot, can't rule it out, though. > But there are other potentially dangerous commits as well - I > suspect we won't be able to avoid a bisection :-/ Yes, I think a bisection would be best if the problem is reproducible. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma-debug: Remove local BUS_NOTIFY_UNBOUND_DRIVER define
On Mon, Oct 01, 2012 at 12:48:31PM -0600, Shuah Khan wrote:
> Remove local BUS_NOTIFY_UNBOUND_DRIVER define. This is not used since
> BUS_NOTIFY_UNBOUND_DRIVER is defined in include/linux/device.h
>
> Signed-off-by: Shuah Khan
> ---
> lib/dma-debug.c |5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/lib/dma-debug.c b/lib/dma-debug.c
> index 66ce414..b9087bf 100644
> --- a/lib/dma-debug.c
> +++ b/lib/dma-debug.c
> @@ -120,11 +120,6 @@ static const char *type2name[4] = { "single", "page",
> static const char *dir2name[4] = { "DMA_BIDIRECTIONAL", "DMA_TO_DEVICE",
> "DMA_FROM_DEVICE", "DMA_NONE" };
>
> -/* little merge helper - remove it after the merge window */
> -#ifndef BUS_NOTIFY_UNBOUND_DRIVER
> -#define BUS_NOTIFY_UNBOUND_DRIVER 0x0005
> -#endif
> -
Thanks, applied.
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] IOMMU Updates for v3.7-rc1
Hi Linus, The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9: Linux 3.6 (2012-09-30 16:47:46 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v3.7-rc1 for you to fetch changes up to 009487258399cb4f431992919fa0f386d1b74ceb: Merge branches 'dma-debug', 'iommu/fixes', 'arm/tegra', 'arm/exynos', 'x86/amd', 'x86/vt-d' and 'x86/amd-irq-remapping' into next (2012-10-02 14:40:03 +0200) IOMMU Updates for Linux v3.7-rc1 This time the IOMMU updates contain a bunch of fixes and cleanups to various IOMMU drivers and the DMA debug code. New features are the code for IRQ remapping support with the AMD IOMMU (preperation for that was already merged in the last release) and a debugfs interface to export some statistics in the NVidia Tegra IOMMU driver. Alex Williamson (1): intel-iommu: Default to non-coherent for domains unattached to iommus Borislav Petkov (1): iommu/amd: Fix features reporting Dan Carpenter (1): iommu/amd: Fix possible use after free in get_irq_table() Frank Arnold (1): iommu/amd: Fix some typos Hiroshi Doyu (2): iommu/tegra: smmu: debugfs for TLB/PTC statistics iommu/tegra: smmu: Use debugfs_create_dir for directory Joerg Roedel (18): iommu/amd: Keep track of HPET and IOAPIC device ids iommu/amd: Add slab-cache for irq remapping tables iommu/amd: Allocate data structures to keep track of irq remapping tables iommu/amd: Check if IOAPIC information is correct iommu/amd: Split device table initialization into irq and dma part iommu/amd: Make sure IOMMU is not considered to translate itself iommu/amd: Add IRTE invalidation routine iommu/amd: Add routines to manage irq remapping tables iommu/amd: Add IOAPIC remapping routines iommu/amd: Implement MSI routines for interrupt remapping iommu/amd: Add call-back routine for HPET MSI iommu/amd: Add initialization routines for AMD interrupt remapping iommu/amd: Make sure irq remapping still works on dma init failure iommu/irq: Use amd_iommu_irq_ops if supported iommu/amd: Print message to system log when irq remapping is enabled iommu/amd: Report irq remapping through IOMMU-API iommu/amd: Remove obsolete comment line Merge branches 'dma-debug', 'iommu/fixes', 'arm/tegra', 'arm/exynos', 'x86/amd', 'x86/vt-d' and 'x86/amd-irq-remapping' into next Shuah Khan (1): dma-debug: Remove local BUS_NOTIFY_UNBOUND_DRIVER define Stephen Warren (1): dma: tegra: move smmu.h into SMMU driver Wei Yongjun (2): iommu/amd: remove duplicated include from amd_iommu_init.c iommu/exynos: use list_del_init instead of list_del/INIT_LIST_HEAD arch/arm/mach-tegra/include/mach/smmu.h | 63 drivers/iommu/Kconfig |2 +- drivers/iommu/amd_iommu.c | 514 ++- drivers/iommu/amd_iommu_init.c | 253 +-- drivers/iommu/amd_iommu_proto.h |8 + drivers/iommu/amd_iommu_types.h | 59 +++- drivers/iommu/exynos-iommu.c|3 +- drivers/iommu/intel-iommu.c |4 +- drivers/iommu/irq_remapping.c |5 + drivers/iommu/irq_remapping.h |6 + drivers/iommu/tegra-smmu.c | 261 +++- lib/dma-debug.c |5 - 12 files changed, 1071 insertions(+), 112 deletions(-) delete mode 100644 arch/arm/mach-tegra/include/mach/smmu.h Please pull. Regards, Joerg signature.asc Description: Digital signature
Re: [PATCH v5] dma-debug: New interfaces to debug dma mapping errors
On Mon, Oct 08, 2012 at 11:08:06AM -0600, Shuah Khan wrote: > Add dma-debug interface debug_dma_mapping_error() to debug drivers that fail > to check dma mapping errors on addresses returned by dma_map_single() and > dma_map_page() interfaces. This interface clears a flag set by > debug_dma_map_page() to indicate that dma_mapping_error() has been called by > the driver. When driver does unmap, debug_dma_unmap() checks the flag and if > this flag is still set, prints warning message that includes call trace that > leads up to the unmap. This interface can be called from dma_mapping_error() > routines to enable dma mapping error check debugging. > > Tested: Intel iommu and swiotlb (iommu=soft) on x86-64 with > CONFIG_DMA_API_DEBUG enabled and disabled. > > Signed-off-by: Shuah Khan Applied, thanks. -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Documentation DMA-API-HOWTO.txt Add dma mapping error check usage examples
On Thu, Oct 18, 2012 at 02:00:58PM -0600, Shuah Khan wrote: > Enhance the document to discuss the importance of dma mapping error checks > after dma_map_single() and dma_map_page() calls. Also added usage examples > that include unmap examples in error paths when dma mapping error is returned. > Includes correct and incorrect usages to high light some common mistakes in > error paths especially when dma mapping fails when more than one dma mapping > call is made. > > Signed-off-by: Shuah Khan Applied, thanks. -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/5] amd_iommu: Refactor IOMMU group and support virtual aliases
On Thu, Oct 18, 2012 at 03:29:10PM -0600, Alex Williamson wrote: > I think this series is good-to-go, modulo any testing you may be able to > do on it. I'm going to be offline for a couple weeks so feel free to > incorporate this RFC directly or I can re-spin something when I'm back. Okay, I applied the patches and will do some testing before pushing them out. I will fix all objections by follow-on patches. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] IOMMU Fixes for v3.7-rc2
Hi Linus, The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v3.7-rc2 for you to fetch changes up to d0078e72314df2e5ede03f2102cddde06767c374: iommu/tegra: smmu: Fix deadly typo (2012-10-24 16:58:53 +0200) IOMMU Fixes for Linux 3.7-rc2 Two fixes this time: 1. Another fix for a broken BIOS to detect when AMD IOMMU interrupt remapping can not work reliably 2. Typo fix for NVidia IOMMU driver Hiro Sugawara (1): iommu/tegra: smmu: Fix deadly typo Joerg Roedel (1): iommu/amd: Work around wrong IOAPIC device-id in IVRS table drivers/iommu/amd_iommu_init.c | 39 --- drivers/iommu/tegra-smmu.c |2 +- 2 files changed, 33 insertions(+), 8 deletions(-) Please pull. Regards, Joerg signature.asc Description: Digital signature
Re: [PATCH 12/19] x86, irq: Add data structure to keep AMD specific irq remapping information
On Sun, Aug 26, 2012 at 08:21:26PM +0200, Sebastian Andrzej Siewior wrote:
> On Mon, Aug 20, 2012 at 03:55:58PM +0200, Joerg Roedel wrote:
> > --- a/arch/x86/include/asm/hw_irq.h
> > +++ b/arch/x86/include/asm/hw_irq.h
> > @@ -101,6 +101,7 @@ static inline void set_io_apic_irq_attr(struct
> > io_apic_irq_attr *irq_attr,
> > irq_attr->polarity = polarity;
> > }
> >
> > +/* Intel specific interrupt remapping information */
> > struct irq_2_iommu {
> > struct intel_iommu *iommu;
> > u16 irte_index;
> > @@ -108,6 +109,12 @@ struct irq_2_iommu {
> > u8 irte_mask;
> > };
> >
> > +/* AMD specific interrupt remapping information */
> > +struct irq_2_irte {
> > + u16 devid; /* Device ID for IRTE table */
> > + u16 index; /* Index into IRTE table*/
> > +};
> so irte_index like in iommu case would make the comment superfluous. However
> the struct is already named _irte...
> However, the "{Intel|AMD} specific..." is helpfull since irte and such are
> present in both.
Yes, the structs also represent the differences in the remapping
hardware between Intel and AMD very well. On Intel there is one
remapping table per hardware IOMMU so it is important to get from a
given irq to the IOMMU and its remapping table to find the IRTE.
On AMD hardware there is a remapping table per device. So the
coresponding device id is stored in the struct to find the right
remapping table.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/19] x86, io_apic: Introduce function pointer for setup_timer_IRQ0_pin
On Sun, Aug 26, 2012 at 08:16:03PM +0200, Sebastian Andrzej Siewior wrote:
> On Mon, Aug 20, 2012 at 03:55:56PM +0200, Joerg Roedel wrote:
> > diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
> > index 827f8a1..71824fc 100644
> > --- a/drivers/iommu/irq_remapping.c
> > +++ b/drivers/iommu/irq_remapping.c
> > @@ -87,11 +87,18 @@ error:
> > return ret;
> > }
> >
> > +static void __init irq_remapping_setup_timer_pin(unsigned int ioapic_idx,
> > +unsigned int pin, int vector)
> > +{
> > + /* Not needed with interrupt remapping */
>
> I see that this is not needed because it is empty. But *why* isn't it needed?
> That comment would make sense here. So please drop this or explain :)
Well, the function is never called with interrupt-remapping enabled
anyway, so it is not needed. On the other side this makes the complete
patch pointless :) I'll remove it from the patch-set.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/19] x86, irq: Move irq_remapped() check into free_remapped_irq
On Sun, Aug 26, 2012 at 08:27:55PM +0200, Sebastian Andrzej Siewior wrote:
> On Mon, Aug 20, 2012 at 03:56:01PM +0200, Joerg Roedel wrote:
> > --- a/arch/x86/kernel/apic/io_apic.c
> > +++ b/arch/x86/kernel/apic/io_apic.c
> > @@ -2981,8 +2981,8 @@ void destroy_irq(unsigned int irq)
> >
> > irq_set_status_flags(irq, IRQ_NOREQUEST|IRQ_NOPROBE);
> >
> > - if (irq_remapped(cfg))
> > - free_remapped_irq(irq);
> > + free_remapped_irq(irq);
> > +
> > raw_spin_lock_irqsave(&vector_lock, flags);
> > __clear_irq_vector(irq, cfg);
> > raw_spin_unlock_irqrestore(&vector_lock, flags);
> > diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
> > index 3957fb2..f2affc7 100644
> > --- a/drivers/iommu/irq_remapping.c
> > +++ b/drivers/iommu/irq_remapping.c
> > @@ -229,10 +229,13 @@ int set_remapped_irq_affinity(struct irq_data *data,
> > const struct cpumask *mask,
> >
> > void free_remapped_irq(int irq)
> > {
> > + struct irq_cfg *cfg = irq_get_chip_data(irq);
> > +
> > if (!remap_ops || !remap_ops->free_irq)
> > return;
> >
> > - remap_ops->free_irq(irq);
> > + if (cfg && irq_remapped(cfg))
>
> You shuffle code with the exception that you now check for cfg. Why?
Just to be sure it is not NULL, but looking again at the previous code
it is not necessary. I remove the check for cfg.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 16/19] x86, irq: Introduce setup_remapped_irq()
On Sun, Aug 26, 2012 at 08:30:30PM +0200, Sebastian Andrzej Siewior wrote:
> On Mon, Aug 20, 2012 at 03:56:02PM +0200, Joerg Roedel wrote:
> > --- a/arch/x86/include/asm/irq_remapping.h
> > +++ b/arch/x86/include/asm/irq_remapping.h
> > @@ -44,6 +44,9 @@ extern void compose_remapped_msi_msg(struct pci_dev *pdev,
> > struct msi_msg *msg, u8 hpet_id);
> > extern int setup_hpet_msi_remapped(unsigned int irq, unsigned int id);
> > extern void panic_if_irq_remap(const char *msg);
> > +extern bool setup_remapped_irq(int irq,
> > + struct irq_cfg *cfg,
> > + struct irq_chip *chip);
> here and in the next definition, is it possible to fit it in one line or
> alteast in two?
It doesn't fit in one line (without violating the 80 column
recommendation). So I think this is the best readable alternative
format.
> What about
>
> bool setup_remapped_irq(int irq, struct irq_cfg *cfg, struct irq_chip *chip)
> {
> if (!irq_remapped(cfg))
> return false;
> irq_set_status_flags(irq, IRQ_MOVE_PCNTXT);
> irq_remap_modify_chip_defaults(chip);
> return true;
> }
You are right, that is better. I changed it.
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/19] x86, msi: Introduce x86_msi.compose_msi_msg call-back
On Sun, Aug 26, 2012 at 08:41:40PM +0200, Sebastian Andrzej Siewior wrote:
> On Mon, Aug 20, 2012 at 03:56:03PM +0200, Joerg Roedel wrote:
> > This call-back points to the right function for initializing
> > the msi_msg structure.
>
> So you pull out the compose_remapped_msi_msg() out of msi_compose_msg() and
> put this in a callback. Such information is good since you don't see this in
> diff and even --patience does not help here.
Added that to the commit message.
>
> > --- a/drivers/iommu/irq_remapping.c
> > +++ b/drivers/iommu/irq_remapping.c
> > @@ -242,10 +243,12 @@ void compose_remapped_msi_msg(struct pci_dev *pdev,
> > unsigned int irq, unsigned int dest,
> > struct msi_msg *msg, u8 hpet_id)
> > {
> > - if (!remap_ops || !remap_ops->compose_msi_msg)
> > - return;
> > + struct irq_cfg *cfg = irq_get_chip_data(irq);
> >
> > - remap_ops->compose_msi_msg(pdev, irq, dest, msg, hpet_id);
> > + if (cfg && !irq_remapped(cfg))
> > + native_compose_msi_msg(pdev, irq, dest, msg, hpet_id);
> > + else if (remap_ops && remap_ops->compose_msi_msg)
> > + remap_ops->compose_msi_msg(pdev, irq, dest, msg, hpet_id);
>
> cfg _has_ to be valid here and if it is not than you shouldn't assume that
> this irq is remapped.
> Also remap_ops has to be set here. And ->compose_msi_msg() should be set
> here as well. Would it make sense if it is not set?
I removed the check for cfg, but I am still conservative on calling
function pointers without checking them first.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/19] x86, io_apic: Introduce eoi_ioapic_pin call-back
On Sun, Aug 26, 2012 at 08:52:33PM +0200, Sebastian Andrzej Siewior wrote: > Basically you shuffle the code from up there, down there and call from behind > a function pointer. There are two things different this time: > - no version check >= 0x20 > I belive this is obsolete since this runs only on x86-64 with x(2)apic > support and assumes more or less version 0x20+ or we wouldn't be here at > all. Right, all systems that have interrupt remapping have an io-apic version of 0x20 or higher. > - the irq_remapped(cfg) check is gone. The cfg thing is per-interrupt basis > created so you _now_ you act like the interrupt is remapped even if it is > not. Or am I wrong here? That comes from the fact that with the current implementation (with and without my patches) IO-APIC interrupts are always remapped. So it is safe to remove that check. > > + > New line and the end? Why would that be? Coding leftover, I'll remove that. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/19] x86, io_apic: Move irq_remapping_enabled checks out of check_timer()
Move these checks to IRQ remapping code by introducing the
panic_on_irq_remap() function.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/irq_remapping.h |5 +
arch/x86/kernel/apic/io_apic.c |6 ++
drivers/iommu/irq_remapping.c|6 ++
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index f1afa04..fb99a73 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -45,6 +45,7 @@ extern void compose_remapped_msi_msg(struct pci_dev *pdev,
unsigned int irq, unsigned int dest,
struct msi_msg *msg, u8 hpet_id);
extern int setup_hpet_msi_remapped(unsigned int irq, unsigned int id);
+extern void panic_if_irq_remap(const char *msg);
#else /* CONFIG_IRQ_REMAP */
@@ -75,6 +76,10 @@ static inline int setup_hpet_msi_remapped(unsigned int irq,
unsigned int id)
{
return -ENODEV;
}
+
+static inline void panic_if_irq_remap(const char *msg)
+{
+}
#endif /* CONFIG_IRQ_REMAP */
#endif /* __X86_IRQ_REMAPPING_H */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 9500a07..360f62b 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2786,8 +2786,7 @@ static inline void __init check_timer(void)
* 8259A.
*/
if (pin1 == -1) {
- if (irq_remapping_enabled)
- panic("BIOS bug: timer not connected to IO-APIC");
+ panic_if_irq_remap("BIOS bug: timer not connected to IO-APIC");
pin1 = pin2;
apic1 = apic2;
no_pin1 = 1;
@@ -2819,8 +2818,7 @@ static inline void __init check_timer(void)
clear_IO_APIC_pin(0, pin1);
goto out;
}
- if (irq_remapping_enabled)
- panic("timer doesn't work through Interrupt-remapped
IO-APIC");
+ panic_if_irq_remap("timer doesn't work through
Interrupt-remapped IO-APIC");
local_irq_disable();
clear_IO_APIC_pin(apic1, pin1);
if (!no_pin1)
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 5b28e28..827f8a1 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -261,3 +261,9 @@ int setup_hpet_msi_remapped(unsigned int irq, unsigned int
id)
return remap_ops->setup_hpet_msi(irq, id);
}
+
+void panic_if_irq_remap(const char *msg)
+{
+ if (irq_remapping_enabled)
+ panic(msg);
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/19] x86, irq: Introduce setup_remapped_irq()
This function does irq-remapping specific interrupt setup
like modifying the chip defaults.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/irq_remapping.h |9 +
arch/x86/kernel/apic/io_apic.c | 13 +++--
drivers/iommu/irq_remapping.c|9 +
3 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index 562db68..b30fca1 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -44,6 +44,9 @@ extern void compose_remapped_msi_msg(struct pci_dev *pdev,
struct msi_msg *msg, u8 hpet_id);
extern int setup_hpet_msi_remapped(unsigned int irq, unsigned int id);
extern void panic_if_irq_remap(const char *msg);
+extern bool setup_remapped_irq(int irq,
+ struct irq_cfg *cfg,
+ struct irq_chip *chip);
static inline bool irq_remapped(struct irq_cfg *cfg)
{
@@ -93,6 +96,12 @@ static inline void irq_remap_modify_chip_defaults(struct
irq_chip *chip)
{
}
+static inline bool setup_remapped_irq(int irq,
+ struct irq_cfg *cfg,
+ struct irq_chip *chip)
+{
+ return false;
+}
#endif /* CONFIG_IRQ_REMAP */
#endif /* __X86_IRQ_REMAPPING_H */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 87a0fd1..88c4fff 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1292,11 +1292,8 @@ static void ioapic_register_intr(unsigned int irq,
struct irq_cfg *cfg,
fasteoi = false;
}
- if (irq_remapped(cfg)) {
- irq_set_status_flags(irq, IRQ_MOVE_PCNTXT);
- irq_remap_modify_chip_defaults(chip);
+ if (setup_remapped_irq(irq, cfg, chip))
fasteoi = trigger != 0;
- }
hdl = fasteoi ? handle_fasteoi_irq : handle_edge_irq;
irq_set_chip_and_handler_name(irq, chip, hdl,
@@ -3103,10 +3100,7 @@ int setup_msi_irq(struct pci_dev *dev, struct msi_desc
*msidesc, int irq)
irq_set_msi_desc(irq, msidesc);
write_msi_msg(irq, &msg);
- if (irq_remapped(irq_get_chip_data(irq))) {
- irq_set_status_flags(irq, IRQ_MOVE_PCNTXT);
- irq_remap_modify_chip_defaults(chip);
- }
+ setup_remapped_irq(irq, irq_get_chip_data(irq), chip);
irq_set_chip_and_handler_name(irq, chip, handle_edge_irq, "edge");
@@ -3244,8 +3238,7 @@ int default_setup_hpet_msi(unsigned int irq, unsigned int
id)
hpet_msi_write(irq_get_handler_data(irq), &msg);
irq_set_status_flags(irq, IRQ_MOVE_PCNTXT);
- if (irq_remapped(irq_get_chip_data(irq)))
- irq_remap_modify_chip_defaults(chip);
+ setup_remapped_irq(irq, irq_get_chip_data(irq), chip);
irq_set_chip_and_handler_name(irq, chip, handle_edge_irq, "edge");
return 0;
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 165ac14..1e6bc13 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -295,3 +295,12 @@ void irq_remap_modify_chip_defaults(struct irq_chip *chip)
chip->irq_eoi = ir_ack_apic_level;
chip->irq_set_affinity = x86_io_apic_ops.set_affinity;
}
+
+bool setup_remapped_irq(int irq, struct irq_cfg *cfg, struct irq_chip *chip)
+{
+ if (!irq_remapped(cfg))
+ return false;
+ irq_set_status_flags(irq, IRQ_MOVE_PCNTXT);
+ irq_remap_modify_chip_defaults(chip);
+ return true;
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/19] x86, apic: Move irq_remapping_enabled checks into IRQ-remapping code
Move the three easy to move checks in the x86' apic.c file
into the IRQ-remapping code.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/apic/apic.c |9 +++--
drivers/iommu/irq_remapping.c | 11 +--
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 24deb30..41681b3 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1444,8 +1444,7 @@ void __init bsp_end_local_APIC_setup(void)
* Now that local APIC setup is completed for BP, configure the fault
* handling for interrupt remapping.
*/
- if (irq_remapping_enabled)
- irq_remap_enable_fault_handling();
+ irq_remap_enable_fault_handling();
}
@@ -2218,8 +2217,7 @@ static int lapic_suspend(void)
local_irq_save(flags);
disable_local_APIC();
- if (irq_remapping_enabled)
- irq_remapping_disable();
+ irq_remapping_disable();
local_irq_restore(flags);
return 0;
@@ -2287,8 +2285,7 @@ static void lapic_resume(void)
apic_write(APIC_ESR, 0);
apic_read(APIC_ESR);
- if (irq_remapping_enabled)
- irq_remapping_reenable(x2apic_mode);
+ irq_remapping_reenable(x2apic_mode);
local_irq_restore(flags);
}
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index 151690d..283a43f 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -82,7 +82,9 @@ int __init irq_remapping_enable(void)
void irq_remapping_disable(void)
{
- if (!remap_ops || !remap_ops->disable)
+ if (!irq_remapping_enabled ||
+ !remap_ops ||
+ !remap_ops->disable)
return;
remap_ops->disable();
@@ -90,7 +92,9 @@ void irq_remapping_disable(void)
int irq_remapping_reenable(int mode)
{
- if (!remap_ops || !remap_ops->reenable)
+ if (!irq_remapping_enabled ||
+ !remap_ops ||
+ !remap_ops->reenable)
return 0;
return remap_ops->reenable(mode);
@@ -98,6 +102,9 @@ int irq_remapping_reenable(int mode)
int __init irq_remap_enable_fault_handling(void)
{
+ if (!irq_remapping_enabled)
+ return 0;
+
if (!remap_ops || !remap_ops->enable_faulting)
return -ENODEV;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/19 v3] Improve IRQ remapping abstraction in x86 core code
Hi, here is the third version of the patch-set to improve the abstraction of interrupt remapping in the x86 core code. A more detailed description can be found in the original post at: https://lkml.org/lkml/2012/8/7/317 Changes from v2->v3: * Rebased to v3.6-rc7 * Worked in most comments on v2 by Sebastian Andrzej Siewior Changes from v1->v2: * Fixed a couple of compile issues on i386 (reported by Fengguang Wu, thanks a lot) * Rebased to Linux v3.6-rc2 Please review. Cheers, Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/19] x86, irq: Move irq_remapped() check into free_remapped_irq
The function is called unconditionally now in IO-APIC code
removing another irq_remapped() check from x86 core code.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/apic/io_apic.c |4 ++--
drivers/iommu/irq_remapping.c |5 -
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index dd555e7..87a0fd1 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2991,8 +2991,8 @@ void destroy_irq(unsigned int irq)
irq_set_status_flags(irq, IRQ_NOREQUEST|IRQ_NOPROBE);
- if (irq_remapped(cfg))
- free_remapped_irq(irq);
+ free_remapped_irq(irq);
+
raw_spin_lock_irqsave(&vector_lock, flags);
__clear_irq_vector(irq, cfg);
raw_spin_unlock_irqrestore(&vector_lock, flags);
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index f0ac30a..165ac14 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -222,10 +222,13 @@ int set_remapped_irq_affinity(struct irq_data *data,
const struct cpumask *mask,
void free_remapped_irq(int irq)
{
+ struct irq_cfg *cfg = irq_get_chip_data(irq);
+
if (!remap_ops || !remap_ops->free_irq)
return;
- remap_ops->free_irq(irq);
+ if (irq_remapped(cfg))
+ remap_ops->free_irq(irq);
}
void compose_remapped_msi_msg(struct pci_dev *pdev,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/19] x86, hpet: Introduce x86_msi_ops.setup_hpet_msi
This function pointer can be overwritten by the IRQ
remapping code. The irq_remapping_enabled check can be
removed from default_setup_hpet_msi.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/hpet.h |5 +++--
arch/x86/include/asm/x86_init.h |1 +
arch/x86/kernel/apic/io_apic.c |7 +--
arch/x86/kernel/hpet.c |2 +-
arch/x86/kernel/x86_init.c | 10 ++
drivers/iommu/irq_remapping.c |3 ++-
6 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/hpet.h b/arch/x86/include/asm/hpet.h
index 2c392d6..ad2dae0 100644
--- a/arch/x86/include/asm/hpet.h
+++ b/arch/x86/include/asm/hpet.h
@@ -82,9 +82,9 @@ extern void hpet_msi_write(struct hpet_dev *hdev, struct
msi_msg *msg);
extern void hpet_msi_read(struct hpet_dev *hdev, struct msi_msg *msg);
#ifdef CONFIG_PCI_MSI
-extern int arch_setup_hpet_msi(unsigned int irq, unsigned int id);
+extern int default_setup_hpet_msi(unsigned int irq, unsigned int id);
#else
-static inline int arch_setup_hpet_msi(unsigned int irq, unsigned int id)
+static inline int default_setup_hpet_msi(unsigned int irq, unsigned int id)
{
return -EINVAL;
}
@@ -113,6 +113,7 @@ extern void hpet_unregister_irq_handler(rtc_irq_handler
handler);
static inline int hpet_enable(void) { return 0; }
static inline int is_hpet_enabled(void) { return 0; }
#define hpet_readl(a) 0
+#define default_setup_hpet_msi NULL
#endif
#endif /* _ASM_X86_HPET_H */
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index be8e9a6..1f49c8a 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -186,6 +186,7 @@ struct x86_msi_ops {
void (*teardown_msi_irq)(unsigned int irq);
void (*teardown_msi_irqs)(struct pci_dev *dev);
void (*restore_msi_irqs)(struct pci_dev *dev, int irq);
+ int (*setup_hpet_msi)(unsigned int irq, unsigned int id);
};
struct x86_io_apic_ops {
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 8c6260f..ab07371 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3307,17 +3307,12 @@ static struct irq_chip hpet_msi_type = {
.irq_retrigger = ioapic_retrigger_irq,
};
-int arch_setup_hpet_msi(unsigned int irq, unsigned int id)
+int default_setup_hpet_msi(unsigned int irq, unsigned int id)
{
struct irq_chip *chip = &hpet_msi_type;
struct msi_msg msg;
int ret;
- if (irq_remapping_enabled) {
- if (!setup_hpet_msi_remapped(irq, id))
- return -1;
- }
-
ret = msi_compose_msg(NULL, irq, &msg, id);
if (ret < 0)
return ret;
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 1460a5d..22d4fe5 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -478,7 +478,7 @@ static int hpet_msi_next_event(unsigned long delta,
static int hpet_setup_msi_irq(unsigned int irq)
{
- if (arch_setup_hpet_msi(irq, hpet_blockid)) {
+ if (x86_msi.setup_hpet_msi(irq, hpet_blockid)) {
destroy_irq(irq);
return -EINVAL;
}
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index dc19c50..339e108 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -113,10 +114,11 @@ struct x86_platform_ops x86_platform = {
EXPORT_SYMBOL_GPL(x86_platform);
struct x86_msi_ops x86_msi = {
- .setup_msi_irqs = native_setup_msi_irqs,
- .teardown_msi_irq = native_teardown_msi_irq,
- .teardown_msi_irqs = default_teardown_msi_irqs,
- .restore_msi_irqs = default_restore_msi_irqs,
+ .setup_msi_irqs = native_setup_msi_irqs,
+ .teardown_msi_irq = native_teardown_msi_irq,
+ .teardown_msi_irqs = default_teardown_msi_irqs,
+ .restore_msi_irqs = default_restore_msi_irqs,
+ .setup_hpet_msi = default_setup_hpet_msi,
};
struct x86_io_apic_ops x86_io_apic_ops = {
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index f72a5e8..f439151 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -36,7 +36,8 @@ static void irq_remapping_disable_io_apic(void)
static void __init irq_remapping_modify_x86_ops(void)
{
- x86_io_apic_ops.disable = irq_remapping_disable_io_apic;
+ x86_io_apic_ops.disable = irq_remapping_disable_io_apic;
+ x86_msi.setup_hpet_msi = setup_hpet_msi_remapped;
}
static __init int setup_nointremap(char *str)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 19/19] x86, irq: Move irq_remapped out of x86 core code
The irq_remapped function is only used in IOMMU code after
the last patch. So move its definition there too.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/irq_remapping.h | 10 --
drivers/iommu/irq_remapping.c|5 +
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index b30fca1..95fd352 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -48,11 +48,6 @@ extern bool setup_remapped_irq(int irq,
struct irq_cfg *cfg,
struct irq_chip *chip);
-static inline bool irq_remapped(struct irq_cfg *cfg)
-{
- return (cfg->remapped == 1);
-}
-
void irq_remap_modify_chip_defaults(struct irq_chip *chip);
#else /* CONFIG_IRQ_REMAP */
@@ -87,11 +82,6 @@ static inline void panic_if_irq_remap(const char *msg)
{
}
-static inline bool irq_remapped(struct irq_cfg *cfg)
-{
- return false;
-}
-
static inline void irq_remap_modify_chip_defaults(struct irq_chip *chip)
{
}
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index df8b71e..99f61b7 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -31,6 +31,11 @@ static int set_remapped_irq_affinity(struct irq_data *data,
const struct cpumask *mask,
bool force);
+static bool irq_remapped(struct irq_cfg *cfg)
+{
+ return (cfg->remapped == 1);
+}
+
static void irq_remapping_disable_io_apic(void)
{
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/19] x86, msi: Use IRQ remapping specific setup_msi_irqs routine
Use seperate routines to setup MSI IRQs for both
irq_remapping_enabled cases.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/irq_remapping.h | 12 ---
arch/x86/include/asm/pci.h |2 ++
arch/x86/kernel/apic/io_apic.c | 26 ++--
drivers/iommu/irq_remapping.c| 57 --
4 files changed, 59 insertions(+), 38 deletions(-)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index 5fb9bbb..0ee1e88 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -47,9 +47,6 @@ extern void free_remapped_irq(int irq);
extern void compose_remapped_msi_msg(struct pci_dev *pdev,
unsigned int irq, unsigned int dest,
struct msi_msg *msg, u8 hpet_id);
-extern int msi_alloc_remapped_irq(struct pci_dev *pdev, int irq, int nvec);
-extern int msi_setup_remapped_irq(struct pci_dev *pdev, unsigned int irq,
- int index, int sub_handle);
extern int setup_hpet_msi_remapped(unsigned int irq, unsigned int id);
#else /* CONFIG_IRQ_REMAP */
@@ -83,15 +80,6 @@ static inline void compose_remapped_msi_msg(struct pci_dev
*pdev,
struct msi_msg *msg, u8 hpet_id)
{
}
-static inline int msi_alloc_remapped_irq(struct pci_dev *pdev, int irq, int
nvec)
-{
- return -ENODEV;
-}
-static inline int msi_setup_remapped_irq(struct pci_dev *pdev, unsigned int
irq,
-int index, int sub_handle)
-{
- return -ENODEV;
-}
static inline int setup_hpet_msi_remapped(unsigned int irq, unsigned int id)
{
return -ENODEV;
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index df75d07..1470b53 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -121,9 +121,11 @@ static inline void x86_restore_msi_irqs(struct pci_dev
*dev, int irq)
#define arch_teardown_msi_irq x86_teardown_msi_irq
#define arch_restore_msi_irqs x86_restore_msi_irqs
/* implemented in arch/x86/kernel/apic/io_apic. */
+struct msi_desc;
int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type);
void native_teardown_msi_irq(unsigned int irq);
void native_restore_msi_irqs(struct pci_dev *dev, int irq);
+int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc, int irq);
/* default to the implementation in drivers/lib/msi.c */
#define HAVE_DEFAULT_MSI_TEARDOWN_IRQS
#define HAVE_DEFAULT_MSI_RESTORE_IRQS
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index ab07371..5ae0292 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3145,7 +3145,7 @@ static struct irq_chip msi_chip = {
.irq_retrigger = ioapic_retrigger_irq,
};
-static int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc, int
irq)
+int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc, int irq)
{
struct irq_chip *chip = &msi_chip;
struct msi_msg msg;
@@ -3172,9 +3172,9 @@ static int setup_msi_irq(struct pci_dev *dev, struct
msi_desc *msidesc, int irq)
int native_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
{
- int node, ret, sub_handle, index = 0;
unsigned int irq, irq_want;
struct msi_desc *msidesc;
+ int node, ret;
/* x86 doesn't support multiple MSI yet */
if (type == PCI_CAP_ID_MSI && nvec > 1)
@@ -3182,36 +3182,16 @@ int native_setup_msi_irqs(struct pci_dev *dev, int
nvec, int type)
node = dev_to_node(&dev->dev);
irq_want = nr_irqs_gsi;
- sub_handle = 0;
list_for_each_entry(msidesc, &dev->msi_list, list) {
irq = create_irq_nr(irq_want, node);
if (irq == 0)
return -1;
+
irq_want = irq + 1;
- if (!irq_remapping_enabled)
- goto no_ir;
- if (!sub_handle) {
- /*
-* allocate the consecutive block of IRTE's
-* for 'nvec'
-*/
- index = msi_alloc_remapped_irq(dev, irq, nvec);
- if (index < 0) {
- ret = index;
- goto error;
- }
- } else {
- ret = msi_setup_remapped_irq(dev, irq, index,
-sub_handle);
- if (ret < 0)
- goto error;
- }
-no_ir:
ret = setup_msi_irq(dev, msidesc, irq);
if (ret < 0)
goto error;
- sub_handle++;
}
return 0;
diff --git a/drivers/iommu/irq_remappin
[PATCH 04/19] x86, io_apic: Introduce x86_io_apic_ops.print_entries for debugging
This call-back is used to dump IO-APIC entries for debugging
purposes into the kernel log. VT-d needs a special routine
for this and will overwrite the default.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/io_apic.h |3 +
arch/x86/include/asm/x86_init.h |1 +
arch/x86/kernel/apic/io_apic.c | 109 ++-
arch/x86/kernel/x86_init.c |1 +
drivers/iommu/intel_irq_remapping.c |8 +++
5 files changed, 69 insertions(+), 53 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index d59e172..21aa81e 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -180,6 +180,8 @@ extern unsigned int native_io_apic_read(unsigned int apic,
unsigned int reg);
extern void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned
int val);
extern void native_io_apic_modify(unsigned int apic, unsigned int reg,
unsigned int val);
extern void native_disable_io_apic(void);
+extern void native_io_apic_print_entries(unsigned int apic, unsigned int
nr_entries);
+extern void intel_ir_io_apic_print_entries(unsigned int apic, unsigned int
nr_entries);
static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
{
@@ -225,6 +227,7 @@ static inline void disable_ioapic_support(void) { }
#define native_io_apic_write NULL
#define native_io_apic_modify NULL
#define native_disable_io_apic NULL
+#define native_io_apic_print_entries NULL
#endif
#endif /* _ASM_X86_IO_APIC_H */
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 8e1b44c..be8e9a6 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -194,6 +194,7 @@ struct x86_io_apic_ops {
void(*write) (unsigned int apic, unsigned int reg,
unsigned int value);
void(*modify) (unsigned int apic, unsigned int reg,
unsigned int value);
void(*disable)(void);
+ void(*print_entries)(unsigned int apic, unsigned int
nr_entries);
};
extern struct x86_init_ops x86_init;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index c28c991..8c6260f 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1527,9 +1527,63 @@ static void __init setup_timer_IRQ0_pin(unsigned int
ioapic_idx,
ioapic_write_entry(ioapic_idx, pin, entry);
}
-__apicdebuginit(void) print_IO_APIC(int ioapic_idx)
+void native_io_apic_print_entries(unsigned int apic, unsigned int nr_entries)
+{
+ int i;
+
+ pr_debug(" NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:\n");
+
+ for (i = 0; i <= nr_entries; i++) {
+ struct IO_APIC_route_entry entry;
+
+ entry = ioapic_read_entry(apic, i);
+
+ pr_debug(" %02x %02X ", i, entry.dest);
+ pr_cont("%1d%1d%1d %1d %1d"
+ "%1d%1d%02X\n",
+ entry.mask,
+ entry.trigger,
+ entry.irr,
+ entry.polarity,
+ entry.delivery_status,
+ entry.dest_mode,
+ entry.delivery_mode,
+ entry.vector);
+ }
+}
+
+void intel_ir_io_apic_print_entries(unsigned int apic,
+ unsigned int nr_entries)
{
int i;
+
+ pr_debug(" NR Indx Fmt Mask Trig IRR Pol Stat Indx2 Zero Vect:\n");
+
+ for (i = 0; i <= nr_entries; i++) {
+ struct IR_IO_APIC_route_entry *ir_entry;
+ struct IO_APIC_route_entry entry;
+
+ entry = ioapic_read_entry(apic, i);
+
+ ir_entry = (struct IR_IO_APIC_route_entry *)&entry;
+
+ pr_debug(" %02x %04X ", i, ir_entry->index);
+ pr_cont("%1d %1d%1d%1d %1d "
+ "%1d%1d %X%02X\n",
+ ir_entry->format,
+ ir_entry->mask,
+ ir_entry->trigger,
+ ir_entry->irr,
+ ir_entry->polarity,
+ ir_entry->delivery_status,
+ ir_entry->index2,
+ ir_entry->zero,
+ ir_entry->vector);
+ }
+}
+
+__apicdebuginit(void) print_IO_APIC(int ioapic_idx)
+{
union IO_APIC_reg_00 reg_00;
union IO_APIC_reg_01 reg_01;
union IO_APIC_reg_02 reg_02;
@@ -1582,58 +1636,7 @@ __apicdebuginit(void) print_IO_APIC(int ioapic_idx)
printk(KERN_DEBUG " IRQ redirection table:\n");
- if (irq_remapping_enabled) {
- printk(KERN_DEBUG " NR Indx Fmt Mask Trig IRR&
[PATCH 02/19] x86, apic: Mask IO-APIC and PIC unconditionally on LAPIC resume
IO-APIC and PIC use the same resume routines when IRQ
remapping is enabled or disabled. So it should be safe to
mask the other APICs for the IRQ-remapping-disabled case
too.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/apic/apic.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 41681b3..109380a 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2233,16 +2233,15 @@ static void lapic_resume(void)
return;
local_irq_save(flags);
- if (irq_remapping_enabled) {
- /*
-* IO-APIC and PIC have their own resume routines.
-* We just mask them here to make sure the interrupt
-* subsystem is completely quiet while we enable x2apic
-* and interrupt-remapping.
-*/
- mask_ioapic_entries();
- legacy_pic->mask_all();
- }
+
+ /*
+* IO-APIC and PIC have their own resume routines.
+* We just mask them here to make sure the interrupt
+* subsystem is completely quiet while we enable x2apic
+* and interrupt-remapping.
+*/
+ mask_ioapic_entries();
+ legacy_pic->mask_all();
if (x2apic_mode)
enable_x2apic();
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/19] x86, io_apic: Introduce eoi_ioapic_pin call-back
This callback replaces the old __eoi_ioapic_pin function
which needs a special path for interrupt remapping.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/io_apic.h |5 +
arch/x86/include/asm/x86_init.h |1 +
arch/x86/kernel/apic/io_apic.c | 20 ++--
arch/x86/kernel/x86_init.c |1 +
drivers/iommu/irq_remapping.c | 12
5 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 1838e88..459e50a 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -161,6 +161,7 @@ extern void eoi_ioapic_irq(unsigned int irq, struct irq_cfg
*cfg);
extern void native_compose_msi_msg(struct pci_dev *pdev,
unsigned int irq, unsigned int dest,
struct msi_msg *msg, u8 hpet_id);
+extern void native_eoi_ioapic_pin(int apic, int pin, int vector);
int io_apic_setup_irq_pin_once(unsigned int irq, int node, struct
io_apic_irq_attr *attr);
extern int save_ioapic_entries(void);
@@ -211,6 +212,9 @@ static inline void io_apic_modify(unsigned int apic,
unsigned int reg, unsigned
{
x86_io_apic_ops.modify(apic, reg, value);
}
+
+extern void io_apic_eoi(unsigned int apic, unsigned int vector);
+
#else /* !CONFIG_X86_IO_APIC */
#define io_apic_assign_pci_irqs 0
@@ -246,6 +250,7 @@ static inline void disable_ioapic_support(void) { }
#define native_ioapic_set_affinity NULL
#define native_setup_ioapic_entry NULL
#define native_compose_msi_msg NULL
+#define native_eoi_ioapic_pin NULL
#endif
#endif /* _ASM_X86_IO_APIC_H */
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 3ef598e..7505cd7 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -211,6 +211,7 @@ struct x86_io_apic_ops {
int (*setup_entry)(int irq, struct IO_APIC_route_entry
*entry,
unsigned int destination, int vector,
struct io_apic_irq_attr *attr);
+ void(*eoi_ioapic_pin)(int apic, int pin, int vector);
};
extern struct x86_init_ops x86_init;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index c545a1d..1718a30 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -310,7 +310,7 @@ static __attribute_const__ struct io_apic __iomem
*io_apic_base(int idx)
+ (mpc_ioapic_addr(idx) & ~PAGE_MASK);
}
-static inline void io_apic_eoi(unsigned int apic, unsigned int vector)
+void io_apic_eoi(unsigned int apic, unsigned int vector)
{
struct io_apic __iomem *io_apic = io_apic_base(apic);
writel(vector, &io_apic->eoi);
@@ -557,19 +557,10 @@ static void unmask_ioapic_irq(struct irq_data *data)
* Otherwise, we simulate the EOI message manually by changing the trigger
* mode to edge and then back to level, with RTE being masked during this.
*/
-static void __eoi_ioapic_pin(int apic, int pin, int vector, struct irq_cfg
*cfg)
+void native_eoi_ioapic_pin(int apic, int pin, int vector)
{
if (mpc_ioapic_ver(apic) >= 0x20) {
- /*
-* Intr-remapping uses pin number as the virtual vector
-* in the RTE. Actual vector is programmed in
-* intr-remapping table entry. Hence for the io-apic
-* EOI we use the pin number.
-*/
- if (cfg && irq_remapped(cfg))
- io_apic_eoi(apic, pin);
- else
- io_apic_eoi(apic, vector);
+ io_apic_eoi(apic, vector);
} else {
struct IO_APIC_route_entry entry, entry1;
@@ -597,7 +588,8 @@ void eoi_ioapic_irq(unsigned int irq, struct irq_cfg *cfg)
raw_spin_lock_irqsave(&ioapic_lock, flags);
for_each_irq_pin(entry, cfg->irq_2_pin)
- __eoi_ioapic_pin(entry->apic, entry->pin, cfg->vector, cfg);
+ x86_io_apic_ops.eoi_ioapic_pin(entry->apic, entry->pin,
+ cfg->vector);
raw_spin_unlock_irqrestore(&ioapic_lock, flags);
}
@@ -634,7 +626,7 @@ static void clear_IO_APIC_pin(unsigned int apic, unsigned
int pin)
}
raw_spin_lock_irqsave(&ioapic_lock, flags);
- __eoi_ioapic_pin(apic, pin, entry.vector, NULL);
+ x86_io_apic_ops.eoi_ioapic_pin(apic, pin, entry.vector);
raw_spin_unlock_irqrestore(&ioapic_lock, flags);
}
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 357d127..68794a8 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -131,4 +131,5 @@ struct x86_io_apic_ops x86_io_apic_ops = {
.print_entries
[PATCH 13/19] x86, io-apic: Move CONFIG_IRQ_REMAP code out of x86 core
Move all the code to either to the header file
asm/irq_remapping.h or to drivers/iommu/.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/hw_irq.h|1 +
arch/x86/include/asm/io_apic.h |5
arch/x86/include/asm/irq_remapping.h | 17 +
arch/x86/kernel/apic/io_apic.c | 44 +-
drivers/iommu/intel_irq_remapping.c |4
drivers/iommu/irq_remapping.c| 25 +++
6 files changed, 53 insertions(+), 43 deletions(-)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index fc89a2a..10a78c3 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -127,6 +127,7 @@ struct irq_cfg {
u8 vector;
u8 move_in_progress : 1;
#ifdef CONFIG_IRQ_REMAP
+ u8 remapped : 1;
union {
struct irq_2_iommu irq_2_iommu;
struct irq_2_irte irq_2_irte;
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 71f5f08..36fb5ab 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -144,6 +144,7 @@ extern int timer_through_8259;
(mp_irq_entries && !skip_ioapic_setup && io_apic_irqs)
struct io_apic_irq_attr;
+struct irq_cfg;
extern int io_apic_set_pci_routing(struct device *dev, int irq,
struct io_apic_irq_attr *irq_attr);
void setup_IO_APIC_irq_extra(u32 gsi);
@@ -152,6 +153,10 @@ extern void ioapic_insert_resources(void);
extern int native_setup_ioapic_entry(int, struct IO_APIC_route_entry *,
unsigned int, int,
struct io_apic_irq_attr *);
+extern int native_setup_ioapic_entry(int, struct IO_APIC_route_entry *,
+unsigned int, int,
+struct io_apic_irq_attr *);
+extern void eoi_ioapic_irq(unsigned int irq, struct irq_cfg *cfg);
int io_apic_setup_irq_pin_once(unsigned int irq, int node, struct
io_apic_irq_attr *attr);
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index 6f4b48b..562db68 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -45,6 +45,13 @@ extern void compose_remapped_msi_msg(struct pci_dev *pdev,
extern int setup_hpet_msi_remapped(unsigned int irq, unsigned int id);
extern void panic_if_irq_remap(const char *msg);
+static inline bool irq_remapped(struct irq_cfg *cfg)
+{
+ return (cfg->remapped == 1);
+}
+
+void irq_remap_modify_chip_defaults(struct irq_chip *chip);
+
#else /* CONFIG_IRQ_REMAP */
static inline void setup_irq_remapping_ops(void) { }
@@ -76,6 +83,16 @@ static inline int setup_hpet_msi_remapped(unsigned int irq,
unsigned int id)
static inline void panic_if_irq_remap(const char *msg)
{
}
+
+static inline bool irq_remapped(struct irq_cfg *cfg)
+{
+ return false;
+}
+
+static inline void irq_remap_modify_chip_defaults(struct irq_chip *chip)
+{
+}
+
#endif /* CONFIG_IRQ_REMAP */
#endif /* __X86_IRQ_REMAPPING_H */
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index d5cd6e1..6f2f21a 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -68,22 +68,6 @@
#define for_each_irq_pin(entry, head) \
for (entry = head; entry; entry = entry->next)
-#ifdef CONFIG_IRQ_REMAP
-static void irq_remap_modify_chip_defaults(struct irq_chip *chip);
-static inline bool irq_remapped(struct irq_cfg *cfg)
-{
- return cfg->irq_2_iommu.iommu != NULL;
-}
-#else
-static inline bool irq_remapped(struct irq_cfg *cfg)
-{
- return false;
-}
-static inline void irq_remap_modify_chip_defaults(struct irq_chip *chip)
-{
-}
-#endif
-
/*
* Is the SiS APIC rmw bug present ?
* -1 = don't know, 0 = no, 1 = yes
@@ -606,7 +590,7 @@ static void __eoi_ioapic_pin(int apic, int pin, int vector,
struct irq_cfg *cfg)
}
}
-static void eoi_ioapic_irq(unsigned int irq, struct irq_cfg *cfg)
+void eoi_ioapic_irq(unsigned int irq, struct irq_cfg *cfg)
{
struct irq_pin_list *entry;
unsigned long flags;
@@ -2551,32 +2535,6 @@ static void ack_apic_level(struct irq_data *data)
ioapic_irqd_unmask(data, cfg, masked);
}
-#ifdef CONFIG_IRQ_REMAP
-static void ir_ack_apic_edge(struct irq_data *data)
-{
- ack_APIC_irq();
-}
-
-static void ir_ack_apic_level(struct irq_data *data)
-{
- ack_APIC_irq();
- eoi_ioapic_irq(data->irq, data->chip_data);
-}
-
-static void ir_print_prefix(struct irq_data *data, struct seq_file *p)
-{
- seq_printf(p, " IR-%s", data->chip->name);
-}
-
-static void irq_remap_modify_chip_defaults(struct irq_chip *chip)
-{
- chip->irq_print_chip = ir_print_prefix;
- chip->irq_ack = ir_ack_apic_edg
[PATCH 10/19] x86, io_apic: Remove irq_remapping_enabled check in setup_timer_IRQ0_pin
This function is only called when irq-remapping is disabled. Signed-off-by: Joerg Roedel --- arch/x86/kernel/apic/io_apic.c |3 --- 1 file changed, 3 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 360f62b..d5cd6e1 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -1489,9 +1489,6 @@ static void __init setup_timer_IRQ0_pin(unsigned int ioapic_idx, struct IO_APIC_route_entry entry; unsigned int dest; - if (irq_remapping_enabled) - return; - memset(&entry, 0, sizeof(entry)); /* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/19] x86, irq: Move irq_remapping_enabled declaration to iommu code
Remove the last left-over from this flag from x86 code.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/irq_remapping.h |4
drivers/iommu/dmar.c |2 ++
drivers/iommu/intel-iommu.c |2 ++
drivers/iommu/irq_remapping.h|3 +++
4 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index fb99a73..6f4b48b 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -26,8 +26,6 @@
#ifdef CONFIG_IRQ_REMAP
-extern int irq_remapping_enabled;
-
extern void setup_irq_remapping_ops(void);
extern int irq_remapping_supported(void);
extern int irq_remapping_prepare(void);
@@ -49,8 +47,6 @@ extern void panic_if_irq_remap(const char *msg);
#else /* CONFIG_IRQ_REMAP */
-#define irq_remapping_enabled 0
-
static inline void setup_irq_remapping_ops(void) { }
static inline int irq_remapping_supported(void) { return 0; }
static inline int irq_remapping_prepare(void) { return -ENODEV; }
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 86e2f4a..174bb65 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -41,6 +41,8 @@
#include
#include
+#include "irq_remapping.h"
+
/* No locks are needed as DMA remapping hardware unit
* list is constructed at boot time and hotplug of
* these units are not supported by the architecture.
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 2297ec1..6d713db 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -46,6 +46,8 @@
#include
#include
+#include "irq_remapping.h"
+
#define ROOT_SIZE VTD_PAGE_SIZE
#define CONTEXT_SIZE VTD_PAGE_SIZE
diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
index b12974c..1003297 100644
--- a/drivers/iommu/irq_remapping.h
+++ b/drivers/iommu/irq_remapping.h
@@ -34,6 +34,7 @@ struct msi_msg;
extern int disable_irq_remap;
extern int disable_sourceid_checking;
extern int no_x2apic_optout;
+extern int irq_remapping_enabled;
struct irq_remap_ops {
/* Check whether Interrupt Remapping is supported */
@@ -83,6 +84,8 @@ struct irq_remap_ops {
extern struct irq_remap_ops intel_irq_remap_ops;
+#else /* CONFIG_IRQ_REMAP */
+#define irq_remapping_enabled 0
#endif /* CONFIG_IRQ_REMAP */
#endif /* __IRQ_REMAPPING_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/19] x86, io-apic: Remove !irq_remapped() check from __target_IO_APIC_irq()
This function is only called from default_ioapic_set_affinity() which is only used when interrupt remapping is disabled since the introduction of the set_affinity function pointer. So the check will always evaluate as true and can be removed. Signed-off-by: Joerg Roedel --- arch/x86/kernel/apic/io_apic.c |8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 6f2f21a..dd555e7 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -2308,12 +2308,8 @@ static void __target_IO_APIC_irq(unsigned int irq, unsigned int dest, struct irq apic = entry->apic; pin = entry->pin; - /* -* With interrupt-remapping, destination information comes -* from interrupt-remapping table entry. -*/ - if (!irq_remapped(cfg)) - io_apic_write(apic, 0x11 + pin*2, dest); + + io_apic_write(apic, 0x11 + pin*2, dest); reg = io_apic_read(apic, 0x10 + pin*2); reg &= ~IO_APIC_REDIR_VECTOR_MASK; reg |= vector; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/19] x86, io_apic: Introduce set_affinity function pointer
With interrupt remapping a special function is used to
change the affinity of an IO-APIC interrupt. Abstract this
with a function pointer.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/io_apic.h |4
arch/x86/include/asm/irq_remapping.h |9 -
arch/x86/include/asm/x86_init.h |6 ++
arch/x86/kernel/apic/io_apic.c | 17 +++--
arch/x86/kernel/x86_init.c |1 +
drivers/iommu/irq_remapping.c|4
6 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 21aa81e..a744cbb 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -182,6 +182,9 @@ extern void native_io_apic_modify(unsigned int apic,
unsigned int reg, unsigned
extern void native_disable_io_apic(void);
extern void native_io_apic_print_entries(unsigned int apic, unsigned int
nr_entries);
extern void intel_ir_io_apic_print_entries(unsigned int apic, unsigned int
nr_entries);
+extern int native_ioapic_set_affinity(struct irq_data *,
+ const struct cpumask *,
+ bool);
static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
{
@@ -228,6 +231,7 @@ static inline void disable_ioapic_support(void) { }
#define native_io_apic_modify NULL
#define native_disable_io_apic NULL
#define native_io_apic_print_entries NULL
+#define native_ioapic_set_affinity NULL
#endif
#endif /* _ASM_X86_IO_APIC_H */
diff --git a/arch/x86/include/asm/irq_remapping.h
b/arch/x86/include/asm/irq_remapping.h
index 0ee1e88..f1afa04 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -40,9 +40,6 @@ extern int setup_ioapic_remapped_entry(int irq,
unsigned int destination,
int vector,
struct io_apic_irq_attr *attr);
-extern int set_remapped_irq_affinity(struct irq_data *data,
-const struct cpumask *mask,
-bool force);
extern void free_remapped_irq(int irq);
extern void compose_remapped_msi_msg(struct pci_dev *pdev,
unsigned int irq, unsigned int dest,
@@ -68,12 +65,6 @@ static inline int setup_ioapic_remapped_entry(int irq,
{
return -ENODEV;
}
-static inline int set_remapped_irq_affinity(struct irq_data *data,
- const struct cpumask *mask,
- bool force)
-{
- return 0;
-}
static inline void free_remapped_irq(int irq) { }
static inline void compose_remapped_msi_msg(struct pci_dev *pdev,
unsigned int irq, unsigned int dest,
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 1f49c8a..f5f712b 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -189,6 +189,9 @@ struct x86_msi_ops {
int (*setup_hpet_msi)(unsigned int irq, unsigned int id);
};
+struct irq_data;
+struct cpumask;
+
struct x86_io_apic_ops {
void(*init) (void);
unsigned int(*read) (unsigned int apic, unsigned int reg);
@@ -196,6 +199,9 @@ struct x86_io_apic_ops {
void(*modify) (unsigned int apic, unsigned int reg,
unsigned int value);
void(*disable)(void);
void(*print_entries)(unsigned int apic, unsigned int
nr_entries);
+ int (*set_affinity)(struct irq_data *data,
+ const struct cpumask *mask,
+ bool force);
};
extern struct x86_init_ops x86_init;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 5ae0292..65c265ed 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2378,9 +2378,10 @@ int __ioapic_set_affinity(struct irq_data *data, const
struct cpumask *mask,
return 0;
}
-static int
-ioapic_set_affinity(struct irq_data *data, const struct cpumask *mask,
- bool force)
+
+int native_ioapic_set_affinity(struct irq_data *data,
+ const struct cpumask *mask,
+ bool force)
{
unsigned int dest, irq = data->irq;
unsigned long flags;
@@ -2579,8 +2580,7 @@ static void irq_remap_modify_chip_defaults(struct
irq_chip *chip)
chip->irq_print_chip = ir_print_prefix;
chip->irq_ack = ir_ack_apic_edge;
chip->irq_eoi = ir_ack_apic_level;
-
- chip->irq_set_affinity = set_remapped_irq_affinity;
+ chip->irq_set_affinity = x86_io_apic_ops.set_affinity;
}
#endif /* CONFIG_IRQ_REMAP */
@@ -2591,7 +2591,7 @@ static struct ir
[PATCH 03/19] x86, io_apic: Introduce x86_io_apic_ops.disable()
This function pointer is used to call a system-specific
function for disabling the IO-APIC. Currently this is used
for IRQ remapping which has its own disable routine.
Also introduce the necessary infrastructure in the interrupt
remapping code to overwrite this and other function pointers
as necessary by interrupt remapping.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/io_apic.h |2 ++
arch/x86/include/asm/x86_init.h |9 +
arch/x86/kernel/apic/io_apic.c | 41 ++-
arch/x86/kernel/x86_init.c |9 +
drivers/iommu/irq_remapping.c | 31 -
5 files changed, 61 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 73d8c53..d59e172 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -179,6 +179,7 @@ extern void __init native_io_apic_init_mappings(void);
extern unsigned int native_io_apic_read(unsigned int apic, unsigned int reg);
extern void native_io_apic_write(unsigned int apic, unsigned int reg, unsigned
int val);
extern void native_io_apic_modify(unsigned int apic, unsigned int reg,
unsigned int val);
+extern void native_disable_io_apic(void);
static inline unsigned int io_apic_read(unsigned int apic, unsigned int reg)
{
@@ -223,6 +224,7 @@ static inline void disable_ioapic_support(void) { }
#define native_io_apic_readNULL
#define native_io_apic_write NULL
#define native_io_apic_modify NULL
+#define native_disable_io_apic NULL
#endif
#endif /* _ASM_X86_IO_APIC_H */
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 38155f6..8e1b44c 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -189,10 +189,11 @@ struct x86_msi_ops {
};
struct x86_io_apic_ops {
- void(*init) (void);
- unsigned int(*read) (unsigned int apic, unsigned int reg);
- void(*write) (unsigned int apic, unsigned int reg, unsigned
int value);
- void(*modify)(unsigned int apic, unsigned int reg, unsigned
int value);
+ void(*init) (void);
+ unsigned int(*read) (unsigned int apic, unsigned int reg);
+ void(*write) (unsigned int apic, unsigned int reg,
unsigned int value);
+ void(*modify) (unsigned int apic, unsigned int reg,
unsigned int value);
+ void(*disable)(void);
};
extern struct x86_init_ops x86_init;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index c265593..c28c991 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1935,30 +1935,14 @@ void __init enable_IO_APIC(void)
clear_IO_APIC();
}
-/*
- * Not an __init, needed by the reboot code
- */
-void disable_IO_APIC(void)
+void native_disable_io_apic(void)
{
/*
-* Clear the IO-APIC before rebooting:
-*/
- clear_IO_APIC();
-
- if (!legacy_pic->nr_legacy_irqs)
- return;
-
- /*
* If the i8259 is routed through an IOAPIC
* Put that IOAPIC in virtual wire mode
* so legacy interrupts can be delivered.
-*
-* With interrupt-remapping, for now we will use virtual wire A mode,
-* as virtual wire B is little complex (need to configure both
-* IOAPIC RTE as well as interrupt-remapping table entry).
-* As this gets called during crash dump, keep this simple for now.
*/
- if (ioapic_i8259.pin != -1 && !irq_remapping_enabled) {
+ if (ioapic_i8259.pin != -1) {
struct IO_APIC_route_entry entry;
memset(&entry, 0, sizeof(entry));
@@ -1978,12 +1962,25 @@ void disable_IO_APIC(void)
ioapic_write_entry(ioapic_i8259.apic, ioapic_i8259.pin, entry);
}
+ if (cpu_has_apic || apic_from_smp_config())
+ disconnect_bsp_APIC(ioapic_i8259.pin != -1);
+
+}
+
+/*
+ * Not an __init, needed by the reboot code
+ */
+void disable_IO_APIC(void)
+{
/*
-* Use virtual wire A mode when interrupt remapping is enabled.
+* Clear the IO-APIC before rebooting:
*/
- if (cpu_has_apic || apic_from_smp_config())
- disconnect_bsp_APIC(!irq_remapping_enabled &&
- ioapic_i8259.pin != -1);
+ clear_IO_APIC();
+
+ if (!legacy_pic->nr_legacy_irqs)
+ return;
+
+ x86_io_apic_ops.disable();
}
#ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 9f3167e..3ea56c2 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -120,8 +120,9 @@ struct x86_msi_ops x86_msi = {
};
struct x86_io_apic_ops x86_io_apic_ops = {
- .init = native_io_apic_init_mappings,
- .re
[PATCH 08/19] x86, io_apic: Convert setup_ioapic_entry to function pointer
This pointer is changed to a different function when IRQ
remapping is enabled.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/io_apic.h |5 +
arch/x86/include/asm/x86_init.h |5 +
arch/x86/kernel/apic/io_apic.c | 14 +-
arch/x86/kernel/x86_init.c |1 +
drivers/iommu/irq_remapping.c |1 +
5 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index a744cbb..71f5f08 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -149,6 +149,10 @@ extern int io_apic_set_pci_routing(struct device *dev, int
irq,
void setup_IO_APIC_irq_extra(u32 gsi);
extern void ioapic_insert_resources(void);
+extern int native_setup_ioapic_entry(int, struct IO_APIC_route_entry *,
+unsigned int, int,
+struct io_apic_irq_attr *);
+
int io_apic_setup_irq_pin_once(unsigned int irq, int node, struct
io_apic_irq_attr *attr);
extern int save_ioapic_entries(void);
@@ -232,6 +236,7 @@ static inline void disable_ioapic_support(void) { }
#define native_disable_io_apic NULL
#define native_io_apic_print_entries NULL
#define native_ioapic_set_affinity NULL
+#define native_setup_ioapic_entry NULL
#endif
#endif /* _ASM_X86_IO_APIC_H */
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index f5f712b..bc13022 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -189,6 +189,8 @@ struct x86_msi_ops {
int (*setup_hpet_msi)(unsigned int irq, unsigned int id);
};
+struct IO_APIC_route_entry;
+struct io_apic_irq_attr;
struct irq_data;
struct cpumask;
@@ -202,6 +204,9 @@ struct x86_io_apic_ops {
int (*set_affinity)(struct irq_data *data,
const struct cpumask *mask,
bool force);
+ int (*setup_entry)(int irq, struct IO_APIC_route_entry
*entry,
+ unsigned int destination, int vector,
+ struct io_apic_irq_attr *attr);
};
extern struct x86_init_ops x86_init;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 65c265ed..9500a07 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1319,14 +1319,10 @@ static void ioapic_register_intr(unsigned int irq,
struct irq_cfg *cfg,
fasteoi ? "fasteoi" : "edge");
}
-static int setup_ioapic_entry(int irq, struct IO_APIC_route_entry *entry,
- unsigned int destination, int vector,
- struct io_apic_irq_attr *attr)
+int native_setup_ioapic_entry(int irq, struct IO_APIC_route_entry *entry,
+ unsigned int destination, int vector,
+ struct io_apic_irq_attr *attr)
{
- if (irq_remapping_enabled)
- return setup_ioapic_remapped_entry(irq, entry, destination,
- vector, attr);
-
memset(entry, 0, sizeof(*entry));
entry->delivery_mode = apic->irq_delivery_mode;
@@ -1384,8 +1380,8 @@ static void setup_ioapic_irq(unsigned int irq, struct
irq_cfg *cfg,
attr->ioapic, mpc_ioapic_id(attr->ioapic), attr->ioapic_pin,
cfg->vector, irq, attr->trigger, attr->polarity, dest);
- if (setup_ioapic_entry(irq, &entry, dest, cfg->vector, attr)) {
- pr_warn("Failed to setup ioapic entry for ioapic %d, pin %d\n",
+ if (x86_io_apic_ops.setup_entry(irq, &entry, dest, cfg->vector, attr)) {
+ pr_warn("Failed to setup ioapic entry for ioapic %d, pin %d\n",
mpc_ioapic_id(attr->ioapic), attr->ioapic_pin);
__clear_irq_vector(irq, cfg);
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 8806d0b..3cd6bf7 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -129,4 +129,5 @@ struct x86_io_apic_ops x86_io_apic_ops = {
.disable= native_disable_io_apic,
.print_entries = native_io_apic_print_entries,
.set_affinity = native_ioapic_set_affinity,
+ .setup_entry= native_setup_ioapic_entry,
};
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index ccf87e5..5b28e28 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -91,6 +91,7 @@ static void __init irq_remapping_modify_x86_ops(void)
{
x86_io_apic_ops.disable = irq_remapping_disable_io_apic;
x86_io_apic_ops.set_affinity= set_remapped_irq_affinity;
+ x86_io_ap
[PATCH 12/19] x86, irq: Add data structure to keep AMD specific irq remapping information
Add a data structure to store information the IOMMU driver
can use to get from a 'struct irq_cfg' to the remapping
entry.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/hw_irq.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index eb92a6e..fc89a2a 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -101,6 +101,7 @@ static inline void set_io_apic_irq_attr(struct
io_apic_irq_attr *irq_attr,
irq_attr->polarity = polarity;
}
+/* Intel specific interrupt remapping information */
struct irq_2_iommu {
struct intel_iommu *iommu;
u16 irte_index;
@@ -108,6 +109,12 @@ struct irq_2_iommu {
u8 irte_mask;
};
+/* AMD specific interrupt remapping information */
+struct irq_2_irte {
+ u16 devid; /* Device ID for IRTE table */
+ u16 index; /* Index into IRTE table*/
+};
+
/*
* This is performance-critical, we want to do it O(1)
*
@@ -120,7 +127,10 @@ struct irq_cfg {
u8 vector;
u8 move_in_progress : 1;
#ifdef CONFIG_IRQ_REMAP
- struct irq_2_iommu irq_2_iommu;
+ union {
+ struct irq_2_iommu irq_2_iommu;
+ struct irq_2_irte irq_2_irte;
+ };
#endif
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/19] x86, msi: Introduce x86_msi.compose_msi_msg call-back
This call-back points to the right function for initializing
the msi_msg structure. The old code for msi_msg generation
was split up into the irq-remapped and the default case.
The irq-remapped case just calls into the specific Intel or
AMD implementation when the device is behind an IOMMU.
Otherwise the default function is called.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/io_apic.h |4 +++
arch/x86/include/asm/x86_init.h |4 +++
arch/x86/kernel/apic/io_apic.c | 59 ---
arch/x86/kernel/x86_init.c |1 +
drivers/iommu/irq_remapping.c |9 --
5 files changed, 46 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 36fb5ab..1838e88 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -158,6 +158,9 @@ extern int native_setup_ioapic_entry(int, struct
IO_APIC_route_entry *,
struct io_apic_irq_attr *);
extern void eoi_ioapic_irq(unsigned int irq, struct irq_cfg *cfg);
+extern void native_compose_msi_msg(struct pci_dev *pdev,
+ unsigned int irq, unsigned int dest,
+ struct msi_msg *msg, u8 hpet_id);
int io_apic_setup_irq_pin_once(unsigned int irq, int node, struct
io_apic_irq_attr *attr);
extern int save_ioapic_entries(void);
@@ -242,6 +245,7 @@ static inline void disable_ioapic_support(void) { }
#define native_io_apic_print_entries NULL
#define native_ioapic_set_affinity NULL
#define native_setup_ioapic_entry NULL
+#define native_compose_msi_msg NULL
#endif
#endif /* _ASM_X86_IO_APIC_H */
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index bc13022..3ef598e 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -180,9 +180,13 @@ struct x86_platform_ops {
};
struct pci_dev;
+struct msi_msg;
struct x86_msi_ops {
int (*setup_msi_irqs)(struct pci_dev *dev, int nvec, int type);
+ void (*compose_msi_msg)(struct pci_dev *dev, unsigned int irq,
+ unsigned int dest, struct msi_msg *msg,
+ u8 hpet_id);
void (*teardown_msi_irq)(unsigned int irq);
void (*teardown_msi_irqs)(struct pci_dev *dev);
void (*restore_msi_irqs)(struct pci_dev *dev, int irq);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 88c4fff..c545a1d 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -2999,37 +2999,16 @@ void destroy_irq(unsigned int irq)
/*
* MSI message composition
*/
-#ifdef CONFIG_PCI_MSI
-static int msi_compose_msg(struct pci_dev *pdev, unsigned int irq,
- struct msi_msg *msg, u8 hpet_id)
+void native_compose_msi_msg(struct pci_dev *pdev,
+ unsigned int irq, unsigned int dest,
+ struct msi_msg *msg, u8 hpet_id)
{
- struct irq_cfg *cfg;
- int err;
- unsigned dest;
-
- if (disable_apic)
- return -ENXIO;
-
- cfg = irq_cfg(irq);
- err = assign_irq_vector(irq, cfg, apic->target_cpus());
- if (err)
- return err;
-
- err = apic->cpu_mask_to_apicid_and(cfg->domain,
- apic->target_cpus(), &dest);
- if (err)
- return err;
+ struct irq_cfg *cfg = irq_cfg(irq);
- if (irq_remapped(cfg)) {
- compose_remapped_msi_msg(pdev, irq, dest, msg, hpet_id);
- return err;
- }
+ msg->address_hi = MSI_ADDR_BASE_HI;
if (x2apic_enabled())
- msg->address_hi = MSI_ADDR_BASE_HI |
- MSI_ADDR_EXT_DEST_ID(dest);
- else
- msg->address_hi = MSI_ADDR_BASE_HI;
+ msg->address_hi |= MSI_ADDR_EXT_DEST_ID(dest);
msg->address_lo =
MSI_ADDR_BASE_LO |
@@ -3048,8 +3027,32 @@ static int msi_compose_msg(struct pci_dev *pdev,
unsigned int irq,
MSI_DATA_DELIVERY_FIXED:
MSI_DATA_DELIVERY_LOWPRI) |
MSI_DATA_VECTOR(cfg->vector);
+}
- return err;
+#ifdef CONFIG_PCI_MSI
+static int msi_compose_msg(struct pci_dev *pdev, unsigned int irq,
+ struct msi_msg *msg, u8 hpet_id)
+{
+ struct irq_cfg *cfg;
+ int err;
+ unsigned dest;
+
+ if (disable_apic)
+ return -ENXIO;
+
+ cfg = irq_cfg(irq);
+ err = assign_irq_vector(irq, cfg, apic->target_cpus());
+ if (err)
+ return err;
+
+ err = apic->cpu_mask_to_apicid_and(cfg->domain,
+ apic->target_cpus(), &dest);
+ if (err)
+ return err;
+
+ x86
[PATCH 1/2] iommu/amd: Update MAINTAINERS entry
I have no access to my AMD email address anymore. Update entry in MAINTAINERS to the new address. Signed-off-by: Joerg Roedel --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 027ec2b..0267ba2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -526,10 +526,10 @@ F:drivers/video/geode/ F: arch/x86/include/asm/geode.h AMD IOMMU (AMD-VI) -M: Joerg Roedel +M: Joerg Roedel L: io...@lists.linux-foundation.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git -S: Supported +S: Maintained F: drivers/iommu/amd_iommu*.[ch] F: include/linux/amd-iommu.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] kvm, svm: Update MAINTAINERS entry
I have no access to my AMD email address anymore. Update entry in MAINTAINERS to the new address. Cc: Avi Kivity Cc: Marcelo Tosatti Signed-off-by: Joerg Roedel --- MAINTAINERS |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0267ba2..d881321 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4234,10 +4234,10 @@ F: include/linux/kvm* F: virt/kvm/ KERNEL VIRTUAL MACHINE (KVM) FOR AMD-V -M: Joerg Roedel +M: Joerg Roedel L: k...@vger.kernel.org W: http://kvm.qumranet.com -S: Supported +S: Maintained F: arch/x86/include/asm/svm.h F: arch/x86/kvm/svm.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: integrator: Make sure INTEGRATOR_AP depends on PCI
On Wed, Aug 28, 2013 at 09:26:57AM +0200, Linus Walleij wrote:
> On Wed, Aug 14, 2013 at 10:04 PM, Joerg Roedel wrote:
>
> > So when integrator does not depend on PCI this diff is more appropriate?
> >
> > diff --git a/arch/arm/mach-integrator/pci_v3.h
> > b/arch/arm/mach-integrator/pci_v3.h
> > index 755fd29..51738e0 100644
> > --- a/arch/arm/mach-integrator/pci_v3.h
> > +++ b/arch/arm/mach-integrator/pci_v3.h
> > @@ -1,2 +1,9 @@
> > -/* Simple oneliner include to the PCIv3 early init */
> > +/* Define PCIv3 early init */
> > +#ifdef CONFIG_PCI
> > extern int pci_v3_early_init(void);
> > +#else
> > +static inline int pci_v3_early_init(void)
> > +{
> > + return 0;
> > +}
> > +#endif
>
> Yes.
> Reviewed-by: Linus Walleij
>
> And can you please create and send a proper patch with this
> content to a...@kernel.org and the mailing list on CC, with
> a request for the ARM SoC maintainers to apply it directly
> as a fix?
>
> You might as well add Cc: sta...@vger.kernel.org as well.
Will do, thanks for your review.
Cheers,
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iommu: Remove stack trace from broken irq remapping warning
On Thu, Oct 03, 2013 at 01:21:42PM -0400, Neil Horman wrote: > On Fri, Sep 27, 2013 at 12:53:35PM -0400, Neil Horman wrote: > > The warning for the irq remapping broken check in intel_irq_remapping.c is > > pretty pointless. We need the warning, but we know where its comming from, > > the > > stack trace will always be the same, and it needlessly triggers things like > > Abrt. This changes the warning to just print a text warning about BIOS > > being > > broken, without the stack trace, then sets the appropriate taint bit. > > Since we > > automatically disable irq remapping, theres no need to contiue making Abrt > > jump > > at this problem > > > > Signed-off-by: Neil Horman > > CC: Joerg Roedel > > CC: Bjorn Helgaas > > CC: Andy Lutomirski > > CC: Konrad Rzeszutek Wilk > > CC: Sebastian Andrzej Siewior > > Ping Bjorn, Jeorg, any thoughts here? Yes, the patch is doing the right thing. I have it already on my list and will merge it soon. Joerg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iommu: Remove stack trace from broken irq remapping warning
On Fri, Sep 27, 2013 at 12:53:35PM -0400, Neil Horman wrote: > The warning for the irq remapping broken check in intel_irq_remapping.c is > pretty pointless. We need the warning, but we know where its comming from, > the > stack trace will always be the same, and it needlessly triggers things like > Abrt. This changes the warning to just print a text warning about BIOS being > broken, without the stack trace, then sets the appropriate taint bit. Since > we > automatically disable irq remapping, theres no need to contiue making Abrt > jump > at this problem Applied to x86/vt-d, thanks Neil. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] IOMMU Fixes for v3.12-rc3
Hi Linus, The following changes since commit 4a10c2ac2f368583138b774ca41fac4207911983: Linux 3.12-rc2 (2013-09-23 15:41:09 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v3.12-rc3 for you to fetch changes up to 82aeef0bf03684b377678c00c05e613f30dca39c: x86/iommu: correct ICS register offset (2013-09-24 13:04:07 +0200) IOMMU Fixes for Linux v3.12-rc3 A couple of fixes from the IOMMU side: * Some small fixes for the new ARM-SMMU driver * A register offset correction for VT-d * Adding MAINTAINERS entry for drivers/iommu Overall no really big or intrusive changes. Dan Carpenter (2): iommu/arm-smmu: fix a signedness bug iommu/arm-smmu: fix iommu_present() test in init Joerg Roedel (1): Merge branch 'for-joerg/arm-smmu/fixes' of git://git.kernel.org/.../will/linux into iommu/fixes Li, Zhen-Hua (1): x86/iommu: correct ICS register offset Stephen Warren (1): MAINTAINERS: add overall IOMMU section Will Deacon (1): iommu/arm-smmu: don't enable SMMU device until probing has completed MAINTAINERS |7 +++ drivers/iommu/arm-smmu.c| 13 +++-- include/linux/intel-iommu.h |2 +- 3 files changed, 15 insertions(+), 7 deletions(-) Please pull. Thanks, Joerg signature.asc Description: Digital signature
