Re: [PATCH v5 11/16] hw/microblaze: Support various endianness for s3adsp1800 machines

[Daniel P . Berrangé]

On Thu, Feb 06, 2025 at 02:53:58PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Daniel,
> 
> On 6/2/25 14:20, Daniel P. Berrangé wrote:
> > On Thu, Feb 06, 2025 at 02:10:47PM +0100, Philippe Mathieu-Daudé wrote:
> > > Introduce an abstract machine parent class which defines
> > > the 'little_endian' property. Duplicate the current machine,
> > > which endian is tied to the binary endianness, to one big
> > > endian and a little endian machine; updating the machine
> > > description. Keep the current default machine for each binary.
> > > 
> > > 'petalogix-s3adsp1800' machine is aliased as:
> > > - 'petalogix-s3adsp1800-be' on big-endian binary,
> > > - 'petalogix-s3adsp1800-le' on little-endian one.
> > 
> > Does it makes sense to expose these as different machine types ?
> > 
> > If all the HW is identical in both cases, it feels like the
> > endianness could just be a bool property of the machine type,
> > rather than a new machine type.
> 
> Our test suites expect "qemu-system-foo -M bar" to work out of
> the box, we can not have non-default properties.
> 
> (This is related to the raspberry pi discussion in
> 20250204002240.97830-1-philmd@linaro.org/">https://lore.kernel.org/qemu-devel/20250204002240.97830-1-philmd@linaro.org/).
> 
> My plan is to deprecate 'petalogix-s3adsp1800', so once we
> remove it we can merge both qemu-system-microblaze and
> qemu-system-microblazeel into a single binary.
> 
> If you don't want to add more machines, what should be the
> endianness of the 'petalogix-s3adsp1800' machine in a binary
> with no particular endianness? Either we add for explicit
> endianness (fixing test suites) or we add one machine for
> each endianness; I fail to see other options not too
> confusing for our users.

We would pick an arbitrary endianness of our choosing
I guess. How does this work in physical machines ? Is
the choice of endianess a firmware setting, or a choice
by the vendor when manufacturing in some way ?

Picking an arbitrary endianess is compatible with our
test suite, it just has the implication that we would
only end up testing the machine in a single endianness
configuration.

If we wanted to test both endianness options, the test
would need amending to know to try both values of the
endian property on the machine.

> This approach is the same I took to merge MIPS*, SH4* and
> Xtensa* machines in endianness-agnostic binaries.

If we have prior art like this, then remaining consistentv is
desirable and thus my comments are too late.

> Also the same I'm using to merge 32/64-bit targets into the
> same binaries.
> Assuming we have a qemu-system-x86 binary able to run i386 and
> x86_64 machines, what do you expect when starting '-M pc'? How
> to not confuse users wanting to run FreeDOS in 32-bit mode?
> 
> Again, IMO having '-M pc,mode=32' is simpler, but that breaks
> the test suites assumptions than machines can start with no
> default values (see QOM introspection tests for example).

With x86 there's no need for mode=32. Whether the machine
supports 64-bit or not is a property of the CPU model
chosen. eg  "qemu -M pc -cpu Nehalem" would be 64-bit and
"qemu -M pc -cpu pentium" would be 32-bit.

The qemu-system-i386 binary is pretty much pointless as a
separate thing. Libvirt will happily use qemu-system-x86_64
to run 32-bit guests, by just specifying a 32-bit CPU
model


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 :|