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

[Ben Hildred <42656e@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4829 bytes --]

On Thu, Aug 27, 2015 at 9:29 AM, Jan Beulich <JBeulich@suse.com> 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).
>
> 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@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
--
Ben Hildred
Automation Support Services
303 815 6721

[-- Attachment #1.2: Type: text/html, Size: 6430 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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