pci passthrough - VF reset at boot is dropping assigned MAC

pci passthrough - VF reset at boot is dropping assigned MAC

[David Ahern]

Running qemu-kvm.git as of today (ffce28f, April 18, 2011) the virtual
function passed to the VM is losing its assigned mac address. That is,
prior to launching qemu-kvm, the following command is run to set the MAC
address:

ip link set dev eth2 vf 0 mac 02:12:34:56:79:20

Yet, when the VM boots the MAC address is random which is what happens
when the VF is reset. Looking through the commit logs between 0.13.0 --
the version in Fedora 14 -- and latest git I found the following:

commit d9488459ff2ab113293586c1c36b1679bb15deee
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Thu Mar 17 15:24:31 2011 -0600

    device-assignment: Reset device on system reset

    On system reset, we currently try to quiesce DMA by clearing the
    command register.  This assumes that nothing re-enables bus master
    support without first de-programming the device.  Use a bigger
    hammer to help the guest not shoot itself by issuing a function
    reset via sysfs on each system reset.

    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Acked-by: Chris Wright <chrisw@redhat.com>
    Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>


Is this the cause of the MAC address reset and is this behavior intended?

David

Re: pci passthrough - VF reset at boot is dropping assigned MAC

[Alex Williamson]

On Mon, 2011-04-25 at 10:28 -0600, David Ahern wrote:
> Running qemu-kvm.git as of today (ffce28f, April 18, 2011) the virtual
> function passed to the VM is losing its assigned mac address. That is,
> prior to launching qemu-kvm, the following command is run to set the MAC
> address:
> 
> ip link set dev eth2 vf 0 mac 02:12:34:56:79:20
> 
> Yet, when the VM boots the MAC address is random which is what happens
> when the VF is reset. Looking through the commit logs between 0.13.0 --
> the version in Fedora 14 -- and latest git I found the following:
> 
> commit d9488459ff2ab113293586c1c36b1679bb15deee
> Author: Alex Williamson <alex.williamson@redhat.com>
> Date:   Thu Mar 17 15:24:31 2011 -0600
> 
>     device-assignment: Reset device on system reset
> 
>     On system reset, we currently try to quiesce DMA by clearing the
>     command register.  This assumes that nothing re-enables bus master
>     support without first de-programming the device.  Use a bigger
>     hammer to help the guest not shoot itself by issuing a function
>     reset via sysfs on each system reset.
> 
>     Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>     Acked-by: Chris Wright <chrisw@redhat.com>
>     Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> 
> 
> Is this the cause of the MAC address reset and is this behavior intended?

Ugh, I hope not, it's certainly not an intended side effect.  Can you
see if the problem still happens if you revert this patch?  If it does,
we might need more device specific reset functions to save and restore
that extra bit of state.  I assume this is still the 82576 VF you were
asking about before?  Thanks,

Alex

Re: pci passthrough - VF reset at boot is dropping assigned MAC

[David Ahern]

On 04/25/11 10:37, Alex Williamson wrote:
> On Mon, 2011-04-25 at 10:28 -0600, David Ahern wrote:
>> Running qemu-kvm.git as of today (ffce28f, April 18, 2011) the virtual
>> function passed to the VM is losing its assigned mac address. That is,
>> prior to launching qemu-kvm, the following command is run to set the MAC
>> address:
>>
>> ip link set dev eth2 vf 0 mac 02:12:34:56:79:20
>>
>> Yet, when the VM boots the MAC address is random which is what happens
>> when the VF is reset. Looking through the commit logs between 0.13.0 --
>> the version in Fedora 14 -- and latest git I found the following:
>>
>> commit d9488459ff2ab113293586c1c36b1679bb15deee
>> Author: Alex Williamson <alex.williamson@redhat.com>
>> Date:   Thu Mar 17 15:24:31 2011 -0600
>>
>>     device-assignment: Reset device on system reset
>>
>>     On system reset, we currently try to quiesce DMA by clearing the
>>     command register.  This assumes that nothing re-enables bus master
>>     support without first de-programming the device.  Use a bigger
>>     hammer to help the guest not shoot itself by issuing a function
>>     reset via sysfs on each system reset.
>>
>>     Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>>     Acked-by: Chris Wright <chrisw@redhat.com>
>>     Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>
>>
>> Is this the cause of the MAC address reset and is this behavior intended?
> 
> Ugh, I hope not, it's certainly not an intended side effect.  Can you
> see if the problem still happens if you revert this patch?  If it does,

