From owner-freebsd-stable@FreeBSD.ORG Fri Sep 7 16:53:04 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 794861065672 for ; Fri, 7 Sep 2012 16:53:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D64C8FC1A for ; Fri, 7 Sep 2012 16:53:04 +0000 (UTC) Received: by vbmv11 with SMTP id v11so4934510vbm.13 for ; Fri, 07 Sep 2012 09:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8vCes1xlQg91AZ/7Xz9k27DCJwPRb52pBbc9c2bv/dU=; b=0xSKFulBXg9roiGXt0osqQ/nxhAk7ZoqAhF/XAcFn0ia7OQ3NtC28LXY2jAm+RC2j7 dAyTgXh/iE+j02KFdyATlqliuXI7k2UCzbm7AhkINy5sLI2qvbBNS9qVIezraWFz48Bp PVwC8kTTIJqcNBnTjXo9qgkiuTTXB5B5SFg0N6cXK5LPXMh+6sBzKu9URiOKu4Q4TySR Gig6bdMdTJAGtyCQlHzZyRAv4oYdXkx9O5BsenF9O8DAYldjgAqrywYUxJOe/+ucKGul F8HA3jP0WbJAhb4XcUX0ND12HkIegZIVWyQyJD2C7muPq7XTO+Y/k56ZIuK9tcxRXhof Zsvg== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr6289322vdi.51.1347036782901; Fri, 07 Sep 2012 09:53:02 -0700 (PDT) Received: by 10.58.68.8 with HTTP; Fri, 7 Sep 2012 09:53:02 -0700 (PDT) In-Reply-To: <5049ECAF.3020709@omnilan.de> References: <50491E26.1010106@omnilan.de> <5049ECAF.3020709@omnilan.de> Date: Fri, 7 Sep 2012 09:53:02 -0700 Message-ID: From: Jack Vogel To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: intel 82579 nic support? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:53:04 -0000 OH, now things are clearer, this is a client part, and it is supported by the em driver, I don't know why loading igb would have any effect. If you load native FreeBSD 8.3 or 9.1 this device should work. The only case where you "pass through" a PCI device to a VM guest that I am familiar with is using Linux/KVM and SRIOV, meaning you give the guest a VF, this support is in the igb and ixgbe drivers. This device is in the chipset, so I was told that a) passing it thru is problematic because its not really a standalone NIC, and it is probably dependent on resources in the chipset that are not being given to the guest, b) there is no real gain with this hardware doing this, you can get performance using the normal virtual device connection. Bottom line, its possible this could be made to work, but I've not done it, and its not something I'm able to support. Regards, Jack On Fri, Sep 7, 2012 at 5:46 AM, Harald Schmalzbauer < h.schmalzbauer@omnilan.de> wrote: > schrieb Jack Vogel am 07.09.2012 00:27 (localtime): > > 82579 is not a NIC, its a PHY, and it you look at the current code you > > will see the support > > is in there. So the real question is what the actual NIC is, how about > > a pciconf -lv? > > > > Next, how are you trying "to pass through the device into my FreeBSD > > VM", what is > > the virtualization environment. > > > > Widely spread, uh ya, but not virtualized, so tell me more about the > > environment. > > Thanks for your reply. I didn't know that this phy is officially > supported, so I haven't provided any info. > But I'm happy you asked for: > > PassThrough is done as PCI dev, with VT-d and DMA support (have been > using that for SAS controllers many times and FreeBSD sees the devices > like without vmware in between on the same maschine) > According to VMware, the phy is 82579LM > With "if_em" in the kernel and the 82579 configured as PCI-passthrough I > get these lines at boot time: > em2: port 0x7000-0x701f mem > 0xd6720000-0xd673ffff,0xd6702000-0xd6702fff irq 18 at device 0.0 on pci6 > em2: Memory Access and/or Bus Master bits were not set! > em2: Using an MSI interrupt > em2: Setup of Shared code failed > device_attach: em2 attach returned 6 > (em0+1 are virtual-HW devices, em2 thy physical PCI-passthrough) > > Now if I kldload "if_igb", it seems to also try to attach to the 82579 > (at least kernel prints these lines (again)): > em2: port 0x7000-0x701f mem > 0xd6720000-0xd673ffff,0xd6702000-0xd6702fff irq 18 at device 0.0 on pci6 > em2: Memory Access and/or Bus Master bits were not set! > em2: Using an MSI interrupt > em2: Setup of Shared code failed > device_attach: em2 attach returned 6 > > Disabling MSI (MSIX) hasn't changed anythin. > > Here's the pciconf: > em1@pci0:5:0:0: class=0x020000 card=0x07d015ad chip=0x10d38086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '82574L Gigabit Network Connection' > class = network > subclass = ethernet > none1@pci0:6:0:0: class=0x020000 card=0x35788086 chip=0x15028086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '82579LM Gigabit Network Connection' > class = network > subclass = ethernet > > Thanks you for your attention! > > -Harry > >