[Intel IOMMU][patch 2/8] Some generic search functions required to lookup device relationships.

devices under a p2p share the same domain in a DMAR. We just cache the type of device, if its a native PCIe device or not for later use. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] - Index: 2.6.21-rc6

[Intel IOMMU][patch 4/8] Supporting Zero Length Reads in Intel IOMMU.

provides a workaround for some drivers that request a write-only mapping when they really should request a read-write. (We ran into one such case in eepro100.c in handling rx_ring_dma) Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED

[Intel IOMMU][patch 2/8] Some generic search functions required to lookup device relationships.

devices under a p2p share the same domain in a DMAR. We just cache the type of device, if its a native PCIe device or not for later use. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] - Index: 2.6.21-rc6

[Intel IOMMU][patch 7/8] Support for legacy ISA devices

Floppy disk drivers dont work well with DMA remapping. Its possible to extend the current use for x86_64, but the gain is very little. If someone feels compelled to clean this up, its up for grabs. Since these use 16M, we just provide a unity map for the ISA bridge device. Signed-off-by: Ashok

[Intel IOMMU][patch 6/8] Doc updates for Intel Virtualization Technology for Directed I/O.

Document Intel IOMMU driver boot option. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: linux-2.6.21-rc5/Documentation/Intel-IOMMU.txt === --- /dev/null 1970-01-01 00:00:00.0

[Intel IOMMU][patch 5/8] Graphics driver workarounds to provide unity map

for gfx devices, that is physical address equals to virtual address.In this way, gfx will use physical address for DMA, this is primarily for add-in card GFX device. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: 2.6.21-rc6/arch/x86_64/kernel/e820

[Intel IOMMU][patch 8/8] Preserve some Virtual Address when devices cannot address entire range.

-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: linux-2.6.21-rc5/Documentation/kernel-parameters.txt === --- linux-2.6.21-rc5.orig/Documentation/kernel-parameters.txt 2007-04-17 06:02

[Intel IOMMU][patch 7/8] Support for legacy ISA devices

Floppy disk drivers dont work well with DMA remapping. Its possible to extend the current use for x86_64, but the gain is very little. If someone feels compelled to clean this up, its up for grabs. Since these use 16M, we just provide a unity map for the ISA bridge device. Signed-off-by: Ashok

[Intel IOMMU][patch 1/8] ACPI support for Intel Virtualization Technology for Directed I/O

This patch contains basic ACPI parsing and enumeration support. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: linux-2.6.21-rc5/arch/x86_64/Kconfig === --- linux-2.6.21-rc5.orig/arch

[Intel IOMMU][patch 0/8] Intel IOMMU Support

, Ashok Raj -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

[Intel IOMMU][patch 0/8] Intel IOMMU Support.

, this will provide more compatibility, but we will lose oppertunity to identify broken device drivers that dont use dma api's and fix them Depending on who you talk to.. some like it.. some just hate it! and would like to fix the broken ones instead. Cheers, Ashok Raj -- - To unsubscribe from

[Intel IOMMU][patch 4/8] Supporting Zero Length Reads in Intel IOMMU.

provides a workaround for some drivers that request a write-only mapping when they really should request a read-write. (We ran into one such case in eepro100.c in handling rx_ring_dma) Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED

[Intel IOMMU][patch 1/8] ACPI support for Intel Virtualization Technology for Directed I/O

This patch contains basic ACPI parsing and enumeration support. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: linux-2.6.21-rc5/arch/x86_64/Kconfig === --- linux-2.6.21-rc5.orig/arch

[Intel IOMMU][patch 6/8] Doc updates for Intel Virtualization Technology for Directed I/O.

Document Intel IOMMU driver boot option. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: linux-2.6.21-rc5/Documentation/Intel-IOMMU.txt === --- /dev/null 1970-01-01 00:00:00.0

[Intel IOMMU][patch 5/8] Graphics driver workarounds to provide unity map

for gfx devices, that is physical address equals to virtual address.In this way, gfx will use physical address for DMA, this is primarily for add-in card GFX device. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: 2.6.21-rc6/arch/x86_64/kernel/e820

[Intel IOMMU][patch 8/8] Preserve some Virtual Address when devices cannot address entire range.

-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: linux-2.6.21-rc5/Documentation/kernel-parameters.txt === --- linux-2.6.21-rc5.orig/Documentation/kernel-parameters.txt 2007-04-17 06:02

