pmap of amd64
Yonghong Yan
noah.yan at gmail.com
Tue Oct 16 14:46:11 PDT 2007
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 at 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
>
More information about the Kernel
mailing list