Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758220Ab1BKV7d (ORCPT ); Fri, 11 Feb 2011 16:59:33 -0500 Received: from mail-yi0-f46.google.com ([209.85.218.46]:61731 "EHLO mail-yi0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757938Ab1BKV7c convert rfc822-to-8bit (ORCPT ); Fri, 11 Feb 2011 16:59:32 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YjA3unkxHCUrXNd3X5TzyWJHn0kvNRgLfUZWW06up0UU3RQGAUjEt6KQCf+/XrqDT6 8z8e1h1IDCUKxhWuagC6RmrqnBHIDIGftEC1PRf8dY08ONf9AaGKAZSWLZUMCxYtH84p jqz3XoPPfyL7iuj/EiS1FYyKSYLVD+UuULmMc= MIME-Version: 1.0 In-Reply-To: <20110211204030.GD2010@jolsa.brq.redhat.com> References: <1297432830-3912-1-git-send-email-jolsa@redhat.com> <20110211170722.GA2010@jolsa.brq.redhat.com> <20110211191359.GC2010@jolsa.brq.redhat.com> <20110211204030.GD2010@jolsa.brq.redhat.com> Date: Fri, 11 Feb 2011 16:59:31 -0500 Message-ID: Subject: Re: [PATCH] x86_64: disable identity mappings statically From: Brian Gerst To: Jiri Olsa Cc: x86@kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3936 Lines: 97 On Fri, Feb 11, 2011 at 3:40 PM, Jiri Olsa wrote: > On Fri, Feb 11, 2011 at 03:19:11PM -0500, Brian Gerst wrote: >> On Fri, Feb 11, 2011 at 2:13 PM, Jiri Olsa wrote: >> > On Fri, Feb 11, 2011 at 12:59:47PM -0500, Brian Gerst wrote: >> >> On Fri, Feb 11, 2011 at 12:07 PM, Jiri Olsa wrote: >> >> > On Fri, Feb 11, 2011 at 08:46:41AM -0800, Eric W. Biederman wrote: >> >> >> Jiri Olsa writes: >> >> >> >> >> >> > hi, >> >> >> > >> >> >> > while browsing the page table setup code, I noticed the x86_64 head >> >> >> > code might not need the identity mappings at all. >> >> >> > It seems it's ok to switch it off completely from the begining, >> >> >> > unless I'm missing something. >> >> >> >> >> >> Have you tested it? >> >> > >> >> > yes, I booted it with no problem >> >> >> >> The only reason this doesn't crash is because the identity mappings >> >> provided by the boot code are marked as global, and therefore might >> >> not be flushed by simply loading cr3.  The cpu can evict TLB entries >> >> at any time though, so it's a bad idea to run without the identity >> >> mappings even for the brief moment before jumping to the virtual >> >> address. >> > >> > I added code for flushing whole TLB (including global pages) and it >> > still boots (attached). >> > >> > I'm sorry if I'm missing something obvious (probably the TLB flushing >> > code is wrong), but I'd like to understand this part. >> > >> > What instruction/action would require the identity mapping, >> > after the page table is set? >> > >> > thanks (and again sry for noise :) ) >> > jirka >> > >> > >> > --- >> > diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S >> > index c55e6fa..073f489 100644 >> > --- a/arch/x86/kernel/head_64.S >> > +++ b/arch/x86/kernel/head_64.S >> > @@ -165,6 +165,13 @@ ENTRY(secondary_startup_64) >> >        movl    $(X86_CR4_PAE | X86_CR4_PGE), %eax >> >        movq    %rax, %cr4 >> > >> > +       /* invalidate whole TLB */ >> > +       movq %cr4, %rax >> > +       movq %rax, %rdx >> > +       andq $~X86_CR4_PGE, %rax >> > +       movq %rax, %cr4 >> > +       movq %rdx, %cr4 >> > + >> >        /* Setup early boot stage 4 level pagetables. */ >> >        movq    $(init_level4_pgt - __START_KERNEL_map), %rax >> >        addq    phys_base(%rip), %rax >> > >> >> The way you have it, it will immediately reload the global identity >> entry into the TLB when it executes the next instruction, because cr3 >> is still pointing to the old pagetables.  Disable PGE during or >> immediately after the load of cr3 to make sure the global identity >> entries are flushed. > > you're right, when I put it after setting cr3 it crashed > but I still don't understand what instruction took it down..? The instruction immediately following the flush (doesn't matter what it is). You flushed the entry for the page you were executing from, so the cpu has to reload the entry for that page so that it can fetch the next instruction. Since that page doesn't exist in the new page table, it crashes. Getting back to the original patch. Here is the relevant text from the Intel System Programming Guide: ------------------------------ 4.10.4.1 Operations that Invalidate TLBs and Paging-Structure Caches ... The processor is always free to invalidate additional entries in the TLBs and paging-structure caches. The following are some examples: ... MOV to CR3 may invalidate TLB entries for global pages. ------------------------------ So even if it just so happens to work on your particular cpu, it is not guaranteed to always work. -- Brian Gerst -- 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/