I commented out the write() in the reset function and indeed the mac
address was not reset on VM boot.

> we might need more device specific reset functions to save and restore
> that extra bit of state.  I assume this is still the 82576 VF you were
> asking about before?  Thanks,

Yes. I got distracted end of last week. Response to that thread coming soon.

David


> 
> Alex
> 
> 

Re: pci passthrough - VF reset at boot is dropping assigned MAC

[Alex Williamson]

On Mon, 2011-04-25 at 10:41 -0600, David Ahern wrote:
> 
> On 04/25/11 10:37, Alex Williamson wrote:
> > On Mon, 2011-04-25 at 10:28 -0600, David Ahern wrote:
> >> Running qemu-kvm.git as of today (ffce28f, April 18, 2011) the virtual
> >> function passed to the VM is losing its assigned mac address. That is,
> >> prior to launching qemu-kvm, the following command is run to set the MAC
> >> address:
> >>
> >> ip link set dev eth2 vf 0 mac 02:12:34:56:79:20
> >>
> >> Yet, when the VM boots the MAC address is random which is what happens
> >> when the VF is reset. Looking through the commit logs between 0.13.0 --
> >> the version in Fedora 14 -- and latest git I found the following:
> >>
> >> commit d9488459ff2ab113293586c1c36b1679bb15deee
> >> Author: Alex Williamson <alex.williamson@redhat.com>
> >> Date:   Thu Mar 17 15:24:31 2011 -0600
> >>
> >>     device-assignment: Reset device on system reset
> >>
> >>     On system reset, we currently try to quiesce DMA by clearing the
> >>     command register.  This assumes that nothing re-enables bus master
> >>     support without first de-programming the device.  Use a bigger
> >>     hammer to help the guest not shoot itself by issuing a function
> >>     reset via sysfs on each system reset.
> >>
> >>     Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> >>     Acked-by: Chris Wright <chrisw@redhat.com>
> >>     Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> >>
> >>
> >> Is this the cause of the MAC address reset and is this behavior intended?
> > 
> > Ugh, I hope not, it's certainly not an intended side effect.  Can you
> > see if the problem still happens if you revert this patch?  If it does,
> 
> I commented out the write() in the reset function and indeed the mac
> address was not reset on VM boot.

Ok, here's what I see on my system:

# modprobe igbvf
# dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
# modprobe -r igbvf
# echo 1 > /sys/bus/pci/devices/0000:01:11.5/reset
# modprobe igbvf
# dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c

So yes, it does change.  However, if I set the VF mac instead of using a
randomly generated one, I get:

# modprobe -r igbvf
# ip link set eth2 vf 6 mac 02:00:10:91:73:01
# modprobe igbvf
# dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
# modprobe -r igbvf
# echo 1 > /sys/bus/pci/devices/0000:01:11.5/reset
# modprobe igbvf
# dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
igbvf 0000:01:11.5: Address: 02:00:10:91:73:01

So now it sticks.  You're going to get random mac addresses on the VFs
every time you reload the igb driver (ie. ever boot) anyway (at least
with these sr-iov cards), so if you need consistent macs, they probably
need to be set before launching the VM anyway.  Thanks,

Alex

Re: pci passthrough - VF reset at boot is dropping assigned MAC

[David Ahern]

On 04/25/11 11:30, Alex Williamson wrote:
> So yes, it does change.  However, if I set the VF mac instead of using a
> randomly generated one, I get:
> 
> # modprobe -r igbvf
> # ip link set eth2 vf 6 mac 02:00:10:91:73:01
> # modprobe igbvf
> # dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
> igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
> igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> # modprobe -r igbvf
> # echo 1 > /sys/bus/pci/devices/0000:01:11.5/reset
> # modprobe igbvf
> # dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
> igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
> igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> 
> So now it sticks.  You're going to get random mac addresses on the VFs
> every time you reload the igb driver (ie. ever boot) anyway (at least
> with these sr-iov cards), so if you need consistent macs, they probably
> need to be set before launching the VM anyway.  Thanks,


You lost me on this. I do not have the igbvf driver loaded in the host,
only the guest. I am setting the MAC address for the VF in the host
before launching the VM. The host's igb driver gets loaded at boot only.

David


> 
> Alex
> 

Re: pci passthrough - VF reset at boot is dropping assigned MAC

[David Ahern]

On 04/25/11 11:30, Alex Williamson wrote:
> # modprobe -r igbvf
> # ip link set eth2 vf 6 mac 02:00:10:91:73:01
> # modprobe igbvf
> # dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
> igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
> igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> # modprobe -r igbvf
> # echo 1 > /sys/bus/pci/devices/0000:01:11.5/reset
> # modprobe igbvf
> # dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
> igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
> igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> 
> So now it sticks.  You're going to get random mac addresses on the VFs
> every time you reload the igb driver (ie. ever boot) anyway (at least
> with these sr-iov cards), so if you need consistent macs, they probably
> need to be set before launching the VM anyway.  Thanks,
> 
> Alex
> 

Ok, I was able to repeat the above commands from the host command line.

However, when qemu-kvm starts the MAC is reset.

# ip link show | less

2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000
    link/ether 00:1b:21:98:b7:10 brd ff:ff:ff:ff:ff:ff
    vf 0 MAC 02:12:34:56:80:20

--> that's the MAC address I set

I start qemu-kvm (unpatched version) and the host side sees the address
changed:

# ip link show | less

2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000
    link/ether 00:1b:21:98:b7:10 brd ff:ff:ff:ff:ff:ff
    vf 0 MAC 7a:17:3f:98:0f:db


Can you try that aspect on your end - seeing if the MAC address
maintains after starting qemu-kvm?

David

Re: pci passthrough - VF reset at boot is dropping assigned MAC

[Alex Williamson]

On Mon, 2011-04-25 at 12:04 -0600, David Ahern wrote:
> 
> On 04/25/11 11:30, Alex Williamson wrote:
> > # modprobe -r igbvf
> > # ip link set eth2 vf 6 mac 02:00:10:91:73:01
> > # modprobe igbvf
> > # dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
> > igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
> > igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
> > igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> > # modprobe -r igbvf
> > # echo 1 > /sys/bus/pci/devices/0000:01:11.5/reset
> > # modprobe igbvf
> > # dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
> > igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
> > igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
> > igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> > igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> > 
> > So now it sticks.  You're going to get random mac addresses on the VFs
> > every time you reload the igb driver (ie. ever boot) anyway (at least
> > with these sr-iov cards), so if you need consistent macs, they probably
> > need to be set before launching the VM anyway.  Thanks,
> > 
> > Alex
> > 
> 
> Ok, I was able to repeat the above commands from the host command line.
> 
> However, when qemu-kvm starts the MAC is reset.
> 
> # ip link show | less
> 
> 2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> qlen 1000
>     link/ether 00:1b:21:98:b7:10 brd ff:ff:ff:ff:ff:ff
>     vf 0 MAC 02:12:34:56:80:20
> 
> --> that's the MAC address I set
> 
> I start qemu-kvm (unpatched version) and the host side sees the address
> changed:
> 
> # ip link show | less
> 
> 2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> qlen 1000
>     link/ether 00:1b:21:98:b7:10 brd ff:ff:ff:ff:ff:ff
>     vf 0 MAC 7a:17:3f:98:0f:db
> 
> 
> Can you try that aspect on your end - seeing if the MAC address
> maintains after starting qemu-kvm?

I don't see this happening on my system, once manually set the mac never
changes.  I can restart and reset the VM and the host and guest both
continue seeing the set mac address.  I tested it with both a recent
rhel6.1 host kernel as well as upstream 2.6.39-rc4.  If I switch to a VF
with an unset mac, those will change on each VM reset or restart.
Thanks,

Alex

Re: pci passthrough - VF reset at boot is dropping assigned MAC

[David Ahern]

