[lkml]   [2008]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 3/7] x86, cpa: make the kernel physical mapping initialization a two pass sequence
    Suresh Siddha wrote:
    > Jeremy, hi. This dependency is not documented or explicitly called anywhere
    > in the mm/init_64.c code. I would have expected to see a big comment near this
    > kind of code :(

    Indeed yes. I've explained it in various places, including commit
    comments, but there should be a comment right there in the code.

    > It is not just the NX bit that we change. For DEBUG_PAGEALLOC, we want
    > use 4k pages instead of large page mappings during the identity mapping
    > (as this will clean some of the cpa pool code avoiding the cpa and hence
    > the page allocations for splitting the big pages from interrupt context's).
    > In this case will will split the static large page mappings.

    Well, that's OK. We just need to preserve the original page permissions
    when fragmenting the large mappings. (This isn't a case that affects
    Xen, because it will already be 4k mappings.)

    >> 3. The actual implementation is pretty ugly; adding a global variable
    >> and hopping about with goto does not improve this code.
    > This is very early init code and I can't be fancy like calling cpa()
    > which need mm to be up and running.

    Well, is there any urgency to set NX that early? It might catch some
    early bugs, but there's no urgent need.

    > And also, cpa's on individual chunks
    > for entire identity mapping will make the boot slow.

    Really? Why? How slow?

    >> it cause real failures? Could we revert this patch and address the
    >> problem some other way? Which app note is this, BTW? The one I have on
    >> hand, "TLBs, Paging-Structure Caches, and Their Invalidation", Apr 2007,
    >> does not seem to mention this restriction.
    > Section 6 page 26

    Ah, OK. I have the first version of this document which does not
    mention this. It would be good to explicitly cite this document by name
    in the comments.

    >> Xen with this code in place (touching this code is always non-trivial).
    >> I haven't looked into it in depth yet, but there's a few stand out "bad
    >> for Xen" pieces of code here. (And I haven't tested 32-bit yet.)
    >> Quick rules for keeping Xen happy here:
    >> 1. Xen provides its own initial pagetable; the head_64.S one is
    >> unused when booting under Xen.
    >> 2. Xen requires that any pagetable page must always be mapped RO, so
    >> we're careful to not replace an existing mapping with a new one,
    >> in case the existing mapping is a pagetable one.
    >> 3. Xen never uses large pages, and the hypervisor will fail any
    >> attempt to do so.
    > Thanks for this info. Will get back to you tomorrow.

    Great. Also, do you think you'll have a chance to look at unifying the
    32 and 64 bit code (where 32 uses the 64-bit version)?


     \ /
      Last update: 2008-10-07 17:31    [W:0.024 / U:1.552 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site