[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0


  • To: Dave Anderson <anderson@xxxxxxxxxx>, "Discussion list for crash utility usage, maintenance and development" <crash-utility@xxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Tue, 07 Oct 2008 14:55:00 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 07 Oct 2008 06:55:19 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AckohEoOiNelwJR3Ed2EcgAWy6hiGQ==
  • Thread-topic: [Xen-devel] Re: [Crash-utility] xencrash fixes for xen-3.3.0

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



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.