From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table Date: Tue, 26 Nov 2013 17:42:32 +0100 Message-ID: <5294CF78.1040104@redhat.com> 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> <5294CAA6.3010009@cloudius-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Michael S. Tsirkin" , Gleb Natapov , Avi Kivity , "Huangweidong (C)" , KVM , "Jinxin (F)" , "Zhanghaoyu (A)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57582 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932214Ab3KZQmo (ORCPT ); Tue, 26 Nov 2013 11:42:44 -0500 In-Reply-To: <5294CAA6.3010009@cloudius-systems.com> Sender: kvm-owner@vger.kernel.org List-ID: Il 26/11/2013 17:21, Avi Kivity ha scritto: >>> 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. It's "srcu" (a separate SRCU instance specific to the irq routing table), which I managed to misspell twice. Actually, it turns out that qrcu actually exists (http://lwn.net/Articles/223752/) and has extremely fast grace periods, but read_lock/read_unlock are also more expensive. So it was probably some kind of Freudian slip. Paolo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlLir-0006qz-71 for qemu-devel@nongnu.org; Tue, 26 Nov 2013 11:42:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlLim-0000nQ-7Y for qemu-devel@nongnu.org; Tue, 26 Nov 2013 11:42:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlLil-0000nB-Ue for qemu-devel@nongnu.org; Tue, 26 Nov 2013 11:42:44 -0500 Message-ID: <5294CF78.1040104@redhat.com> Date: Tue, 26 Nov 2013 17:42:32 +0100 From: Paolo Bonzini 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> <5294CAA6.3010009@cloudius-systems.com> In-Reply-To: <5294CAA6.3010009@cloudius-systems.com> Content-Type: text/plain; charset=ISO-8859-1 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: Avi Kivity Cc: "Huangweidong (C)" , Gleb Natapov , KVM , "Michael S. Tsirkin" , "Zhanghaoyu (A)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong , Avi Kivity , "Jinxin (F)" Il 26/11/2013 17:21, Avi Kivity ha scritto: >>> 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. It's "srcu" (a separate SRCU instance specific to the irq routing table), which I managed to misspell twice. Actually, it turns out that qrcu actually exists (http://lwn.net/Articles/223752/) and has extremely fast grace periods, but read_lock/read_unlock are also more expensive. So it was probably some kind of Freudian slip. Paolo