From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH v2] igb: Allow to remove administratively set MAC on VFs
Date: Fri, 07 Apr 2017 12:06:15 -0700 [thread overview]
Message-ID: <1491591975.39459.1.camel@intel.com> (raw)
In-Reply-To: <20170405134622.12227-1-vinschen@redhat.com>
On Wed, 2017-04-05 at 15:46 +0200, Corinna Vinschen wrote:
> ? Before libvirt modifies the MAC address and vlan tag for an SRIOV
> VF
> ? for use by a virtual machine (either using vfio device assignment
> or
> ? macvtap passthru mode), it saves the current MAC address and vlan
> tag
> ? so that it can reset them to their original value when the guest is
> ? done.? Libvirt can't leave the VF MAC set to the value used by the
> ? now-defunct guest since it may be started again later using a
> ? different VF, but it certainly shouldn't just pick any random
> value,
> ? either. So it saves the state of everything prior to using the VF,
> and
> ? resets it to that.
>
> ? The igb driver initializes the MAC addresses of all VFs to
> ? 00:00:00:00:00:00, and reports that when asked (via an RTM_GETLINK
> ? netlink message, also visible in the list of VFs in the output of
> "ip
> ? link show"). But when libvirt attempts to restore the MAC address
> back
> ? to 00:00:00:00:00:00 (using an RTM_SETLINK netlink message) the
> kernel
> ? responds with "Invalid argument".
>
> ? Forbidding a reset back to the original value leaves the VF MAC at
> the
> ? value set for the now-defunct virtual machine. Especially on a
> system
> ? with NetworkManager enabled, this has very bad consequences, since
> ? NetworkManager forces all interfacess to be IFF_UP all the time -
> if
> ? the same virtual machine is restarted using a different VF (or even
> on
> ? a different host), there will be multiple interfaces watching for
> ? traffic with the same MAC address.
>
> ? To allow libvirt to revert to the original state, we need a way to
> ? remove the administrative set MAC on a VF, to allow normal host
> ? operation again, and to reset/overwrite the VF MAC via VF netdev.
>
> ? This patch implements the outlined scenario by allowing to set the
> ? VF MAC to 00:00:00:00:00:00 via RTM_SETLINK on the PF.
> ? igb_ndo_set_vf_mac resets the IGB_VF_FLAG_PF_SET_MAC flag to 0,
> ? so it's possible to reset the VF MAC back to the original value via
> ? the VF netdev.
>
> ? Note: Recent patches to libvirt allow for a workaround if the NIC
> ? isn't capable of resetting the administrative MAC back to all 0,
> but
> ? in theory the NIC should allow resetting the MAC in the first
> place.
>
> Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
> ---
> ?drivers/net/ethernet/intel/igb/igb_main.c | 42
> +++++++++++++++++++++++--------
> ?1 file changed, 31 insertions(+), 11 deletions(-)
This patch does not apply (not even close). Please make sure to base
you patch off my dev-queue branch of my next-queue tree on kernel.org.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20170407/33afc844/attachment.asc>
WARNING: multiple messages have this Message-ID (diff)
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: Corinna Vinschen <vinschen@redhat.com>,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
Alexander Duyck <alexander.duyck@gmail.com>,
Duyck@vinschen.de, Alexander H <alexander.h.duyck@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH v2] igb: Allow to remove administratively set MAC on VFs
Date: Fri, 07 Apr 2017 12:06:15 -0700 [thread overview]
Message-ID: <1491591975.39459.1.camel@intel.com> (raw)
In-Reply-To: <20170405134622.12227-1-vinschen@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]
On Wed, 2017-04-05 at 15:46 +0200, Corinna Vinschen wrote:
> Before libvirt modifies the MAC address and vlan tag for an SRIOV
> VF
> for use by a virtual machine (either using vfio device assignment
> or
> macvtap passthru mode), it saves the current MAC address and vlan
> tag
> so that it can reset them to their original value when the guest is
> done. Libvirt can't leave the VF MAC set to the value used by the
> now-defunct guest since it may be started again later using a
> different VF, but it certainly shouldn't just pick any random
> value,
> either. So it saves the state of everything prior to using the VF,
> and
> resets it to that.
>
> The igb driver initializes the MAC addresses of all VFs to
> 00:00:00:00:00:00, and reports that when asked (via an RTM_GETLINK
> netlink message, also visible in the list of VFs in the output of
> "ip
> link show"). But when libvirt attempts to restore the MAC address
> back
> to 00:00:00:00:00:00 (using an RTM_SETLINK netlink message) the
> kernel
> responds with "Invalid argument".
>
> Forbidding a reset back to the original value leaves the VF MAC at
> the
> value set for the now-defunct virtual machine. Especially on a
> system
> with NetworkManager enabled, this has very bad consequences, since
> NetworkManager forces all interfacess to be IFF_UP all the time -
> if
> the same virtual machine is restarted using a different VF (or even
> on
> a different host), there will be multiple interfaces watching for
> traffic with the same MAC address.
>
> To allow libvirt to revert to the original state, we need a way to
> remove the administrative set MAC on a VF, to allow normal host
> operation again, and to reset/overwrite the VF MAC via VF netdev.
>
> This patch implements the outlined scenario by allowing to set the
> VF MAC to 00:00:00:00:00:00 via RTM_SETLINK on the PF.
> igb_ndo_set_vf_mac resets the IGB_VF_FLAG_PF_SET_MAC flag to 0,
> so it's possible to reset the VF MAC back to the original value via
> the VF netdev.
>
> Note: Recent patches to libvirt allow for a workaround if the NIC
> isn't capable of resetting the administrative MAC back to all 0,
> but
> in theory the NIC should allow resetting the MAC in the first
> place.
>
> Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 42
> +++++++++++++++++++++++--------
> 1 file changed, 31 insertions(+), 11 deletions(-)
This patch does not apply (not even close). Please make sure to base
you patch off my dev-queue branch of my next-queue tree on kernel.org.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-04-07 19:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 15:10 [Intel-wired-lan] [PATCH] igb: Allow to remove administratively set MAC on VFs Corinna Vinschen
2017-04-04 15:10 ` Corinna Vinschen
2017-04-04 17:16 ` [Intel-wired-lan] " Duyck, Alexander H
2017-04-04 17:16 ` Duyck, Alexander H
2017-04-04 17:33 ` Alexander Duyck
2017-04-04 17:33 ` Alexander Duyck
2017-04-05 9:13 ` Corinna Vinschen
2017-04-05 9:13 ` Corinna Vinschen
2017-04-05 12:53 ` Alexander Duyck
2017-04-05 13:46 ` [Intel-wired-lan] [PATCH v2] " Corinna Vinschen
2017-04-05 13:46 ` Corinna Vinschen
2017-04-07 19:06 ` Jeff Kirsher [this message]
2017-04-07 19:06 ` [Intel-wired-lan] " Jeff Kirsher
2017-04-10 8:55 ` Corinna Vinschen
2017-04-10 8:55 ` Corinna Vinschen
2017-04-10 8:58 ` [Intel-wired-lan] [PATCH v3] " Corinna Vinschen
2017-04-10 8:58 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1491591975.39459.1.camel@intel.com \
--to=jeffrey.t.kirsher@intel.com \
--cc=intel-wired-lan@osuosl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.