From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGLQH-00066X-DC for qemu-devel@nongnu.org; Fri, 24 Jun 2016 03:21:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGLQC-00049K-9w for qemu-devel@nongnu.org; Fri, 24 Jun 2016 03:21:04 -0400 Received: from indium.canonical.com ([91.189.90.7]:37898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGLQC-00049G-4J for qemu-devel@nongnu.org; Fri, 24 Jun 2016 03:21:00 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.76 #1 (Debian)) id 1bGLQ9-0000GU-V7 for ; Fri, 24 Jun 2016 07:20:58 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id BAECB2E80D8 for ; Fri, 24 Jun 2016 07:20:55 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Jun 2016 07:15:03 -0000 From: Thorsten Kohfeldt Reply-To: Bug 1384892 <1384892@bugs.launchpad.net> Sender: bounces@canonical.com References: <20141023194249.8096.62457.malonedeb@chaenomeles.canonical.com> <20160622111056.22171.10037.malone@soybean.canonical.com> Message-Id: <576CDDF7.2040702@gmx.de> Errors-To: bounces@canonical.com Subject: Re: [Qemu-devel] [Bug 1384892] Re: RTL8168 NIC VFIO not working anymore since QEMU 2.1 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Current QEMU code is quite different now. When I tested last (with QEMU 2.4) the problem still existed. I had quite a discussion with Alex up to and around end of 2015, but unfortunately since then I just did not have any spare time to convince Alex to accept what I call 'the real fix', a series of patches. I also could not test QEMU2.5 yet, but it does not *look* like it = contains any additional fix towards the problem. Just a hint about the 'underlying' problem: Several subtypes of that card hang up DURING loading the assigned = firmware, as QEMU does not correctly map all required i/o areas for supporting the firmware load (unless i/o mmap is disabled). The cards need to be power cycled then, reset is not enough. The correct mapping cannot really be derived from looking at the Linux driver code - it is rather to be deduced from access traces. If a firmware is NOT accessible, the card doesn't hang, but also it is running 'unpatched' i.e. might expose bugs that the hardware designer/manufacturer has detected and fixed via firmware. A better workaround is disabling i/o mmap when VFIO-attaching the card. This is supported by newer QEMU versions. So no, the problem is not fixed yet, but yes, I guess you can close this bug if you feel like it. Regards Am 22.06.2016 um 13:10 schrieb T. Huth: > Alex' patch has been included here: > http://git.qemu.org/?p=3Dqemu.git;a=3Dcommitdiff;h=3D69970fcef937bddd7f745 > ... so I assume this ticket could be closed now? -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1384892 Title: RTL8168 NIC VFIO not working anymore since QEMU 2.1 Status in QEMU: New Bug description: After upgrading QEMU from 2.0 to 2.1 (and libiscsi from 1.7.0 to 1.12 as = a dependency) my two RTL8168 NICs stopped working. The NICs do not respond to any command and even the LEDs on the network c= onnection turn off, a few seconds after the VM started. To get them back running I had to downgrade to 2.0 and restart the system. Unfortunately, I have no clue what to do or how to debug this problem sin= ce there are no specific errors logged. I tried two different VMs: Debian Wheezy and IPFire (see attachment for f= urther details). The QEMU 2.1 changelog states "Support for RTL8168 NICs." so there were s= ome major changes done, I guess. On the IPFire guest the kernel log shows many of these lines: r8169 0000:00:07.0 green1: rtl_eriar_cond =3D=3D 1 (loop: 100, delay: 100) r8169 0000:00:07.0 green1: rtl_phy_reset_cond =3D=3D 1 (loop: 100, delay:= 1) On the Debian guest there is only: r8169 0000:00:07.0: firmware: agent loaded rtl_nic/rtl8168e-3.fw into mem= ory r8169 0000:00:07.0: lan0: link down ADDRCONF(NETDEV_UP): lan0: link is not ready The commandline for IPFire can be seen in the attachment. It is the same = for Debian. There are also the complete kernel logs for the working (2.0) and non-wor= king (2.1) cases. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1384892/+subscriptions