Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932104AbVKWRDJ (ORCPT ); Wed, 23 Nov 2005 12:03:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932107AbVKWRDJ (ORCPT ); Wed, 23 Nov 2005 12:03:09 -0500 Received: from smtp.osdl.org ([65.172.181.4]:55992 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S932104AbVKWRDG (ORCPT ); Wed, 23 Nov 2005 12:03:06 -0500 Date: Wed, 23 Nov 2005 09:02:31 -0800 (PST) From: Linus Torvalds To: Alan Cox cc: Andi Kleen , Gerd Knorr , Dave Jones , Zachary Amsden , Pavel Machek , Andrew Morton , Linux Kernel Mailing List , "H. Peter Anvin" , Zwane Mwaikambo , Pratap Subrahmanyam , Christopher Li , "Eric W. Biederman" , Ingo Molnar Subject: Re: [patch] SMP alternatives In-Reply-To: <1132766489.7268.71.camel@localhost.localdomain> Message-ID: References: <4378A7F3.9070704@suse.de> <4379ECC1.20005@suse.de> <437A0649.7010702@suse.de> <437B5A83.8090808@suse.de> <438359D7.7090308@suse.de> <1132764133.7268.51.camel@localhost.localdomain> <20051123163906.GF20775@brahms.suse.de> <1132766489.7268.71.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1501 Lines: 34 On Wed, 23 Nov 2005, Alan Cox wrote: > > The MSR bits will break things like ECC scrubbing however. That can be > addressed although the test patch I have just refuses to load EDAC if > the BIOS writers didn't follow the BIOS guidelines. > > Certainly it would be cleaner and easier to save the MSR, scrub and put > it back than do the fixup magic. Some drivers would need auditing as > they seem to use locked ops or xchg (implicit lock) to lock with a PCI > DMA master. What I suggested to Intel at the Developer Days is to have a MSR (or, better yet, a bit in the page table pointer %cr0) that disables "lock" in _user_ space. Ie a lock would be a no-op when in CPL3, and only with certain processes. The kernel really isn't that critical. We always need the locks in SMP (unlike user space, which never needs them if the process isn't threaded), and in the kernel space we occasionally need it even with UP to protect against devices. And we _can_ do these instruction rewrites, and they are even pretty trivial for the non-hotplug case. User space is actually a lot more important. People spend more time in user space, and there the lock prefix is much more often totally useless and cannot just be edited away once per boot. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/