Re: [Intel IOMMU][patch 1/8] ACPI support for Intel Virtualization Technology for Directed I/O

On Tue, Apr 24, 2007 at 08:50:48PM +0200, Andi Kleen wrote: + +LIST_HEAD(dmar_drhd_units); +LIST_HEAD(dmar_rmrr_units); Comment describing what lock protects those lists? In fact there seems to be no locking. What about hotplug? There is no support to handle an IOMMU hotplug at this

Re: [Intel IOMMU][patch 8/8] Preserve some Virtual Address when devices cannot address entire range.

On Tue, Apr 24, 2007 at 09:33:15PM +0200, Andi Kleen wrote: On Tuesday 24 April 2007 08:03:07 Ashok Raj wrote: Some devices may not support entire 64bit DMA. In a situation where such devices are co-located in a shared domain, we need to ensure there is some address space reserved

Re: [Intel IOMMU][patch 7/8] Support for legacy ISA devices

On Tue, Apr 24, 2007 at 09:31:09PM +0200, Andi Kleen wrote: On Tuesday 24 April 2007 08:03:06 Ashok Raj wrote: Floppy disk drivers dont work well with DMA remapping. What is the problem? You can't allocate mappings 16MB? No.. these drivers dont call DMA mapping api's.. thats the problem

Re: [Intel IOMMU][patch 4/8] Supporting Zero Length Reads in Intel IOMMU.

On Tue, Apr 24, 2007 at 09:28:11PM +0200, Andi Kleen wrote: On Tuesday 24 April 2007 08:03:03 Ashok Raj wrote: PCI specs permit zero length reads (ZLR) even if the mapping for that region is write only. Support for this feature is indicated by the presence of a bit in the DMAR

Re: [Intel IOMMU][patch 3/8] Generic hardware support for Intel IOMMU.

On Tue, Apr 24, 2007 at 09:27:08PM +0200, Andi Kleen wrote: On Tuesday 24 April 2007 08:03:02 Ashok Raj wrote: +#ifdef CONFIG_DMAR +#ifdef CONFIG_SMP +static void dmar_msi_set_affinity(unsigned int irq, cpumask_t mask) Why does it need an own interrupt type? Problem is its MSI type

Re: [Intel IOMMU][patch 6/8] Doc updates for Intel Virtualization Technology for Directed I/O.

On Tue, Apr 24, 2007 at 11:17:55PM +0200, Markus Rechberger wrote: +We also allocate gaurd pages with each mapping, so we can attempt to catch +any overflow that might happen. + guess you probably mean guard tables here... So there is a good chance i can be The Governor of California :-)

Re: [Intel IOMMU][patch 8/8] Preserve some Virtual Address when devices cannot address entire range.

On Tue, Apr 24, 2007 at 02:23:51PM -0700, David Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: Tue, 24 Apr 2007 23:12:54 +0200 We already have a couple of other IOMMU architectures who essentially have the same problem. Have you checked how they solve this? Sparc64, for one,

Re: [Intel IOMMU][patch 8/8] Preserve some Virtual Address when devices cannot address entire range.

On Wed, Apr 25, 2007 at 12:03:57AM +0200, Andi Kleen wrote: On Tuesday 24 April 2007 23:50:26 David Miller wrote: From: Ashok Raj [EMAIL PROTECTED] Date: Tue, 24 Apr 2007 14:38:35 -0700 Its not clear if we have a very generic device breakage.. most devices on these platforms

[patch 0/8] [Intel IOMMU] Support for Intel Virtualization Technology for Directed I/O

to Documentation area for startup options and some basics. 7. Workaround to provide unity map for ISA bridge device to enable floppy disk. 8. Ability to preserve some mappings for devices not able to address entire range. Please help review and provide feedback. Cheers, Ashok Raj Shaohua Li

[patch 2/8] [Intel IOMMU] Some generic search functions required to lookup device relationships.

devices under a p2p share the same domain in a DMAR. We just cache the type of device, if its a native PCIe device or not for later use. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] - Index: linux-2.6.21-rc5

[patch 4/8] [Intel IOMMU] Supporting Zero Length Reads in Intel IOMMU.

provides a workaround for some drivers that request a write-only mapping when they really should request a read-write. (We ran into one such case in eepro100.c in handling rx_ring_dma) Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED

[patch 5/8] [Intel IOMMU] Graphics driver workarounds to provide unity map

