Messages in this thread | | | Date | Wed, 23 Nov 2005 10:26:22 -0700 | From | "Jeff V. Merkey" <> | Subject | Re: [patch] SMP alternatives |
| |
Linus Torvalds wrote:
>On Wed, 23 Nov 2005, H. Peter Anvin wrote: > > >>Linus Torvalds wrote: >> >> >>>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. >>> >>> >>You mean %cr3, right? >> >> > >Yes. > >It _should_ be fairly easy to do something like that - just a simple >global flag that gets set and makes CPL3 ignore lock prefixes. Even timing >doesn't matter - it it takes a hundred cycles for the setting to take >effect, we don't care, since you can't write %cr3 from user space anyway, >and it will certainly take a hundred cycles (and a few serializing >instructions) until we get to CPL3. > >I'd personally prefer it to be in %cr3, since we'd have to reload it on >task switching, and that's one of the registers we load anyway. And it >would make sense. But it could be in an MSR too. > >Of course, if it's in one of the low 12 bits of %cr3, there would have to >be a "enable this bit" in %cr4 or something. Historically, you could write >any crap in the low bits, I think. > > 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/ > > > The lock prefix '0F' is used for a lot of opcodes other than "lock". Go check the instruction set reference. It's not trivial what you are proposing. Intel has a pretty hacked up opcode map with a lot of history. The bit should be in CR4 and not CR3.
J - 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/
| |