lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 14 Aug 2014 08:39:23 -0700
From:	John Fastabend <>
To:	Yoann Juet <>,
	John Fastabend <>
CC:	"" <>,
	Yoann Juet <>
Subject: Re: ixgbe: SR-IOV, macvlan filter on VFs

On 08/14/2014 08:27 AM, Yoann Juet wrote:
>> hmm this should work I think.
>> Did you set the VF mac address at some point with,
>>      ip link set dev DEVICE vf NUM mac ADDR
>> If not this how did you setup the virtual functions? Manually via
>> sriov_numvfs? Or via libvirt or other library.
> I'm using libvirt with interface type 'network' or 'hostdev'. The mac
> address is optional within this configuration block. But, If omitted,
> it's automatically generated. Even if I could set the mac address via
> the 'ip link' command (not very practical with libvirt but possible),
> Keepalived still needs two mac addresses per VF. From the guest
> perspective:
>     - ethX: @mac1, @ip1
>     - macvlanX<->ethX: @mac2 (vmac), @ip2 (vip)
> Correct me if I'm wrong, the command 'ip link set dev DEVICE vf NUM mac ADDR' can only set one mac per VF.

Right this seems to be the case. My guess is libvirt uses the IFLA_VF_MAC
attribute to set the MAC from the host side. After this is done the PF
driver will deny any additional MAC requests from the VF which is where
you get that error message.

I need to check the libvirt theory but if that is the case I'm not sure
what the best fix off hand is. Maybe an option to libvirt not to set the
MAC via the PF. The other option would be to add another knob to allow the
setting of MAC addrs from the VF via 'ip link' similar to the TX spoofing
bit already in place. Both would presumably resolve your use case.

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists