[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/1] hw/net/spapr_llan: 6 byte mac ad
Re: [Qemu-devel] [Qemu-ppc] [PATCH 1/1] hw/net/spapr_llan: 6 byte mac address device tree entry
Thu, 17 Nov 2016 10:47:05 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
On 17.11.2016 05:24, 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 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(-)
I just double-checked the code in SLOF, and it should also be able to
deal with both, 8-byte and 6-byte MAC address properties, so from that
point of view, the change is OK.
But since there are still old kernels in the field (RHEL6 is using
2.6.32 for example), it's maybe better to play safe and only provide a
6-byte address property if bit #1 is set in the nicconf.macaddr array,
and provide an 8-byte property otherwise.