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?

   e.g. does/can an architecture need to be instantiated later via QMP?
   can it be changed dynamically?


Reply via email to