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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

"Familiar booting environment"? I knew of EFI's much earlier than
I saw grub for the first time, so to me EFI's is more familiar if you
so will.

> Furthermore, it offers common management of /boot in the dom0 filesystem
> between legacy and EFI boots.

Which is an argument for porting suitable file system drivers to EFI,
not an argument to layer multiple boot loaders. Plus booting _is_
(naturally) different between platforms. Plus if EFI was ported to
architectures of interest (see ARM), the difference between
platforms would decrease too (which btw was one of the original
goals of EFI). Are you btw saying that ARM should use grub2 too?
I didn't hear that mentioned as a goal anywhere so far...

> Therefore I am very much +1 get grub working.

Then you kind of misunderstood: I'm not against getting grub2
working (i.e. patches prior to this one are fine in principle). What
I'm against is hacking around firmware+grub2 combinations not
suitable for Xen's purposes (where one could argue which of the
three is really at fault, and I'm far from convinced it's Xen).

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel