All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
@ 2013-02-01 17:45 ` Kinney, Steven
  0 siblings, 0 replies; 9+ messages in thread
From: Kinney, Steven @ 2013-02-01 17:45 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, Bjorn Helgaas,
	Greg Kroah-Hartman, Sebastian Andrzej Siewior, Myron Stowe,
	Hiroshi DOYU, Stephen Warren, Jiri Kosina, Kukjin Kim,
	linux-kernel, iommu, Peter Zijlstra, Paul Mackerras,
	Arnaldo Carvalho de Melo, Thomas Renninger, Andi Kleen,
	Cyrill Gorcunov

Hi Joerg,

                    Sorry for the delay regarding the response.  I can describe the invocation and the results, pertaining to static counts.  Also, I would imagine that driver writers or individuals wanting to measure IOMMU translation performance would be the consumers regarding this perf capability.  Of course, this is my understanding and why I am very interested in the kernel communities comments and advice.  First, to invoke the use of the IOMMUv2 PMU the following command will suffice:

	./perf stat -e iommuv2/config=0x8000000000000005,config1=0x0/u <command>  /* I have the RAW bit explicitly set (MSb) */

	The <config> will set the following:

		CSource [7:0] - Identifies the IOMMUv2 performance metric that will be counted.  In this case 0x05 which is the total peripheral memory operations translated.
		DeviceID [23:8] - The PCI BDF identifying the specific device that will be considered.  In this case 0x0000 is the IOMMU itself.
		PASID [39:24] - Filter based on PASID, optional.  0x0000, no filtering
		Domain [55:40] - Filter based on Domain, optional, 0x0000 no filtering.
		en_deviceid_filter[56] - Explicit enabling of DeviceID filtering, implicitly set if DeviceID is not 0x0000.
		en_pasid_filter[57] - Must be set to enable optional PASID filtering.
		en_domain_filter [58] - Must be set to enable optional Domain filtering.

	The <config1> will set the following (more obscure settings)

		deviceid_mask [15:0] - Apply a bit mask, regarding the associated filter, or match register, for refining purposes.
		pasid_mask [31:16] - Same as device_mask pertaining to PASID.
		domain_mask [47:32] - Same as device_mask, pertaining to Domain.

When the IOMMUv2 PMU is invoked, the first task is to verify there is a PC resource available.  The IOMMUv2 PMU uses a soft register and bit mask, linearized from bank/counter information populated within the amd_iommu struct during initialization, to allocate a free bank/counter to assign to the perf IOMMU event.  The bank/counter information is used, among other values, to calculate an offset into the IOMMU MMIO region to access registers; for example ICounter, CSource, etc.  So from an IOMMUv2 driver perspective, pertaining to the additional functionality written into amd_iommu_init.c, once the IOMMUv2 PMU has assigned the counter resource it needs to configure the physical IOMMUv2 PC registers.  For example,:

		1) Allocate IOMMUv2 Bank/Counter index, first go-around the assignment is bank=0, counter=0.
		2) At the moment, the code is only populating the DevID (PCI BDF) into DeviceID; PASID and Domain will be added later.   The devid is held to 0x0000.
		3) The Fxn is the functional register within the counter set and is used to calculate the counter register offset within the MMIO Region.  For example CSource is +08h; see Table 70: Counter Bank Addressing (MMIO) in IOMMUv2 2.0 specification.
		4) The value to be written, in the case of the above example, is 0x05, pertaining to the CSource register.
		5) Since this is a write operation is_write is true.
		6) Now there is enough information to access the IOMMUv2 PC register(s) and the perf IOMMUv2 calls into the IOMMU core driver (exported function)

			Int amd_iommu_v2_get_set_pc_reg_val( u16 devid, u8 bank, u8 cntr, u8 fxn, long long *value, bool is_write);

		Most of the IOMMUv2 driver functionality is self-explanatory, and the function, above, will verify IOMMUv2 PC capability, calculate the counter set offset within the IOMMU MMIO region and verify that the offset is within the MMIO region aperture.  After this is completed, the function simply writes to the selected register.  Since the number of banks and counters are dynamic, dependent upon future design, the limits for MMIO region offset values are calculated based on reported maximum bank/counter.

After the CSource register has been written to, other than a zero(0), the ICounter will start counting the relative IOMMU events described by the CSource value.

To stop the counter (ICounter), the CSource register is set to zero(0); so a perf event accessing the IOMMUv2 PC will write a defined value to the CSource register, execute a command, write a zero(0) to the CSource register then read the ICounter value.  The count, for the specific IOMMU perf event, is the previous count minus the current ICounter value; the ICounter cannot be reset other than overflow.

So, when the perf command example is executed, for example with a ls or some other trivial executable, the result will be a count of all IOMMU peripheral memory operations translated (total).  I choose this simply to assure count increment.  

Sorry for the long winded explanation, but we can look at any detail you would like to explore regarding the above description.

BR,

Steve


-----Original Message-----
From: Joerg Roedel [mailto:joro@8bytes.org] 
Sent: Monday, January 28, 2013 9:37 AM
To: Kinney, Steven
Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; x86@kernel.org; Bjorn Helgaas; Greg Kroah-Hartman; Sebastian Andrzej Siewior; Myron Stowe; Hiroshi DOYU; Stephen Warren; Jiri Kosina; Kukjin Kim; linux-kernel@vger.kernel.org; iommu@lists.linux-foundation.org; Peter Zijlstra; Paul Mackerras; Arnaldo Carvalho de Melo; Thomas Renninger; Andi Kleen; Cyrill Gorcunov
Subject: Re: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature

On Mon, Jan 28, 2013 at 02:59:25PM +0000, 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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
@ 2013-02-01 17:45 ` Kinney, Steven
  0 siblings, 0 replies; 9+ messages in thread
From: Kinney, Steven @ 2013-02-01 17:45 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Kukjin Kim, Peter Zijlstra, Stephen Warren, Greg Kroah-Hartman,
	x86-DgEjT+Ai2ygdnm+yROfE0A, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	Cyrill Gorcunov, Andi Kleen, Sebastian Andrzej Siewior,
	Ingo Molnar, Paul Mackerras, Arnaldo Carvalho de Melo,
	H. Peter Anvin, Bjorn Helgaas, Jiri Kosina, Thomas Gleixner,
	Myron Stowe, Thomas Renninger

Hi Joerg,

                    Sorry for the delay regarding the response.  I can describe the invocation and the results, pertaining to static counts.  Also, I would imagine that driver writers or individuals wanting to measure IOMMU translation performance would be the consumers regarding this perf capability.  Of course, this is my understanding and why I am very interested in the kernel communities comments and advice.  First, to invoke the use of the IOMMUv2 PMU the following command will suffice:

	./perf stat -e iommuv2/config=0x8000000000000005,config1=0x0/u <command>  /* I have the RAW bit explicitly set (MSb) */

	The <config> will set the following:

		CSource [7:0] - Identifies the IOMMUv2 performance metric that will be counted.  In this case 0x05 which is the total peripheral memory operations translated.
		DeviceID [23:8] - The PCI BDF identifying the specific device that will be considered.  In this case 0x0000 is the IOMMU itself.
		PASID [39:24] - Filter based on PASID, optional.  0x0000, no filtering
		Domain [55:40] - Filter based on Domain, optional, 0x0000 no filtering.
		en_deviceid_filter[56] - Explicit enabling of DeviceID filtering, implicitly set if DeviceID is not 0x0000.
		en_pasid_filter[57] - Must be set to enable optional PASID filtering.
		en_domain_filter [58] - Must be set to enable optional Domain filtering.

	The <config1> will set the following (more obscure settings)

		deviceid_mask [15:0] - Apply a bit mask, regarding the associated filter, or match register, for refining purposes.
		pasid_mask [31:16] - Same as device_mask pertaining to PASID.
		domain_mask [47:32] - Same as device_mask, pertaining to Domain.