for gfx devices, that is physical address equals to virtual address.In this way, gfx will use physical address for DMA, this is primarily for add-in card GFX device. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: linux-2.6.21-rc5/arch/x86_64

[patch 6/8] [Intel IOMMU] Doc updates for Intel Virtualization Technology for Directed I/O.

Document Intel IOMMU driver boot option. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: linux-2.6.21-rc5/Documentation/Intel-IOMMU.txt === --- /dev/null 1970-01-01 00:00:00.0

[patch 8/8] [Intel IOMMU] Preserve some Virtual Address when devices cannot address entire range.

-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: linux-2.6.21-rc5/Documentation/kernel-parameters.txt === --- linux-2.6.21-rc5.orig/Documentation/kernel-parameters.txt 2007-04-09 03:05

[patch 1/8] [Intel IOMMU] ACPI support for Intel Virtualization Technology for Directed I/O

This patch contains basic ACPI parsing and enumeration support. Signed-off-by: Ashok Raj [EMAIL PROTECTED] Signed-off-by: Shaohua Li [EMAIL PROTECTED] Index: linux-2.6.21-rc5/arch/x86_64/Kconfig === --- linux-2.6.21-rc5.orig/arch

[patch 7/8] [Intel IOMMU] Support for legacy ISA devices

Floppy disk drivers dont work well with DMA remapping. Its possible to extend the current use for x86_64, but the gain is very little. If someone feels compelled to clean this up, its up for grabs. Since these use 16M, we just provide a unity map for the ISA bridge device. Signed-off-by: Ashok

Re: [patch 1/8] [Intel IOMMU] ACPI support for Intel Virtualization Technology for Directed I/O

On Mon, Apr 09, 2007 at 11:39:19PM -0400, Len Brown wrote: On Monday 09 April 2007 17:55, Ashok Raj wrote: This patch contains basic ACPI parsing and enumeration support. AFAICS, ACPI supplies the envelope which delivers the table, and ACPI has some convenience structure definitions

Re: [patch 0/8] [Intel IOMMU] Support for Intel Virtualization Technology for Directed I/O

On Tue, Apr 10, 2007 at 09:49:55AM +0200, Andi Kleen wrote: On Monday 09 April 2007 23:55:52 Ashok Raj wrote: Please help review and provide feedback. High level question: how did you solve the user X server needs IOMMU bypass problem? There is no special consideration for user space

Re: [patch 0/8] [Intel IOMMU] Support for Intel Virtualization Technology for Directed I/O

On Tue, Apr 10, 2007 at 04:34:48AM -0400, Jeff Garzik wrote: Shaohua Li wrote: DMA remapping just uses ACPI table to tell which dma remapping engine a pci device is controlled by at boot time. At run time, DMA remapping hasn't any interactive with ACPI. The Linux kernel _really_ wants a

Re: [PATCH] PC300 pci_enable_device fix

] More majordomo info at [1]http://vger.kernel.org/majordomo-info.html Please read the FAQ at [2]http://www.tux.org/lkml/ References 1. http://vger.kernel.org/majordomo-info.html 2. http://www.tux.org/lkml/ -- Cheers, Ashok Raj - Open Source Technology Center - To unsubscribe from

Extending defconfig for x86_64

for next update. -- Cheers, Ashok Raj - Open Source Technology Center This provides a working default config file for Intel systems. Tested on harwich (4p + ht systems), if more are required either add to this config, or create new defconfig's as required. Signed-off-by: Ashok Raj [EMAIL PROTECTED

Fix irq_affinity write from /proc for IPF

for the cross post to lia64 ] -- Cheers, Ashok Raj - Open Source Technology Center --- fix_ia64_smp_affinity - Make GENERIC_HARDIRQ work for IPF and CPU Hotplug Signed-off-by: Ashok Raj [EMAIL PROTECTED] Made GENERIC_HARDIRQ mechanism work for IPF and CPU hotplug. When write to /proc/irq is handled

Re: Fix irq_affinity write from /proc for IPF

On Mon, Mar 14, 2005 at 03:59:23PM -0800, Andrew Morton wrote: Ashok Raj [EMAIL PROTECTED] wrote: ia64 is preferred, please. Nobody knows what an IPF is. Right!. Sorry about that. Is it not possible for ia64's -set_affinity() handler to do this deferring? There are other places

Re: [PATCH] User Level Interrupts

