On Tue, 20 Sep 2016 09:28:57 +0800
Wei Xu <w...@redhat.com> wrote:

> Hi Guys,
> I'm trying to pass through a rtl8168 nic to linux guest on my laptop 
> recently, the link is directly connected to my notebook with a cable.
> qemu: 2.7.0-rc4
> host/guest kernel: 4.7.0-rc5
> driver name: r8169
> After binding the driver to vfio-pci and launching the VM for a few 
> seconds, the connection led on the nic was turned off, and the guest
> only see a link down nic with below messages.
> [    6.173188] r8169 0000:00:04.0 ens4: rtl_phy_reset_cond == 1 (loop: 
> 100, delay: 1).
> [    6.177234] r8169 0000:00:04.0 ens4: link down
> [    6.177592] r8169 0000:00:04.0 ens4: link down
> [    6.177889] IPv6: ADDRCONF(NETDEV_UP): ens4: link is not ready
> It's quite similar as below bug except it's for windows driver while
> i'm testing linux.
> https://bugs.launchpad.net/qemu/+bug/1384892
> More info:
> My vm image is a pre-installed fedora 22 desktop, i also tried a fresh 
> fedora live iso, looks it can load the driver correctly.
> I tried to disable auto negotiation for the link but it didn't work for me.
> I did the same test with my notebook with a Intel I218-LM ethernet 
> controller, it works pretty well every time.
> I googled around and looks it happened to bare metal too, so just wonder
> if this is a bug of network-manager, or is being caused by the nic 
> driver or an issue in qemu/kernel vfio, anybody can help?

Realtek nics don't work well with device assignment, they barely work
well on bare metal.  Stick with the Intel nic or just use the rtl nic
with virtio.  I've spent longer than I care to admit on the rtl quirks
we have in QEMU and I expect they still only work with a few devices.


vfio-users mailing list

Reply via email to