hit this problem with 82599 nic on rhel6u5 guest.

Can you try the following:
 -  Do not change the mac address of the passthru macvtap device and try bringing
    up the VM and passing the right hw address to it.  If this works, this would
    point to a bug in the driver for the VF device.  You may need to remove IP
    address from the VF device.

 - Try not using bridged or vepa modes and see if that makes it work.

The reason I ask is that I just tried setting up a passthru macvtap on top of a
Emulex 10G nic non-SRIOV (be2net driver) and it worked just fine.

Test on latest version:
Host:
# uname -r
2.6.32-414.el6.x86_64
[root@amd-6168-256-1 home]# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.397.el6.x86_64

Guest:
rhel6.5

Steps:
1. create macvtap in passthru mode on a VF
# ip address show p5p2_5
24: p5p2_5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether b2:96:79:9f:3f:db brd ff:ff:ff:ff:ff:ff
    inet6 fe80::b096:79ff:fe9f:3fdb/64 scope link 
       valid_lft forever preferred_lft forever
# ip link add link p5p2_5 dev macvtap0 type macvtap mode passthru
# ip link set macvtap0 up
#  ip -d link show macvtap0
35: macvtap0@p5p2_5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether b2:96:79:9f:3f:30 brd ff:ff:ff:ff:ff:ff
    macvtap  mode passthru 


2.Boot guest with only one NIC
/usr/libexec/qemu-kvm -M rhel6.5.0 -cpu Opteron_G3 -m 4G -smp 16,sockets=2,cores=8,threads=1 -enable-kvm -usb -device usb-tablet,id=input0 -name win2008r2-64 -uuid `uuidgen` -rtc base=localtime,clock=host,driftfix=slew  -device virtio-scsi-pci,bus=pci.0,addr=0x5,id=scsi0  -boot menu=on -drive file=/home/RHEL-Server-6.4-64-virtio.qcow2,if=none,id=drive-scsi0-0-0,media=disk,cache=none,format=qcow2,werror=stop,rerror=stop,aio=native  -device scsi-hd,drive=drive-scsi0-0-0,bus=scsi0.0,scsi-id=0,lun=0,id=flang  -vnc :11 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0  -qmp tcp:0:4445,server,nowait -monitor stdio   -netdev tap,id=hostnet2,vhost=on,fd=35  -device virtio-net-pci,netdev=hostnet2,id=net0,mac=b2:96:79:9f:3f:db 35<>/dev/tap35


Results:

Guest can get IP,and work well


Addtional info :If change the Mac, also hit the problem on the latest version.

Correction for comment 4:

Test on latest version:
Host:
# uname -r
2.6.32-414.el6.x86_64
[root@amd-6168-256-1 home]# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.397.el6.x86_64

Guest:
rhel6.5

Steps:
1. create macvtap in passthru mode on a VF
# ip address show p5p2_5
24: p5p2_5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether b2:96:79:9f:3f:db brd ff:ff:ff:ff:ff:ff
    inet6 fe80::b096:79ff:fe9f:3fdb/64 scope link 
       valid_lft forever preferred_lft forever
# ip link add link p5p2_5 dev macvtap0 type macvtap mode passthru
# ip link set macvtap0 up
#  ip -d link show macvtap0
35: macvtap0@p5p2_5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether b2:96:79:9f:3f:db brd ff:ff:ff:ff:ff:ff
    macvtap  mode passthru 


2.Boot guest with only one NIC
/usr/libexec/qemu-kvm -M rhel6.5.0 -cpu Opteron_G3 -m 4G -smp 16,sockets=2,cores=8,threads=1 -enable-kvm -usb -device usb-tablet,id=input0 -name win2008r2-64 -uuid `uuidgen` -rtc base=localtime,clock=host,driftfix=slew  -device virtio-scsi-pci,bus=pci.0,addr=0x5,id=scsi0  -boot menu=on -drive file=/home/RHEL-Server-6.4-64-virtio.qcow2,if=none,id=drive-scsi0-0-0,media=disk,cache=none,format=qcow2,werror=stop,rerror=stop,aio=native  -device scsi-hd,drive=drive-scsi0-0-0,bus=scsi0.0,scsi-id=0,lun=0,id=flang  -vnc :11 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0  -qmp tcp:0:4445,server,nowait -monitor stdio   -netdev tap,id=hostnet2,vhost=on,fd=35  -device virtio-net-pci,netdev=hostnet2,id=net0,mac=b2:96:79:9f:3f:db 35<>/dev/tap35


Results:

Guest can get IP,and work well


Addtional info :If change the Mac, also hit the problem on the latest version.

I ran some additional tests on the intel VF capable device and this is what
I've found:

1) If the user sets VF mac address using command
   # ip link set dev <dev> vf <num> mac <mac>
   then subsequent this command, the nic driver reports an error when attempting
   to configure macvlan or macvtap devices on the device corresponding to the
   VF.  This seems to be a limitation of the driver/hw/fw.  Passthru mode
   macvlan/vtap device will however work as it inherits the mac address of
   physical device (in this case VF).  This is why it worked correctly when
   the mac address on the macvtap was not changed, and did not work when the
   mac address of the macvtap was changed.


2) If the user does not set the VF mac, leaving set 00:00:00:00:00:00, then
   the randomly generated mac address, assigned to the net device which
   corresponds to the VF, does not get get added to the nic forwarding
   table.  This can be verified using command /sbin/bridge fdb show
   In this case, vepa and bridge mode macvlan/vtap devices work correctly
   as they add their own mac addresses to the nic forwarding table.  However,
   the passthru mode is different as it inherits the mac address of the physical
   device.  In this case, the mac address is still not added and thus
   passthru mode does not work correctly.  Changing the mac address of the
   passthru mode macvlan/vtap would make it work.

There are 2 possible solutions:
 1) Change the ixgbevf driver to add the randomly generated mac address to the
    hw forwarding table.
of
 2) Change the macvlan driver to add the mac address to always add the address to hw forwarding table and treat EEXIST correctly.

My preference is for (1) since the VF net device itself does not work if the VF mac has not been set and the net device mac address is randomly generated.

After further investigation into this issue, this is an invalid use of a passthru mode.  See Bug 923051 for details.  Closing this bug.