From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPC5K-0004rS-Cn for qemu-devel@nongnu.org; Mon, 18 Jul 2016 13:12:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPC5H-00086P-2I for qemu-devel@nongnu.org; Mon, 18 Jul 2016 13:12:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53523) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPC5G-00086C-SR for qemu-devel@nongnu.org; Mon, 18 Jul 2016 13:11:58 -0400 References: <1468851450-9863-1-git-send-email-pbonzini@redhat.com> <578D0938.2050004@gmail.com> <578D0A60.4020608@gmail.com> <8c52110d-c009-087c-be04-3920d97af323@redhat.com> <578D0CD6.3080005@gmail.com> From: Paolo Bonzini Message-ID: <4c479cb3-a8ef-caab-4dbc-3bfd014c7a0a@redhat.com> Date: Mon, 18 Jul 2016 19:11:55 +0200 MIME-Version: 1.0 In-Reply-To: <578D0CD6.3080005@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] atomics: add volatile_read/volatile_set List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Fedorov , qemu-devel@nongnu.org Cc: sergey.fedorov@linaro.org, alex.bennee@linaro.org On 18/07/2016 19:07, Sergey Fedorov wrote: > On 18/07/16 20:00, Paolo Bonzini wrote: >> >> On 18/07/2016 18:57, Sergey Fedorov wrote: >>> On 18/07/16 19:53, Paolo Bonzini wrote: >>>> On 18/07/2016 18:52, Sergey Fedorov wrote: >>>>> So how are we going to use them? >>>> Instead of atomic_read/atomic_set when marking invalid TBs. >>> But shouldn't they be atomic to avoid reading torn writes? >> A torn write would probably fail to match anyway, but even if it doesn't >> it is indistinguishable from a race, isn't it? > > I'm afraid, torn write can happen to be a false match against a wrong > TB. In case of a race with atomic access we either get the right TB or > an invalid one which couldn't match any valid CPU state. Probably, we > have to make sure (and document this) that TB invalidation process > cannot make a partially invalidated TB which can match any meaningful > CPU state. x86 is atomic (because flags are 32-bit); those that have cs_base==0 are safe against torn writes too. Only SPARC perhaps could use "tb->cs_base|=1" instead in case 0xffffffff........ matches another TB. Paolo >> >> By the way, tb_cmp should also use volatile_read. > > You are right, we must user the save type of access in tb_cmp(). > > Thanks, > Sergey >