qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Thomas Huth <thuth@redhat.com>
Cc: Sam Bobroff <sam.bobroff@au1.ibm.com>,
	qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH v3 1/1] hw/net/spapr_llan: 6 byte mac address device tree entry
Date: Tue, 14 Feb 2017 14:23:48 +1100	[thread overview]
Message-ID: <20170214032348.GE2169@umbus.fritz.box> (raw)
In-Reply-To: <602f2661-0d45-d135-e3f8-64426329a736@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]

On Mon, Feb 13, 2017 at 08:36:45AM +0100, Thomas Huth wrote:
> 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.bobroff@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.

Hm, yes, good point.  Applied to ppc-for-2.9.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      reply	other threads:[~2017-02-14  3:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-21 23:19 [Qemu-devel] [PATCH v3 1/1] hw/net/spapr_llan: 6 byte mac address device tree entry Sam Bobroff
2016-11-22  7:16 ` Thomas Huth
2017-02-13  5:33 ` [Qemu-devel] [Qemu-ppc] " David Gibson
2017-02-13  7:36   ` Thomas Huth
2017-02-14  3:23     ` David Gibson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170214032348.GE2169@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=sam.bobroff@au1.ibm.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).