When the IOMMUv2 PMU is invoked, the first task is to verify there is a PC resource available.  The IOMMUv2 PMU uses a soft register and bit mask, linearized from bank/counter information populated within the amd_iommu struct during initialization, to allocate a free bank/counter to assign to the perf IOMMU event.  The bank/counter information is used, among other values, to calculate an offset into the IOMMU MMIO region to access registers; for example ICounter, CSource, etc.  So from an IOMMUv2 driver perspective, pertaining to the additional functionality written into amd_iommu_init.c, once the IOMMUv2 PMU has assigned the counter resource it needs to configure the physical IOMMUv2 PC registers.  For example,:

		1) Allocate IOMMUv2 Bank/Counter index, first go-around the assignment is bank=0, counter=0.
		2) At the moment, the code is only populating the DevID (PCI BDF) into DeviceID; PASID and Domain will be added later.   The devid is held to 0x0000.
		3) The Fxn is the functional register within the counter set and is used to calculate the counter register offset within the MMIO Region.  For example CSource is +08h; see Table 70: Counter Bank Addressing (MMIO) in IOMMUv2 2.0 specification.
		4) The value to be written, in the case of the above example, is 0x05, pertaining to the CSource register.
		5) Since this is a write operation is_write is true.
		6) Now there is enough information to access the IOMMUv2 PC register(s) and the perf IOMMUv2 calls into the IOMMU core driver (exported function)

			Int amd_iommu_v2_get_set_pc_reg_val( u16 devid, u8 bank, u8 cntr, u8 fxn, long long *value, bool is_write);

		Most of the IOMMUv2 driver functionality is self-explanatory, and the function, above, will verify IOMMUv2 PC capability, calculate the counter set offset within the IOMMU MMIO region and verify that the offset is within the MMIO region aperture.  After this is completed, the function simply writes to the selected register.  Since the number of banks and counters are dynamic, dependent upon future design, the limits for MMIO region offset values are calculated based on reported maximum bank/counter.

After the CSource register has been written to, other than a zero(0), the ICounter will start counting the relative IOMMU events described by the CSource value.

To stop the counter (ICounter), the CSource register is set to zero(0); so a perf event accessing the IOMMUv2 PC will write a defined value to the CSource register, execute a command, write a zero(0) to the CSource register then read the ICounter value.  The count, for the specific IOMMU perf event, is the previous count minus the current ICounter value; the ICounter cannot be reset other than overflow.

So, when the perf command example is executed, for example with a ls or some other trivial executable, the result will be a count of all IOMMU peripheral memory operations translated (total).  I choose this simply to assure count increment.  

Sorry for the long winded explanation, but we can look at any detail you would like to explore regarding the above description.

BR,

Steve


-----Original Message-----
From: Joerg Roedel [mailto:joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org] 
Sent: Monday, January 28, 2013 9:37 AM
To: Kinney, Steven
Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; Bjorn Helgaas; Greg Kroah-Hartman; Sebastian Andrzej Siewior; Myron Stowe; Hiroshi DOYU; Stephen Warren; Jiri Kosina; Kukjin Kim; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Peter Zijlstra; Paul Mackerras; Arnaldo Carvalho de Melo; Thomas Renninger; Andi Kleen; Cyrill Gorcunov
Subject: Re: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature

On Mon, Jan 28, 2013 at 02:59:25PM +0000, 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
@ 2013-01-28 15:36         ` Joerg Roedel
  0 siblings, 0 replies; 9+ messages in thread
From: Joerg Roedel @ 2013-01-28 15:36 UTC (permalink / raw)
  To: Kinney, Steven
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, Bjorn Helgaas,
	Greg Kroah-Hartman, Sebastian Andrzej Siewior, Myron Stowe,
	Hiroshi DOYU, Stephen Warren, Jiri Kosina, Kukjin Kim,
	linux-kernel, iommu, Peter Zijlstra, Paul Mackerras,
	Arnaldo Carvalho de Melo, Thomas Renninger, Andi Kleen,
	Cyrill Gorcunov

On Mon, Jan 28, 2013 at 02:59:25PM +0000, 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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
@ 2013-01-28 15:36         ` Joerg Roedel
  0 siblings, 0 replies; 9+ messages in thread
From: Joerg Roedel @ 2013-01-28 15:36 UTC (permalink / raw)
  To: Kinney, Steven
  Cc: Kukjin Kim, Peter Zijlstra, Stephen Warren, Greg Kroah-Hartman,
	x86-DgEjT+Ai2ygdnm+yROfE0A, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	Cyrill Gorcunov, Andi Kleen, Sebastian Andrzej Siewior,
	Ingo Molnar, Paul Mackerras, Arnaldo Carvalho de Melo,
	H. Peter Anvin, Bjorn Helgaas, Jiri Kosina, Thomas Gleixner,
	Myron Stowe, Thomas Renninger

