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