About creating machines on the command line

About creating machines on the command line

[Luc Michel]

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

--
Luc

Re: About creating machines on the command line

[BALATON Zoltan]

On Mon, 11 Jan 2021, 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.

I'm not sure the command line would be the best interface for this, it's 
already hard enough to get a simple VM running, adding more options would 
just make it more obscure for mere users who just want to use existing 
machines to create a VM. So I think some kind of config file to define the 
machine would be better.

Another issue with command line was backward compatibility that it's hard 
to change if it's used as an interface in scripts, etc. My personal 
opinion is that the command line should be a user interface to run VMs but 
for management apps and this kind of dynamic machine creation a better 
defined API might be better. But I'm not in any way authorative to decide 
so this is just my input to this.

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

It was found that readconfig is limited and cannot even handle its current 
purpose so it probably would need to be rewritten. This might be a good 
opportunity for that. Maybe you need a better format than ini file that 
can actually describe the machine parts and their connections you want to 
create in a managable way. Question arises how general this has to be to 
describe all the properties of objects and their connections and if you'll 
end up with somthing like still needing to write a board code which is the 
current situation just instead of writing C you'd use some other language 
and call it a "config file". What do you really want here? Avoid writing C 
or avoid recompiling QEMU to experiment with devices? In the latter case 
better support from the QEMU monitor to create machines interactively 
could also be a solution and if you could run scripts with monitor 
commands in it that could be your config file.

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

Is that something that cannot be solved? Maybe by adding another command 
or a state where starting with -S and adding devices before continue would 
not be hotplug?

These are just some random thoughts I had, feel free to ignore any of it.

Regards,
BALATON Zoltan

Re: About creating machines on the command line

[Liviu Ionescu]

I know it does not answer your question directly, but you might find useful to take a look at the solution used in the xPack QEMU Arm (formerly GNU ARM Eclipse QEMU).

In this fork I dynamically create the peripheral registers when QEMU starts, by reading a JSON file, converted from the CMSIS SVD files.

Unfortunately this is not enough, since the actions associated with each register are not defined in these JSONs, and need to be hardcoded in code.


But I think that the mechanism to create peripherals and registers might be adapted to your use case too.

Regards,

Liviu

Re: About creating machines on the command line

[Luc Michel]

Hi Liviu,

On 1/11/21 9:28 PM, Liviu Ionescu wrote:
> I know it does not answer your question directly, but you might find useful to take a look at the solution used in the xPack QEMU Arm (formerly GNU ARM Eclipse QEMU).
> 
> In this fork I dynamically create the peripheral registers when QEMU starts, by reading a JSON file, converted from the CMSIS SVD files.
> 
> Unfortunately this is not enough, since the actions associated with each register are not defined in these JSONs, and need to be hardcoded in code.
> 
> 
> But I think that the mechanism to create peripherals and registers might be adapted to your use case too.
Thanks, I'll have a look. But yes the goal here is to rely on QEMU's 
already existing device models to dynamically create a machine.

Luc

> 
> Regards,
> 
> Liviu
> 
> 

Re: About creating machines on the command line

[Liviu Ionescu]

> On 14 Jan 2021, at 12:56, Luc Michel <luc.michel@greensocs.com> wrote:
> 
> ... But yes the goal here is to rely on QEMU's already existing device models to dynamically create a machine.

I did not check the current QEMU device models, so I might be wrong, but I think that the scope might be slightly different.

In my fork I read the JSON with the detailed peripherals definitions, which include not only memory address, but registers, sizes, alignment, bit-fields, access right, reset values, etc, and from these definitions I automatically create the QEMU objects.

The result is a device with all registers available, you can already read/write all of them, just that there are no actions associated yet, and these actions need to be added manually.

There is also a tool that generates the C code for this, so basically I can turn a CMSIS SVD definition into a complete QEMU device, partly functional (without actions).

I plan to further improve this mechanism, but it'll probably take some time.


Regards,

Liviu

Re: About creating machines on the command line

[Luc Michel]

Hi Zoltan,

On 1/11/21 9:04 PM, BALATON Zoltan wrote:
> On Mon, 11 Jan 2021, 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.
> 
> I'm not sure the command line would be the best interface for this, it's 
> already hard enough to get a simple VM running, adding more options 
> would just make it more obscure for mere users who just want to use 
> existing machines to create a VM. So I think some kind of config file to 
> define the machine would be better.

OK. My first thought here was to be not too much "intrusive" in the QEMU 
source code, so adding a couple a command line options seemed to be the 
way to go, as -device was already doing what we wanted.

