On 13.02.2017 06:33, David Gibson wrote: > On Tue, Nov 22, 2016 at 10:19:38AM +1100, Sam Bobroff wrote: >> 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 support the (correct) 6 >> byte value so they no longer require the workaround. >> >> It would be neatest to always provide a 6 byte value but that would >> cause a problem with old Linux kernel ibmveth drivers, so the old 8 >> byte value is still presented when necessary. >> >> Since commit 13f85203e (3.10, May 2013) the driver has been able to >> handle 6 or 8 byte addresses so versions after that don't need to be >> considered specially. >> >> 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.) >> >> So to maintain compatibility the old 8 byte value is presented when >> the lowest two bits of the first byte are not 10. >> >> Signed-off-by: Sam Bobroff <sam.bobr...@au1.ibm.com> > > Sorry, I didn't see this one until now. > > Since we need a workaround for the workaround, is it actually worth > going to the 6-byte property?
8-byte addresses are just wrong, all other network devices and the standard use 6-byte MAC addresses instead. So we should use 6-byte addresses in QEMU whenever it is possible, too. Unfortunately there are still guests in the field that use this bad assumption with 8 byte addresses, so I think this work-around is the best we can and should do right now. Thomas
signature.asc
Description: OpenPGP digital signature
