From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39213) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bw3hw-0002gu-W3 for qemu-devel@nongnu.org; Mon, 17 Oct 2016 04:55:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bw3hs-00050L-US for qemu-devel@nongnu.org; Mon, 17 Oct 2016 04:55:45 -0400 Received: from [59.151.112.132] (port=38853 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bw3hr-0004wp-QO for qemu-devel@nongnu.org; Mon, 17 Oct 2016 04:55:40 -0400 References: <1476443819-10347-1-git-send-email-caoj.fnst@cn.fujitsu.com> <20161014095030.1c7c93c7@t450s.home> From: Cao jin Message-ID: <58049264.5000002@cn.fujitsu.com> Date: Mon, 17 Oct 2016 16:57:08 +0800 MIME-Version: 1.0 In-Reply-To: <20161014095030.1c7c93c7@t450s.home> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] vfio: fix duplicate function call List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: qemu-devel@nongnu.org Hi, On 10/14/2016 11:50 PM, Alex Williamson wrote: > On Fri, 14 Oct 2016 19:16:59 +0800 > Cao jin wrote: > >> When vfio device is reset(encounter FLR, or bus reset), if need to do >> bus reset(vfio_pci_hot_reset_one is called), vfio_pci_pre_reset & >> vfio_pci_post_reset will be called twice. >> >> Signed-off-by: Cao jin >> --- >> Also has a little question on vfio_pci_reset. it will be called when encounter >> bus reset, or FLR. The reset method's priority in this function now is: >> >> 1. If has "device specific reset function", then do it >> 2. If has FLR, then do it. >> 3. If it can do bus reset(only 1 affected device), then do it >> 4. If has pm_reset, then do it >> >> The question is: why pm reset has low priority than bus reset(if it does >> can do a bus reset)? why bus reset is not the last choice? In PCI driver >> of kernel, pls see __pci_dev_reset, we can see, if device support pm reset, >> it won't do bus reset. > > The PCI spec doesn't really define what sort of reset is done with a PM > reset. My thinking was that if a device advertises an FLR capability > then the hardware has made a concerted effort to have a per function > reset mechanism available. NoSoftRst- is not terribly common and it's > not entirely clear to me that the hardware has made a conscious effort > to provide this for the purposes of per function reset mechanism. > Therefore I've opt'd to prioritize a bus reset over a PM reset. > I still have a question about vfio_pci_reset. I checked commit message in f16f39c3, if I understand right, couldn't we put /* See if we can do our own bus reset */ if (!vfio_pci_hot_reset_one(vdev)) { goto post_reset; } in the 1st priority? Because if there is 1 affected device, then it will do bus reset which is the best reset we can do; if there are more than 1 affected devices, after this patch, vfio_pci_hot_reset_one will do nothing, and then try other reset methods. -- Yours Sincerely, Cao jin