On 6/2/25 15:31, Daniel P. Berrangé wrote:
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
https://lore.kernel.org/qemu-devel/20250204002240.97830-1-phi...@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 ?
Like MIPS*, SH4* and Xtensa*, it is a jumper on the board
(wired to a CPU pin which is sampled once at cold reset).
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.
My worry is about how to not break what distros currently ship.
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
IIRC Thomas tried to convert TARGET_X86_64 to a runtime check
but it wasn't that easy:
https://lore.kernel.org/qemu-devel/20230425133851.489283-1-th...@redhat.com/
