[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 1/1] hw/net/spapr_llan: 6 byte mac
Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 1/1] hw/net/spapr_llan: 6 byte mac address device tree entry
Mon, 13 Feb 2017 08:36:45 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
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 <address@hidden>
> 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
Description: OpenPGP digital signature