On 4/28/25 3:25 AM, Peter Krempa wrote:
On Fri, Apr 25, 2025 at 14:07:34 -0700, Pierrick Bouvier wrote:
On 4/25/25 08:38, Markus Armbruster wrote:
Pierrick Bouvier <pierrick.bouv...@linaro.org> writes:
Note: This RFC was posted to trigger a discussion around this topic, and it's
not expected to merge it as it is.
Context
=======
Linaro is working towards heterogeneous emulation, mixing several architectures
in a single QEMU process. The first prerequisite is to be able to build such a
binary, which we commonly name "single-binary" in our various series.
An (incomplete) list of series is available here:
https://patchew.org/search?q=project%3AQEMU+single-binary
We don't expect to change existing command line interface or any observable
behaviour, it should be identical to existing binaries. If anyone notices a
difference, it will be a bug.
Define "notice a difference" :) More on that below.
Given a single-binary *named* exactly like an existing qemu-system-X binary,
any user or QEMU management layer should not be able to distinguish it from
the real qemu-system-X binary.
The new potential things will be:
- introduction of an (optional) -target option, which allows to
override/disambiguate default target detected.
- potentially more boards/cpus/devices visible, once we start developing
heterogeneous emulation. See it as a new CONFIG_{new_board} present.
Out of that, once the current target is identified, based on argv[0], there
should be absolutely no difference, whether in the behaviour, UI, command
line, or the monitor interfaces.
Okay, so assuming that the correctly named binaries will apply whatever
necessary magic to have them behave identically as they did.
I'll also ignore the distros that rename them assuming they do it in a
way that stays compatible.
The question is how the new unified binary will behave when being
introspected:
- Can the unified binary be introspected without selecting an
architecture?
(by introspection I mean starting with -M none and querying stuff via
QMP)
if no: libvirt will have a chicken&egg problem deciding what to do
- What will be the answer for the platform-specific stuff such as CPU
definitions?
It's a good question, to which I didn't really spend time thinking of,
mainly because I prefer to stay focus on achieving a single-binary
having a *single-target* available at runtime first.
Once we have this, which should be a "zero effect" change, I think we'll
be ready to discuss how the monitor and QEMU command line should be
affected by heterogeneous emulation.
I feel that several people expressed their desire to create a new and
minimal command line/monitor for this new heterogeneous scenario.
IMHO, I would prefer to see things going towards the direction of having
a "main" target, and secondaries targets available at runtime.
Basically, for a aarch64/microblaze mixed board, it would be the same as
enhancing qemu-system-aarch64, with microblaze cpus available.
Eventually, we can add specific options/monitor commands associated to
this, but I'm not sure that refactoring the whole thing is the good way
to go.
That said, my experience on such usages, and on QEMU in general, is much
more limited than all the people here, so I would be happy to listen and
follow what they will design and implement.
It's just my personal software engineer alarm which gets triggered when
I hear "Let's create another new way to access this", when we are not
even sure at this point of how many heterogenous boards we'll have in
the next 10 years. Maybe heterogenenous scenarios will concern only a
few exotic boards, and it would not be worth buying new shiny wheels for
the QEMU car ahead of this. Just my two cents.
In all cases, my current focus is to be able to compile and link such a
binary, without which we can't do any step further.
Regards,
Pierrick
