From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wjps7-00087J-T3 for qemu-devel@nongnu.org; Mon, 12 May 2014 09:02:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wjps1-0002j2-PY for qemu-devel@nongnu.org; Mon, 12 May 2014 09:02:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wjps1-0002im-Fp for qemu-devel@nongnu.org; Mon, 12 May 2014 09:02:17 -0400 Message-ID: <5370C64B.9080007@redhat.com> Date: Mon, 12 May 2014 15:02:03 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <33183CC9F5247A488A2544077AF19020815E7B70@SZXEMA503-MBS.china.huawei.com> <53709B0C.4030808@redhat.com> <20140512100814.GA15514@redhat.com> <53709F01.8090204@redhat.com> <20140512101844.GC15514@redhat.com> <5370A19F.5000900@redhat.com> <20140512110723.GB15684@redhat.com> <5370B48B.6080001@redhat.com> <20140512121252.GA16576@redhat.com> <5370C2B6.6080605@redhat.com> <20140512125323.GA16846@redhat.com> In-Reply-To: <20140512125323.GA16846@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] vhost: Can we change synchronize_rcu to call_rcu in vhost_set_memory() in vhost kernel module? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: "Huangweidong (C)" , "gleb@redhat.com" , Radim Krcmar , "qemu-devel@nongnu.org" , "Gonglei (Arei)" , "avi.kivity@gmail.com" , "Herongguang (Stephen)" Il 12/05/2014 14:53, Michael S. Tsirkin ha scritto: >> > In any case, whether writes synchronize with RCU or bypass it >> > doesn't change the picture. In either case, writes are ordered >> > against each other but not against reads. RCU does nothing except >> > preventing dangling pointer accesses. >> > >> > Paolo > This is the only part I don't get. > RCU will make sure no VCPUs are running, won't it? > So it's a kind of full barrier. The actual point where the new value becomes visible is where the write happens, not where you do synchronize_rcu. This is the same for both full-copy of the routing table or overwriting the entry. However, the delay in servicing an older irqfd write can be arbitrary if the scheduler decides not to run the irqfd_inject thread. Such an older write might definitely read a newer routing entry. And that's the invalid scenario according to the PCI spec. Paolo