All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
To: Luc Michel <luc.michel@greensocs.com>,
	qemu-devel@nongnu.org, Nikos Dragazis <ndragazis@arrikto.com>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	Thanos Makatos <thanos.makatos@nutanix.com>,
	Andra-Irina Paraschiv <andraprs@amazon.com>,
	"John G. Johnson" <john.g.johnson@oracle.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Alexander Graf <graf@amazon.com>
Cc: Damien Hedde <damien.hedde@greensocs.com>,
	peter.maydell@linaro.org, berrange@redhat.com,
	sam.grove@sifive.com, Mark Burton <mark.burton@greensocs.com>,
	richard.fuhler@sifive.com, armbru@redhat.com,
	edgar.iglesias@gmail.com
Subject: Re: About creating machines on the command line
Date: Wed, 3 Feb 2021 17:55:21 +0100	[thread overview]
Message-ID: <93e41283-ec7c-4c2b-dcfd-9e0e7a2e435c@amsat.org> (raw)
In-Reply-To: <13ecc030-f42b-5a27-a0b3-b07921426ce9@greensocs.com>

On 1/11/21 3:50 PM, 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.

Cc'ing John who is working on command line, and some developers from
the "inter-VM device emulation interface" call.
https://www.mail-archive.com/qemu-devel@nongnu.org/msg723252.html

> 
> 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.
> Thanks!
> 
> -- 
> Luc
> 


  parent reply	other threads:[~2021-02-03 17:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 14:50 About creating machines on the command line Luc Michel
2021-01-11 20:04 ` BALATON Zoltan
2021-01-11 20:28   ` Liviu Ionescu
2021-01-14 10:56     ` Luc Michel
2021-01-14 11:07       ` Liviu Ionescu
2021-01-14  9:30   ` Luc Michel
2021-01-14 11:37 ` Daniel P. Berrangé
2021-01-14 17:11   ` Kashyap Chamarthy
2021-01-14 17:26     ` Daniel P. Berrangé
2021-02-03 16:55 ` Philippe Mathieu-Daudé [this message]
2021-02-03 17:09   ` graf--- via
2021-02-04 20:29     ` John Snow
2021-02-05 16:04       ` Luc Michel
2021-02-05 10:43     ` Luc Michel
2021-02-10 12:13       ` Alexander Graf
2021-02-13 13:58         ` Luc Michel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=93e41283-ec7c-4c2b-dcfd-9e0e7a2e435c@amsat.org \
    --to=f4bug@amsat.org \
    --cc=andraprs@amazon.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=damien.hedde@greensocs.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=graf@amazon.com \
    --cc=jan.kiszka@siemens.com \
    --cc=john.g.johnson@oracle.com \
    --cc=luc.michel@greensocs.com \
    --cc=mark.burton@greensocs.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=ndragazis@arrikto.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.fuhler@sifive.com \
    --cc=sam.grove@sifive.com \
    --cc=thanos.makatos@nutanix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.