> 
> Another issue with command line was backward compatibility that it's 
> hard to change if it's used as an interface in scripts, etc. My personal 
> opinion is that the command line should be a user interface to run VMs 
> but for management apps and this kind of dynamic machine creation a 
> better defined API might be better. But I'm not in any way authorative 
> to decide so this is just my input to this.

Makes sense. I tend to agree with you. I'd appreciate more feedback on 
this to know if it's indeed a shared opinion.

> 
>> 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.
> 
> It was found that readconfig is limited and cannot even handle its 
> current purpose so it probably would need to be rewritten. This might be 
> a good opportunity for that. Maybe you need a better format than ini 
> file that can actually describe the machine parts and their connections 
> you want to create in a managable way. Question arises how general this 
> has to be to describe all the properties of objects and their 
> connections and if you'll end up with somthing like still needing to 
> write a board code which is the current situation just instead of 
> writing C you'd use some other language and call it a "config file". 
> What do you really want here? Avoid writing C or avoid recompiling QEMU 
> to experiment with devices?

Yes the idea is definitely to have a mean to create custom machines 
without the need of recompiling QEMU.

> In the latter case better support from the 
> QEMU monitor to create machines interactively could also be a solution 
> and if you could run scripts with monitor commands in it that could be 
> your config file.

Yes. We plan to have a script that will serve as a "frontend" anyways to 
generate the necessary commands (being on the command line, or monitor 
command or...)

> 
>> 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.
> 
> Is that something that cannot be solved? Maybe by adding another command 
> or a state where starting with -S and adding devices before continue 
> would not be hotplug?

Sure. The goal here was to avoid adding yet another run state to QEMU. 
The command line happened to kind of support what we plan to do. If 
people are OK with enhancing the monitor for this, going the QMP way 
could be a solution. Does anyone has an opinion on this?

> 
> These are just some random thoughts I had, feel free to ignore any of it.

Thanks for your feedback!

> 
> Regards,
> BALATON Zoltan

Re: About creating machines on the command line

[Daniel P. Berrangé]

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

Re: About creating machines on the command line

[Kashyap Chamarthy]

On Thu, Jan 14, 2021 at 11:37:06AM +0000, Daniel P. Berrangé wrote:
> On Mon, Jan 11, 2021 at 03:50:58PM +0100, Luc Michel wrote:

[...]

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

In that case, I hope the above intention / direction will be documented
somewhere more clearly.  In the past I ran into at least a couple of
companies that use QEMU in production and heavily rely on '-readconfig',
despite knowing some of its shortcomings.  There might be others out
there.

> Also this means we have a bias against adding new command line options
> to current QEMU.

[...]

-- 
/kashyap

Re: About creating machines on the command line

[Daniel P. Berrangé]

On Thu, Jan 14, 2021 at 06:11:50PM +0100, Kashyap Chamarthy wrote:
> On Thu, Jan 14, 2021 at 11:37:06AM +0000, Daniel P. Berrangé wrote:
> > On Mon, Jan 11, 2021 at 03:50:58PM +0100, Luc Michel wrote:
> 
> [...]
> 
> > > 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. 
> 
> In that case, I hope the above intention / direction will be documented
> somewhere more clearly.  In the past I ran into at least a couple of
> companies that use QEMU in production and heavily rely on '-readconfig',
> despite knowing some of its shortcomings.  There might be others out
> there.

Such a change would go through the deprecation process as normal so
they would have 2 releases prior warning.

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

Re: About creating machines on the command line

[Philippe Mathieu-Daudé]

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
> 

Re: About creating machines on the command line

[graf--- via]

On 03.02.21 17:55, Philippe Mathieu-Daudé wrote:
> 
> 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.

Is the command line really the right abstraction level here? Wouldn't it 
make more sense to have a QOM / <scripting language> bridge that allows 
you to create and connect QOM objects using for example Python?

You could then have machine descriptions in a script, which could be 
generated by the SoC customization tools.

In combination with plugin support for platform devices, that should 
allow pretty much any customization you would need to happen, no?


Alex

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



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: About creating machines on the command line

[John Snow]

On 2/3/21 12:09 PM, graf--- via wrote:
> 
> 
> On 03.02.21 17:55, Philippe Mathieu-Daudé wrote:
>>
>> 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
>>

I have a bunch of extremely naive questions about what it would take to 
generalize this kind of interface; my familiarity is largely with x86 
and so I actually just have a series of very basic questions about the 
scope of this work.

>>>
>>> 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.
> 
> Is the command line really the right abstraction level here? Wouldn't it 
> make more sense to have a QOM / <scripting language> bridge that allows 
> you to create and connect QOM objects using for example Python?
> 
> You could then have machine descriptions in a script, which could be 
> generated by the SoC customization tools.
> 
> In combination with plugin support for platform devices, that should 
> allow pretty much any customization you would need to happen, no?
> 
> 
> Alex
> 

