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: Thu, 28 Nov 2013 12:12:55 +0200 Message-ID: <52971727.2030600@cloudius-systems.com> References: <5294A68F.6060301@redhat.com> <5294B461.5000405@redhat.com> <5294B634.4050801@cloudius-systems.com> <20131126150357.GA20352@redhat.com> <5294BC3B.6070902@redhat.com> <5297050E.6000700@redhat.com> <20131128091903.GA4609@kernel.org> <5297118C.3050104@cloudius-systems.com> <20131128101138.GB5822@minantech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , "Zhanghaoyu (A)" , Gleb Natapov , Avi Kivity , "Huangweidong (C)" , KVM , "Michael S. Tsirkin" , "Jinxin (F)" , Luonengjun , "qemu-devel@nongnu.org" , Zanghongyong To: Gleb Natapov Return-path: Received: from mail-bk0-f47.google.com ([209.85.214.47]:33242 "EHLO mail-bk0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757687Ab3K1KNA (ORCPT ); Thu, 28 Nov 2013 05:13:00 -0500 Received: by mail-bk0-f47.google.com with SMTP id mx12so3712349bkb.34 for ; Thu, 28 Nov 2013 02:12:59 -0800 (PST) In-Reply-To: <20131128101138.GB5822@minantech.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/28/2013 12:11 PM, Gleb Natapov wrote: > On Thu, Nov 28, 2013 at 11:49:00AM +0200, Avi Kivity wrote: >> On 11/28/2013 11:19 AM, Gleb Natapov wrote: >>> On Thu, Nov 28, 2013 at 09:55:42AM +0100, Paolo Bonzini wrote: >>>> Il 28/11/2013 07:27, Zhanghaoyu (A) ha scritto: >>>>>>> Without synchronize_rcu you could have >>>>>>> >>>>>>> VCPU writes to routing table >>>>>>> e = entry from IRQ routing table >>>>>>> kvm_irq_routing_update(kvm, new); >>>>>>> VCPU resumes execution >>>>>>> kvm_set_msi_irq(e, &irq); >>>>>>> kvm_irq_delivery_to_apic_fast(); >>>>>>> >>>>>>> where the entry is stale but the VCPU has already resumed execution. >>>>>>> >>>>> If we use call_rcu()(Not consider the problem that Gleb pointed out temporarily) instead of synchronize_rcu(), should we still ensure this? >>>> The problem is that we should ensure this, so using call_rcu is not >>>> possible (even not considering the memory allocation problem). >>>> >>> Not changing current behaviour is certainly safer, but I am still not 100% >>> convinced we have to ensure this. >>> >>> Suppose guest does: >>> >>> 1: change msi interrupt by writing to pci register >>> 2: read the pci register to flush the write >>> 3: zero idt >>> >>> I am pretty certain that this code can get interrupt after step 2 on real HW, >>> but I cannot tell if guest can rely on it to be delivered exactly after >>> read instruction or it can be delayed by couple of instructions. Seems to me >>> it would be fragile for an OS to depend on this behaviour. AFAIK Linux does not. >>> >> Linux is safe, it does interrupt migration from within the interrupt >> handler. If you do that before the device-specific EOI, you won't >> get another interrupt until programming the MSI is complete. >> >> Is virtio safe? IIRC it can post multiple interrupts without guest acks. >> >> Using call_rcu() is a better solution than srcu IMO. Less code >> changes, consistently faster. > Why not fix userspace to use KVM_SIGNAL_MSI instead? > > Shouldn't it work with old userspace too? Maybe I misunderstood your intent.