From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wk33P-0005Me-LI for qemu-devel@nongnu.org; Mon, 12 May 2014 23:07:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wk33I-0005ru-NE for qemu-devel@nongnu.org; Mon, 12 May 2014 23:06:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35234) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wk33I-0005rJ-Ed for qemu-devel@nongnu.org; Mon, 12 May 2014 23:06:48 -0400 Message-ID: <1399950404.6734.147.camel@bling.home> From: Alex Williamson Date: Mon, 12 May 2014 21:06:44 -0600 In-Reply-To: <1399926513.6734.123.camel@bling.home> References: <20140510230225.17688.6353.stgit@bling.home> <20140512200237.GA2418@electric-eye.fr.zoreil.com> <1399926513.6734.123.camel@bling.home> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] vfio-pci: Quirk RTL8168 NIC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Francois Romieu Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On Mon, 2014-05-12 at 14:28 -0600, Alex Williamson wrote: > On Mon, 2014-05-12 at 22:02 +0200, Francois Romieu wrote: > > Alex Williamson : > > [...] > > > device MSI will be blocked. The Linux driver doesn't make use of this > > > window, so apparently it's not required to make use of MSI-X. This > > > > It does not really use MSI-X (no RSS). > > Oh right, I looked for code references to the register but didn't notice > that Linux configures it for MSI, not MSI-X. In my brief testing I only > saw that Windows generates interrupts on the first vector, so perhaps > not much lost without the extra vectors. I guess it's this patch that > proves that MSI-X can be configured without this backdoor then. Do you > have any insight into why this exists? > > > > quirk makes the device work with the Windows driver that does use this > > > window for MSI-X, but I certainly cannot recommend this device for > > > assignment (the Windows 7 driver also constantly pokes PCI config > > > space). > > > > Do you have some offsets for those ? > > I believe it was 0x80, which is 0x10 off from the PCIe capability, so > the link control register. I don't seem to have a log, but I'll > regenerate one tonight to get the exact sequence (the interface is in > use right now). As promised: vfio: vfio_pci_read_config(0000:05:00.0, @0x4, len=0x2) 507 vfio: vfio_pci_read_config(0000:05:00.0, @0x80, len=0x1) 40 vfio: vfio_pci_read_config(0000:05:00.0, @0x81, len=0x1) 0 vfio: vfio_pci_read_config(0000:05:00.0, @0x80, len=0x1) 40 vfio: vfio_pci_read_config(0000:05:00.0, @0x81, len=0x1) 0 vfio: vfio_pci_read_config(0000:05:00.0, @0x80, len=0x1) 40 vfio: vfio_pci_read_config(0000:05:00.0, @0x81, len=0x1) 0 The 80/81 access may happen asynchronous to the command register access, sometimes I see 3 sets between the command register access as above, sometimes 4. As I mentioned earlier, the PCIe cap is at 0x70: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards ... Capabilities: [70] Express Endpoint, MSI 01 So the cycle is: word read from command register: I/O+ Mem+ BusMaster+ DisINTx+ SERR+ byte read from PCIe link control register[0]: CommClk+ byte read from PCIe link control register[1]: nothing I'll be interested if that means anything to you. It's not a very high rate access, the command register access is maybe 1Hz. Thanks, Alex