From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Leedom Subject: Re: KVM vs. PCI-E Function Level Reset (FLR) ... Date: Fri, 16 Jul 2010 10:29:31 -0700 Message-ID: <201007161029.31768.leedom@chelsio.com> References: <201007131341.01669.leedom@chelsio.com> <201007150839.37130.leedom@chelsio.com> <201007160856.10622.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, linux-pci@vger.kernel.org, qemu-devel@nongnu.org To: Sheng Yang Return-path: Received: from stargate.chelsio.com ([67.207.112.58]:22547 "EHLO stargate.chelsio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754249Ab0GPRcD (ORCPT ); Fri, 16 Jul 2010 13:32:03 -0400 In-Reply-To: <201007160856.10622.sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: | 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