Re: About creating machines on the command line

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Jan 11, 2021 at 03:50:58PM +0100, Luc Michel wrote:
> Hi,
> 
> We would like to work on improving QEMU to be able to create custom machines
> from the command line. The goal here is to get feedback from the community
> and shape the future developments.
> 
> The use case mainly comes from people working with tools to customize their
> designs, such as SiFive Core Designer
> (https://scs.sifive.com/core-designer). This kind of tools may allow
> creation or customization of a whole SoC, from the number of cores, to the
> memory and IRQ mapping of peripherals etc.
> 
> The ultimate goal would be to be able to create any kind of machine on the
> command line. However we are aware that this is a substantial amount of
> changes in QEMU.
> 
> In its current state, QEMU allows for very limited customization of existing
> machines on the command line. We identified the following limitations (feel
> free to add to the list):
> 
>   - Most devices are not user creatable. Moreover, sysbus devices must be
> explicitly allowed by a machine to be creatable through `-device`,
> 
>   - Memory regions cannot be created on the command line,
> 
>   - Device MMIO regions cannot be mapped on a bus from the command line,
> 
>   - GPIOs and clocks cannot be wired from the command line,
> 
>   - CPUs are not sysbus devices (and not user-creatable). They need special
> care when creating them regarding system reset. Not being on a bus means
> that they must be reset manually on system reset. This is done in machines
> by registering a QEMU reset handler.
> 
>   - Machine specific boot code is usually hard-coded into the machine
> itself.  Some architectures (e.g. ARM) do factorize bootloader related code,
> but there is no standard way of doing that in QEMU.
> 
> We don't want to address all those limitations at once. We plan to start
> with the following scenario:
> 
>   - Start with a base machine that would handle CPU creation and bootloader
> stuff. Note that the "none" machine is probably not sufficient in its
> current shape. It does allow only one CPU and obviously does not handle the
> boot process.
> 
>   - Allow for this machine every sysbus devices we want to be user
> command-line creatable (and mark them user_creatable if needed)
> 
>   - Add command line options to create memory regions (probably ram ones at
> first)
> 
>   - Add command line options to map a memory region (including sysbus device
> MMIO regions) onto another (memory_region_add_subregion)
> 
>   - Add command line options to connect GPIOs and clocks.
> 
> This would hopefully allow for simple machines creation. We would then be
> able to use either the command line or the `-readconfig` option to create
> the machine.
> 
> Note that we are not planning to use QMP/HMP for now. From our
> understanding, a `device_add` request is always considered as hot-plug,
> which is not what we want here.
> 
> Please tell us what do you think about this plan. Any feedback is
> appreciated.  Then we can discuss the details of how to do this properly.

There's a general desire amongst QEMU maintainers to move to a world
where QAPI is used for describing everything. In this vision, eventually
all current command line options would be replaced with QMP commands
and QAPI objects specs.

In this world -readconfig is likely to be deleted. Also this means we
have a bias against adding new command line options to current QEMU.

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