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.bouvier@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