All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: KEXEC: fix kexec_get_range_compat to fail vocally
Date: Mon, 5 Dec 2011 13:39:42 +0000	[thread overview]
Message-ID: <4EDCC99E.4010401@citrix.com> (raw)
In-Reply-To: <4EDCD29F02000078000656D5@nat28.tlf.novell.com>

On 05/12/11 13:18, Jan Beulich wrote:
>>>> On 05.12.11 at 14:01, Andrew Cooper <andrew.cooper3@citrix.com> 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

  reply	other threads:[~2011-12-05 13:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-05 11:35 KEXEC: fix kexec_get_range_compat to fail vocally Andrew Cooper
2011-12-05 12:58 ` Jan Beulich
2011-12-05 13:01   ` Andrew Cooper
2011-12-05 13:18     ` Jan Beulich
2011-12-05 13:39       ` Andrew Cooper [this message]
2011-12-05 19:46 ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EDCC99E.4010401@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.