[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v2 00/16] Initial support for machine creation via QMP

From: Damien Hedde
Subject: Re: [RFC PATCH v2 00/16] Initial support for machine creation via QMP
Date: Thu, 23 Sep 2021 13:08:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0

On 9/22/21 19:50, Philippe Mathieu-Daudé wrote:
Hi Damien,

On 9/22/21 18:13, Damien Hedde wrote:

The goal of this work is to bring dynamic machine creation to QEMU:
we want to setup a machine without compiling a specific machine C
code. It would ease supporting highly configurable platforms (for
example resulting from an automated design flow). The requirements
for such configuration include begin able to specify the number of
cores, available peripherals, emmory mapping, IRQ mapping, etc.

This series focuses on the first step: populating a machine with
devices during its creation. We propose patches to support this
using QMP commands. This is a working set of patches and improves
over the earlier rfc (posted in May):

Do you have a roadmap for the following steps? Or are you done with
this series?

Hi Philippe,

We would like to stick to this scope ("creating devices in a machine") for this particular series otherwise it will become very big and cover a huge scope.

We have some patches to "migrate" more devices to be early user-creatable (like the last 2 patches of this series) so that we can use more device when building a machine. But these are trivial and only depends on what is the condition to allow this. We plan to submit these when this series is done.

We plan to address other issues we have in others series of patches. We do not put a roadmap somewhere. But we can details this in a page in our github or in the qemu wiki if you think this is a good idea.
Here are the main remaining issues:
+ the base machine (we are using "none" here because it is "almost" empty and fit our needs but it has some limitations)
+ adding cpus
+ non-trivial memory mappings
+ solving backend (eg: net) connection issues

Yesterday I was thinking about this, and one thing I was wondering is
if it would be possible to have DeviceClass and MachineClass implement
a populate_fdt() handler, to automatically generate custom DTB for these
custom machines.

Maybe in your case you don't need that, as your framework generating the
QEMU machine also generates the DTB, or even parse a DTB to generate the
machine... :)

You are right, we do not need this. We indeed use a device tree file to describe the platform but this is an "extended" device tree (it has more info than needed for linux). If it was not the case, I think it would still be easier to generate it from the source platform description than using qemu as an intermediate.

It is probably possible but it is tricky to generate the dtb: mapping in dtb are not standardized and really depends on the node types.

For example, to generate the interrupt-map property of a device node. You need to know the interrupt mapping (which interrupt line goes in which interrupt controller) and also have info about the interrupt controller's cells format (eg: how many bytes do we need to specify the interrupt). For example for some controller, you have specify the interrupt kind (rising or falling edge, high or low active level).

So you'll probably need some special "get_dtb_interrupt_cell" method in interrupt controllers to generate these entries for you so that a device can ask dtb data to its controller.

Bus mappings also depend on the bus type, but since qemu devices are already organized on a bus-type basis, this is probably easier to solve.

You'll have similar issues with every mapping. But bus and interrupt are the most important ones.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]