lkml.org 
[lkml]   [2009]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: unified percpu stuff
From
On Tue, Jan 27, 2009 at 12:50 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Brian Gerst wrote:
>>>
>>> BTW, does the initial cpu0 percpu area get reallocated and moved during
>>> boot, or does cpu0 keep using the same memory forever?
>>>
>>
>> It is reallocated in setup_per_cpu_areas().
>>
>
> Hm, OK. What's the reason we need to move cpu 0's percpu area? Its always
> seemed a bit awkward.
>
> Once it has been moved, how can I find the address of a variable in the
> original boot-time cpu 0 percpu area? There's a couple of pages which Xen
> will have marked RO which need to be made RW if they're being freed back
> into the kernel pool. Currently I use per_cpu_var(gdt_page), but guess
> that's a small offset rather than a directly usable address.

The fact that the boot cpu area is moved isn't new. It's been that
way for a while. The reason it is moved is so that extra space can be
allocated at the end for dynamic allocations. It looks like Xen just
avoided it by not loading the per-cpu GDT until after the copy. I
guess you could get by without reloading the GDT, but you would still
need to set MSR_GS_BASE for 64-bit. 32-bit happens to work because
%fs is probably initialized to the same segment as %ds. If 32-bit
were ever to switch to zero-based per-cpu like 64-bit, that assumption
would fail.

You need to add __per_cpu_load to the offset to get the address of the
variable in the original boot per-cpu area.

--
Brian Gerst


\
 
 \ /
  Last update: 2009-01-27 20:11    [W:0.052 / U:0.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site