Re: [Xen-devel] KEXEC: fix kexec_get_range_compat to fail vocally

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/12/11 13:18, Jan Beulich wrote:
>>>> On 05.12.11 at 14:01, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 05/12/11 12:58, Jan Beulich wrote:
>>> Both under the assumption that apart from the truncation nothing
>>> prevents addresses above the 4G boundary from being usable with
>>> a 32-bit kernel for at least one of the ranges (probably only
>>> KEXEC_RANGE_MA_CPU and KEXEC_RANGE_MA_VMCOREINFO are
>>> candidates for this on x86).
>> Will those ranges not be covered by my patch?
> That wasn't the question. My point was that your change and the new
> sub-hypercall are useful only if any of these ranges can validly live
> above 4G (i.e. if we don't need to instead constrain the allocations).
>
> Jan

Ah ok - I misunderstood.  As part of my planned changes to the kexec
path, there will be a command line parameter to request all kexec
related allocs are below a specified address.  My intention is that this
would typically be set to either 64GB if you use a 32bit PAE crash
kernel, or 4G for using a 32bit non-PAE kernel.  Certain other
allocations which would be covered by this parameter would be the
console ring, so the crash kernel can pull it out of memory and dump it
to disk.

We need this functionality for XenServer as we use a 32bit PAE crash
kernel, but it does have an impact on how many 32bit PV guests you can
boot on a large memory machine.  At the moment, there is a hack^H "fix"
from before my time in the XS patch queue to allocate crash notes in
Xen's BSS so it falls into the Xen mapped region of dom0 memory, but has
the problem of needing all the notes to be compile time constant
lengths, which reduces flexibility.  (It was also to work around an old
bug in kexec tools where it would consider the "Crash Notes" invalid if
they were not explicitly in a System Ram section - this appears fixed now.)

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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