From patchwork Thu Apr 21 17:18:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Sergey Fedorov X-Patchwork-Id: 8902851 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 9295A9F457 for ; Thu, 21 Apr 2016 17:18:30 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BC00320320 for ; Thu, 21 Apr 2016 17:18:29 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D5EC22021F for ; Thu, 21 Apr 2016 17:18:27 +0000 (UTC) Received: from localhost ([::1]:44830 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atIFG-0008RM-UU for patchwork-qemu-devel@patchwork.kernel.org; Thu, 21 Apr 2016 13:18:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atIF9-0008OV-8g for qemu-devel@nongnu.org; Thu, 21 Apr 2016 13:18:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atIF4-0002oB-69 for qemu-devel@nongnu.org; Thu, 21 Apr 2016 13:18:19 -0400 Received: from mail-lb0-x22e.google.com ([2a00:1450:4010:c04::22e]:34230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atIF3-0002o6-KM for qemu-devel@nongnu.org; Thu, 21 Apr 2016 13:18:14 -0400 Received: by mail-lb0-x22e.google.com with SMTP id b1so27181854lbi.1 for ; Thu, 21 Apr 2016 10:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=KYVwrUvWJIIiFKgDJhGkLBqB34GQljxyuLVrBqacNg8=; b=Yf1S1FdxejDqBuLfaLzI0ZLTJjWFXZ1C/ih6R6yFY6UVV/5YTpayh39oeXxh1G3hHq gnJ45YJHaEJaZdp3YI6OyXgA7umpmngFcPRR+tB+DoAg2/E6eWKDShK0nlUT82ZTAvIy hYp8rpDrZKY9Z0o9pRez45sAjwCVBt6Ks/78esz7zD3FwRHjx1s/reO9XcSdKGtQpjrW 57gqiYKvFSmcACeUMSV04jp7hmtlS5HyyVnQe10TMad4dB/TDjTvZTfWYAlEXuFDvk3r ZJFYhqu14pu3UZrSXbJjN2XPkCXEUwmi9hKbZEFx4ZK9gs5TTQKjQQOoWKeiljzWqu+9 REBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KYVwrUvWJIIiFKgDJhGkLBqB34GQljxyuLVrBqacNg8=; b=MgzaqdC1O1M6DNpbHYiOwpyQuATVJek/tOnq4vrUk1I8km5qJjxI6f/hdfo/1QO2sm f8VsT1dC3S0t/tuNpl+BlYmU82Z2L0dg4v+ebakomGrN5EHiDPRWYuokQz+jBbjFHWAq drQSMSOhzx4AD13a29lbIQnz7HJRMcu204BwyNZWOZ9KrEfqMdw5dZTCavdKzkSLRnV9 SgSrz8jA38+vKqYiI89/cYSX6hAOLRhkqeqpWZtnMiywkZr7n0g4IHKN82VBL0Patj7E byXcwBQf60KP1Dm5muq+PuNwo+A89oIRVxYBZIV5FVZ1r75bwdzVk3u+wc2SwSyuC4bm UhZQ== X-Gm-Message-State: AOPr4FXA8NyoMHP8xsBrsWuqqZLuP41IPe97jWptaiz+d4ubkFCHUKuVJqvcULbMRqD54w== X-Received: by 10.112.162.131 with SMTP id ya3mr6758448lbb.11.1461259092416; Thu, 21 Apr 2016 10:18:12 -0700 (PDT) Received: from [192.168.1.189] ([195.91.132.170]) by smtp.gmail.com with ESMTPSA id 31sm697422lfu.48.2016.04.21.10.18.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Apr 2016 10:18:11 -0700 (PDT) To: =?UTF-8?Q?Alex_Benn=c3=a9e?= References: <1460666749-24452-1-git-send-email-sergey.fedorov@linaro.org> <1460666749-24452-5-git-send-email-sergey.fedorov@linaro.org> <87inzfvwiq.fsf@linaro.org> <5714F7C4.6040306@gmail.com> <87h9eyx2e9.fsf@linaro.org> <57151EA4.7040309@gmail.com> <5718E54B.1020602@gmail.com> <87twivt0qo.fsf@linaro.org> <5718FCE1.4050106@gmail.com> From: Sergey Fedorov Message-ID: <57190B52.7070409@gmail.com> Date: Thu, 21 Apr 2016 20:18:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5718FCE1.4050106@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c04::22e Subject: Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sergey Fedorov , Peter Crosthwaite , qemu-devel@nongnu.org, Paolo Bonzini , =?UTF-8?Q?Andreas_F=c3=a4rber?= , Richard Henderson Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 21/04/16 19:16, Sergey Fedorov wrote: > On 21/04/16 18:55, Alex Bennée wrote: >> Sergey Fedorov writes: >> >>> On 18/04/16 20:51, Sergey Fedorov wrote: >>>> On 18/04/16 20:17, Alex Bennée wrote: >>>>> Sergey Fedorov writes: >>>>>> On 18/04/16 17:09, Alex Bennée wrote: >>>>>>> Sergey Fedorov writes: >>>>>>>> diff --git a/cpu-exec.c b/cpu-exec.c >>>>>> (snip) >>>>>>>> @@ -507,14 +510,12 @@ int cpu_exec(CPUState *cpu) >>>>>>>> } >>>>>>>> tb_lock(); >>>>>>>> tb = tb_find_fast(cpu); >>>>>>>> - /* Note: we do it here to avoid a gcc bug on Mac OS X when >>>>>>>> - doing it in tb_find_slow */ >>>>>>> Is this still true? Would it make more sense to push the patching down >>>>>>> to the gen_code? >>>>>> This comment comes up to the commit: >>>>>> >>>>>> commit 1538800276aa7228d74f9d00bf275f54dc9e9b43 >>>>>> Author: bellard >>>>>> Date: Mon Dec 19 01:42:32 2005 +0000 >>>>>> >>>>>> workaround for gcc bug on PowerPC >>>>>> >>>>>> >>>>>> It was added more than ten years ago. Anyway, now this code is here not >>>>>> because of the bug: we need to reset 'next_tb' which is a local variable >>>>>> in cpu_exec(). Personally, I don't think it would be neater to hide it >>>>>> into gen_code(). Do you have some thoughts on how we could benefit from >>>>>> doing so? BTW, I had a feeling that it may be useful to reorganize >>>>>> cpu_exec() a bit, although I don't have a solid idea of how to do this >>>>>> so far. >>>>> I'm mainly eyeing the tb_lock/unlock which would be nice to push further >>>>> down the call chain if we can, especially if the need to lock >>>>> tb_find_fast can be removed later on. >>>> Yes, it would be nice to possibly have all tb_lock/unlock() calls (or at >>>> least their pairs) in the same block. There is a lot to be thought over :) >>> It's not so simple because tb_find_fast() is also called in replay mode >>> to find a TB for cpu_exec_nocache()... I'm not sure it's worth touching >>> it now. >> If the locking is pushed into tb_find_fast or further down is this an >> issue? > We would have to pass 'next_tb' (or 'last_tb' and 'tb_exit' after > cleaning it up) if we move TB chaining code to tb_find_fast(). But > tb_find_fast() is also called in replay mode to find a TB for > cpu_exec_nocache() where we don't bother with TB chaining... Do you > think it would be fine to make those changes? Are you thinking about something like this: @@ -441,7 +459,8 @@ int cpu_exec(CPUState *cpu) } else if (replay_has_exception() && cpu->icount_decr.u16.low + cpu->icount_extra == 0) { /* try to cause an exception pending in the log */ - cpu_exec_nocache(cpu, 1, tb_find_fast(cpu), true); + last_tb = NULL; /* Avoid chaining TBs */ + cpu_exec_nocache(cpu, 1, tb_find_fast(cpu, &last_tb, 0), true); ret = -1; break; #endif @@ -511,23 +530,7 @@ int cpu_exec(CPUState *cpu) cpu->exception_index = EXCP_INTERRUPT; cpu_loop_exit(cpu); } - tb_lock(); - tb = tb_find_fast(cpu); - if (cpu->tb_flushed) { - /* Ensure that no TB jump will be modified as the - * translation buffer has been flushed. - */ - last_tb = NULL; - cpu->tb_flushed = false; - } - /* see if we can patch the calling TB. When the TB - spans two pages, we cannot safely do a direct - jump. */ - if (last_tb != NULL && tb->page_addr[1] == -1 - && !qemu_loglevel_mask(CPU_LOG_TB_NOCHAIN)) { - tb_add_jump(last_tb, tb_exit, tb); - } - tb_unlock(); + tb = tb_find_fast(cpu, &last_tb, tb_exit); if (likely(!cpu->exit_request)) { uintptr_t ret; trace_exec_tb(tb, tb->pc); ... right? Kind regards, Sergey diff --git a/cpu-exec.c b/cpu-exec.c index 1d12e8bc2739..07e9ede49193 100644 --- a/cpu-exec.c +++ b/cpu-exec.c @@ -320,7 +320,9 @@ found: return tb; } -static inline TranslationBlock *tb_find_fast(CPUState *cpu) +static inline TranslationBlock *tb_find_fast(CPUState *cpu, + TranslationBlock **last_tb, + int tb_exit) { CPUArchState *env = (CPUArchState *)cpu->env_ptr; TranslationBlock *tb; @@ -331,11 +333,27 @@ static inline TranslationBlock *tb_find_fast(CPUState *cpu) always be the same before a given translated block is executed. */ cpu_get_tb_cpu_state(env, &pc, &cs_base, &flags); + tb_lock(); tb = cpu->tb_jmp_cache[tb_jmp_cache_hash_func(pc)]; if (unlikely(!tb || tb->pc != pc || tb->cs_base != cs_base || tb->flags != flags)) { tb = tb_find_slow(cpu, pc, cs_base, flags); } + if (cpu->tb_flushed) { + /* Ensure that no TB jump will be modified as the + * translation buffer has been flushed. + */ + *last_tb = NULL; + cpu->tb_flushed = false; + } + /* see if we can patch the calling TB. When the TB + spans two pages, we cannot safely do a direct + jump. */ + if (*last_tb != NULL && tb->page_addr[1] == -1 + && !qemu_loglevel_mask(CPU_LOG_TB_NOCHAIN)) { + tb_add_jump(*last_tb, tb_exit, tb); + } + tb_unlock(); return tb; }