From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asCnf-0004IN-GX for qemu-devel@nongnu.org; Mon, 18 Apr 2016 13:17:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1asCna-0007Y1-0z for qemu-devel@nongnu.org; Mon, 18 Apr 2016 13:17:27 -0400 Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:32800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asCnZ-0007XM-GU for qemu-devel@nongnu.org; Mon, 18 Apr 2016 13:17:21 -0400 Received: by mail-wm0-x22b.google.com with SMTP id f198so23106705wme.0 for ; Mon, 18 Apr 2016 10:17:21 -0700 (PDT) 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> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <5714F7C4.6040306@gmail.com> Date: Mon, 18 Apr 2016 18:17:18 +0100 Message-ID: <87h9eyx2e9.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 4/4] tcg: rework tb_invalidated_flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Fedorov Cc: Sergey Fedorov , qemu-devel@nongnu.org, Paolo Bonzini , Peter Crosthwaite , Richard Henderson , Andreas =?utf-8?Q?F=C3=A4rber?= Sergey Fedorov writes: > On 18/04/16 17:09, Alex Bennée wrote: >> Sergey Fedorov writes: >>> From: Sergey Fedorov >>> >>> 'tb_invalidated_flag' was meant to catch two events: >>> * some TB has been invalidated by tb_phys_invalidate(); >>> * the whole translation buffer has been flushed by tb_flush(). >>> >>> Then it was checked: >>> * in cpu_exec() to ensure that the last executed TB can be safely >>> linked to directly call the next one; >>> * in cpu_exec_nocache() to decide if the original TB should be provided >>> for further possible invalidation along with the temporarily >>> generated TB. >>> >>> It is always safe to patch an invalidated TB since it is not going to be >>> used anyway. >> Wouldn't that have implications for code searching through the linked >> list of jump patched TBs? > > The only implication I can see is that the jump in that already > invalidated TB could just get reset back later on in > tb_phys_invalidate(). We could keep track of invalidated TB's and skip > patching those but it's also some overhead in the main CPU execution > loop wich I'm not sure is worth to be introduced. > > (snip) >>> 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. >> >> I got slightly confused as to what next_tb ends up meaning at what point >> in the run loop. > > Yes, it seems to be a misleading name for this variable. As it was > discussed on IRC, I'd like to break it into two variables, say 'last_tb' > and 'tb_exit_idx', as soon as cpu_tb_exec() returns. Probably this > series could also include such a patch. Yes this would be a worthwhile separate patch. > > Kind regards, > Sergey -- Alex Bennée