From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvmxQ-0004I8-7B for qemu-devel@nongnu.org; Tue, 02 Dec 2014 07:53:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XvmxG-0006qQ-GN for qemu-devel@nongnu.org; Tue, 02 Dec 2014 07:53:32 -0500 Received: from mout.gmx.net ([212.227.17.20]:49453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XvmxG-0006po-7W for qemu-devel@nongnu.org; Tue, 02 Dec 2014 07:53:22 -0500 Received: from lucio-pc ([85.177.146.218]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LnPnu-1YNgWk0WL8-00hhdy for ; Tue, 02 Dec 2014 13:53:20 +0100 Date: Tue, 2 Dec 2014 13:53:11 +0100 From: Lucio =?UTF-8?B?QW5kcsOpcw==?= Illanes Albornoz Message-ID: <20141202135311.4a4fdf04@lucio-pc> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] AMD video card passthrough reset issues List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hello, I'm doing secondary VGA passthrough with an AMD Radeon R7 260X using QEMU = v2.1.2 w/ KVM and VFIO on Debian v7.7 (wheezy) (qemu v2.1+dfsg-5~bpo70+1 fr= om wheezy-backports) and kernel version 3.16.5 (from wheezy-backports as we= ll) and Windows 8.1 Update 1 (x64) as the guest OS. At present, rebooting the VM reproducibly has Windows fail to enable/start = said video card upon bootup w/ an error code of 43, as seems to be the case= w/ mostly everyone else running a comparable configuration; disabling/ejec= ting it before rebooting/powering down the VM from within the guest, as wit= h everyone else, has proven to be a reliable mitigation. However, being tha= t there are scenarios where this is either not feasible or impossible altog= ether, short of if done through a service or kernel-mode driver (and even t= hen,) I had intended to investigate the causes behind this issue. Unfortunately, the flu got to me first (so to speak.) I did notice that sim= ply removing the PCI device in question and then causing a PCI bus (re)scan= (both) through sysfs on the host in between VM reboots/power cycles is eff= ectively equivalent to disabling it within the guest. Thus, I find myself w= ondering precisely what it is that does take place when doing so vs. when Q= EMU performs a `hot reset' through the corresponding interface in drivers/v= fio/pci/; evidently, the difference must be of sufficient importance since = the latter mechanism ends up leaving my video card unavailable for subseque= nt VM operation until the next host reboot. I should very much appreciate any hints concerning whether it would be poss= ible to have QEMU/VFIO perform whatever need be done itself or if it should= be possible to have this be done by either itself. Cheers Lucio Andr=C3=A9s Illanes Albornoz