From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59519 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZolX-00071I-3E for qemu-devel@nongnu.org; Fri, 16 Jul 2010 13:32:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZolV-00081B-N7 for qemu-devel@nongnu.org; Fri, 16 Jul 2010 13:32:02 -0400 Received: from stargate.chelsio.com ([67.207.112.58]:24398) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZolV-00080u-FR for qemu-devel@nongnu.org; Fri, 16 Jul 2010 13:32:01 -0400 From: Casey Leedom Date: Fri, 16 Jul 2010 10:29:31 -0700 References: <201007131341.01669.leedom@chelsio.com> <201007150839.37130.leedom@chelsio.com> <201007160856.10622.sheng@linux.intel.com> In-Reply-To: <201007160856.10622.sheng@linux.intel.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007161029.31768.leedom@chelsio.com> Subject: [Qemu-devel] Re: KVM vs. PCI-E Function Level Reset (FLR) ... List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sheng Yang Cc: linux-pci@vger.kernel.org, qemu-devel@nongnu.org, kvm@vger.kernel.org | From: Sheng Yang | Date: Thursday, July 15, 2010 05:56 pm | | Yeah, the detection of reset is not that straightforward... Maybe we need | an ioctl for reset event in qemu-kvm kvm_reset_vcpu(). | | We don't need assign/deassign device when reboot/reset, we only need to | notify KVM that the reset is happening, then KVM know what's to do. I'm not familiar enough with the KVM/QEmu to know where how to make these changes easily. I'd be happy to test such changes or even take a whack at making the changes if someone could point me at the relevant repositories/files. Alternatively, I could file a bug if KVM has its own bug database ... | > [Calling pci_reset_function() in our driver->probe() routine] was | > mostly for device driver load/unload support. I.e. being able | > to issue a Function Level Reset to a PCI Device Function (regardless of | > it being an SR-IOV Virtual Function or not) is a nice way to zap the | > device back to a canonical state. | | OK. | | What I meant was, before your driver, there is no such requirement in the | code. And no one can predict every usage of the code in the future, so | it's quite reasonable you called the "deadlock" is there. And I can't say | it's a "deadlock" because there is no code in the current tree make it | "deadlock" IIUR. | | So now you have this requirement, you can modify it to fit your need. | That's quite straightforward... | | > Oh, and the driver has been posted to net-next. I'm guessing that it | > | > _should_ get merged into 2.6.35 ... or maybe 2.6.36 ... I'm really not | > sure of how the merge schedule between net-next and the core kernel runs | > ... | | That's good. So you can modify the function to provide a lockless version. | That make sense now. :) Okay, I'll ask Yu Zhao why he added the lock in pci_dev_reset() (changeset 8c1c699fec9e9021bf6ff0285dee086bb27aec90) and if he feels that adding a non- locking path would make sense -- this is an area of the kernel which I've only perused so I don't want to propose random changes ... :-) Casey