Re: pmap of amd64

["Yonghong Yan" <noah.yan@xxxxxxxxx>]

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 <noah.yan@gmail.com> 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 <dillon@apollo.backplane.com> 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
> >
>