. We are moving in
the direction of cleaning up defines in selftests for the same
reason.
Let's just make sure this works on older kernels. We do support
mainline kselftest on stable releases. With that:
Reviewed-by: Shuah Khan
thanks,
--
On 4/9/21 2:00 PM, Shuah Khan wrote:
On 4/9/21 2:58 AM, Suravee Suthikulpanit wrote:
In early AMD desktop/mobile platforms (during 2013), when the IOMMU
Performance Counter (PMC) support was first introduced in
commit 30861ddc9cca ("perf/x86/amd: Add IOMMU Performance Counter
res
30935570.3...@monopod.intra.ispras.ru/
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201753
Cc: Tj (Elloe Linux)
Cc: Shuah Khan
Cc: Alexander Monakov
Cc: David Coe
Cc: Paul Menzel
Signed-off-by: Suravee Suthikulpanit
---
Tested-by: Shuah Khan
thanks,
-- Shuah
Results with this patch on AMD Ryzen 5 PR
On 4/9/21 10:37 AM, Shuah Khan wrote:
On 4/9/21 2:58 AM, Suravee Suthikulpanit wrote:
In early AMD desktop/mobile platforms (during 2013), when the IOMMU
Performance Counter (PMC) support was first introduced in
commit 30861ddc9cca ("perf/x86/amd: Add IOMMU Performance Counter
res
to removing the pre-init
test.
Link:
https://lore.kernel.org/linux-iommu/alpine.lnx.3.20.13.2006030935570.3...@monopod.intra.ispras.ru/
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201753
Cc: Tj (Elloe Linux)
Cc: Shuah Khan
Cc: Alexander Monakov
Cc: David Coe
Signed-off-by: Paul Menzel
n use
be relatively safe to remove this legacy logic.
Link:
https://lore.kernel.org/linux-iommu/alpine.lnx.3.20.13.2006030935570.3...@monopod.intra.ispras.ru/
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201753
Cc: Tj (Elloe Linux)
Cc: Shuah Khan
Cc: Alexander Monakov
Cc: David Coe
Cc: P
On 2/26/21 2:44 PM, Paul Menzel wrote:
[cc: +suravee, +jörg]
Dear Alex, dear Shuah, dear Suravee, dear Jörg,
Am 03.06.20 um 08:54 schrieb Alexander Monakov:
On Tue, 2 Jun 2020, Shuah Khan wrote:
I changed the logic to read config to get max banks and counters
before checking if counters
On 5/31/20 1:22 AM, Alexander Monakov wrote:
Hi,
Adding Shuah Khan to Cc: I've noticed you've seen this issue on Ryzen 2400GE;
can you have a look at the patch? Would be nice to know if it fixes the
problem for you too.
I am not seeing any change in behavior on my system. I sti
On 1/23/20 11:43 PM, Suravee Suthikulpanit wrote:
On 1/24/20 5:32 AM, Shuah Khan wrote:
init_iommu_perf_ctr() clobbers the register when it checks write access
to IOMMU perf counters and fails to restore when they are writable.
Add save and restore to fix it.
Signed-off-by: Shuah Khan
init_iommu_perf_ctr() clobbers the register when it checks write access
to IOMMU perf counters and fails to restore when they are writable.
Add save and restore to fix it.
Signed-off-by: Shuah Khan
---
Changes since v1:
-- Fix bug in sucessful return path. Add a return instead of
fall
On 1/21/20 8:32 AM, Shuah Khan wrote:
On 1/20/20 7:10 PM, Suravee Suthikulpanit wrote:
On 1/17/2020 5:08 PM, Joerg Roedel wrote:
Adding Suravee, who wrote the IOMMU Perf Counter code.
On Tue, Jan 14, 2020 at 08:12:20AM -0700, Shuah Khan wrote:
init_iommu_perf_ctr() clobbers the register when
On 1/20/20 7:10 PM, Suravee Suthikulpanit wrote:
On 1/17/2020 5:08 PM, Joerg Roedel wrote:
Adding Suravee, who wrote the IOMMU Perf Counter code.
On Tue, Jan 14, 2020 at 08:12:20AM -0700, Shuah Khan wrote:
init_iommu_perf_ctr() clobbers the register when it checks write access
to IOMMU perf
init_iommu_perf_ctr() clobbers the register when it checks write access
to IOMMU perf counters and fails to restore when they are writable.
Add save and restore to fix it.
Signed-off-by: Shuah Khan
---
drivers/iommu/amd_iommu_init.c | 22 --
1 file changed, 16 insertions
Hi Alan,
On 6/18/19 9:28 AM, shuah wrote:
On 6/14/19 8:44 AM, Alan Stern wrote:
On Thu, 13 Jun 2019, shuah wrote:
Great! So all we have to do is fix vhci-hcd. Then we can remove all
the virt_boundary_mask stuff from usb-storage and uas entirely.
(I'm assuming wireless USB isn't
On 6/14/19 8:44 AM, Alan Stern wrote:
On Thu, 13 Jun 2019, shuah wrote:
Great! So all we have to do is fix vhci-hcd. Then we can remove all
the virt_boundary_mask stuff from usb-storage and uas entirely.
(I'm assuming wireless USB isn't a genuine issue. As far as I know, it
is p
uine issue. As far as I know, it
is pretty much abandoned at this point.)
Valentina and Shua: Adding SG support to vhci-hcd shouldn't be too
hard. It ought to be possible even without changing the network
protocol.
I will start taking a look at this. Is there a target release in plan
to drop virt_boundary_mask stuff?
thanks,
-- Shuah
k at the defines shows:
#define CALGARY_MAPPING_ERROR 0
#define S390_MAPPING_ERROR (~(dma_addr_t) 0x0)
#define SPARC_MAPPING_ERROR (~(dma_addr_t)0x0)
This is the reason why there is a arch or in some cases bus specific
mapping_error ops is needed.
We coul
racing/events/vfio/vfio_iommu_spapr_tce/map will.
>
> But iommu/map does work, it's just not called by the vfio spapr tce
> backend, which is absolutely correct. In fact, that's part of my
> reservation about this approach is that it could be interpreted as
&g
On 01/15/2015 07:29 PM, Shuah Khan wrote:
> iommu_map() calls trace_map() with iova and size. trace_map()
> should report original iova and original size as opposed to
> iova and size after they get changed during mapping. size is
> always zero at the end of mapping which is usele
rflow.
Signed-off-by: Shuah Khan
Suggested-by: Alex Williamson
---
drivers/iommu/iommu.c| 2 +-
include/trace/events/iommu.h | 31 ++-
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 2eb7554..9e
iommu_unmap() calls trace_unmap() with changed iova and original
size. trace_unmap() should report original iova instead. Change
iommu_unmap() to call trace_unmap() with original iova.
Signed-off-by: Shuah Khan
Reported-by: Alex Williamson
---
drivers/iommu/iommu.c | 3 ++-
1 file changed, 2
as the
original iova. Change iommu_map() to call trace_map() to
report original iova and original size.
Signed-off-by: Shuah Khan
Reported-by: Alex Williamson
---
drivers/iommu/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu
ses, dma_alloc_*() interfaces are the ones to use.
Please also refer to DMA-API.txt as well. Hope this helps.
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
__
. Similarly, it adds an overhead in releasing memory for devres to
compared to other dma_unmap_* wrappers. Users need to be aware of
that. This overhead is going to be in the performance path when
drivers unmap buffers during run-time.
Adding Joerg Roedel to the thread.
-- Shuah
--
Sh
ces are moved in and out of domains
* and their respective RMRR info is lost. We exempt USB devices
* from this process due to their usage of RMRRs that are known
* to not be needed after BIOS hand-off to OS.
*/
flags=0x0002
swapper/0-1 [003] 2.004115: io_page_fault: IOMMU:pci
:00:1a.0 iova=0xcadc6000 flags=0x0002
swapper/0-1 [003] 2.004129: io_page_fault: IOMMU:pci
:00:1f.0 iova=0x flags=0x0002
Signed-off-by: Shuah Khan
iommu_error class event can be enabled to trigger when an iommu
error occurs. This trace event is intended to be called to report the
error information. Trace information includes driver name, device name,
iova, and flags.
iommu_error:io_page_fault
Signed-off-by: Shuah Khan
---
drivers/iommu
.
iommu_error:io_page_fault
This patch set depends on the previous patch set that added iommu tracing
feature. Reference:
http://www.kernelhub.org/?msg=313155&p=2
http://www.kernelhub.org/?msg=313156&p=2
Shuah Khan (2):
iommu: Add iommu_error class event to iommu trace
iommu: Change iommu driver
On 09/24/2013 04:48 AM, Joerg Roedel wrote:
On Fri, Aug 16, 2013 at 11:20:16AM -0600, Shuah Khan wrote:
+DEFINE_EVENT(iommu_fault, report_fault,
+
+ TP_PROTO(struct device *dev, unsigned long iova, int flags),
+
+ TP_ARGS(dev, iova, flags)
+);
I am not entirely happy with the
unity-mapped ranges defined in the BIOS table. The code for those
>> > mappings was basically untested before you ran it on that machine.
>> >
>> What is the machine in question? Maybe someone else has access to one,
>> if it's not too exotic.
>
> Shuah had a
On Wed, Apr 10, 2013 at 10:27 AM, Suravee Suthikulanit
wrote:
> On 4/10/2013 11:21 AM, Shuah Khan wrote:
>>
>> Good feature. Do you also plan to add decode logic for these flags.
>> For example, RZ is only meaningful when PR=1, RW is only meaningful
>> when
>> PR=
+
> +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_cont(" flags:%s %s %s %s %s %s %s %s %s",
> +
ns(+), 63 deletions(-)
>
Joerg,
Reviewed all the patches in this set. No longer have access to test machine. :(
Reviewed-by: Shuah Khan
-- Shuah
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
.
>
> Signed-off-by: Joerg Roedel
> ---
Reviewed-by: Shuah Khan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ymore.
>
> Signed-off-by: Joerg Roedel
> ---
Reviewed-by: Shuah Khan
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Apr 9, 2013 at 2:13 PM, Joerg Roedel wrote:
> When the IVRS entries for IOAPIC and HPET are overridden on
> the kernel command line, a problem detected in the check
> function might not be a firmware bug anymore. So disable
> the firmware bug reporting if the user provided valid
> ivrs_ioa
device table after dma_ops.
Back-port upstream commit: f528d980c17b8714aedc918ba86e058af914d66b
Tested on 3.2.38
Signed-off-by: Joerg Roedel
Signed-off-by: Shuah Khan
CC: sta...@vger.kernel.org 3.2
---
drivers/iommu/amd_iommu_init.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions
On Thu, 2013-02-28 at 12:52 -0700, Shuah Khan wrote:
> On Tue, 2013-02-26 at 16:49 -0700, Shuah Khan wrote:
> > 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
On Tue, 2013-02-26 at 16:49 -0700, Shuah Khan wrote:
> 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 i
On Mon, 2013-02-25 at 14:53 -0700, Shuah Khan wrote:
> On Mon, 2013-02-25 at 14:23 -0700, Bjorn Helgaas wrote:
> > On Mon, Feb 25, 2013 at 9:37 AM, Shuah Khan wrote:
> > > On Wed, 2013-02-20 at 18:19 -0700, Bjorn Helgaas wrote:
> > >> On Mon, Feb 11, 2013
device table after dma_ops.
Back-port upstream commit: f528d980c17b8714aedc918ba86e058af914d66b
Signed-off-by: Joerg Roedel
Signed-off-by: Shuah Khan
CC: sta...@vger.kernel.org 3.4
---
drivers/iommu/amd_iommu_init.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a
Change to remove calc_devid() and use PCI_DEVID() from pci instead.
Signed-off-by: Shuah Khan
---
drivers/iommu/amd_iommu.c |2 +-
drivers/iommu/amd_iommu_init.c |6 +++---
drivers/iommu/amd_iommu_types.h |7 ---
3 files changed, 4 insertions(+), 11 deletions(-)
diff
Change to remove local PCI_BUS() define and use the new PCI_BUS_NUM()
interface from pci.
Signed-off-by: Shuah Khan
---
drivers/iommu/amd_iommu.c | 12 ++--
drivers/iommu/amd_iommu_init.c | 34 +-
drivers/iommu/amd_iommu_types.h |4 +---
3
Change to remove local PCI_BUS() define and use the new PCI_BUS_NUM()
interface from pci.
Signed-off-by: Shuah Khan
---
drivers/pci/pcie/aer/aerdrv_core.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer
igned-off-by: Shuah Khan
---
include/linux/pci.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 15472d6..95c105a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -35,6 +35,21 @@
/* Include the ID list */
#in
pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
it doesn't have interfaces to return PCI bus and PCI device id. Drivers
(AMD IOMMU, and AER) have module specific definitions for PCI_BUS() and
AMD_IOMMU driver also has a module specific interface to calculate PCI
device id f
device table after dma_ops.
Back-port upstream commit: f528d980c17b8714aedc918ba86e058af914d66b
Signed-off-by: Joerg Roedel
Signed-off-by: Shuah Khan
CC: sta...@vger.kernel.org 3.0
---
arch/x86/kernel/amd_iommu_init.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
On Mon, 2013-02-25 at 14:23 -0700, Bjorn Helgaas wrote:
> On Mon, Feb 25, 2013 at 9:37 AM, Shuah Khan wrote:
> > On Wed, 2013-02-20 at 18:19 -0700, Bjorn Helgaas wrote:
> >> On Mon, Feb 11, 2013 at 4:00 PM, Shuah Khan wrote:
> >> > pci defines PCI_DEVFN(), PCI_SLO
On Wed, 2013-02-20 at 18:19 -0700, Bjorn Helgaas wrote:
> On Mon, Feb 11, 2013 at 4:00 PM, Shuah Khan wrote:
> > pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
> > it doesn't have interfaces to return PCI bus and PCI device id. Drivers
> > (AMD
Change to remove calc_devid() and use PCI_DEVID() from pci instead.
Signed-off-by: Shuah Khan
---
drivers/iommu/amd_iommu.c |2 +-
drivers/iommu/amd_iommu_init.c |6 +++---
drivers/iommu/amd_iommu_types.h |7 ---
3 files changed, 4 insertions(+), 11 deletions(-)
diff
Change to remove local PCI_BUS() define and use the new PCI_BUS interface from
pci.
Signed-off-by: Shuah Khan
---
drivers/iommu/amd_iommu_types.h |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index
Change to remove local PCI_BUS() define and use the new PCI_BUS interface from
pci.
Signed-off-by: Shuah Khan
---
drivers/pci/pcie/aer/aerdrv_core.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pci/pcie/aer/aerdrv_core.c
b/drivers/pci/pcie/aer/aerdrv_core.c
index 564d97f
ulate device id from bus number, and devfn pair.
Signed-off-by: Shuah Khan
---
include/uapi/linux/pci.h |4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/pci.h b/include/uapi/linux/pci.h
index 3c292bc0..6b2c8b3 100644
--- a/include/uapi/linux/pci.h
+++ b/include/uapi/linux/
pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
it doesn't have interfaces to return PCI bus and PCI device id. Drivers
(AMD IOMMU, and AER) have module specific definitions for PCI_BUS() and
AMD_IOMMU driver also has a module specific interface to calculate PCI
device id f
On Mon, 2013-02-11 at 11:49 -0800, Greg KH wrote:
> On Wed, Feb 06, 2013 at 07:40:50PM -0700, Shuah Khan wrote:
> > On Wed, 2013-02-06 at 13:12 +0100, Joerg Roedel wrote:
> > > On Tue, Feb 05, 2013 at 06:57:21AM -0700, Shuah Khan wrote:
> > > > Thanks much. I will h
On Mon, Feb 11, 2013 at 12:49 PM, Greg KH wrote:
> On Wed, Feb 06, 2013 at 07:40:50PM -0700, Shuah Khan wrote:
>> On Wed, 2013-02-06 at 13:12 +0100, Joerg Roedel wrote:
>> > On Tue, Feb 05, 2013 at 06:57:21AM -0700, Shuah Khan wrote:
>> > > Thanks much. I will h
device table after dma_ops.
Reference: http://www.gossamer-threads.com/lists/linux/kernel/1670769
Signed-off-by: Shuah Khan
CC: sta...@vger.kernel.org 3.0
---
arch/x86/kernel/amd_iommu_init.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel
device table after dma_ops.
Signed-off-by: Shuah Khan
CC: sta...@vger.kernel.org 3.4
---
drivers/iommu/amd_iommu_init.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index ef0ae93..b573f80 100644
On Wed, 2013-02-06 at 13:12 +0100, Joerg Roedel wrote:
> 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 po
On Tue, Feb 5, 2013 at 6:31 AM, Joerg Roedel wrote:
> 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.
On Fri, 2013-02-01 at 14:00 +0100, Joerg Roedel wrote:
> 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(). T
t;
US: user-supervisor US=0
"Supervisor privileges were asserted."
NX: no execute NX=0
"0 upstream transaction lacks a PASID TLP prefix. Domain ID is zero."
GN: guest/nested GN=0
"Transaction used a nested address (GPA)."
Thanks,
-- Shuah
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Fri, Jan 11, 2013 at 7:50 AM, Joerg Roedel wrote:
> On Thu, Jan 10, 2013 at 01:40:17PM -0700, Shuah Khan wrote:
>> I am currently debugging IO_PAGE_FAULTS on 3.6.11 (happens on all
>> pre-3.7 releases). I root-caused the reason 3.7 works is because in
>> 3.7 amd iommu
On Thu, Jan 10, 2013 at 1:40 PM, Shuah Khan wrote:
> On Thu, Jan 10, 2013 at 10:09 AM, Joerg Roedel wrote:
>> On Mon, Jan 07, 2013 at 06:51:52PM +1100, Alexey Kardashevskiy wrote:
>>> The iommu_init() initializes IOMMU internal structures and data
>>> re
5.120819] pci 0000:00:00.2: PCI INT A: no GSI
[ 15.120880]
In 3.6, early iommu initialization occurs way later.
-- Shuah
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Fri, 2012-10-12 at 12:35 -0700, Jonathan Nieder wrote:
> Shuah Khan wrote:
> > On Fri, 2012-10-12 at 11:38 -0700, Jonathan Nieder wrote:
>
> >> To save Willy time: am I correct in guessing the upstream commit you
> >> are referring to is 98fc5a693bbdda498a556654
On Tue, 2012-10-16 at 16:50 +, Tom Mingarelli wrote:
> This patch is to prevent devices that have RMRRs associated with them
> from getting placed into the SI Domain during init. We don't put USB devices
> into this category, however. This fixes the issue where the RMRR info
> for devices bein
On Tue, 2012-10-16 at 16:50 +, Tom Mingarelli wrote:
> This patch is to prevent devices that have RMRRs associated with them
> from getting placed into the SI Domain during init. We don't put USB devices
> into this category, however. This fixes the issue where the RMRR info
> for devices bein
On Fri, 2012-10-12 at 11:38 -0700, Jonathan Nieder wrote:
> Shuah Khan wrote:
>
> > This bug is in linux-2.6.32 and an equivalent fix in linux-2.6.33 and has
> > been
> > carried forward to later kernels and is in the upstream kernel. This
> > equivalent
>
bug in
amd_iommu_attach_device() for linux-2.6.32.
Signed-off-by: Shuah Khan
CC: v2.6.32
---
arch/x86/kernel/amd_iommu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/amd_iommu.c b/arch/x86/kernel/amd_iommu.c
index 3a44b75..67de7d7 100644
--- a/arch/x86/
Alex,
couple of comments in-lined:
On Mon, Oct 8, 2012 at 10:49 PM, Alex Williamson
wrote:
> This needs to be broken apart, start with pulling all the IOMMU
> group init code into a new function.
>
> Signed-off-by: Alex Williamson
> ---
>
> drivers/iommu/amd_iommu.c | 61
> +
On Mon, Oct 1, 2012 at 2:08 AM, Joerg Roedel wrote:
> On Fri, Sep 28, 2012 at 05:39:03PM -0600, Shuah Khan wrote:
>> On Fri, Sep 28, 2012 at 6:24 AM, Joerg Roedel wrote:
>> > void __init setup_irq_remapping_ops(void)
>> > {
>> > remap_ops = &
On Mon, Oct 1, 2012 at 2:05 AM, Joerg Roedel wrote:
> On Fri, Sep 28, 2012 at 05:18:18PM -0600, Shuah Khan wrote:
>> > +void amd_iommu_disable(void)
>> > +{
>> > + amd_iommu_suspend();
>>
>> Is it safe to attempt to suspend when iommu is in suspen
On Fri, Sep 28, 2012 at 6:24 AM, Joerg Roedel wrote:
> Finally enable interrupt remapping for AMD systems.
>
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/irq_remapping.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_rema
Joerg,
On Fri, Sep 28, 2012 at 6:24 AM, Joerg Roedel wrote:
> Add the six routines required to setup interrupt remapping
> with the AMD IOMMU. Also put it all together into the AMD
> specific irq_remap_ops.
>
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/amd_iommu.c | 16 +
On Fri, Sep 28, 2012 at 6:23 AM, Joerg Roedel wrote:
> To easily map device ids to interrupt remapping table
> entries a new lookup table is necessary.
>
> Signed-off-by: Joerg Roedel
> ---
> drivers/iommu/amd_iommu_init.c | 16
> drivers/iommu/amd_iommu_types.h |9 ++
ia the IOMMU twice. But while that's a lesson that's
> hopefully been learned and will be implemented in future, we have to
> deal with the existing hardware and its (ab)use of RMRRs.
>
Right. We do have hardware that is relying on being able to do dma from
devices to a system RAM via RMRR.
-- Shuah
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ch is not
sufficient.
Signed-off-by: Shuah Khan
---
drivers/iommu/amd_iommu_init.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index c567903..1d8ab7f 100644
--- a/drivers/iommu/amd_iommu_init.c
78 matches
Mail list logo
