From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8F3f-0004OQ-JB for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:33:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8F3d-0004Tu-NW for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:33:35 -0400 Received: from david.siemens.de ([192.35.17.14]:22647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8F3d-0004Tn-CA for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:33:33 -0400 Message-ID: <4E80B768.8010000@siemens.com> Date: Mon, 26 Sep 2011 19:33:28 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E802DDD.8090100@siemens.com> <4E805923.50806@siemens.com> <4E806573.6000207@siemens.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] tcg: Remove stack protection from helper functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Laurent Desnogues , Peter Maydell , Anthony Liguori , Mulyadi Santosa , qemu-devel On 2011-09-26 19:22, Blue Swirl wrote: > On Mon, Sep 26, 2011 at 11:56 AM, Peter Maydell > wrote: >> On 26 September 2011 12:43, Jan Kiszka wrote: >>> On 2011-09-26 13:33, Peter Maydell wrote: >>>> On 26 September 2011 11:51, Jan Kiszka wrote: >>>>> This increases the overhead of frequently executed helpers. We need to >>>>> move rule past QEMU_CFLAGS assignment to ensure that the required simple >>>>> assignment picks up all bits. The signal workaround is moved just for >>>>> the sake of consistency. >>>> >>>>> +# NOTE: Must be after the last QEMU_CFLAGS assignment >>>>> +op_helper.o user-exec.o: QEMU_CFLAGS := $(subst -fstack-protector-all,,$(QEMU_CFLAGS)) $(HELPER_CFLAGS) >>>> >>>> Why also user-exec.o ? >>> >>> That's a good question. It doesn't look like it's deserving this. >>> >>>> Why not the other source files with helpers in? >>> >>> Name them and I add them. >> >> target-*/*helper.c ? >> >> But mostly I think what I'm trying to say is that this is making >> a tradeoff between safety and speed, so it ought to come with a >> rationale for why it is OK to remove the safety checks for these >> files. Given that rationale you can identify other files that are >> also safe/worthwhile to flip the flag for. > > I wouldn't remove -fstack-protector-all by default. Especially op code > interfaces with the guest. I'd love to have some function attribute for this, because a stack protector for rather simple arithmetic operations or something like helper_cli/sti are pointlessly burned cycles. Maybe we can introduce op_helper_simple.c. > > For max performance version, I'd check if -fomit-frame-pointer and -O3 > makes sense. See also this article: > https://www.debian-administration.org/article/672/Optimizing_code_via_compiler_flags We already run without frame pointers, -O3 might be worth exploring in addition. Still, that won't take the protector overhead away. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux