just for curious: what is recursive pml4 mapping, found from freebsd pmap.h
also, freebsd only have a page of PML4 entries, about 4K/64=64 entries, not all 512 (2**9). On 10/16/07, Yonghong Yan <[EMAIL PROTECTED]> wrote: > Hi Matt, > > lots of things hang me around by the department open house. > thanks for your suggestions. some of them i am not fully understand, > but prefer to hold my questions until i see that it starting to > trouble me :). > > will start with the simple solution first and then move on to > something complicated. > > yyh > > On 10/12/07, Matthew Dillon <[EMAIL PROTECTED]> wrote: > > I should add a clarification regarding the per-cpu info. I think the > > distinction should be as a separate PML4 entry and not a PDP entry. > > This > > way the kernel can have a single PDP/PD hierarchy that is shared across > > all cpus. > > > > The per-cpu magic can be statically hardwired for each cpu via a PML4 > > entry and maybe a few other pages (per-cpu) creating a PDP/PD > > hierarchy. There are two ways to do it. > > > > (1) We can map a page containing the address of the per-cpu globaldata > > structure and use %fs in the trap code: > > > > movq $SOME_FIXED_CONSTANT_ADDRESS,%fs > > > > (2) We can map the actual per-cpu globaldata to a fixed address and > > access > > it directly. > > > > Either way will work. I will note that the system code expects 'mycpu' > > to be a variable kernel space address representing the location of the > > globaldata structure in kernel space and it will get confusde if > > 'mycpu' returns the same fixed address on every cpu. So the %fs method > > may be the best way to go so we don't have to run through all the system > > code changing the expectations for 'mycpu'. > > > > -Matt > > >
