From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: virtio config access races Date: Fri, 13 Jul 2012 13:25:15 +0930 Message-ID: <871ukgz55o.fsf@rustcorp.com.au> References: <20120712225941.GA9317@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: virtualization@lists.linux-foundation.org, kvm@vger.kernel.org To: "Michael S. Tsirkin" Return-path: Received: from ozlabs.org ([203.10.76.45]:34047 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751530Ab2GMESw (ORCPT ); Fri, 13 Jul 2012 00:18:52 -0400 In-Reply-To: <20120712225941.GA9317@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, 13 Jul 2012 01:59:41 +0300, "Michael S. Tsirkin" wrote: > It looks like there's a problem in the way virtio config currently > works: if driver reads config in probe routine, config > subsequently can change before core sets DRIVER_OK. > This will not cause an interrupt and so this event is lost. > Maybe we should document that devices should delay such > events until after DRIVER_OK? The device is currently defined to be active from the time we acknowledge the features (which means we may get a spurious interrupt before we probe, I think). We abuse this for virtio_blk for example, where we add_disk() inside the probe function. Hmm, the changed interrupt is live from find_vqs, right? Perhaps we should leave it to drivers to set that up in the right order. Thoughts? Rusty.