From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Stéphane Graber" <stgraber@stgraber.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH] hw/usb/network: Remove hardcoded 0x40 prefix
Date: Wed, 7 May 2025 09:45:44 +0100 [thread overview]
Message-ID: <aBsduLe2QDbr4Ol1@redhat.com> (raw)
In-Reply-To: <20250506164602.3897164-1-stgraber@stgraber.org>
On Tue, May 06, 2025 at 12:45:53PM -0400, Stéphane Graber via wrote:
> USB NICs have a "40:" prefix hardcoded for all MAC addresses.
>
> This overrides user-provided configuration and leads to an inconsistent
> experience.
>
> I couldn't find any documented reason (comment or git commits) for this
> behavior. It seems like everyone is just expecting the MAC address to be
> fully passed through to the guest, but it isn't.
>
> This is also particularly problematic as the "40:" prefix isn't a
> reserved prefix for MAC addresses (IEEE OUI). There are a number of
> valid allocations out there which use this prefix, meaning that QEMU may
> be causing MAC address conflicts.
>
> Signed-off-by: Stéphane Graber <stgraber@stgraber.org>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2951
> ---
> hw/usb/dev-network.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
> index 81cc09dcac..1df2454181 100644
> --- a/hw/usb/dev-network.c
> +++ b/hw/usb/dev-network.c
> @@ -1383,7 +1383,7 @@ static void usb_net_realize(USBDevice *dev, Error **errp)
> qemu_format_nic_info_str(qemu_get_queue(s->nic), s->conf.macaddr.a);
> snprintf(s->usbstring_mac, sizeof(s->usbstring_mac),
> "%02x%02x%02x%02x%02x%02x",
> - 0x40,
> + s->conf.macaddr.a[0],
> s->conf.macaddr.a[1],
> s->conf.macaddr.a[2],
> s->conf.macaddr.a[3],
To repeat what I said in the ticket, the 0x40 byte originates from when
this was first committed to QEMU. We can see the finall accepted patch
https://lists.nongnu.org/archive/html/qemu-devel/2008-07/msg00385.html
but tracing the history back further, this was *not* in the version of
the patches submitted by the original author 2 years earlier:
https://lists.nongnu.org/archive/html/qemu-devel/2006-10/msg00339.html
There's no explanation of this difference. Could easily be a left-over
hack from some debugging attempt that no one noticed until now.
It can't have been forcing a specific vendor's prefix, since prefixes
are more than 1 byte long. To me, it smells like a debugging hack
where someone wanted to see this fixed byte appear, though even that
is a bit wierd as you could just set the desired mac as a cli arg.
Anyway I can't come up with a justification for keeping this, so
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
..unless someone believes we need to tie this change to a machine type
version ?
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-05-07 8:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 16:45 [PATCH] hw/usb/network: Remove hardcoded 0x40 prefix Stéphane Graber via
2025-05-07 8:45 ` Daniel P. Berrangé [this message]
2025-05-12 14:10 ` Peter Maydell
2025-09-01 16:11 ` Peter Maydell
2025-09-01 17:07 ` Philippe Mathieu-Daudé
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=aBsduLe2QDbr4Ol1@redhat.com \
--to=berrange@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stgraber@stgraber.org \
/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).