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):
https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg03706.html
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.
Thanks,
Damien