Right, I am just reading this proposal as "We want an interface language 
that allows us to construct more arbitrary configurations."

In this case, something QMP/QOM-based would be the right place to do it 
and not the CLI as it exists today. Small details in the grand scheme of 
things the kind of internal modeling cleanup this idea seems to imply.

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

It does sound like a staggering level of work.

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

I suppose this implies a type of machine that doesn't have migration 
compatibility. e.g. your "blank" might be different from someone else's 
"blank".

Or at least, not migration compatibility in its current form. Some 
thought might need to be put into how to negotiate migration 
compatibility between two instances of QEMU; it sounds like a hard problem.

(Jokingly, I'd want to call a machine like this "Apple Pie", but that 
would probably be too confusing for both Apple and Raspberry Pi 
enthusiasts.)

>>>    - Allow for this machine every sysbus devices we want to be user
>>> command-line creatable (and mark them user_creatable if needed)
>>>

Is it even possible to enumerate, for every sysbus device in QEMU, what 
the interface requirements are?

e.g. I assume most need a memory region, or maybe an IO region, or maybe 
an IRQ resource of some kind, or ...

doing this kind of dynamic bringup requires a lot of configuration data 
that is at-present just hardcoded absolutely everywhere.

>>>    - Add command line options to create memory regions (probably ram 
>>> ones
>>> at first)
>>>

Naive question: what does adding a memory region mean to you in this 
context?

For whom (which device, spec, standard, instruction set, etc?) are these 
regions tangible abstractions?

>>>    - Add command line options to map a memory region (including sysbus
>>> device MMIO regions) onto another (memory_region_add_subregion)
>>>

More naive questions:

The assumption here being that sysbus devices can be modeled using their 
own private memory addressing namespace; and we configure them by 
mapping that space onto the machine's physical address space.

Instead of, say, making the memory address of that device a property of 
the device.

Yes?

>>>    - Add command line options to connect GPIOs and clocks.
>>>

Similar to elsewhere, I wonder how much work it is to generalize this 
kind of pluggability so that all existing clocks and GPIO devices can be 
modeled in the same way.

(I say this meaning: Wow, I have no idea. I know a lot of the ones we 
have are hard-coded. What does a configuration interface for this look 
like?)

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

We're working our way towards being able to use QMP to define machines 
prior to execution start in order to have a QMP-only interaction with 
QEMU possible.

You likely want to invest in that kind of a strategy where you define 
structures that describe the machines you want to build.

>>> 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
>>>
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
> 

Re: About creating machines on the command line

[Luc Michel]

On 2/4/21 9:29 PM, John Snow wrote:
> On 2/3/21 12:09 PM, graf--- via wrote:
>>
>>
>> On 03.02.21 17:55, Philippe Mathieu-Daudé wrote:
>>>
>>> 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
>>>
> 
> I have a bunch of extremely naive questions about what it would take to 
> generalize this kind of interface; my familiarity is largely with x86 
> and so I actually just have a series of very basic questions about the 
> scope of this work.
> 
>>>>
>>>> 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.
>>
>> Is the command line really the right abstraction level here? Wouldn't 
>> it make more sense to have a QOM / <scripting language> bridge that 
>> allows you to create and connect QOM objects using for example Python?
>>
>> You could then have machine descriptions in a script, which could be 
>> generated by the SoC customization tools.
>>
>> In combination with plugin support for platform devices, that should 
>> allow pretty much any customization you would need to happen, no?
>>
>>
>> Alex
>>
> 
> Right, I am just reading this proposal as "We want an interface language 
> that allows us to construct more arbitrary configurations."

Yes exactly.

> 
> In this case, something QMP/QOM-based would be the right place to do it 
> and not the CLI as it exists today.

Yes, we realized this through the discussions. We are now changing our 
plan to focus on QMP.

> Small details in the grand scheme of 
> things the kind of internal modeling cleanup this idea seems to imply.
> 
>>>>
>>>> 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:
>>>>
> 
> It does sound like a staggering level of work.
> 
>>>>    - 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.
>>>>
> 
> I suppose this implies a type of machine that doesn't have migration 
> compatibility. e.g. your "blank" might be different from someone else's 
> "blank".
> 
> Or at least, not migration compatibility in its current form. Some 
> thought might need to be put into how to negotiate migration 
> compatibility between two instances of QEMU; it sounds like a hard problem.
> 
> (Jokingly, I'd want to call a machine like this "Apple Pie", but that 
> would probably be too confusing for both Apple and Raspberry Pi 
> enthusiasts.)

