From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86: wrap kexec feature with CONFIG_KEXEC Date: Tue, 1 Sep 2015 11:59:04 +0100 Message-ID: <55E584F8.2030304@citrix.com> References: <1440686870-19104-1-git-send-email-jonathan.creekmore@gmail.com> <55DF2C57.8030100@citrix.com> <1441103777.27618.31.camel@citrix.com> <55E58171.80509@citrix.com> <55E5A017020000780009E87E@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZWjHR-0007P5-2I for xen-devel@lists.xenproject.org; Tue, 01 Sep 2015 10:59:09 +0000 In-Reply-To: <55E5A017020000780009E87E@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Ian Campbell Cc: Jonathan Creekmore , keir@xen.org, David Vrabel , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 01/09/15 11:54, Jan Beulich wrote: >>>> On 01.09.15 at 12:44, wrote: >> On 01/09/15 11:36, Ian Campbell wrote: >>> In general (i.e. not 100% consistently, I think) we have tended to avoid >>> making things user-facing compile time options. Many of the existing >>> CONFIG_* and HAVE_* are really about things which are arch dependent, or >>> require specific porting to each arch etc. I think the KEXEC flag is one of >>> those. >>> >>> This keeps the test matrix more reasonable (unlike e.g. Linux's Kconfig) >>> and also helps us by ensuring that users are mostly running one of a small >>> number of possible configs. >>> >>> I slightly fear that after Kexec you are going to want to strip out more >>> and more stuff... >> I for one welcome a Kconfig style approach. We will never be in the >> same order of magnitude of options as Linux, and it will help to >> properly modularise the code. > Indeed the idea was brought up a few times already, and I would > also welcome such a step (accepting the downside of the larger > test matrix). Not the least considering the "no shadow mode" and > "big memory" build options that got introduced not so long ago. >>From a large attack surface point of view, support for 32bit ABI on 64bit Xen is a welcome candidate for more controlled environments. >>From a code volume point of view, having things like PV or support configurable would be interesting. ~Andrew