RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1351089 - The mac address didn't change when set ctrl_mac_addr=off
Summary: The mac address didn't change when set ctrl_mac_addr=off
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virtio-win
Version: 7.3
Hardware: x86_64
OS: Linux
high
low
Target Milestone: rc
: ---
Assignee: Yvugenfi@redhat.com
QA Contact: lijin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-29 08:12 UTC by Yiqian Wei
Modified: 2018-10-30 16:23 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The driver didn't follow virtio 1.0 spec regarding the access to virtio-configuration space regarding MAC address setting. Consequence: If control MAC address control queue feature was off, the guest driver tried to set up MAC address using the legacy method that was deprecated in virtio 1.0 devices. Fix: The driver now confirms to the spec and only changes MAX address using control queue. Result: The driver behaves according to the virtio 1.0 spec.
Clone Of:
Environment:
Last Closed: 2018-10-30 16:21:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3413 0 None None None 2018-10-30 16:23:53 UTC

Description Yiqian Wei 2016-06-29 08:12:07 UTC 
Description of problem:

boot a guest with "ctrl_mac_addr=off and disable-legacy=on,disable-modern=off" for virtio-net-pci，the mac address didn't change in hmp.

Version-Release number of selected component (if applicable):
kernel-3.10.0-447.el7.x86_64
qemu-img-rhev-2.6.0-7.el7.x86_64
OVMF-20160608-1.git988715a.el7.noarch

How reproducible:


Steps to Reproduce:
1.Boot a guest with vhost=on and ctrl_mac_addr=off,following is cli:

/usr/libexec/qemu-kvm \
-M q35 \
-cpu SandyBridge \
-monitor stdio \
-m 4G \
-vga qxl \
-drive file=/usr/share       /OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/home/yiwei/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \
-debugcon file:/home/yiwei/q35.ovmf.log \
-global isa-debugcon.iobase=0x402 \
-spice port=5930,disable-ticketing \
-device ioh3420,bus=pcie.0,id=root1.0,slot=1 \
-device x3130-upstream,bus=root1.0,id=upstream1.1 \
-device xio3130-downstream,bus=upstream1.1,id=downstream1.1,chassis=1 \
-drive if=none,id=drive0,file=/home/yiwei/pxb-ovmf.qcow2 \
-device virtio-blk-pci,drive=drive0,scsi=off,bus=downstream1.1,disable-legacy=on,disable-modern=off \
-device ioh3420,bus=pcie.0,id=root1.1,slot=2 \
-device x3130-upstream,bus=root1.1,id=upstream1.2 \
-device xio3130-downstream,bus=upstream1.2,id=downstream1.2,chassis=2 \
-device virtio-net-pci,ctrl_mac_addr=off,netdev=dev1,mac=9a:e8:e9:ea:eb:ec,id=net1,disable-legacy=on,disable-modern=off \
-netdev tap,id=dev1,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
-smp 4

2.Change mac address inside guest.

# ip link set eth0 address 9a:e8:e9:ea:eb:e0

3.Check macaddress via qemu-kvm monitor

 (qemu) info network 
net1: index=0,type=nic,model=virtio-net-pci,macaddr=9a:e8:e9:ea:eb:ec
 \ dev1: index=0,type=tap,ifname=tap1,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown

Actual results:

the mac address no change in hmp.

Expected results:

the mac address change to the new one in hmp

Additional info:

boot a guest with "ctrl_mac_addr=off “,do not add "disable-legacy=on,disable-modern=off",no issue.

hit the same issue on Q35+seabios and pc+seabios.
Comment 6 weliao 2016-08-04 02:57:51 UTC 
Hi,jason, 
  I have a question, if Fence writing it in virtio1.0, when ctrl_mac_addr=on, info network see the mac also can't change, according to your #comment5 , virtio 0.95 can change macaddr, and virtio1.0 can't change mac address in qemu?
  Now test result:
  Scenario 1(virtio 0.95):
    disable-legacy=off,desable-modern=on:
       ctrl_mac_addr=on and  ctrl_mac_addr=off, when change guest mac address. info network via hmp see macaddr all change.
  Scenario 2(virtio 1.0):
    disable-legacy=on,desable-modern=off:
       ctrl_mac_addr=on  change guest mac address, info network via hmp see macaddr change.
       ctrl_mac_addr=off change guest mac address, info network via hmp see
macaddr no change.
    
     this result is expected?  if I have mistake please correct me.


