From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:50966)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <gleb@minantech.com>) id 1Vlxkj-000413-A3
	for qemu-devel@nongnu.org; Thu, 28 Nov 2013 04:19:23 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <gleb@minantech.com>) id 1Vlxka-0006gs-UW
	for qemu-devel@nongnu.org; Thu, 28 Nov 2013 04:19:17 -0500
Received: from mail-bk0-f47.google.com ([209.85.214.47]:40762)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <gleb@minantech.com>) id 1Vlxka-0006fF-Ok
	for qemu-devel@nongnu.org; Thu, 28 Nov 2013 04:19:08 -0500
Received: by mail-bk0-f47.google.com with SMTP id mx12so3680413bkb.34
	for <qemu-devel@nongnu.org>; Thu, 28 Nov 2013 01:19:07 -0800 (PST)
Date: Thu, 28 Nov 2013 11:19:03 +0200
From: Gleb Natapov <gleb@minantech.com>
Message-ID: <20131128091903.GA4609@kernel.org>
References: <52949847.6020908@redhat.com>
	<CAEbWaipAnmoa=gMbB1aNb=btU6LgYXhcnmQWHJ_89m4yvw6Dug@mail.gmail.com>
	<5294A68F.6060301@redhat.com>
	<CAF950W+-UiX6xv4vYmnxji9aWDU8ds2rnx7JugnbHQWJdCCD-Q@mail.gmail.com>
	<5294B461.5000405@redhat.com>
	<5294B634.4050801@cloudius-systems.com>
	<20131126150357.GA20352@redhat.com> <5294BC3B.6070902@redhat.com>
	<D3E216785288A145B7BC975F83A2ED10448BBAB3@SZXEMA510-MBS.china.huawei.com>
	<5297050E.6000700@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5297050E.6000700@redhat.com>
Subject: Re: [Qemu-devel] [RFC] create a single workqueue for each vm to
 update vm irq routing table
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Avi Kivity <avi@cloudius-systems.com>, "Huangweidong (C)" <weidong.huang@huawei.com>, Gleb Natapov <gleb@redhat.com>, KVM <kvm@vger.kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, "Zhanghaoyu (A)" <haoyu.zhang@huawei.com>, Luonengjun <luonengjun@huawei.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Zanghongyong <zanghongyong@huawei.com>, Avi Kivity <avi.kivity@gmail.com>, "Jinxin (F)" <jinxin712@huawei.com>

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.

--
			Gleb.