Xen project Mailing List

On Thu, Aug 27, 2015 at 9:29 AM, Jan Beulich <JBeulich@xxxxxxxx> 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).

If you advocate direct booting ( no boot loader) Âon production machines I wont argue much, as long as there is good recovery tools to deal with failed boots (grub does this very well, I am not aware of anything comparable that is pure efi). however the other use case which care more about is dual booting. I am a novice when it comes to Xen, although otherwise competent. The test machines I have for playing with Xen are also used for other tests, some of which require raw hardware support, so I want the ability to use a boot menu. I am aware of refit, but it does not have serial support which makes automating testing more difficult. and I have not yet got ipxe to successfully boot Xen (although this is purely because I have not yet devoted enough time to that project and I am not yet familiar with how Xen boots).

So no, I'm still not convinced of the need for this patch.

I am at a loss for alternatives. Yes grub on efi violates the spirit of efi. Propose a better way forward rather than deriding those who have found a successful, portable way around the limitations of efi implementations.Â

Jan

_______________________________________________
Grub-devel mailing list
Grub-devel@xxxxxxx
https://lists.gnu.org/mailman/listinfo/grub-devel

Ben Hildred

Automation Support Services

303 815 6721

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