On Mon, Jan 28, 2013 at 02:59:25PM +0000, 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
  2013-01-28 14:29     ` Joerg Roedel
  (?)
@ 2013-01-28 14:59     ` Kinney, Steven
  2013-01-28 15:36         ` Joerg Roedel
  -1 siblings, 1 reply; 9+ messages in thread
From: Kinney, Steven @ 2013-01-28 14:59 UTC (permalink / raw)
  To: Joerg Roedel
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, Bjorn Helgaas,
	Greg Kroah-Hartman, Sebastian Andrzej Siewior, Myron Stowe,
	Hiroshi DOYU, Stephen Warren, Jiri Kosina, Kukjin Kim,
	linux-kernel, iommu, Peter Zijlstra, Paul Mackerras,
	Arnaldo Carvalho de Melo, Thomas Renninger, Andi Kleen,
	Cyrill Gorcunov

Hi Joerg,

                       It was disabled for a reason that does not pertain to IOMMUv2 PC static counts (reading from the ICounter associated with the selected bank/counter).  Testing with perf shows expected results.

Thanks,

Steve

-----Original Message-----
From: Joerg Roedel [mailto:joro@8bytes.org] 
Sent: Monday, January 28, 2013 8:29 AM
To: Kinney, Steven
Cc: Thomas Gleixner; Ingo Molnar; H. Peter Anvin; x86@kernel.org; Bjorn Helgaas; Greg Kroah-Hartman; Sebastian Andrzej Siewior; Myron Stowe; Hiroshi DOYU; Stephen Warren; Jiri Kosina; Kukjin Kim; linux-kernel@vger.kernel.org; iommu@lists.linux-foundation.org; Peter Zijlstra; Paul Mackerras; Arnaldo Carvalho de Melo; Thomas Renninger; Andi Kleen; Cyrill Gorcunov
Subject: 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" <steven.kinney@amd.com>
> 
> 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




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
@ 2013-01-28 14:29     ` Joerg Roedel
  0 siblings, 0 replies; 9+ messages in thread
From: Joerg Roedel @ 2013-01-28 14:29 UTC (permalink / raw)
  To: Steven L. Kinney
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, Bjorn Helgaas,
	Greg Kroah-Hartman, Sebastian Andrzej Siewior, Myron Stowe,
	Hiroshi DOYU, Stephen Warren, Jiri Kosina, Kukjin Kim,
	linux-kernel, iommu, Peter Zijlstra, Paul Mackerras,
	Arnaldo Carvalho de Melo, Thomas Renninger, Andi Kleen,
	Cyrill Gorcunov

On Mon, Jan 21, 2013 at 02:20:56PM -0600, Steven L. Kinney wrote:
> From: "Steven L. Kinney" <steven.kinney@amd.com>
> 
> 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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
@ 2013-01-28 14:29     ` Joerg Roedel
  0 siblings, 0 replies; 9+ messages in thread
From: Joerg Roedel @ 2013-01-28 14:29 UTC (permalink / raw)
  To: Steven L. Kinney
  Cc: Kukjin Kim, Peter Zijlstra, Stephen Warren, Greg Kroah-Hartman,
	x86-DgEjT+Ai2ygdnm+yROfE0A, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	Cyrill Gorcunov, Andi Kleen, Sebastian Andrzej Siewior,
	Ingo Molnar, Paul Mackerras, Arnaldo Carvalho de Melo,
	H. Peter Anvin, Bjorn Helgaas, Jiri Kosina, Thomas Gleixner,
	Myron Stowe, Thomas Renninger

On Mon, Jan 21, 2013 at 02:20:56PM -0600, Steven L. Kinney wrote:
> From: "Steven L. Kinney" <steven.kinney-5C7GfCeVMHo@public.gmane.org>
> 
> 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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
@ 2013-01-21 20:20   ` Steven L. Kinney
  0 siblings, 0 replies; 9+ messages in thread
From: Steven L. Kinney @ 2013-01-21 20:20 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86, Joerg Roedel
  Cc: Bjorn Helgaas, Greg Kroah-Hartman, Sebastian Andrzej Siewior,
	Myron Stowe, Hiroshi DOYU, Stephen Warren, Jiri Kosina,
	Kukjin Kim, linux-kernel, iommu, Peter Zijlstra, Paul Mackerras,
	Arnaldo Carvalho de Melo, Thomas Renninger, Andi Kleen,
	Cyrill Gorcunov, Steven L. Kinney

From: "Steven L. Kinney" <steven.kinney@amd.com>

Original code base by Andreas Herrmann at AMD with minor changes.

Signed-off-by: Steven L. Kinney <steven.kinney@amd.com>
---
 arch/x86/kernel/quirks.c |   17 +++++++++++++++++
 include/linux/pci_ids.h  |    2 ++
 2 files changed, 19 insertions(+)

diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index 26ee48a..ab27b88 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -567,3 +567,20 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_NB_F5,
 			quirk_amd_nb_node);
 
 #endif
+
+#if defined(CONFIG_PCI) && defined(CONFIG_AMD_IOMMU_V2_PC)
+
+static void amd_force_iommu_v2_pc(struct pci_dev *dev)
+{
+	u32 val;
+
+	pci_read_config_dword(dev, 0x70, &val);
+	val |= (1<<9);
+	pci_write_config_dword(dev, 0x70, val);
+	dev_printk(KERN_DEBUG, &dev->dev, "Enabled IOMMUv2 PC\n");
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_M10H_IOMMU,
+			amd_force_iommu_v2_pc);
+
+#endif
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 0eb6579..c6ce47b 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -396,6 +396,8 @@
 /* AMD RD890 Chipset */
 #define PCI_DEVICE_ID_RD890_IOMMU	0x5a23
 
+#define PCI_DEVICE_ID_AMD_15H_M10H_IOMMU       0x1419
+
 #define PCI_VENDOR_ID_ADL		0x1005
 #define PCI_DEVICE_ID_ADL_2301		0x2301
 
-- 
1.7.9.5



^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature
@ 2013-01-21 20:20   ` Steven L. Kinney
  0 siblings, 0 replies; 9+ messages in thread
From: Steven L. Kinney @ 2013-01-21 20:20 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	x86-DgEjT+Ai2ygdnm+yROfE0A, Joerg Roedel
  Cc: Kukjin Kim, Peter Zijlstra, Stephen Warren, Greg Kroah-Hartman,
	Steven L. Kinney, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	Cyrill Gorcunov, Sebastian Andrzej Siewior, Andi Kleen,
	Paul Mackerras, Arnaldo Carvalho de Melo, Jiri Kosina,
	Bjorn Helgaas, Myron Stowe, Thomas Renninger

From: "Steven L. Kinney" <steven.kinney-5C7GfCeVMHo@public.gmane.org>

Original code base by Andreas Herrmann at AMD with minor changes.

Signed-off-by: Steven L. Kinney <steven.kinney-5C7GfCeVMHo@public.gmane.org>
---
 arch/x86/kernel/quirks.c |   17 +++++++++++++++++
 include/linux/pci_ids.h  |    2 ++
 2 files changed, 19 insertions(+)

diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index 26ee48a..ab27b88 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -567,3 +567,20 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_NB_F5,
 			quirk_amd_nb_node);
 
 #endif
+
+#if defined(CONFIG_PCI) && defined(CONFIG_AMD_IOMMU_V2_PC)
+
+static void amd_force_iommu_v2_pc(struct pci_dev *dev)
+{
+	u32 val;
+
+	pci_read_config_dword(dev, 0x70, &val);
+	val |= (1<<9);
+	pci_write_config_dword(dev, 0x70, val);
+	dev_printk(KERN_DEBUG, &dev->dev, "Enabled IOMMUv2 PC\n");
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_15H_M10H_IOMMU,
+			amd_force_iommu_v2_pc);
+
+#endif
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 0eb6579..c6ce47b 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -396,6 +396,8 @@
 /* AMD RD890 Chipset */
 #define PCI_DEVICE_ID_RD890_IOMMU	0x5a23
 
+#define PCI_DEVICE_ID_AMD_15H_M10H_IOMMU       0x1419
+
 #define PCI_VENDOR_ID_ADL		0x1005
 #define PCI_DEVICE_ID_ADL_2301		0x2301
 
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2013-02-01 17:45 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-01 17:45 [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature Kinney, Steven
2013-02-01 17:45 ` Kinney, Steven
  -- strict thread matches above, loose matches on Subject: below --
2013-01-21 20:20 [PATCH 0/3] AMD IOMMUv2 Performance Counter patches Steven L. Kinney
2013-01-21 20:20 ` [PATCH 1/3] AMD x86 quirks: Quirk for enabling IOMMUv2 PC feature Steven L. Kinney
2013-01-21 20:20   ` Steven L. Kinney
2013-01-28 14:29   ` Joerg Roedel
2013-01-28 14:29     ` Joerg Roedel
2013-01-28 14:59     ` Kinney, Steven
2013-01-28 15:36       ` Joerg Roedel
2013-01-28 15:36         ` Joerg Roedel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.