From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Kiper Subject: Re: [PATCH v2 22/23] x86: make Xen early boot code relocatable Date: Thu, 27 Aug 2015 17:10:54 +0200 Message-ID: <20150827151054.GI10944__34416.3939975717$1440688387$gmane$org@olila.local.net-space.pl> 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> 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 1ZUyph-0005In-R4 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2015 15:11:17 +0000 Content-Disposition: inline In-Reply-To: <55DF28E6020000780009D6E4@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 Cc: Juergen Gross , grub-devel@gnu.org, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, roy.franz@linaro.org, ning.sun@intel.com, david.vrabel@citrix.com, phcoder@gmail.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 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. So, I think that early Xen boot code should be relocatable. However, I agree that there is a chance that may solution is not perfect. So, I suppose, taking into account above, we should discuss how to improve it instead of discussing whether we should do it. Daniel