Migration is definitely an issue. We didn't think too much about it yet 
because the use-case is more firmware/OS development oriented (i.e. I 
fix, compile and re-run my code in QEMU to test/debug). Migration is not 
a must-have for this use-case.

> 
>>>>    - Allow for this machine every sysbus devices we want to be user
>>>> command-line creatable (and mark them user_creatable if needed)
>>>>
> 
> Is it even possible to enumerate, for every sysbus device in QEMU, what 
> the interface requirements are?
> 
> e.g. I assume most need a memory region, or maybe an IO region, or maybe 
> an IRQ resource of some kind, or ...
> 
> doing this kind of dynamic bringup requires a lot of configuration data 
> that is at-present just hardcoded absolutely everywhere.

As of today, as I understand it, what a sysbus device exposes is part of 
its "specification" (i.e. in best cases, it is documented in a comment 
somewhere in its header file). Apart from that there is no way of 
knowing that the memory region number 0 is e.g for the ARM GIC, the 
distributor interface, while the number 1 is the CPU interface.

An introspection mechanism would be very helpful here. A simple addition 
would be to be able to name those regions at sysbus device init time, 
the same way we can name GPIOs and clocks. Having a proper name is 
already a good piece of "self-documentation" for the device, and it 
could be made observable by the user (as properties are today in QMP).

> 
>>>>    - Add command line options to create memory regions (probably ram 
>>>> ones
>>>> at first)
>>>>
> 
> Naive question: what does adding a memory region mean to you in this 
> context?
> 
> For whom (which device, spec, standard, instruction set, etc?) are these 
> regions tangible abstractions?

Good question. What we want here is basically being able to create the 
memories of our platform (rom, ram). Those can be viewed as devices 
really, and this is how in our current prototype we made them (a simple 
sysbus device that embeds the memory region and exposes it through SBD 
API). I think this is the good level of abstraction to choose because it 
aligns nicely with the rest. Such a simple device would make sense in 
vanilla IMO. Creating the memories of the platform would then resort to 
creating a device (with parameters to set the size, set if it is 
read-only, ...) and connecting it to a bus.

> 
>>>>    - Add command line options to map a memory region (including sysbus
>>>> device MMIO regions) onto another (memory_region_add_subregion)
>>>>
> 
> More naive questions:
> 
> The assumption here being that sysbus devices can be modeled using their 
> own private memory addressing namespace; and we configure them by 
> mapping that space onto the machine's physical address space.
> 
> Instead of, say, making the memory address of that device a property of 
> the device.
> 
> Yes?

Yes memory regions can be created by sysbus devices and exposed at the 
sysbus device API level. Then the parent device instantiating this 
device (or the machine itself) can use the SBD API to fetch and connect 
them to other memory regions. This is then up to the parent to choose 
where and how to map the child region(s).

> 
>>>>    - Add command line options to connect GPIOs and clocks.
>>>>
> 
> Similar to elsewhere, I wonder how much work it is to generalize this 
> kind of pluggability so that all existing clocks and GPIO devices can be 
> modeled in the same way.
> 
> (I say this meaning: Wow, I have no idea. I know a lot of the ones we 
> have are hard-coded. What does a configuration interface for this look 
> like?)

By hard-coded, you mean the connections? Because otherwise the GPIO and 
Clock APIs are well defined already. Exposing this to QMP does not seem 
to be an issue. I could be wrong though.

> 
>>>> 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.
>>>>
> 
> We're working our way towards being able to use QMP to define machines 
> prior to execution start in order to have a QMP-only interaction with 
> QEMU possible.
> 
> You likely want to invest in that kind of a strategy where you define 
> structures that describe the machines you want to build.

OK. It is clear to us that QMP is the way to go now. The plan is for us 
to work and come up with a first RFC series.

Thanks a lot!

-- 
Luc

> 
>>>> 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
>>>>
>>
>>
>>
>> Amazon Development Center Germany GmbH
>> Krausenstr. 38
>> 10117 Berlin
>> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>> Sitz: Berlin
>> Ust-ID: DE 289 237 879
>>
>>
> 

Re: About creating machines on the command line

[Luc Michel]

On 2/3/21 6:09 PM, Alexander Graf wrote:
> 
> 
> On 03.02.21 17:55, Philippe Mathieu-Daudé wrote:
>>
>> 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.
> 
> Is the command line really the right abstraction level here? Wouldn't it 
> make more sense to have a QOM / <scripting language> bridge that allows 
> you to create and connect QOM objects using for example Python?
Yes, after some discussions with the community, we are now working on 
improving QMP to achieve this. We first started with the idea of the 
command line because it seems to be the place where we had "almost" 
everything we needed already. In either cases we are planning to use a 
front-end script to go from e.g. a DTB to whatever QEMU interface we 
will end up using.

