All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Lingzhu Xiang <lxiang@redhat.com>,
	kexec@lists.infradead.org, Simon Horman <horms@verge.net.au>,
	"Suzuki K. Poulose" <suzuki@in.ibm.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Jeremy Kerr <jk@ozlabs.org>
Subject: Re: [PATCH] ppc/ppc64: Compile purgatory code with gcc option -msoft-float
Date: Fri, 8 Jun 2012 11:19:36 -0400	[thread overview]
Message-ID: <20120608151936.GE29471@redhat.com> (raw)
In-Reply-To: <20120608145113.GB24904@tucnak.redhat.com>

On Fri, Jun 08, 2012 at 04:51:13PM +0200, Jakub Jelinek wrote:
> On Fri, Jun 08, 2012 at 10:39:49AM -0400, Vivek Goyal wrote:
> > BTW, What does -mcmodel do and why should we use -mcmodel? purgatory, is a
> > separate binary which we reloate at turn time based on physical memory
> > location. IOW, why should we make any assumptions about running location
> > of purgatory and pass -mcmodel flag.
> 
> The default x86_64 -mcmodel=small requires that the binary (and all
> corresponding data (rodata etc.) sections must be within the low 2GB of
> address space.  Kernel code is usually in the topmost 2GB of address space,
> and -mcmodel=kernel is the memory model for that (all code and all other
> sections must be in topmost 2GB of address space).  Of course pointers
> are 64-bit in both cases, so any memory you access solely through pointers,
> not through symbols, can be anywhere.  Haven't looked at where purgatory
> relocates itself into the address space.

IIRC, by the time purgatory runs we turn the paging off and we are
operating in protected mode. And by that time purgatory is running from
low 2GB of address space.

It is relocated by kexec-tools itself before it calls kernel. So in
user space we decide a physical address where purgatory can be run
from. Relocate this binary so that it can run from that address and
then call kernel to load this binary at this address. (Kernel might
store the binary at some other location but it is moved to it final
destination just before kexec and just before we jump to it).

Relocation happens here.

kexec-tools/kexec/arch/i386/kexec-bzImage.c

***********************************************************************

        /* Load the trampoline.  This must load at a higher address
         * the the argument/parameter segment or the kernel will stomp
         * it's gdt.
         *
         * x86_64 purgatory code has got relocations type R_X86_64_32S
         * that means purgatory got to be loaded within first 2G otherwise
         * overflow takes place while applying relocations.
         */
        if (!real_mode_entry && relocatable_kernel)
                elf_rel_build_load(info, &info->rhdr, purgatory,
purgatory_size,
                                        0x3000, 0x7fffffff, -1, 0);
        else
                elf_rel_build_load(info, &info->rhdr, purgatory,
purgatory_size,
                                        0x3000, 640*1024, -1, 0);
        dbgprintf("Loaded purgatory at addr 0x%lx\n",
info->rhdr.rel_addr);

*************************************************************************

So at this point of time, it does not look like that we should be passing
-mcmodel for purgatory code.

> 
> -mno-sse -mno-mmx will tell gcc not to use any %mmX or %xmmX registers.
> i?86 also passes -msoft-float in addition to -mno-sse -mno-mmx I think.
> 

Yes, i386 is also passing -msoft-float in kernel. Personally I have no
issues in adding -mno-sse and -mno-mmx and -msoft-float for i386. It is
that kind of thing that one gets the motivation to change these flags
once something breaks down.

[..]
> > > hash computation unconditionally everywhere at -O0 must IMHO pessimize
> > > things unnecessarily.
> > 
> > git blame points to following commit for forcing -O0 on sha256. CCing
> > Jermey, if we can give some details why -O2 was a problem on IA6 and
> > if problem is still there if he has objections if we swtich back to -O2.
> > 
> > commit adf85cbc1756e56c1f52f56235a3c08b3c5b8e05
> > Author: Jeremy Kerr <jk@ozlabs.org>
> > Date:   Thu Dec 13 16:18:53 2007 +0900
> > 
> >     Build system simplification/standardisation
> 
> I think the change was even older, this one just moved the -O0 CFLAGS from
> one spot to a different one.

You are right. Here is the original change.

commit e90343c521b68237c17ea4e4ed376c4a726f0789
Author: Simon Horman <horms@verge.net.au>
Date:   Fri Oct 6 12:27:58 2006 +0900

    build-util_lib-optimisation-flags
    
    [BUILD] Make sure sha256.c is compiled without optimisation


It is almost 6 years old now. Simon, can it be changed to -O2 now?

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2012-06-08 15:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 13:43 [PATCH] ppc/ppc64: Compile purgatory code with gcc option -msoft-float Vivek Goyal
     [not found] ` <20120608134801.GZ24904@tucnak.redhat.com>
2012-06-08 14:39   ` Vivek Goyal
     [not found]     ` <20120608145113.GB24904@tucnak.redhat.com>
2012-06-08 15:19       ` Vivek Goyal [this message]
2012-06-08 17:36         ` Eric W. Biederman
2012-06-11  1:43         ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120608151936.GE29471@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=horms@verge.net.au \
    --cc=jakub@redhat.com \
    --cc=jk@ozlabs.org \
    --cc=kexec@lists.infradead.org \
    --cc=lxiang@redhat.com \
    --cc=suzuki@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.