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

["Jan Beulich" <JBeulich@suse.com>]

>>> 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.

Jan