litmus-rt.git/arch/x86_64, branch v2.6.33.4

x86: kill the old i386 and x86_64 directories

2007-10-25T20:43:12+00:00

The last remaining bits were two .gitignore files.
Deleting them and the directories are history.

Signed-off-by: Sam Ravnborg

x86: move i386 and x86_64 Kconfig files to x86 directory

2007-10-25T20:37:02+00:00

After a small change in kconfig Makefile we could
move all x86 Kconfig files to x86 directory.

Signed-off-by: Sam Ravnborg

x86: unification of i386 and x86_64 Kconfig.debug

2007-10-25T20:35:10+00:00

Adding proper dependencies so the two Kconfig.debug files
are now identical and move the result file to x86.

Signed-off-by: Randy Dunlap 
Signed-off-by: Sam Ravnborg

x86: move defconfig files for i386 and x86_64 to x86

2007-10-25T20:27:41+00:00

With some small changes to kconfig makefile we can now
locate the defconfig files for i386 and x86_64 in
the configs/ subdirectory under x86.
make ARCH=i386 defconfig and make defconfig
works as expected also after this change.
But arch maintainers shall now update a defconfig file in
the configs/ directory.

Signed-off-by: Sam Ravnborg

x86: move i386 and x86_64 Makefiles to arch/x86

2007-10-25T20:27:34+00:00

Moving the ARCH specific Makefiles for i386 and x86_64
required a litle bit tweaking in the top-lvel Makefile.

SRCARCH is now set in the top-level Makefile
because we need this info to include the correct
arch Makefile.

Signed-off-by: Sam Ravnborg

x86: Add BITS to allow simple Makefile sharing

2007-10-23T20:37:23+00:00

Preperatory patch to simplify the sharing of Makefiles in
arch/x86.

Linus came up with this during a discussion about the ugliness of
ifeq($CONFIG_X86_32),y) and obj-$(CONFIG_X86_32) in the shared
Makefiles.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar

x86: add instrumentation menu

2007-10-23T20:37:22+00:00

It seems commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9 was incomplete 
due to a clash with the x86 architecture merge.

Signed-off-by: Adrian Bunk 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

Intel IOMMU: Iommu floppy workaround

2007-10-22T15:13:19+00:00

This config option (DMAR_FLPY_WA) sets up 1:1 mapping for the floppy device so
that the floppy device which does not use DMA api's will continue to work.

Once the floppy driver starts using DMA api's this config option can be turn
off or this patch can be yanked out of kernel at that time.

[akpm@linux-foundation.org: cleanups, rename things, build fix]
[jengelh@computergmbh.de: Kconfig fixes]
Signed-off-by: Anil S Keshavamurthy 
Cc: Andi Kleen 
Cc: Peter Zijlstra 
Cc: Muli Ben-Yehuda 
Cc: "Siddha, Suresh B" 
Cc: Arjan van de Ven 
Cc: Ashok Raj 
Cc: "David S. Miller" 
Cc: Christoph Lameter 
Cc: Greg KH 
Signed-off-by: Jan Engelhardt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Intel IOMMU: Iommu Gfx workaround

2007-10-22T15:13:19+00:00

When we fix all the opensource gfx drivers to use the DMA api's, at that time
we can yank this config options out.

[jengelh@computergmbh.de: Kconfig fixes]
Signed-off-by: Anil S Keshavamurthy 
Cc: Andi Kleen 
Cc: Peter Zijlstra 
Cc: Muli Ben-Yehuda 
Cc: "Siddha, Suresh B" 
Cc: Arjan van de Ven 
Cc: Ashok Raj 
Cc: "David S. Miller" 
Cc: Christoph Lameter 
Cc: Greg KH 
Signed-off-by: Jan Engelhardt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Intel IOMMU: DMAR detection and parsing logic

2007-10-22T15:13:18+00:00

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 
Cc: Andi Kleen 
Cc: Peter Zijlstra 
Cc: Muli Ben-Yehuda 
Cc: "Siddha, Suresh B" 
Cc: Arjan van de Ven 
Cc: Ashok Raj 
Cc: "David S. Miller" 
Cc: Christoph Lameter 
Cc: Greg KH 
Cc: Len Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds