[Qemu-ppc] [PATCH 1/1] hw/net/spapr_llan: 6 byte mac address device tree entry

[Sam Bobroff]

The spapr-vlan device in QEMU has always presented it's MAC address in
the device tree as an 8 byte value, even though PAPR requires it to be
6 bytes.  This is because, at the time, AIX required the value to be 8
bytes.  However, modern versions of AIX only support the (correct) 6
byte value so they are now failing to get this value correctly.

This patch removes the old workaround and presents the address as the
correct 6 byte value in the device tree.

However, the value is also consumed by the Linux ibmveth driver.

Since commit 13f85203e (3.10, May 2013) the driver has been able to
handle 6 or 8 byte addresses so versions after that should be
unaffected by this change.

Drivers from kernels before that can also handle either type of
address, but not always:
* If the first byte's lowest bits are 10, the address must be 6 bytes.
* Otherwise, the address must be 8 bytes.
(The two bits in question are significant in a MAC address: they
indicate a locally-administered unicast address.)

After this change they will see incorrect values for broadcast or
non-locally generated addresses. AFAIK these addresses would not
normally be used as the address of an emulated adapter, so any
breakage should be rare. The breakage would appear as the MAC address
losing the first two bytes and receiving two bytes of garbage at the
other end.

Signed-off-by: Sam Bobroff <address@hidden>
---

 hw/net/spapr_llan.c | 14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/hw/net/spapr_llan.c b/hw/net/spapr_llan.c
index 01ecb02..eebf7cc 100644
--- a/hw/net/spapr_llan.c
+++ b/hw/net/spapr_llan.c
@@ -381,22 +381,10 @@ void spapr_vlan_create(VIOsPAPRBus *bus, NICInfo *nd)
 static int spapr_vlan_devnode(VIOsPAPRDevice *dev, void *fdt, int node_off)
 {
     VIOsPAPRVLANDevice *vdev = VIO_SPAPR_VLAN_DEVICE(dev);
-    uint8_t padded_mac[8] = {0, 0};
     int ret;
 
-    /* Some old phyp versions give the mac address in an 8-byte
-     * property.  The kernel driver has an insane workaround for this;
-     * rather than doing the obvious thing and checking the property
-     * length, it checks whether the first byte has 0b10 in the low
-     * bits.  If a correct 6-byte property has a different first byte
-     * the kernel will get the wrong mac address, overrunning its
-     * buffer in the process (read only, thank goodness).
-     *
-     * Here we workaround the kernel workaround by always supplying an
-     * 8-byte property, with the mac address in the last six bytes */
-    memcpy(&padded_mac[2], &vdev->nicconf.macaddr, ETH_ALEN);
     ret = fdt_setprop(fdt, node_off, "local-mac-address",
-                      padded_mac, sizeof(padded_mac));
+                      &vdev->nicconf.macaddr, ETH_ALEN);
     if (ret < 0) {
         return ret;
     }
-- 
2.10.0.297.gf6727b0