From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Inconsistent use of libxl__device_pci_reset() when adding/removing all functions of a device Date: Tue, 4 Feb 2014 14:55:51 -0500 Message-ID: <20140204195551.GA14122@phenom.dumpdata.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Martin =?iso-8859-1?Q?=D6hrling?= , linux@eikelenboom.it Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Tue, Feb 04, 2014 at 07:19:16PM +0100, Martin =D6hrling wrote: > I tried to use vga passthrough with an AMD card and ran into the issues > with dom0 crash on domU reboot. My intention is to debug the issue and I > have started to read up on the code for pci passthrough. The following > observations may not be an error but perhaps someone could shed some light > over the design intentions. > = > My first impression was that libxl__device_pci_reset() is a function level > reset function. It is called each time a single function of a device is > added or removed. A device reset would break other domU:s if other > functions of the device are passed through to these domU:s. > = > The strange thing is that there is only a single libxl__device_pci_reset() > call when pcidev->vfunc_mask is set to LIBXL_PCI_FUNC_ALL. I'm getting the > impression that the function is assumed to be a device reset function. > = > Is the attempt to reset a function, when all other functions belongs to > pciback, detected and replaced by a device reset? Yes with these patches: https://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=3Ddevel/= xen-pciback.slot_and_bus.v0 But the last one seems to hang pciback when the device is unbound. > = > Best Regards, > Martin > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel