From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nvtvc-0005Yv-02 for qemu-devel@nongnu.org; Sun, 28 Mar 2010 10:57:28 -0400 Received: from [140.186.70.92] (port=49077 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvtvY-0005Wk-1i for qemu-devel@nongnu.org; Sun, 28 Mar 2010 10:57:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvtvU-0003U6-SF for qemu-devel@nongnu.org; Sun, 28 Mar 2010 10:57:22 -0400 Received: from hall.aurel32.net ([88.191.82.174]:45889) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvtvU-0003Sq-KG for qemu-devel@nongnu.org; Sun, 28 Mar 2010 10:57:20 -0400 Date: Sun, 28 Mar 2010 16:57:09 +0200 From: Aurelien Jarno Subject: Re: [Qemu-devel] Significant performance regression in qemu-system-mips. Message-ID: <20100328145709.GT13677@hall.aurel32.net> References: <201003241534.01219.rob@landley.net> <201003261647.52349.rob@landley.net> <20100327123241.GG15194@volta.aurel32.net> <201003271801.40102.rob@landley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <201003271801.40102.rob@landley.net> Sender: Aurelien Jarno List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rob Landley Cc: qemu-devel@nongnu.org, Artyom Tarasenko On Sat, Mar 27, 2010 at 06:01:39PM -0500, Rob Landley wrote: > On Saturday 27 March 2010 07:32:41 Aurelien Jarno wrote: > > On Fri, Mar 26, 2010 at 04:47:51PM -0500, Rob Landley wrote: > > > On Friday 26 March 2010 14:00:00 Aurelien Jarno wrote: > > > > I am pretty fine applying a correct patch if you send a new one. > > > > > > By which you mean rip out the whole #ifdef block? > > > > Yes. > > > > > Here you go: > > > > This looks much better. Can you please resend it with the changes below > > and a Signed-off-by: ? > > If you want the code actually cleaned up instead of minimally changed, > here's a stab at that. (Unfortunately I haven't got a ppc64 setup to test it > with yet, but ppc32 still works.) Not necessarily a code cleanup, but at least a patch which doesn't introduce useless changes. Anyway applied. > Signed-off-by: Rob Landley > > diff --git a/linux-user/elfload.c b/linux-user/elfload.c > index 682a813..3c3ef21 100644 > --- a/linux-user/elfload.c > +++ b/linux-user/elfload.c > @@ -517,31 +517,12 @@ do { \ > > static inline void init_thread(struct target_pt_regs *_regs, struct image_info *infop) > { > - abi_ulong pos = infop->start_stack; > - abi_ulong tmp; > -#if defined(TARGET_PPC64) && !defined(TARGET_ABI32) > - abi_ulong entry, toc; > -#endif > - > _regs->gpr[1] = infop->start_stack; > #if defined(TARGET_PPC64) && !defined(TARGET_ABI32) > - entry = ldq_raw(infop->entry) + infop->load_addr; > - toc = ldq_raw(infop->entry + 8) + infop->load_addr; > - _regs->gpr[2] = toc; > - infop->entry = entry; > + _regs->gpr[2] = ldq_raw(infop->entry + 8) + infop->load_addr; > + infop->entry = ldq_raw(infop->entry) + infop->load_addr; > #endif > _regs->nip = infop->entry; > - /* Note that isn't exactly what regular kernel does > - * but this is what the ABI wants and is needed to allow > - * execution of PPC BSD programs. > - */ > - /* FIXME - what to for failure of get_user()? */ > - get_user_ual(_regs->gpr[3], pos); > - pos += sizeof(abi_ulong); > - _regs->gpr[4] = pos; > - for (tmp = 1; tmp != 0; pos += sizeof(abi_ulong)) > - tmp = ldl(pos); > - _regs->gpr[5] = pos; > } > > #define ELF_EXEC_PAGESIZE 4096 > > > > Ok, I agree I was a bit harsh. (He's the one who introduced his employer > > > into the discussion, but I suspect I read more into that than he meant by > > > it.) > > > > I think you misunderstood him. You were talking about Super-Hitachi > > which is a train [1] from Hitachi (not his employer), while he was talking > > about Super-H which is a CPU [2] from Renesas (his employer). > > So essentially he's insisting he works for Freescale, not Motorola, because > Motorola stopped being interested in the m68k and divested itself of its > processor manufacturing operations. And I'm confusing his product with > something _else_ Motorola used to do. He is insisted on the fact the name of the CPU is Super-H and not Super-Hitachi. > Only transliterated to Japan. > > *shrug* The "SuperH" chipset was developed by Hitachi. I thought the H stood > for "Hitachi". I hadn't actually noticed that Hitachi had divested itself of > its chip design operations, and was trying to avoid referring to it as "sh4" > because that's an architecture generation, not a chip family. (There used to > be sh3 and similar, and I thought there might be an sh5 someday but now that > I've looked into it I can understand why they don't seem too worried about > that happening.) > > My project is trying to get all the architectures Linux and QEMU support to > behave the same way. Thus I'm no more an sh4 expert than I am a ppc expert, I > just poke at it and look stuff up when it doesn't work (which is frequently). > > Speaking of which, qemu-system-ppc in 0.12.3 segfaults accessing /dev/hdc, and > the one in current -git has the missed IRQ issue when accessing /dev/hda. Is > there any chance of 0.12.4 in the near future? (I hate to point people > interested in PPC at a random non-current git snapshot.) It is something fixed in the stable-0.12. Someone has to roll out 0.12.4. > > He has the right to not care about trains ;-) > > It was more the "I can build it, I don't care if you still can" issue, when > the commit in question was a primarily cosmetic change to code that was only > theoretically broken. (Not only did it work for me, but it was so broken > nobody actually noticed the issue in question for years.) > > I got the impression that the reason he didn't care about my use case was > because I was not a customer of his company. That he was acting on behalf > of his employer, not in an impartial purely technical capacity. I have > no commercial interest in sh4, and never did, so I stopped bothering him. > > Rob > -- > Latency is more important than throughput. It's that simple. - Linus Torvalds > -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net