Rusty Russell wrote:
>> So are symbols referencing the .data.percpu section 0-based? Wouldn't
>> you need to subtract __per_cpu_start from the symbols to get a 0-based
>> segment offset?
>>
>
> I don't think I understand the question.
>
> The .data.percpu section is the "template" per-cpu section, freed along
> with other initdata: after setup_percpu_areas() is called, it is not
> supposed to be used. Around that time, the gs segment is set up based
> at __per_cpu_offset[cpu], so "%gs:<varname>" accesses the local version.
>
If you do
DEFINE_PER_CPU(int, foo);
then this ends up defining per_cpu__foo in .data.percpu. Since
.data.percpu is part of the init data section, it starts at some address
X (not 0), so the real offset into the actual per-cpu memory is actually
(per_cpu__foo - __per_cpu_start). setup_per_cpu_areas() builds this
delta into the __per_cpu_offset[], and so it means that the base of your
%gs segment is at -__per_cpu_start from the actual start of the CPU's
per-cpu memory, and the limit has to be correspondingly larger. Which
is a bit ugly. Especially since "__per_cpu_start" is actually very
large, and so this scheme pretty much relies on being able to wrap
around the segment limit, and will be very bad for Xen.
An alternative is to put the "-__per_cpu_start" into the addressing mode
when constructing the address of the per-cpu variable.
J
