Re: [PATCH v2 22/23] x86: make Xen early boot code relocatable

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 27/08/15 16:29, Jan Beulich wrote:
>>>> On 27.08.15 at 17:10, <daniel.kiper@oracle.com> wrote:
>> On Thu, Aug 27, 2015 at 07:12:38AM -0600, Jan Beulich wrote:
>>>>>> On 20.07.15 at 16:29, <daniel.kiper@oracle.com> 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