From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wjo6C-0006I3-D7 for qemu-devel@nongnu.org; Mon, 12 May 2014 07:08:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wjo66-0007b4-8P for qemu-devel@nongnu.org; Mon, 12 May 2014 07:08:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wjo66-0007au-0A for qemu-devel@nongnu.org; Mon, 12 May 2014 07:08:42 -0400 Date: Mon, 12 May 2014 14:07:23 +0300 From: "Michael S. Tsirkin" Message-ID: <20140512110723.GB15684@redhat.com> References: <33183CC9F5247A488A2544077AF19020815E7324@SZXEMA503-MBS.china.huawei.com> <536C8E83.8030504@redhat.com> <33183CC9F5247A488A2544077AF19020815E744C@SZXEMA503-MBS.china.huawei.com> <536CA5A5.4080303@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5370A19F.5000900@redhat.com> 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: Paolo Bonzini Cc: "Huangweidong (C)" , "gleb@redhat.com" , "qemu-devel@nongnu.org" , "Gonglei (Arei)" , "avi.kivity@gmail.com" , "Herongguang (Stephen)" On Mon, May 12, 2014 at 12:25:35PM +0200, Paolo Bonzini wrote: > Il 12/05/2014 12:18, Michael S. Tsirkin ha scritto: > >On Mon, May 12, 2014 at 12:14:25PM +0200, Paolo Bonzini wrote: > >>Il 12/05/2014 12:08, Michael S. Tsirkin ha scritto: > >>>On Mon, May 12, 2014 at 11:57:32AM +0200, Paolo Bonzini wrote: > >>>>Perhaps we can check for cases where only the address is changing, > >>>>and poke at an existing struct kvm_kernel_irq_routing_entry without > >>>>doing any RCU synchronization? > >>> > >>>I suspect interrupts can get lost then: e.g. if address didn't match any > >>>cpus, now it matches some. No? > >> > >>Can you explain the problem more verbosely? :) > >> > >>Multiple writers would still be protected by the mutex, so you > >>cannot have an "in-place update" writer racing with a "copy the > >>array" writer. > > > >I am not sure really. > >I'm worried about reader vs writer. > >If reader sees a stale msi value msi will be sent to a wrong > >address. > > That shouldn't happen on any cache-coherent system, no? > > Or at least, it shouldn't become any worse than what can already > happen with RCU. > > Paolo Meaning guest must do some synchronization anyway? It's an interesting question, I am not sure. We seem to rely guest synchronization sometimes in core KVM. But I am not sure this works correctly in all cases, synchronization with guest VCPU does not have to be the same thing as synchronization with host CPU. For example, can not guest VCPU1 detect that VCPU2 is idle and avoid any synchronization? In any case I'd like to see a patch like this accompanied by some argument explaining why it's a safe thing to do. -- MST