From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [RFC] create a single workqueue for each vm to update vm irq routing table Date: Tue, 26 Nov 2013 18:06:26 +0200 Message-ID: <5294C702.4070400@cloudius-systems.com> 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> <5294C53D.8060009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , Avi Kivity , "Huangweidong (C)" , KVM , "Michael S. Tsirkin" , "Jinxin (F)" , "Zhanghaoyu (A)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong To: Paolo Bonzini Return-path: Received: from mail-bk0-f50.google.com ([209.85.214.50]:61020 "EHLO mail-bk0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756983Ab3KZQGb (ORCPT ); Tue, 26 Nov 2013 11:06:31 -0500 Received: by mail-bk0-f50.google.com with SMTP id e11so2688693bkh.37 for ; Tue, 26 Nov 2013 08:06:30 -0800 (PST) In-Reply-To: <5294C53D.8060009@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. > (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. 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.