From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755418Ab1HYTHF (ORCPT ); Thu, 25 Aug 2011 15:07:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27061 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755306Ab1HYTHB (ORCPT ); Thu, 25 Aug 2011 15:07:01 -0400 Date: Thu, 25 Aug 2011 22:07:49 +0300 From: "Michael S. Tsirkin" To: Jan Kiszka Cc: Brian King , Linux Kernel Mailing List , "linux-pci@vger.kernel.org" , Alex Williamson , Jesse Barnes , Matthew Wilcox Subject: Re: Broken pci_block_user_cfg_access interface Message-ID: <20110825190748.GA30587@redhat.com> References: <4E54D5D7.8050807@siemens.com> <4E551298.2000302@linux.vnet.ibm.com> <4E5613BA.5070101@siemens.com> <4E5647DA.1060901@linux.vnet.ibm.com> <4E5648B9.7050106@siemens.com> <20110825181912.GB27183@redhat.com> <4E5699D8.3070505@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5699D8.3070505@web.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 25, 2011 at 08:52:08PM +0200, Jan Kiszka wrote: > On 2011-08-25 20:19, Michael S. Tsirkin wrote: > > On Thu, Aug 25, 2011 at 03:06:01PM +0200, Jan Kiszka wrote: > >>> I took a look at the sysfs triggered pci reset function and don't see any way > >>> that the controlling device driver ever gets to be involved in this reset. > >>> If code outside the ipr driver were to reset the adapter, the adapter firmware > >>> would be left in an uninitialized state and until scsi core starts timing > >>> out ops and driving EH, the card would be unusable. I can't imagine the > >>> ipr driver is unique in this. > >> > >> Right, that's why a PCI core service is needed for coordination. > >> > >> Jan > > > > But why do we want to trigger reset through sysfs while the > > driver runs? > > A perfectly valid race conditions are created by KVM and VFIO: shared > IRQ handler is triggered while the user space part wants to reset the > assigned device. OK, that would be solved by blocking sysfs reset while config access is blocked, right? > I'm quite sure that this how I first caused this bug to > show up (it triggered for an assigned device with a shared busy IRQ line > during QEMU startup, ie. the initial guest reset). > > Jan >