From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2 22/23] x86: make Xen early boot code relocatable Date: Thu, 27 Aug 2015 19:04:21 +0100 Message-ID: <55DF5125.20708__16337.0521193885$1440698890$gmane$org@citrix.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> 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 1ZV1ZE-0000XL-Ci for xen-devel@lists.xenproject.org; Thu, 27 Aug 2015 18:06:28 +0000 In-Reply-To: <55DF48FB020000780009D83F@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 , Daniel Kiper Cc: Juergen Gross , grub-devel@gnu.org, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, phcoder@gmail.com, roy.franz@linaro.org, ning.sun@intel.com, david.vrabel@citrix.com, xen-devel@lists.xenproject.org, qiaowei.ren@intel.com, keir@xen.org, richard.l.maliszewski@intel.com, gang.wei@intel.com, fu.wei@linaro.org List-Id: xen-devel@lists.xenproject.org On 27/08/15 16:29, Jan Beulich wrote: >>>> On 27.08.15 at 17:10, wrote: >> On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote: >>>>>> On 20.07.15 at 16:29, wrote: >>>> /* Copy bootstrap trampoline to low memory, below 1MB. */ >>>> - mov $sym_phys(trampoline_start),%esi >>>> + lea sym_offset(trampoline_start)(%ebp),%esi >>>> mov $trampoline_end - trampoline_start,%ecx >>>> rep movsb >>>> >>> The latest at this final hunk I'm getting tired (and upset). I'd much >>> rather not touch all this code in these fragile ways, and instead >>> require Xen to be booted without grub2 on badly written firmware >>> like the one on the machine you quote in the description. >> Let's start discussion from here. My further work on this patch series >> is pointless until we do not agree details in this case. >> >> So, I agree that any software (including firmware) should not use >> precious resources (i.e. low memory in that case) if it is not strictly >> required. And I do not think so that latest UEFI implementations >> on new hardware really need this low memory to survive (at least page >> tables could be put anywhere above low memory). However, in case of >> UEFI it is a wish of smart people not requirement set by spec. I was >> checking UEFI docs a few times but I was not able to find anything >> which says that e.g. "...developer MUST allocate memory outside of low >> memory ...". Even I have not found any suggestion about that. However, >> I must admit that I do not know whole UEFI spec, so, if you know something >> which is similar to above please tell me where it is (title, revision, >> page, paragraph, etc.). Hence, if there is not strict requirement in >> regards to memory allocation in specs we are lost. Of course we can >> encourage people to not do nasty things but I do not believe that many >> will listen. So, sadly, I suppose that we will see more and more machines >> in the wild which are "broken" (well, let's say do not align to good >> practices). >> >> On the other hand I think that we should not assume that a given memory >> region (in our case starting at 1 MiB) is (or will be) available in every >> machine. I have not seen anything which says that it is true. We should >> stop doing that even if it works right now. I think that it works by >> chance and there is a chance that it will stop working one day because >> somebody will discover that he or she can put there e.g. device or hole. >> >> Last but not least. I suppose that Xen users and especially distros will >> complain when they are not able to use GRUB2 with Xen on every platform >> just because somebody (i.e. platform designers, developers, or whatever) >> do not accept our beliefs or we require that platform must obey rules >> (i.e. memory map requirements) which are specified nowhere. > You're right, there's no such requirement on memory use in the spec. > But you're missing the point. Supporting grub2 on UEFI is already a > hack (ignoring all intentions EFI had from its first days). And now > you've found an environment where that hack needs another hack > (in Xen) to actually work. That's too much hackery for my taste, the > more that things on this system can (afaict) work quite okay (without > grub2, or with using its chainloader mechanism). > > So no, I'm still not convinced of the need for this patch. I disagree. There are many things a grub environment gives us which plain EFI doesn't, most notably a familiar booting environment and recovery facilities for users (which vastly trumps how EFI expects to run things). Furthermore, it offers common management of /boot in the dom0 filesystem between legacy and EFI boots. Therefore I am very much +1 get grub working. ~Andrew