[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v7 08/14] x86: add multiboot2 protocol support for EFI platforms



On Wed, Sep 28, 2016 at 02:57:10AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 20:11, <daniel.kiper@xxxxxxxxxx> wrote:
> > On Mon, Sep 26, 2016 at 07:47:42AM -0600, Jan Beulich wrote:
> >> >>> On 23.09.16 at 23:47, <daniel.kiper@xxxxxxxxxx> wrote:
> >> > This way Xen can be loaded on EFI platforms using GRUB2 and
> >> > other boot loaders which support multiboot2 protocol.
> >> >
> >> > Signed-off-by: Daniel Kiper <daniel.kiper@xxxxxxxxxx>
> >> > Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
> >> > ---
> >> > v7 - suggestions/fixes:
> >> >    - do not allocate twice memory for trampoline if we were
> >> >      loaded via multiboot2 protocol on EFI platform,
> >>
> >> If you fix bugs not noticed by a reviewer but by yourself, please
> >> drop all acks/R-b-s covering the code in question. And then I'm
> >
> > OK.
> >
> >> afraid I haven't even been able to locate that change - could you
> >> please point out what you did where?
> >
> > The change is very subtle. I add trampoline_setup label behind
> >
> >          /* From arch/x86/smpboot.c: start_eip had better be page-aligned! 
> > */
> >          xor     %cl, %cl
> >
> > instead of
> >
> >          cmp     %ecx,%edx           /* compare with BDA value */
> >          cmovb   %edx,%ecx           /* and use the smaller */
>
> So how did you expect anyone having looked at previous version
> to spot that? Please, in your changes section, rather than
> tediously listing who suggested which change, please make that
> section useful for incremental reviews.

I think that in general it is useful, however, I can agree that
this thing could be described better.

> >> > +        /*
> >> > +         * Initialize BSS (no nasty surprises!).
> >> > +         * It must be done earlier than in BIOS case
> >> > +         * because efi_multiboot2() touches it.
> >> > +         */
> >> > +        lea     .startof.(.bss)(%rip),%edi
> >> > +        mov     $.sizeof.(.bss),%ecx
> >> > +        shr     $3,%ecx
> >> > +        xor     %eax,%eax
> >> > +        rep stosq
> >> > +
> >> > +        pop     %rdi
> >> > +
> >> > +        /*
> >> > +         * efi_multiboot2() is called according to System V AMD64 ABI:
> >> > +         *   - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> >> > +         *   - OUT: %rax - highest usable memory address below 1 MiB;
> >> > +         *                 memory above this address is reserved for 
> >> > trampoline;
> >> > +         *                 memory below this address is used for stack 
> >> > and as
> >> > +         *                 a storage for boot data.
> >>
> >> How can you validly use memory below this address? (And I'd like to
> >
> > Right, I should not do that blindly. As quick fix we can check in
> > efi_arch_process_memory_map()
> > that chosen memory region has size cfg.size plus let's say 64 KiB. Is it 
> > sufficient
> > for you?
>
> Depends. Part of my problem here is that you convert, in your answer,
> my "validly" to "blindly". And then I'd like to see especially "storage for

I am not sure why the difference, IMO minor, is important for you here.

> boot data" better qualified: What exactly is it that you mean to store
> there?

mbi struct created in reloc.c from original multiboot(2) data passed by boot 
loader.

> I don't recall having noticed either this or that area being used
> as stack anywhere in the series, so I'm afraid I've overlooked

Hmmm... I do not know why I put stack here. It should be dropped from comment.

Daniel

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.