From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Leedom Subject: KVM vs. PCI-E Function Level Reset (FLR) ... Date: Tue, 13 Jul 2010 13:41:01 -0700 Message-ID: <201007131341.01669.leedom@chelsio.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm@vger.kernel.org Return-path: Received: from stargate.chelsio.com ([67.207.112.58]:11511 "EHLO stargate.chelsio.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754491Ab0GMUlF (ORCPT ); Tue, 13 Jul 2010 16:41:05 -0400 Received: from maui.asicdesigners.com (maui.asicdesigners.com [10.192.180.15]) by stargate.chelsio.com (8.13.1/8.13.1) with SMTP id o6DKf3n1010463 for ; Tue, 13 Jul 2010 13:41:03 -0700 Sender: kvm-owner@vger.kernel.org List-ID: I've ground my way through most of the Linux kernel code supporting KVM and "Device Assignment" but I haven't been able to untangle the path of when/where PCI-E Function Level Resets (FLRs) are applied and what happens if the Virtual Machine OS/Driver attempts to perform an FLR on the PCI Pass Through Device. It looks like the Linux KVM kernel support code issues an FLR against an Assigned Device when the device is assigned and when it's freed but it's not clear when those actions are taken. For instance, if a device is assigned to a VM and then the VM reboots itself, is that counted as another assignment point? I.e. will KVM issue a new pci_reset_function() on the device so it shows up reset in the newly rebooted VM? And what happens if the VM OS/Driver attempts to write the PCI Pass Through Device's PCI-E FLR bit? I assume that that write (and the following polling reads) are trapped by the KVM code but I can't find the code which implements the PCI Configuration Space emulation to see if the FLR is implemented there. For instance, if I run Linux 2.6.30 in the VM and my Device Driver calls pci_reset_function() in its "probe()" function will that result in a Device FLR? it doesn't appear to be the case ... Note that it's impossible for a Device Driver to call pci_reset_function() under Linux 2.6.31 and later because a call to device_lock() was added to pci_dev_reset() in chageset 8e9394ce on Feb 17, 2010 by Greg Kroah-Hartman. This means that a call to pci_reset_function() in a device driver's "probe()" routine will result in an immediate deadlock. Thanks for any help and/or insight into these questions! Casey