| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0
Keir Fraser wrote:
On 7/10/08 14:39, "Dave Anderson" <anderson@xxxxxxxxxx> wrote:
The patch looks OK. But just for sanity's sake, is it guaranteed that
the per_cpu data section will be greater than 4k on both architectures?
Or could there be some combination of xen CONFIG options that could
reduce the i386 per_cpu data section contents to less than 4K even though
PERCPU_SHIFT is 13?
PERCPU_SHIFT has only ever been 12 or 13 so far, and it's unlikely to ever
get smaller. Ongoing, we could help you out by defining some useful label in
our linker script. For example, __per_cpu_shift = PERCPU_SHIFT (or
'__per_cpu_start + PERCPU_SHIFT', as I'm not sure about creating labels
outside the virtual address ranges defined by the object file).
-- Keir
Yep, that's fine too, but for now Oda-san's patch will suffice now as
long as the smallest possible percpu data section on the x86 arch with
a PERCPU_SHIFT of 13 will always overflow into a space greater than 4k.
So I'm still curious, because I note that on a RHEL5 x86_64 hypervisor
the per-cpu data space is 1576 bytes, and presumably smaller on an x86.
Was there a new data structure that forced the issue? And does it force
the issue on both arches?
Dave
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home