Messages in this thread | | | Date | Wed, 04 Jun 2008 07:17:03 -0700 | From | Mike Travis <> | Subject | Re: [PATCH 3/4] x86_64: Fold pda into per cpu area |
| |
Jeremy Fitzhardinge wrote: > Mike Travis wrote: >> Jeremy Fitzhardinge wrote: >> >>> Mike Travis wrote: >>> >>>> * Declare the pda as a per cpu variable. >>>> >>>> * Make the x86_64 per cpu area start at zero. >>>> >>>> * Since the pda is now the first element of the per_cpu area, >>>> cpu_pda() >>>> is no longer needed and per_cpu() can be used instead. This also >>>> makes >>>> the _cpu_pda[] table obsolete. >>>> >>>> * Since %gs is pointing to the pda, it will then also point to the >>>> per cpu >>>> variables and can be accessed thusly: >>>> >>>> %gs:[&per_cpu_xxxx - __per_cpu_start] >>>> >>>> >> >> The above is only a partial story (I folded the two patches but didn't >> update the comments correctly.] The variables are already offset from >> __per_cpu_start by virtue of the .data.percpu section being based at >> zero. Therefore only the %gs register needs to be set to the base of >> each cpu's percpu section to resolve the target address: >> >> %gs:&per_cpu_xxxx >> > > Oh, good. I'd played with trying to make that work at one point, and > got lost in linker bugs and/or random version-specific strangeness. > J
Incidentally, this is why the following load is needed in x86_64_start_kernel():
pda = (struct x8664_pda *)__per_cpu_load; pda->data_offset = per_cpu_offset(0) = (unsigned long)pda;
/* initialize boot cpu_pda data */ pda_init(0);
pda_init() loads the %gs reg so early accesses to the static per_cpu section can be executed before the percpu areas are allocated.
| |