thanks 
Wei
Comment 7 jason wang 2016-08-04 03:06:34 UTC 
(In reply to weliao from comment #6)
> Hi,jason, 
>   I have a question, if Fence writing it in virtio1.0, when
> ctrl_mac_addr=on, info network see the mac also can't change, according to
> your #comment5 , virtio 0.95 can change macaddr, and virtio1.0 can't change
> mac address in qemu?
>   Now test result:
>   Scenario 1(virtio 0.95):
>     disable-legacy=off,desable-modern=on:
>        ctrl_mac_addr=on and  ctrl_mac_addr=off, when change guest mac
> address. info network via hmp see macaddr all change.
>   Scenario 2(virtio 1.0):
>     disable-legacy=on,desable-modern=off:
>        ctrl_mac_addr=on  change guest mac address, info network via hmp see
> macaddr change.
>        ctrl_mac_addr=off change guest mac address, info network via hmp see
> macaddr no change.
>     
>      this result is expected?  if I have mistake please correct me.
> 
> 
> thanks 
> Wei

This is expected.

Thanks
Comment 8 Zhengtong 2016-08-10 09:51:00 UTC 
Hi Jason, I have hit the same problem on power platform. And I have a little question about this.

As stated in comment #5 . We have disabled mac write at virtio 1.0 , why I can still modify the mac address of device with cmd "ip link set eth0 addr $newmac up"?  

After I modified the mac address, the device works well. Only left the Inconsistency b/w the "mac address" from hmp output and that got from inside guest.
Comment 9 jason wang 2016-08-12 02:38:13 UTC 
(In reply to Zhengtong from comment #8)
> Hi Jason, I have hit the same problem on power platform. And I have a little
> question about this.
> 
> As stated in comment #5 . We have disabled mac write at virtio 1.0 , why I
> can still modify the mac address of device with cmd "ip link set eth0 addr
> $newmac up"?  
> 
> After I modified the mac address, the device works well. Only left the
> Inconsistency b/w the "mac address" from hmp output and that got from inside
> guest.

If you are using vhost, it works by chance since mac filter does not work for vhost. And I don't think this can work with vhost=off.
Comment 10 weliao 2016-09-01 10:07:06 UTC 
Hi jason,

  I tested with win10 x86_64 guest, when used virtio1.0 , the same test scenario but had the different result with linux guest..

Linux guest:
    Scenario(virtio 1.0):
    disable-legacy=on,disable-modern=off:
       ctrl_mac_addr=off change guest mac address, info network via hmp see
macaddress no change.
    

Windows 10 guest:
    Scenario(virtio 1.0):
    disable-legacy=on,disable-modern=off:
       ctrl_mac_addr=off change guest mac address, info network via hmp see
macaddress change.
    
Does the different guest handled differently? I confirm windows 10 support the virtio 1.0, so can you help confirm is this a bug?

thanks,
Wei.
Comment 11 Yiqian Wei 2017-03-24 08:26:02 UTC 
Hi jason,

   I hit the same problem as comment #10.


When virtio1.0 and ctrl_mac_addr=off.
In linux guest to change mac address,find mac address no change via hmp.
---------right(According to comment #5.)

In win2016 guest to change mac address,find mac address change via hmp. 
---------Is this expected or bug?

If it is bug, need to open a new bug ?
Comment 12 jason wang 2018-01-03 02:58:32 UTC 
(In reply to Yiqian Wei from comment #11)
> Hi jason,
> 
>    I hit the same problem as comment #10.
> 
> 
> When virtio1.0 and ctrl_mac_addr=off.
> In linux guest to change mac address,find mac address no change via hmp.
> ---------right(According to comment #5.)
> 
> In win2016 guest to change mac address,find mac address change via hmp. 
> ---------Is this expected or bug?
> 
> If it is bug, need to open a new bug ?

It looks like a bug of windows driver. Cc Yan for more thoughts.

Thanks
Comment 13 Yvugenfi@redhat.com 2018-01-07 15:06:55 UTC 
(In reply to jason wang from comment #12)
> (In reply to Yiqian Wei from comment #11)
> > Hi jason,
> > 
> >    I hit the same problem as comment #10.
> > 
> > 
> > When virtio1.0 and ctrl_mac_addr=off.
> > In linux guest to change mac address,find mac address no change via hmp.
> > ---------right(According to comment #5.)
> > 
> > In win2016 guest to change mac address,find mac address change via hmp. 
> > ---------Is this expected or bug?
> > 
> > If it is bug, need to open a new bug ?
> 
> It looks like a bug of windows driver. Cc Yan for more thoughts.
> 
> Thanks

This is a bug in Windows driver.

The driver will write the MAC address through configuration space on virtio 1.0.
Comment 14 Yvugenfi@redhat.com 2018-01-08 16:33:47 UTC 
Patches are sent upstream: https://github.com/virtio-win/kvm-guest-drivers-windows/pull/229
Comment 15 Vadim Rozenfeld 2018-03-06 07:08:49 UTC 
Please check with the latest drivers from build 148
https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=659785

Thanks,
Vadim.
Comment 16 Yu Wang 2018-03-06 08:32:47 UTC 
Hi Yan,

I tried with the latest driver(build 148), when boot guest with ctrl_mac_addr=off, after changing mac address,both guest and hmp are not changed.
Is that expected?

Since in linux, when boot guest with ctrl_mac_addr=off, mac address will be changed in guest, and not changed in hmp (info network). So I'm not sure these are expected, or windows/linux bug.

Thanks
Yu Wang
Comment 17 Yvugenfi@redhat.com 2018-03-07 13:41:15 UTC 
(In reply to Yu Wang from comment #16)
> Hi Yan,
> 
> I tried with the latest driver(build 148), when boot guest with
> ctrl_mac_addr=off, after changing mac address,both guest and hmp are not
> changed.
> Is that expected?
> 
> Since in linux, when boot guest with ctrl_mac_addr=off, mac address will be
> changed in guest, and not changed in hmp (info network). So I'm not sure
> these are expected, or windows/linux bug.
> 
> Thanks
> Yu Wang

Hi,

There are additional tests on the guest side for the validity of the MAC address. Only the address that has locally administered bit can be set from the guest. Please ensure that such MAC address is used during test.

Best regards,
Yan.
Comment 18 Yu Wang 2018-03-08 03:18:51 UTC 
(In reply to Yan Vugenfirer from comment #17)
> (In reply to Yu Wang from comment #16)
> > Hi Yan,
> > 
> > I tried with the latest driver(build 148), when boot guest with
> > ctrl_mac_addr=off, after changing mac address,both guest and hmp are not
> > changed.
> > Is that expected?
> > 
> > Since in linux, when boot guest with ctrl_mac_addr=off, mac address will be
> > changed in guest, and not changed in hmp (info network). So I'm not sure
> > these are expected, or windows/linux bug.
> > 
> > Thanks
> > Yu Wang
> 
> Hi,
> 
> There are additional tests on the guest side for the validity of the MAC
> address. Only the address that has locally administered bit can be set from
> the guest. Please ensure that such MAC address is used during test.

I research some for this, it seems that my mac is valid (52-54-00-02-9a-8f),
and if I use previous build(build 144,ctrl_mac_addr=off), both guest/hmp mac changed. And If I use build 148 (ctrl_mac_addr=off), both guest/hmp mac will not change.

If I use build 148 (ctrl_mac_addr=on), both guest/hmp mac changed.

So I think the mac is valid for our test.

> 
> Best regards,
> Yan.
Comment 19 Yu Wang 2018-03-13 02:05:37 UTC 
Hi Yan,

Could you check the comment#18?

Thanks
Comment 20 Yvugenfi@redhat.com 2018-03-13 09:11:19 UTC 
(In reply to Yu Wang from comment #19)
> Hi Yan,
> 
> Could you check the comment#18?
> 
> Thanks

I am looking into this.
Comment 21 Yvugenfi@redhat.com 2018-07-03 14:21:12 UTC 
This is expected behavior on Windows.

If ctrl_mac_addr=off with virtio 1.0, we cannot change MAC address in the device - therefore Windows driver will not change MAC address.
Comment 22 Yu Wang 2018-07-04 06:29:26 UTC 
(In reply to Yan Vugenfirer from comment #21)
> This is expected behavior on Windows.
> 
> If ctrl_mac_addr=off with virtio 1.0, we cannot change MAC address in the
> device - therefore Windows driver will not change MAC address.

So I summary the result, you can correct me if I am wrong. (windows guest)

1 legacy mode/ctrl_mac_addr=off, both guest/hmp mac changed (right? I'm not sure)
2 legacy mode/ctrl_mac_addr=on, both guest/hmp mac changed 
3 modern mode/ctrl_mac_addr=off, both guest/hmp mac NOT changed
4 modern mode/ctrl_mac_addr=on, both guest/hmp mac changed

Thanks
Yu Wang
Comment 23 Yvugenfi@redhat.com 2018-07-04 08:15:45 UTC 
(In reply to Yu Wang from comment #22)
> (In reply to Yan Vugenfirer from comment #21)
> > This is expected behavior on Windows.
> > 
> > If ctrl_mac_addr=off with virtio 1.0, we cannot change MAC address in the
> > device - therefore Windows driver will not change MAC address.
> 
> So I summary the result, you can correct me if I am wrong. (windows guest)
> 
> 1 legacy mode/ctrl_mac_addr=off, both guest/hmp mac changed (right? I'm not
> sure)
> 2 legacy mode/ctrl_mac_addr=on, both guest/hmp mac changed 
> 3 modern mode/ctrl_mac_addr=off, both guest/hmp mac NOT changed
> 4 modern mode/ctrl_mac_addr=on, both guest/hmp mac changed

Yes.

> 
> Thanks
> Yu Wang
Comment 24 Yu Wang 2018-07-04 08:59:30 UTC 
According to comment#21 and comment#23, this bug has been fixed, so change status to verified

Thanks all
Yu Wang
Comment 27 errata-xmlrpc 2018-10-30 16:21:49 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3413
Note You need to log in before you can comment on or make changes to this bug.