Re: [PATCH] hw: ppc: sam460ex: Disable Ethernet devicetree nodes

[David Gibson <david@gibson.dropbear.id.au>]

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

On Mon, Aug 16, 2021 at 12:21:33PM +0200, BALATON Zoltan wrote:
> On Mon, 16 Aug 2021, David Gibson wrote:
> > On Sun, Aug 15, 2021 at 07:59:15PM -0700, Guenter Roeck wrote:
> > > IBM EMAC Ethernet controllers are not emulated by qemu. If they are
> > > enabled in devicetree files, they are instantiated in Linux but
> > > obviously won't work. Disable associated devicetree nodes to prevent
> > > unpredictable behavior.
> > > 
> > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > 
> > I'll wait for Zoltan's opinion on this, but this sort of thing is why
> > I was always pretty dubious about qemu *loading* a dtb file, rather
> > than generating a dt internally.
> 
> We are aiming to emulate the real SoC so we use the same dtb that belongs to
> that SoC instead of generating something similar but not quite the same.

Well.. sure, but you don't *actually* emulate the real SoC, so you're
advertising a dtb that doesn't match the real hardware, which is a
bigger bug.

> (QEMU also has a -dtb option but I'm not sure how many machines implement
> it.) So loading a dtb is not bad in my opinion.

Well.... I'm not all that convinced that -dtb is a good idea either.
But to the extent that it is, I've assumed it's very much a "you must
know what you're doing" option (like -bios) where it's the user's
responsibility to make sure the dtb they're supplying matches the
emulated hardware.

> Given that we don't fully
> emulate every device in the SoC having devices described in the dtb that we
> don't have might cause warnings or errors from OSes that try to accesss
> these but that's all I've seen. I'm not sure what unpredictable behaviour
> could result apart from some log messages about missing ethernet so this
> should only be cosmetic to hide those errors. But other than that it likely
> should not break anything so I'm OK with this patch. (I did not implement
> ethernet ports becuase they are quite complex and we already have several
> PCI ethernet devices that work already with guests so it's easier to use
> those than spend time to implement another ethernet device.)

So, the thing I really dislike about this patch is that it's not
committing to either approach.  It's neither having a supplied dtb and
making it qemu's job to match that behaviour exactly, nor is qemu
supplying hardware and producing a dtb to describe that virtual
hardware.  It's doing a bit of both, which just seems like a recipe
for confusion to me.

-- 
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: 833 bytes --]