On 04/25/11 12:36, Alex Williamson wrote:
> On Mon, 2011-04-25 at 12:04 -0600, David Ahern wrote:
>>
>> On 04/25/11 11:30, Alex Williamson wrote:
>>> # modprobe -r igbvf
>>> # ip link set eth2 vf 6 mac 02:00:10:91:73:01
>>> # modprobe igbvf
>>> # dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
>>> igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
>>> igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
>>> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
>>> # modprobe -r igbvf
>>> # echo 1 > /sys/bus/pci/devices/0000:01:11.5/reset
>>> # modprobe igbvf
>>> # dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
>>> igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
>>> igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
>>> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
>>> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
>>>
>>> So now it sticks.  You're going to get random mac addresses on the VFs
>>> every time you reload the igb driver (ie. ever boot) anyway (at least
>>> with these sr-iov cards), so if you need consistent macs, they probably
>>> need to be set before launching the VM anyway.  Thanks,
>>>
>>> Alex
>>>
>>
>> Ok, I was able to repeat the above commands from the host command line.
>>
>> However, when qemu-kvm starts the MAC is reset.
>>
>> # ip link show | less
>>
>> 2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
>> qlen 1000
>>     link/ether 00:1b:21:98:b7:10 brd ff:ff:ff:ff:ff:ff
>>     vf 0 MAC 02:12:34:56:80:20
>>
>> --> that's the MAC address I set
>>
>> I start qemu-kvm (unpatched version) and the host side sees the address
>> changed:
>>
>> # ip link show | less
>>
>> 2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
>> qlen 1000
>>     link/ether 00:1b:21:98:b7:10 brd ff:ff:ff:ff:ff:ff
>>     vf 0 MAC 7a:17:3f:98:0f:db
>>
>>
>> Can you try that aspect on your end - seeing if the MAC address
>> maintains after starting qemu-kvm?
> 
> I don't see this happening on my system, once manually set the mac never
> changes.  I can restart and reset the VM and the host and guest both
> continue seeing the set mac address.  I tested it with both a recent
> rhel6.1 host kernel as well as upstream 2.6.39-rc4.  If I switch to a VF
> with an unset mac, those will change on each VM reset or restart.

Blacklist igbvf in the host and you will. That must be the difference: I
was preventing the vf driver from loading in the host -- it's not needed
there, so why load it?

I rebooted for a fresh run. Loaded the igbvf driver before starting the
VM using my tools. With the igbvf driver loaded in the host the MAC
address for the VF was not reset.

As for why I blacklisted it -- udev. What a PITA with VFs. I saw the
feature for Fedora 15 which should address this.

David

Re: pci passthrough - VF reset at boot is dropping assigned MAC

[Alex Williamson]

On Mon, 2011-04-25 at 13:12 -0600, David Ahern wrote:
> 
> On 04/25/11 12:36, Alex Williamson wrote:
> > On Mon, 2011-04-25 at 12:04 -0600, David Ahern wrote:
> >>
> >> On 04/25/11 11:30, Alex Williamson wrote:
> >>> # modprobe -r igbvf
> >>> # ip link set eth2 vf 6 mac 02:00:10:91:73:01
> >>> # modprobe igbvf
> >>> # dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
> >>> igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
> >>> igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
> >>> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> >>> # modprobe -r igbvf
> >>> # echo 1 > /sys/bus/pci/devices/0000:01:11.5/reset
> >>> # modprobe igbvf
> >>> # dmesg | grep "igbvf 0000\:01\:11.5\: Address\:"
> >>> igbvf 0000:01:11.5: Address: d2:c8:17:d6:97:f7
> >>> igbvf 0000:01:11.5: Address: 4e:ee:2a:d8:12:7c
> >>> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> >>> igbvf 0000:01:11.5: Address: 02:00:10:91:73:01
> >>>
> >>> So now it sticks.  You're going to get random mac addresses on the VFs
> >>> every time you reload the igb driver (ie. ever boot) anyway (at least
> >>> with these sr-iov cards), so if you need consistent macs, they probably
> >>> need to be set before launching the VM anyway.  Thanks,
> >>>
> >>> Alex
> >>>
> >>
> >> Ok, I was able to repeat the above commands from the host command line.
> >>
> >> However, when qemu-kvm starts the MAC is reset.
> >>
> >> # ip link show | less
> >>
> >> 2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> >> qlen 1000
> >>     link/ether 00:1b:21:98:b7:10 brd ff:ff:ff:ff:ff:ff
> >>     vf 0 MAC 02:12:34:56:80:20
> >>
> >> --> that's the MAC address I set
> >>
> >> I start qemu-kvm (unpatched version) and the host side sees the address
> >> changed:
> >>
> >> # ip link show | less
> >>
> >> 2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> >> qlen 1000
> >>     link/ether 00:1b:21:98:b7:10 brd ff:ff:ff:ff:ff:ff
> >>     vf 0 MAC 7a:17:3f:98:0f:db
> >>
> >>
> >> Can you try that aspect on your end - seeing if the MAC address
> >> maintains after starting qemu-kvm?
> > 
> > I don't see this happening on my system, once manually set the mac never
> > changes.  I can restart and reset the VM and the host and guest both
> > continue seeing the set mac address.  I tested it with both a recent
> > rhel6.1 host kernel as well as upstream 2.6.39-rc4.  If I switch to a VF
> > with an unset mac, those will change on each VM reset or restart.
> 
> Blacklist igbvf in the host and you will. That must be the difference: I
> was preventing the vf driver from loading in the host -- it's not needed
> there, so why load it?