Hi Michael have you thought about how this infrastructure would play well with existing CPU hotplug code for ia64? Once you return to user mode via the iret, is it possible that user mode thread could get switched due to a pending cpu quiese attempt to remove a cpu? (Current cpu removal code

Re: [ACPI] Re: [RFC 5/6]clean cpu state after hotremove CPU

On Mon, Apr 04, 2005 at 03:46:20PM -0700, Nathan Lynch wrote: Hi Nigel! On Tue, Apr 05, 2005 at 08:14:25AM +1000, Nigel Cunningham wrote: On Tue, 2005-04-05 at 01:33, Nathan Lynch wrote: Yes, exactly. Someone who understand do_exit please help clean No, that

Re: [patch 1/1] Hot plug CPU to support physical add of new processors (i386)

'); _ -- Cheers, Ashok Raj - Open Source Technology Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [patch 1/1] Hot plug CPU to support physical add of new processors (i386)

On Thu, Sep 01, 2005 at 10:45:10AM +0200, Andi Kleen wrote: Hallo Natalie, On Wednesday 31 August 2005 14:13, [EMAIL PROTECTED] wrote: Current IA32 CPU hotplug code doesn't allow bringing up processors that were not present in the boot configuration. To make existing hot plug facility

Re: [patch 1/1] Hot plug CPU to support physical add of new processors (i386)

be prefectly fine. -- Cheers, Ashok Raj - Open Source Technology Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org

Re: 2.6.13-rc5-mm1 doesnt boot on x86_64

scsi_target *starget, int width) { struct Scsi_Host *shost = dev_to_shost(starget-dev.parent); -- Cheers, Ashok Raj - Open Source Technology Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http

[patch 5/8] x86_64:Dont do broadcast IPIs when hotplug is enabled in flat mode.

in send IPI to a cpu that is offline which can trip when the cpu is in the process of being kicked alive. Signed-off-by: Ashok Raj [EMAIL PROTECTED] --- arch/x86_64/kernel/genapic_flat.c |8 1 files changed, 8 insertions(+) Index

[patch 3/8] x86_64:Dont call enforce_max_cpus when hotplug is enabled

No need to enforce_max_cpus when hotplug code is enabled. This nukes out cpu_present_map and cpu_possible_map making it impossible to add new cpus in the system. Signed-off-by: Ashok Raj [EMAIL PROTECTED] arch/x86_64/kernel/smpboot.c | 40

[patch 1/8] x86_64: Reintroduce clustered_apic_check() for x86_64.

Auto selection of bigsmp patch removed this check from a shared common file in arch/i386/kernel/acpi/boot.c. We still need to call this to determine the right genapic code for x86_64. Signed-off-by: Ashok Raj [EMAIL PROTECTED] --- arch

[patch 7/8] x86_64:Use common functions in cluster and physflat mode

support (for no-broadcast) is required. Signed-off-by: Ashok Raj [EMAIL PROTECTED] arch/x86_64/kernel/genapic.c | 52 + arch/x86_64/kernel/genapic_cluster.c | 55

[patch 8/8] x86_64: Choose physflat for AMD systems only when 8 CPUS.

mode. Andi: Do you think this is acceptable? Signed-off-by: Ashok Raj [EMAIL PROTECTED] --- arch/x86_64/kernel/genapic.c |9 + 1 files changed, 1 insertion(+), 8 deletions(-) Index: linux-2.6.13-rc4-mm1/arch/x86_64/kernel

Re: [patch 1/8] x86_64: Reintroduce clustered_apic_check() for x86_64.

On Mon, Aug 01, 2005 at 01:20:18PM -0700, Ashok Raj wrote: Auto selection of bigsmp patch removed this check from a shared common file in arch/i386/kernel/acpi/boot.c. We still need to call this to determine the right genapic code for x86_64. Thanks venki, missed the check for lapic

[patch 6/8] x86_64:Dont use Lowest Priority when using physical mode.

Delivery mode should be APIC_DM_FIXED when using physical mode. Signed-off-by: Ashok Raj [EMAIL PROTECTED] arch/x86_64/kernel/genapic_flat.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6.13-rc4-mm1/arch/x86_64

Re: [patch 3/8] x86_64:Dont call enforce_max_cpus when hotplug is enabled

On Thu, Aug 04, 2005 at 12:41:10PM +0200, Andi Kleen wrote: On Mon, Aug 01, 2005 at 01:20:20PM -0700, Ashok Raj wrote: No need to enforce_max_cpus when hotplug code is enabled. This nukes out cpu_present_map and cpu_possible_map making it impossible to add new cpus in the system. Hmm - i

Re: [patch 4/8] x86_64:Fix cluster mode send_IPI_allbutself to use get_cpu()/put_cpu()

On Thu, Aug 04, 2005 at 12:43:02PM +0200, Andi Kleen wrote: On Mon, Aug 01, 2005 at 01:20:21PM -0700, Ashok Raj wrote: Need to ensure we dont get prempted when we clear ourself from mask when using clustered mode genapic code. It's not needed I think. If the caller wants to execute code

Re: [patch 5/8] x86_64:Dont do broadcast IPIs when hotplug is enabled in flat mode.

an updated one to Andrew. -- Cheers, Ashok Raj - Open Source Technology Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: [patch 5/8] x86_64:Dont do broadcast IPIs when hotplug is enabled in flat mode.

in your -mm queue is below, with the attached patch. x86_64dont-do-broadcast-ipis-when-hotplug-is-enabled-in-flat-mode.patch -- Cheers, Ashok Raj - Open Source Technology Center Note: Recent introduction of physflat mode for x86_64 inadvertently deleted the use of non-shortcut version of routines

2.6.13-rc5-mm1 doesnt boot on x86_64

Folks, Iam getting this on the recent 2.6.12-rc5-mm1 kernel built with defconfig. Cheers, Ashok Raj --- [cut here ] - [please bite here ] - Kernel BUG at include/linux/list.h:165 invalid operand: [1] SMP CPU 2 Modules linked in: Pid: 1, comm: swapper Not tainted

Re: 2.6.13-rc5-mm1 doesnt boot on x86_64

On Mon, Aug 08, 2005 at 07:11:26PM +0200, Andi Kleen wrote: On Mon, Aug 08, 2005 at 09:48:19AM -0700, Ashok Raj wrote: Folks, Iam getting this on the recent 2.6.12-rc5-mm1 kernel built with defconfig. Cheers, Ashok Raj --- [cut here ] - [please bite here

Re: 2.6.13-rc5-mm1 doesnt boot on x86_64

nothing, and tries to de-reg resulting in the BUG(). I will try to get the recompile and entire dmesg log in the meantime. James -- Cheers, Ashok Raj - Open Source Technology Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL

Re: [patch 09/14] x86_64: Don't call enforce_max_cpus when hotplug is enabled

Hi Andi On Mon, Sep 05, 2005 at 06:48:21AM +0200, Andi Kleen wrote: On Sat, Sep 03, 2005 at 02:33:26PM -0700, [EMAIL PROTECTED] wrote: From: Ashok Raj [EMAIL PROTECTED] No need to enforce_max_cpus when hotplug code is enabled. This nukes out cpu_present_map and cpu_possible_map

Re: [patch 14/14] x86_64: Choose physflat for AMD systems only when 8 CPUS.

On Tue, Sep 06, 2005 at 01:18:08AM +0200, Andi Kleen wrote: On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote: From: Ashok Raj [EMAIL PROTECTED] It is not required to choose the physflat mode when CPU hotplug is enabled and CPUs =8 case. Use of genapic_flat

Re: [patch 13/14] x86_64: Use common functions in cluster and physflat mode

On Tue, Sep 06, 2005 at 01:16:28AM +0200, Andi Kleen wrote: On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote: From: Ashok Raj [EMAIL PROTECTED] Newly introduced physflat_* shares way too much with cluster with only a very differences. So we introduce some common

Re: [patch 09/14] x86_64: Don't call enforce_max_cpus when hotplug is enabled

, and repeat, thats not my intend. -- Cheers, Ashok Raj - Open Source Technology Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ

Re: [patch 13/14] x86_64: Use common functions in cluster and physflat mode

per cpu for each IPI v.s just 2 for a flat mode mask version of the API. -- Cheers, Ashok Raj - Open Source Technology Center - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org

Re: [OOPS] hotplugging cpus via /sys/devices/system/cpu/

On Fri, Sep 09, 2005 at 01:41:58PM -0700, Christopher Beppler wrote: [1.] One line summary of the problem: If I deactivate a CPU with /sys/devices/system/cpux and try to reactivate it, then the CPU doesn't start and the kernel prints out an oops. Could you try this on

Re: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling

On Mon, Jun 11, 2007 at 02:14:49PM -0700, Andrew Morton wrote: Again, if dma_map_{single|sg} API's fails due to failure to allocate memory, the only thing that can be done is to panic as this is what few of the other IOMMU implementation is doing today. If the only option is to

Re: [Intel-IOMMU 02/10] Library routine for pre-allocat pool handling

On Tue, Jun 12, 2007 at 12:25:57AM +0200, Andi Kleen wrote: Please advice. I think the short term only safe option would be to fully preallocate an aperture. If it is too small you can try GFP_ATOMIC but it would be just a unreliable fallback. For safety you could perhaps have some

[Patch V2 2/3] x86, mce: Add infrastructure required to support LMCE

and documentation on Local MCE. Signed-off-by: Ashok Raj ashok@intel.com --- Documentation/x86/x86_64/boot-options.txt | 3 ++ arch/x86/include/asm/mce.h| 5 +++ arch/x86/kernel/cpu/mcheck/mce.c | 3 ++ arch/x86/kernel/cpu/mcheck/mce_intel.c| 59

[Patch V2 1/3] x86, mce: Add LMCE definitions.

Add required definitions to support Local Machine Check Exceptions. See http://www.intel.com/sdm Volume 3, System Programming Guide, chapter 15 for more information on MSR's and documentation on Local MCE. Signed-off-by: Ashok Raj ashok@intel.com --- arch/x86/include/asm/mce.h

[Patch V2 0/3] x86, mce: Local Machine Check Exception (LMCE)

. For more details see Vol3, Chapter 15, Machine Check Architecture. Modified to incorporate feedback from Boris on V1 patches. Ashok Raj (3): x86, mce: Add LMCE definitions. x86, mce: Add infrastructure required to support LMCE x86, mce: Handling LMCE events Documentation/x86/x86_64/boot

[Patch V2 3/3] x86, mce: Handling LMCE events

to perform rendezvous with other logical processors unlike earlier processors that would broadcast machine check errors. See http://www.intel.com/sdm Volume 3, Chapter 15 for more information on MSR's and documentation on Local MCE. Signed-off-by: Ashok Raj ashok@intel.com --- arch/x86

[Patch V1 2/3] x86, mce: Add infrastructure required to support LMCE

and documentation on Local MCE. Signed-off-by: Ashok Raj ashok@intel.com --- Documentation/x86/x86_64/boot-options.txt | 3 ++ arch/x86/include/asm/mce.h| 5 +++ arch/x86/kernel/cpu/mcheck/mce.c | 3 ++ arch/x86/kernel/cpu/mcheck/mce_intel.c| 75

[Patch V1 0/3] x86 Local Machine Check Exception (LMCE)

, Machine Check Architecture. Ashok Raj (3): x86, mce: Add LMCE definitions. x86, mce: Add infrastructure required to support LMCE x86, mce: Handling LMCE events Documentation/x86/x86_64/boot-options.txt | 3 ++ arch/x86/include/asm/mce.h| 10 arch/x86/include/uapi/asm/msr

[Patch V1 3/3] x86, mce: Handling LMCE events

to perform rendezvous with other logical processors unlike earlier processors that would broadcast machine check errors. See http://www.intel.com/sdm Volume 3, Chapter 15 for more information on MSR's and documentation on Local MCE. Signed-off-by: Ashok Raj ashok@intel.com --- arch/x86

[Patch V1 1/3] x86, mce: Add LMCE definitions.

Add required definitions to support Local Machine Check Exceptions. See http://www.intel.com/sdm Volume 3, System Programming Guide, chapter 15 for more information on MSR's and documentation on Local MCE. Signed-off-by: Ashok Raj ashok@intel.com --- arch/x86/include/asm/mce.h

[Patch V1 2/2] x86, mce: clear Local MCE opt-in before kexec.

kexec could boot a kernel that could be legacy with no knowledge of LMCE. hence we should make sure we clear LMCE optin before kexec reboot. Signed-off-by: Ashok Raj ashok@intel.com --- arch/x86/include/asm/mce.h | 4 arch/x86/kernel/cpu/mcheck/mce.c | 30

[Patch V1 1/2] x86, mce: Remove unused declarations

Remove unused references Signed-off-by: Ashok Raj ashok@intel.com --- arch/x86/include/asm/mce.h | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h index 8ba4d7a..b7a3a34 100644 --- a/arch/x86/include/asm/mce.h +++ b/arch/x86

[Patch V0] x86, mce: Don't clear global error reporting banks during cpu_offline

regressions. Signed-off-by: Ashok Raj <ashok@intel.com> Reviewed-by: Tony Luck <tony.l...@intel.com> Tested-by: Serge Ayoun <serge.ay...@intel.com> --- arch/x86/kernel/cpu/mcheck/mce.c | 38 -- 1 file changed, 28 insertions(+), 10 deletions(-) dif

[Patch V1] x86, mce: Don't clear global error reporting banks during cpu_offline

. - Consolidated some code to use sharing - Minor changes to some prototypes to fit usage. - Left handling same for non-Intel CPU models to avoid any unknown regressions. - Fixed review comments from Boris Signed-off-by: Ashok Raj <ashok@intel.com> Reviewed-by: Tony Luck <tony.l...@intel.co

[Patch V1] x86, mce: CPU synchronization for broadcast MCE's is surprised by offline CPUs

rom CPUs logically offlined. - Ensure the offline CPU wil not be choosen as the rendezvous master CPU - Collect logs from the offline cpu and report them via rendezvous master. Signed-off-by: Ashok Raj <ashok@intel.com> Reviewed-by: Tony Luck <tony.l...@intel.com> --- arch/x86/ke

[Patch V1 2/3] x86, mce: Refactor parts of mce_log() to reuse when logging from offline CPUs

Simply refactoring part of mce_log() to facilitate logging from offline CPUs. Signed-off-by: Ashok Raj <ashok@intel.com> Reviewed-by: Tony Luck <tony.l...@intel.com> --- arch/x86/kernel/cpu/mcheck/mce.c | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-)

[Patch V1 1/3] x86, mce: MCE log size not enough for high core parts

with some fudge to grow in future. Signed-off-by: Ashok Raj <ashok@intel.com> Suggested-by: Tony Luck <tony.l...@intel.com> --- arch/x86/include/asm/mce.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h index 2dbc

[Patch V1 3/3] x86, mce: Account for offline CPUs during MCE rendezvous.

CPU - Collect logs from the offline cpu and report them via rendezvous master. Signed-off-by: Ashok Raj <ashok@intel.com> Reviewed-by: Tony Luck <tony.l...@intel.com> --- arch/x86/kernel/cpu/mcheck/mce.c | 32 ++-- 1 file changed, 26 insertions(+), 6 del

[Patch V0] This patch adds some support required for KVM in order to support LMCE.

lt;tony.l...@intel.com> Tested-by: Gong Chen <gong.c...@intel.com> Signed-off-by: Ashok Raj <ashok@intel.com> --- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/vmx.c | 26 +- arch/x86/kvm/x86.c | 17 - 3 files chan

[Patch V2] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

art would only wait for all online_cpus. So offline cpu's should avoid participating in the rendezvous process. Reviewed-by: Tony Luck <tony.l...@intel.com> Cc: sta...@vger.kernel.org Signed-off-by: Ashok Raj <ashok@intel.com> --- arch/x86/kernel/cpu/mcheck/mce.c | 13 +

[Patch V1] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

art would only wait for all online_cpus. So offline cpu's should avoid participating in the rendezvous process. Reviewed-by: Tony Luck <tony.l...@intel.com> Cc: sta...@vger.kernel.org Signed-off-by: Ashok Raj <ashok@intel.com> --- arch/x86/kernel/cpu/mcheck/mce.c | 15

[Patch V0] x86, mce: Ensure offline CPU's don't participate in mce rendezvous process.

art would wait for all online_cpus. So offline cpu's should avoid participating in the rendezvous process. Reviewed-by: Tony Luck <tony.l...@intel.com> Signed-off-by: Ashok Raj <ashok@intel.com> --- arch/x86/kernel/cpu/mcheck/mce.c | 11 ++- 1 file changed, 10 insertions

[Patch V2 1/2] x86,mce: Basic support to add LMCE support to QEMU

opted in to Local delivery. Signed-off-by: Ashok Raj <ashok@intel.com> Tested-by: Gong Chen <gong.c...@intel.com> --- Resending with proper commit message for second patch target-i386/cpu.c | 8 target-i386/cpu.h | 8 ++-- target-i38

[Patch V2 2/2] x86, mce: Need to translate GPA to HPA to inject error in guest.

From: Gong Chen When we need to test error injection to a specific address using EINJ, there needs to be a way to translate GPA to HPA. This will allow host EINJ to inject error to test how guest behavior is when a bad address is consumed. This permits guest OS to perform

[PATCH 1/2] iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu

oodhouse <dw...@infradead.org> Cc: io...@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Cc: sta...@vger.kernel.org Cc: CQ Tang <cq.t...@intel.com> Cc: Ashok Raj <ashok@intel.com> Fixes: 2f26e0a9 ("iommu/vt-d: Add basic SVM PASID support") Signed-off-by: CQ Tang

[PATCH 2/2] iommu/vt-d: tylersburg isoch identity map check is done too late.

.org Cc: sta...@vger.kernel.org Cc: Ashok Raj <ashok@intel.com> Fixes: 86080ccc22 ("iommu/vt-d: Allocate si_domain in init_dmars()") Signed-off-by: Ashok Raj <ashok@intel.com> Reported-by: Yunhong Jiang <yunhong.ji...@intel.com> --- drivers/iommu/intel-iommu.c | 3

[PATCH 1/2] iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu

oodhouse <dw...@infradead.org> Cc: io...@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Cc: sta...@vger.kernel.org Cc: CQ Tang <cq.t...@intel.com> Cc: Ashok Raj <ashok@intel.com> Signed-off-by: CQ Tang <cq.t...@intel.com> Signed-off-by: Ashok Raj <ashok.

[PATCH 2/2] iommu/vt-d: tylersburg isoch identity map check is done too late.

.org Cc: sta...@vger.kernel.org Cc: Ashok Raj <ashok@intel.com> Signed-off-by: Ashok Raj <ashok@intel.com> Reported-by: Yunhong Jiang <yunhong.ji...@intel.com> --- drivers/iommu/intel-iommu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel

[PATCH 1/2] iommu/vt-d: Fix some macros that are incorrectly specified in intel-iommu

oodhouse <dw...@infradead.org> Cc: io...@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Cc: sta...@vger.kernel.org Cc: CQ Tang <cq.t...@intel.com> Cc: Ashok Raj <ashok@intel.com> Signed-off-by: CQ Tang <cq.t...@intel.com> Signed-off-by: Ashok Raj <ashok.

[PATCH 2/2] iommu/vt-d: tylersburg isoch identity map check is done too late.

.org Cc: sta...@vger.kernel.org Cc: Ashok Raj <ashok@intel.com> Signed-off-by: Ashok Raj <ashok@intel.com> Reported-by: Yunhong Jiang <yunhong.ji...@intel.com> --- drivers/iommu/intel-iommu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel

[PATCH] iommu/vt-d: Fix IOMMU lookup for VF's

;dw...@infradead.org> Cc: Joerg Roedel <j...@8bytes.org> Cc: Ashok Raj <ashok@intel.com> Cc: Sainath Grandhi <sainath.gran...@intel.com> Cc: io...@lists.linux-foundation.org Cc: sta...@vger.kernel.org Signed-off-by: Sainath Grandhi <sainath.gran...@intel.com> Signed-off-by:

[PATCH 0/3] Fix improper handling of pcie hotplug events.

This patch series fixes pciehp for certain special conditions observed during testing. Ashok Raj (3): pciehp: Prioritize data-link event over presence detect pciehp: Fix led status when enabling already enabled slot. pciehp: Fix race condition handling surprise link-down drivers/pci

[PATCH 3/3] pciehp: Fix race condition handling surprise link-down

atch fixes that by setting the slot state only when the work to handle the power event is executing, protected by the hot plug mutex. Cc: linux-kernel@vger.kernel.org Cc: sta...@vger.kernel.org Signed-off-by: Ashok Raj <ashok@intel.com> Reviewed-by: Keith Busch <keith.bu...@intel.co

[PATCH 2/3] pciehp: Fix led status when enabling already enabled slot.

pciehp_configure_device determines the slot devices already exist. Cc: linux-kernel@vger.kernel.org Cc: sta...@vger.kernel.org Signed-off-by: Ashok Raj <ashok@intel.com> Reviewed-by: Keith Busch <keith.bu...@intel.com> --- drivers/pci/hotplug/pciehp_ctrl.c | 2 +- 1 file changed, 1 ins

[PATCH 1/3] pciehp: Prioritize data-link event over presence detect

stream bus, the link change event should take precedence over a present detect event. This patch skips checking the PDC status we handled a link event in the same handler. Cc: linux-kernel@vger.kernel.org Cc: sta...@vger.kernel.org Signed-off-by: Ashok Raj <ashok@intel.com> Reviewed-by:

  1   2   3   4   >