From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [Bug 55421] igb VF can't work in KVM guest Date: Thu, 21 Mar 2013 16:21:21 -0600 Message-ID: <1363904481.14627.13.camel@ul30vt.home> References: <20130321212909.537AC11F7D1@bugzilla.kernel.org> <1363901518.14627.1.camel@ul30vt.home> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: "Williams, Mitch A" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:22826 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753664Ab3CUWVX (ORCPT ); Thu, 21 Mar 2013 18:21:23 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 2013-03-21 at 22:03 +0000, Williams, Mitch A wrote: > Thanks for the FYI, Alex. When we pushed this patch upstream, there > was a corresponding patch to igbvf that was pushed at the same time. > With this patch, the VFs detect the zero address and generate a random > MAC address themselves. The reason for this change is to make the VFs > play nicely with udev. The issue was originally raised by Stefan > Assmann. > > With older drivers in the guest, this will cause the issue you noted. > Distros should cherry-pick the corresponding VF patch. I agree the random MAC doesn't play nicely with udev, although I have found that my guest stops adding new persistent net rules after eth680 ;) Arguably anyone using VFs for more than testing should already be assigning a stable MAC address, but I don't really think a guest driver update across every possible guest OS is all that practical. At least that explains why igbvf in the host is unaffected though. Should we expect a Code 10 (device cannot start) from the Windows igbvf driver when it finds a zero'd MAC? Thanks, Alex > > -----Original Message----- > > From: Alex Williamson [mailto:alex.williamson@redhat.com] > > Sent: Thursday, March 21, 2013 2:32 PM > > To: Williams, Mitch A > > Cc: kvm@vger.kernel.org > > Subject: Re: [Bug 55421] igb VF can't work in KVM guest > > > > Mitch, > > > > Bugzilla wouldn't let me add you to the CC, so FYI... > > Thanks, > > > > Alex > > > > On Thu, 2013-03-21 at 21:29 +0000, bugzilla-daemon@bugzilla.kernel.org > > wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=55421 > > > > > > > > > Alex Williamson changed: > > > > > > What |Removed |Added > > > -------------------------------------------------------------------------- > > -- > > > CC| > > |alex.williamson@redhat.com, > > > | > > |jeffrey.t.kirsher@intel.com > > > > > > > > > > > > > > > --- Comment #4 from Alex Williamson 2013-03- > > 21 21:29:09 --- > > > Further bisected to: > > > > > > commit 5ac6f91d39e0884813dc010e14552143cd1d0d8b > > > Author: Mitch A Williams > > > Date: Fri Jan 18 08:57:20 2013 +0000 > > > > > > igb: Don't give VFs random MAC addresses > > > > > > If the user has not assigned a MAC address to a VM, then don't give it > > a > > > random one. Instead, just give it zeros and let it figure out what to > > do > > > with them. > > > > > > Signed-off-by: Mitch Williams > > > CC: Andy Gospodarek > > > CC: Stefan Assmann > > > Tested-by: Aaron Brown > > > Tested-by: Stefan Assmann > > > Signed-off-by: Jeff Kirsher > > > > > > So, for whatever reason we no longer assign a random MAC address when > > using the > > > device in a VM (but we do still use one if attached to igbvf in the host). > > I > > > expect we'll eventually see this on all the Intel SR-IOV NICs. The > > solution is > > > to use the ip command to assign the VF a valid MAC address prior to using > > it > > > with KVM. I'll let those who made the change defend it further if they > > wish. > > > > >