From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZV1ZI-0005ro-1Z for mharc-grub-devel@gnu.org; Thu, 27 Aug 2015 14:06:32 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV1ZG-0005rP-7J for grub-devel@gnu.org; Thu, 27 Aug 2015 14:06:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZV1ZD-0008LN-0i for grub-devel@gnu.org; Thu, 27 Aug 2015 14:06:30 -0400 Received: from smtp.citrix.com ([66.165.176.89]:31748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZV1ZC-0008Kd-Pu for grub-devel@gnu.org; Thu, 27 Aug 2015 14:06:26 -0400 X-IronPort-AV: E=Sophos;i="5.17,422,1437436800"; d="scan'208";a="295283850" Message-ID: <55DF5125.20708@citrix.com> Date: Thu, 27 Aug 2015 19:04:21 +0100 From: Andrew Cooper User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Jan Beulich , Daniel Kiper Subject: Re: [PATCH v2 22/23] x86: make Xen early boot code relocatable 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> In-Reply-To: <55DF48FB020000780009D83F@prv-mh.provo.novell.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 66.165.176.89 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 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 18:06:31 -0000 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