From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlL2d-0005xZ-Vq for qemu-devel@nongnu.org; Tue, 26 Nov 2013 10:59:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlL2Y-0002w2-1X for qemu-devel@nongnu.org; Tue, 26 Nov 2013 10:59:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:23592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlL2X-0002vn-Kq for qemu-devel@nongnu.org; Tue, 26 Nov 2013 10:59:05 -0500 Message-ID: <5294C53D.8060009@redhat.com> Date: Tue, 26 Nov 2013 16:58:53 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <52949847.6020908@redhat.com> <5294A68F.6060301@redhat.com> <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> In-Reply-To: <5294BFB7.2090202@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)" , KVM , Gleb Natapov , "Michael S. Tsirkin" , "Zhanghaoyu (A)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong , Avi Kivity , "Jinxin (F)" 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. (BTW, PCI memory writes are posted, but configuration writes are not). Paolo