From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlLOr-0006B1-Nw for qemu-devel@nongnu.org; Tue, 26 Nov 2013 11:22:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlLOk-0002B8-9D for qemu-devel@nongnu.org; Tue, 26 Nov 2013 11:22:09 -0500 Received: from mail-bk0-f53.google.com ([209.85.214.53]:48833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlLOk-0002Ar-3J for qemu-devel@nongnu.org; Tue, 26 Nov 2013 11:22:02 -0500 Received: by mail-bk0-f53.google.com with SMTP id na10so2653916bkb.26 for ; Tue, 26 Nov 2013 08:22:01 -0800 (PST) Message-ID: <5294CAA6.3010009@cloudius-systems.com> Date: Tue, 26 Nov 2013 18:21:58 +0200 From: Avi Kivity MIME-Version: 1.0 References: <5294B461.5000405@redhat.com> <5294B634.4050801@cloudius-systems.com> <20131126150357.GA20352@redhat.com> <5294BC3B.6070902@redhat.com> <5294BD61.7080904@cloudius-systems.com> <5294BE22.7040105@redhat.com> <5294BFB7.2090202@cloudius-systems.com> <5294C53D.8060009@redhat.com> <5294C702.4070400@cloudius-systems.com> <20131126161151.GC23007@redhat.com> In-Reply-To: <20131126161151.GC23007@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: "Huangweidong (C)" , KVM , Gleb Natapov , "Zhanghaoyu (A)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong , Avi Kivity , Paolo Bonzini , "Jinxin (F)" On 11/26/2013 06:11 PM, Michael S. Tsirkin wrote: > On Tue, Nov 26, 2013 at 06:06:26PM +0200, Avi Kivity wrote: >> On 11/26/2013 05:58 PM, Paolo Bonzini wrote: >>> Il 26/11/2013 16:35, Avi Kivity ha scritto: >>>>>>> If we want to ensure, we need to use a different mechanism for >>>>>>> synchronization than the global RCU. QRCU would work; readers are not >>>>>>> wait-free but only if there is a concurrent synchronize_qrcu, which >>>>>>> should be rare. >>>>>> An alternative path is to convince ourselves that the hardware does not >>>>>> provide the guarantees that the current code provides, and so we can >>>>>> relax them. >>>>> No, I think it's a reasonable guarantee to provide. >>>> Why? >>> Because IIUC the semantics may depend not just on the interrupt >>> controller, but also on the specific PCI device. It seems safer to >>> assume that at least one device/driver pair wants this to work. >> It's indeed safe, but I think there's a nice win to be had if we >> drop the assumption. > I'm not arguing with that, but a minor commoent below: > >>> (BTW, PCI memory writes are posted, but configuration writes are not). >> MSIs are configured via PCI memory writes. >> >> By itself, that doesn't buy us anything, since the guest could flush >> the write via a read. But I think the fact that the interrupt >> messages themselves are posted proves that it is safe. > FYI, PCI read flushes the interrupt itself in, too. > I guess that kills the optimization then. Maybe you can do qrcu, whatever that is.