DragonFly kernel List (threaded) for 2007-10
DragonFly BSD
DragonFly kernel List (threaded) for 2007-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: pmap of amd64


From: "Yonghong Yan" <noah.yan@xxxxxxxxx>
Date: Wed, 17 Oct 2007 16:37:43 -0500

Hi Matt,

just to make sure: when you talking about the globaldata, it is
per-cpu, not globaldata for the whole system, am I right?

is the CPU_prvspace in machine/globaldata.h the array to keep the
per-cpu globaldata?

More questions coming :)

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
>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]