Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 7 Sep 2012 09:53:02 -0700
From:      Jack Vogel <jfvogel@gmail.com>
To:        Harald Schmalzbauer <h.schmalzbauer@omnilan.de>
Cc:        stable@freebsd.org
Subject:   Re: intel 82579 nic support?
Message-ID:  <CAFOYbcmoTR6EyxJR0KGCCE3Yjodh7jQYezFtM2tuuMCT2mjhrw@mail.gmail.com>
In-Reply-To: <5049ECAF.3020709@omnilan.de>
References:  <50491E26.1010106@omnilan.de> <CAFOYbcmS1jG0e5jxV0GoD7YoV9=OwJxXdY1EO6yZVmAGZm=A%2BA@mail.gmail.com> <5049ECAF.3020709@omnilan.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <Intel(R) PRO/1000 Network Connection 7.3.2> 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: <Intel(R) PRO/1000 Network Connection 7.3.2> 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
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFOYbcmoTR6EyxJR0KGCCE3Yjodh7jQYezFtM2tuuMCT2mjhrw>