> 
> You could then have machine descriptions in a script, which could be 
> generated by the SoC customization tools.
Yes, most likely a DTB in our case.

> 
> In combination with plugin support for platform devices, that should 
> allow pretty much any customization you would need to happen, no?
I'm not sure what you mean by "plugin support for platform devices". If 
you refer to the current QEMU plugin API, it's pretty much limited to 
TCG. If you suggest this API could be enhanced to allow for custom 
devices to be added by plugins, for now we are planning to use only 
existing device models. It's more a matter of having flexibility on 
connections between the devices than on the devices themselves (but yes 
that would be a nice next step).

Thanks,

-- 
Luc

> 
> 
> Alex
> 
>>>
>>> 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
>>>
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
> 

Re: About creating machines on the command line

[Alexander Graf]

On 05.02.21 11:43, Luc Michel wrote:
> 
> On 2/3/21 6:09 PM, Alexander Graf wrote:
>>
>>
>> On 03.02.21 17:55, Philippe Mathieu-Daudé wrote:
>>>
>>> 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.
>>
>> Is the command line really the right abstraction level here? Wouldn't it
>> make more sense to have a QOM / <scripting language> bridge that allows
>> you to create and connect QOM objects using for example Python?
> Yes, after some discussions with the community, we are now working on
> improving QMP to achieve this. We first started with the idea of the
> command line because it seems to be the place where we had "almost"
> everything we needed already. In either cases we are planning to use a
> front-end script to go from e.g. a DTB to whatever QEMU interface we
> will end up using.
> 
>>
>> You could then have machine descriptions in a script, which could be
>> generated by the SoC customization tools.
> Yes, most likely a DTB in our case.

So, something like this?

     https://github.com/Xilinx/qemu/blob/master/hw/arm/arm_generic_fdt.c

I'm not sure how DTB would translate 1:1 into qom properties for a reeal 
generic mechanism? And how easy it would be to extract target device 
specifics, such as interrupt descriptors or PCI ranges properties.

If you want to make this fully generic, try to ensure that you can model 
weird beasts such as the q35 machine model.

Either way, the idea has come up multiple times before. I don't know of 
anyone who successfully managed to push it upstream yet, but I 
definitely hope we will be at a point where you can describe machine 
models in something different than C.


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: About creating machines on the command line

[Luc Michel]

On 2/10/21 1:13 PM, Alexander Graf wrote:
> 
> 
> On 05.02.21 11:43, Luc Michel wrote:
>>
>> On 2/3/21 6:09 PM, Alexander Graf wrote:
>>>
>>>
>>> On 03.02.21 17:55, Philippe Mathieu-Daudé wrote:
>>>>
>>>> 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.
>>>
>>> Is the command line really the right abstraction level here? Wouldn't it
>>> make more sense to have a QOM / <scripting language> bridge that allows
>>> you to create and connect QOM objects using for example Python?
>> Yes, after some discussions with the community, we are now working on
>> improving QMP to achieve this. We first started with the idea of the
>> command line because it seems to be the place where we had "almost"
>> everything we needed already. In either cases we are planning to use a
>> front-end script to go from e.g. a DTB to whatever QEMU interface we
>> will end up using.
>>
>>>
>>> You could then have machine descriptions in a script, which could be
>>> generated by the SoC customization tools.
>> Yes, most likely a DTB in our case.
> 
> So, something like this?
> 
>      https://github.com/Xilinx/qemu/blob/master/hw/arm/arm_generic_fdt.c

Yes, but we specifically want to avoid embedding the part that will 
parse and translate the DTB into QEMU.

> 
> I'm not sure how DTB would translate 1:1 into qom properties for a reeal 
> generic mechanism? And how easy it would be to extract target device 
> specifics, such as interrupt descriptors or PCI ranges properties.
I think there is no such 1:1 mapping. That's why we believe the tool(s) 
that parses the DTB and translate it into QMP commands must stay out of 
QEMU.

> 
> If you want to make this fully generic, try to ensure that you can model 
> weird beasts such as the q35 machine model.
> 
> Either way, the idea has come up multiple times before. I don't know of 
> anyone who successfully managed to push it upstream yet, but I 
> definitely hope we will be at a point where you can describe machine 
> models in something different than C.
We'll try an go step by step, to not raise all the issues at the same 
time hopefully.

Thanks

-- 
Luc

> 
> 
> Alex
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 
>