From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqiWA-0001Mm-HR for qemu-devel@nongnu.org; Thu, 14 Apr 2016 10:45:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqiW6-0005Se-CK for qemu-devel@nongnu.org; Thu, 14 Apr 2016 10:45:14 -0400 Received: from mail-lf0-x243.google.com ([2a00:1450:4010:c07::243]:34429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqiW6-0005SW-4h for qemu-devel@nongnu.org; Thu, 14 Apr 2016 10:45:10 -0400 Received: by mail-lf0-x243.google.com with SMTP id e190so12517691lfe.1 for ; Thu, 14 Apr 2016 07:45:09 -0700 (PDT) References: <1458222382-6498-1-git-send-email-sergey.fedorov@linaro.org> <1458222382-6498-5-git-send-email-sergey.fedorov@linaro.org> <56EAC8A2.7060700@redhat.com> <56EAC9E3.60000@gmail.com> <56F94B59.80905@gmail.com> <56F9A051.9090907@redhat.com> <56FA52E3.3000900@gmail.com> <56FA5ADB.7030103@redhat.com> From: Sergey Fedorov Message-ID: <570FACF1.6020009@gmail.com> Date: Thu, 14 Apr 2016 17:45:05 +0300 MIME-Version: 1.0 In-Reply-To: <56FA5ADB.7030103@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/5] tcg: reorder removal from lists in tb_phys_invalidate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , sergey.fedorov@linaro.org, qemu-devel@nongnu.org Cc: Richard Henderson , Peter Crosthwaite , =?UTF-8?Q?Alex_Benn=c3=a9e?= On 29/03/16 13:37, Paolo Bonzini wrote: >>>> Your observation that tb->pc==-1 is not necessarily safe still holds of >>>> >> > course. Probably the best thing is an inline that can do one of: >>>> >> > >>>> >> > 1) set cs_base to an invalid value (anything nonzero is enough except on >>>> >> > x86 and SPARC; SPARC can use all-ones) >>>> >> > >>>> >> > 2) sets the flags to an invalid combination (x86 can use all ones) >>>> >> > >>>> >> > 3) sets the PC to an invalid value (no one really needs it) >> > >> > It's a bit tricky. Does it really worth doing so instead of using a >> > separate dedicated flag? Mainly, it should cost one extra compare on TB >> > look-up. I suppose it's a kind of trade-off between performance and code >> > clarity. > I think a new inline function cpu_make_tb_invalid would not be too tricky. > Just setting "tb->cs_base = -1;" is pretty much obvious for all the targets > that do not use cs_base at all and for SPARC which sets it to a PC (and > thus a multiple of four). x86 is the odd one out. So what would you suggest to use for x86? I can't think of something that looks like a really compelling combination when I look at cpu_get_tb_cpu_state() in target-i386/cpu.h. Personally, I'm not so happy trying to use pc/cs_base/flags to mark an invalid TB. Are my worries unreasonable? :) Some other thoughts? Anyway, I am wondering if there is still a way to clear tb_phys_hash and tb_jmp_cache safely. Maybe something like this: * Remove the TB from physical hash list * Memory barrier * Remove the TB from each vCPU's virtual address hash cache Would that work? Kind regards, Sergey