From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table Date: Tue, 26 Nov 2013 18:11:51 +0200 Message-ID: <20131126161151.GC23007@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Paolo Bonzini , 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]:44660 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757176Ab3KZQIt (ORCPT ); Tue, 26 Nov 2013 11:08:49 -0500 Content-Disposition: inline In-Reply-To: <5294C702.4070400@cloudius-systems.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > The fact > that Linux does interrupt migration from within the interrupt > handler also shows that someone else believes that it is the only > safe place to do it. >