From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v2 22/23] x86: make Xen early boot code relocatable Date: Fri, 28 Aug 2015 08:16:05 -0600 Message-ID: <55E08945020000780009DD90@prv-mh.provo.novell.com> References: <1437402558-7313-1-git-send-email-daniel.kiper@oracle.com> <1437402558-7313-23-git-send-email-daniel.kiper@oracle.com> <55DF28E6020000780009D6E4@prv-mh.provo.novell.com> <20150827151054.GI10944@olila.local.net-space.pl> <55DF48FB020000780009D83F@prv-mh.provo.novell.com> <55E03676020000780009DAFB@prv-mh.provo.novell.com> <20150828134214.GC2412@l.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZVKRv-0005RQ-2l for xen-devel@lists.xenproject.org; Fri, 28 Aug 2015 14:16:11 +0000 In-Reply-To: <20150828134214.GC2412@l.oracle.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk Cc: Juergen Gross , The development of GNU GRUB , wei.liu2@citrix.com, Ian Campbell , Stefano Stabellini , andrew.cooper3@citrix.com, Daniel Kiper , ning.sun@intel.com, Roy Franz , Ben Hildred <42656e@gmail.com>, david.vrabel@citrix.com, Vladimir Serbinenko , xen-devel@lists.xenproject.org, qiaowei.ren@intel.com, keir@xen.org, richard.l.maliszewski@intel.com, gang.wei@intel.com, Fu Wei List-Id: xen-devel@lists.xenproject.org >>> On 28.08.15 at 15:42, wrote: > And I am not comfortable to say 'GRUB2+Xen cannot run on this hardware > because your firmware vendor is not following the EFI spec in spirit.' Well, not the least since I don't really agree with this (albeit I can see where you're coming from) ... > Now that said - do you have suggestions on how to make this work > with GRUB in the picture? ... I don't think I'm the one to make suggestions on how to make things work with grub in the picture when I continue to be of the opinion that it shouldn't have been brought into the picture in the first place. But for the purely technical (patch) aspect: Anything (e.g. macroization such that at least some sym_phys() uses can remain untouched) allowing to limit the impact of said patch on the source code (thus helping review and perhaps also long term maintainability) would be a step towards talking me into withdrawing my objection. Jan