aboutsummaryrefslogtreecommitdiffstats
path: root/include/acpi/actbl1.h
diff options
context:
space:
mode:
authorKeshavamurthy, Anil S <anil.s.keshavamurthy@intel.com>2007-10-21 19:41:41 -0400
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-10-22 11:13:18 -0400
commit10e5247f40f3bf7508a0ed2848c9cae37bddf4bc (patch)
treeadca606f00ebcbdbdc5c474f012105d7e59152f6 /include/acpi/actbl1.h
parent89910cccb8fec0c1140d33a743e72a712efd4f05 (diff)
Intel IOMMU: DMAR detection and parsing logic
This patch supports the upcomming Intel IOMMU hardware a.k.a. Intel(R) Virtualization Technology for Directed I/O Architecture and the hardware spec for the same can be found here http://www.intel.com/technology/virtualization/index.htm FAQ! (questions from akpm, answers from ak) > So... what's all this code for? > > I assume that the intent here is to speed things up under Xen, etc? Yes in some cases, but not this code. That would be the Xen version of this code that could potentially assign whole devices to guests. I expect this to be only useful in some special cases though because most hardware is not virtualizable and you typically want an own instance for each guest. Ok at some point KVM might implement this too; i likely would use this code for this. > Do we > have any benchmark results to help us to decide whether a merge would be > justified? The main advantage for doing it in the normal kernel is not performance, but more safety. Broken devices won't be able to corrupt memory by doing random DMA. Unfortunately that doesn't work for graphics yet, for that need user space interfaces for the X server are needed. There are some potential performance benefits too: - When you have a device that cannot address the complete address range an IOMMU can remap its memory instead of bounce buffering. Remapping is likely cheaper than copying. - The IOMMU can merge sg lists into a single virtual block. This could potentially speed up SG IO when the device is slow walking SG lists. [I long ago benchmarked 5% on some block benchmark with an old MPT Fusion; but it probably depends a lot on the HBA] And you get better driver debugging because unexpected memory accesses from the devices will cause a trappable event. > > Does it slow anything down? It adds more overhead to each IO so yes. This patch: Add support for early detection and parsing of DMAR's (DMA Remapping) reported to OS via ACPI tables. DMA remapping(DMAR) devices support enables independent address translations for Direct Memory Access(DMA) from Devices. These DMA remapping devices are reported via ACPI tables and includes pci device scope covered by these DMA remapping device. For detailed info on the specification of "Intel(R) Virtualization Technology for Directed I/O Architecture" please see http://www.intel.com/technology/virtualization/index.htm Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Cc: Andi Kleen <ak@suse.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Muli Ben-Yehuda <muli@il.ibm.com> Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Ashok Raj <ashok.raj@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Christoph Lameter <clameter@sgi.com> Cc: Greg KH <greg@kroah.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/acpi/actbl1.h')
-rw-r--r--include/acpi/actbl1.h27
1 files changed, 20 insertions, 7 deletions
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 4e5d3ca53a8e..a1b1b2ee3e51 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -257,7 +257,8 @@ struct acpi_table_dbgp {
257struct acpi_table_dmar { 257struct acpi_table_dmar {
258 struct acpi_table_header header; /* Common ACPI table header */ 258 struct acpi_table_header header; /* Common ACPI table header */
259 u8 width; /* Host Address Width */ 259 u8 width; /* Host Address Width */
260 u8 reserved[11]; 260 u8 flags;
261 u8 reserved[10];
261}; 262};
262 263
263/* DMAR subtable header */ 264/* DMAR subtable header */
@@ -265,8 +266,6 @@ struct acpi_table_dmar {
265struct acpi_dmar_header { 266struct acpi_dmar_header {
266 u16 type; 267 u16 type;
267 u16 length; 268 u16 length;
268 u8 flags;
269 u8 reserved[3];
270}; 269};
271 270
272/* Values for subtable type in struct acpi_dmar_header */ 271/* Values for subtable type in struct acpi_dmar_header */
@@ -274,13 +273,15 @@ struct acpi_dmar_header {
274enum acpi_dmar_type { 273enum acpi_dmar_type {
275 ACPI_DMAR_TYPE_HARDWARE_UNIT = 0, 274 ACPI_DMAR_TYPE_HARDWARE_UNIT = 0,
276 ACPI_DMAR_TYPE_RESERVED_MEMORY = 1, 275 ACPI_DMAR_TYPE_RESERVED_MEMORY = 1,
277 ACPI_DMAR_TYPE_RESERVED = 2 /* 2 and greater are reserved */ 276 ACPI_DMAR_TYPE_ATSR = 2,
277 ACPI_DMAR_TYPE_RESERVED = 3 /* 3 and greater are reserved */
278}; 278};
279 279
280struct acpi_dmar_device_scope { 280struct acpi_dmar_device_scope {
281 u8 entry_type; 281 u8 entry_type;
282 u8 length; 282 u8 length;
283 u8 segment; 283 u16 reserved;
284 u8 enumeration_id;
284 u8 bus; 285 u8 bus;
285}; 286};
286 287
@@ -290,7 +291,14 @@ enum acpi_dmar_scope_type {
290 ACPI_DMAR_SCOPE_TYPE_NOT_USED = 0, 291 ACPI_DMAR_SCOPE_TYPE_NOT_USED = 0,
291 ACPI_DMAR_SCOPE_TYPE_ENDPOINT = 1, 292 ACPI_DMAR_SCOPE_TYPE_ENDPOINT = 1,
292 ACPI_DMAR_SCOPE_TYPE_BRIDGE = 2, 293 ACPI_DMAR_SCOPE_TYPE_BRIDGE = 2,
293 ACPI_DMAR_SCOPE_TYPE_RESERVED = 3 /* 3 and greater are reserved */ 294 ACPI_DMAR_SCOPE_TYPE_IOAPIC = 3,
295 ACPI_DMAR_SCOPE_TYPE_HPET = 4,
296 ACPI_DMAR_SCOPE_TYPE_RESERVED = 5 /* 5 and greater are reserved */
297};
298
299struct acpi_dmar_pci_path {
300 u8 dev;
301 u8 fn;
294}; 302};
295 303
296/* 304/*
@@ -301,6 +309,9 @@ enum acpi_dmar_scope_type {
301 309
302struct acpi_dmar_hardware_unit { 310struct acpi_dmar_hardware_unit {
303 struct acpi_dmar_header header; 311 struct acpi_dmar_header header;
312 u8 flags;
313 u8 reserved;
314 u16 segment;
304 u64 address; /* Register Base Address */ 315 u64 address; /* Register Base Address */
305}; 316};
306 317
@@ -312,7 +323,9 @@ struct acpi_dmar_hardware_unit {
312 323
313struct acpi_dmar_reserved_memory { 324struct acpi_dmar_reserved_memory {
314 struct acpi_dmar_header header; 325 struct acpi_dmar_header header;
315 u64 address; /* 4_k aligned base address */ 326 u16 reserved;
327 u16 segment;
328 u64 base_address; /* 4_k aligned base address */
316 u64 end_address; /* 4_k aligned limit address */ 329 u64 end_address; /* 4_k aligned limit address */
317}; 330};
318 331