I already have it blacklisted.  It's not needed if you're using the VFs
they way we are, but there are other uses.

> I rebooted for a fresh run. Loaded the igbvf driver before starting the
> VM using my tools. With the igbvf driver loaded in the host the MAC
> address for the VF was not reset.
> 
> As for why I blacklisted it -- udev. What a PITA with VFs. I saw the
> feature for Fedora 15 which should address this.

Yes, my VM is up to renaming the VFs eth1340 since the mac changes every
boot.  I'm still confused though as I did a whole round of testing after
a reboot where igbvf was never loaded and the set mac address stuck
across VM restarts and resets.

Alex

Re: pci passthrough - VF reset at boot is dropping assigned MAC

[David Ahern]

On 04/25/11 13:18, Alex Williamson wrote:
>>> I don't see this happening on my system, once manually set the mac never
>>> changes.  I can restart and reset the VM and the host and guest both
>>> continue seeing the set mac address.  I tested it with both a recent
>>> rhel6.1 host kernel as well as upstream 2.6.39-rc4.  If I switch to a VF
>>> with an unset mac, those will change on each VM reset or restart.
>>
>> Blacklist igbvf in the host and you will. That must be the difference: I
>> was preventing the vf driver from loading in the host -- it's not needed
>> there, so why load it?
> 
> I already have it blacklisted.  It's not needed if you're using the VFs
> they way we are, but there are other uses.
> 
>> I rebooted for a fresh run. Loaded the igbvf driver before starting the
>> VM using my tools. With the igbvf driver loaded in the host the MAC
>> address for the VF was not reset.
>>
>> As for why I blacklisted it -- udev. What a PITA with VFs. I saw the
>> feature for Fedora 15 which should address this.
> 
> Yes, my VM is up to renaming the VFs eth1340 since the mac changes every
> boot.  I'm still confused though as I did a whole round of testing after
> a reboot where igbvf was never loaded and the set mac address stuck
> across VM restarts and resets.
> 
> Alex
> 

The resetting of the VM MAC address is fixed in 2.6.39-rc4, so it's a
Fedora 14, 2.6.35.12 problem.

David

Re: pci passthrough - VF reset at boot is dropping assigned MAC

[David Ahern]

On 04/25/11 14:29, David Ahern wrote:
> 
> 
> On 04/25/11 13:18, Alex Williamson wrote:
>>>> I don't see this happening on my system, once manually set the mac never
>>>> changes.  I can restart and reset the VM and the host and guest both
>>>> continue seeing the set mac address.  I tested it with both a recent
>>>> rhel6.1 host kernel as well as upstream 2.6.39-rc4.  If I switch to a VF
>>>> with an unset mac, those will change on each VM reset or restart.
>>>
>>> Blacklist igbvf in the host and you will. That must be the difference: I
>>> was preventing the vf driver from loading in the host -- it's not needed
>>> there, so why load it?
>>
>> I already have it blacklisted.  It's not needed if you're using the VFs
>> they way we are, but there are other uses.
>>
>>> I rebooted for a fresh run. Loaded the igbvf driver before starting the
>>> VM using my tools. With the igbvf driver loaded in the host the MAC
>>> address for the VF was not reset.
>>>
>>> As for why I blacklisted it -- udev. What a PITA with VFs. I saw the
>>> feature for Fedora 15 which should address this.
>>
>> Yes, my VM is up to renaming the VFs eth1340 since the mac changes every
>> boot.  I'm still confused though as I did a whole round of testing after
>> a reboot where igbvf was never loaded and the set mac address stuck
>> across VM restarts and resets.
>>
>> Alex
>>
> 
> The resetting of the VM MAC address is fixed in 2.6.39-rc4, so it's a
> Fedora 14, 2.6.35.12 problem.

Just to finish this off. This is the patch that fixed the MAC address
reset problem:

commit a6b5ea353845b3f3d9ac4317c0b3be9cc37c259b
Author: Greg Rose <gregory.v.rose@intel.com>
Date:   Sat Nov 6 05:42:59 2010 +0000

    igb: Warn on attempt to override administratively set MAC/VLAN

    Print a warning message to the system log when the VF attempts to
    override administratively set MAC/VLAN configuration.

    Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

David