Re: [Qemu-devel] [RFC PATCH V1 00/14] Dynamic machine model creation from device trees

[Peter Crosthwaite]

Hi Anthony,

So the primary motivation for using this is in embedded systems design flows where you are already working with DTS for software boot. For microblaze-linux, xilinx-ppc and the xilinx-arm platforms which we are working with, it even more makes sense as the hardware platform design tools are capable of emitting platforms descriptions as DTS. With this framework, there is no need to write another description of your system (i.e. a config file, or a hardcoded machine model). DTSs are a standardised way of describing machines in the embedded linux arena, and are our machine description source, so in one way or another, we will continue need to create QEMU machines that match a DTB.

So anyways, the framework does a little bit more than read-config as the framework allows you to define a mapping between dts descriptions and qdev device models, rather than your configuration source being straight up qdev property values. There's also examples of more Ad-Hoc device models that are not currently qdev models (e.g. pflash_cfi) where you are forced to take a code driven approach rather than have to rely on QDev. It also allows you to define machine creation behavior for device nodes that are not QDev devices at all (e.g. simple busses or memories).

The possibility would exist to take a DTS and to auto-translate it into a config format, however the process for doing this would be near identical to the code in this patch series, but rather than just straight up instantiate the devices as you go, you would have to dump all the results to a single data structure then read-config that result i.e:

foo.dtb -> foo.cfg -> pass to qemu.

But another important feature of this work that is perhaps glossed over in the original description, is the ability to specify opaque interconnection data for inter-communicating devices. dtb provides a natural way for devices to reference each other and we use this to handle device interconnections without interferring with device models.  In the example given, we create qemu_irqs for interrupt controllers as they are discovered then tag them as opaque data for the interrupt controller fdt_node. When connected device instantiate, they cast the opaque data to qemu_irq and connect the interrupt. It would be difficult to do this is the two stage process, as you would have create directives for managing this opaque data in config files.

Now my understanding is the part of the qdev philosophy is to not embed connection information in device models themselves? So I am wondering what you mean by the work needs to happen in the device model? Just briefly looking at the QOM patches you mentioned they seem to solving a different problem of encapsulating and interfacing device connections at the device level. The problem we are trying to solve here is instanitating and interconnecting devices at the machine level, so I am looking for some clarification on what you mean there.

Regards

Peter

On Thu, Aug 25, 2011 at 11:27 PM, Anthony Liguori <address@hidden> wrote:

On 08/25/2011 01:41 AM, Peter A. G. Crosthwaite wrote:

Hello

This is a general RFC for a framework developed at Petalogix for creating QEMU models based on a passed device tree. Machine models are dynamically constructed from parsing a Device Tree Specification (DTS) - no more hard-coded machine models, which is critical for the FPGA-based platforms (i.e. target-microblaze) but also will be very useful for forthcoming DTS-driven ARM kernels as well. Device models (including QDev models) are tagged as being associated with a "compatible" string. If a node with the registered compatible string is found when the argument dts is parsed, then the QDev model is instantiated.

For example, An ethernet controller might have a device tree node:

    Ethernet_MAC: address@hidden {
                       compatible = "xlnx,xps-ethernetlite-4.00.a", "xlnx,xps-ethernetlite-1.00.a";
                       device_type = "network";
                       interrupt-parent =<&xps_intc_0>;
                       interrupts =<  1 0>;
                               local-mac-address = [ 00 0a 35 00 22 01 ];
                       reg =<  0x81000000 0x10000>;
                       ...
               } ;

Our framework registers the compatibility  "xlnx,xps-ethernetlite-1.00.a" as being associated with the xilinx.ethlite qdev model (hw/xilinx_ethlite.c), and each time this compatiblity is discovered in the device tree, the qdev model is instantiated (see path 10/14 for code details on this particular example).The reg property is used to set the device base address and the interrupt properties are used to connect interrupts. Device tree (more info @ devicetree.org) provides a standarised way of specifiying such connecitons, and we use all this to create machine models.

Compatibilities are registered statically from within device models as such:

    fdt_qdev_register_compatibility(&xilinx_ethlite_fdt_qdev_ops,
        "xlnx,xps-ethernetlite-1.00.a");

Where the first argument is a struct containing constant and handlers provided by the deivce model to handle device instantiation. Device instantiation is performed by the framework (not the Qdev models themselves)

We have also set up a mechanism for machine models to communicate with each other by means other than bus transactions. DTS provides a means to specify arbitrary interconnections between devices, and we use this to instantiate connections such as hierarchical interrupt controllers and point to point DMA interconnections. This provides a consistent and clean way of specifying inter-device connectivity other than via the system bus.

The platform is tested for Xilinx Microblaze and PPC platforms, and we have been using it both interally at PetaLogix and publishing to customers for approx. 6 months now. We have setup FDT instantiation code for all of the xilinx microbalze/PPC supported periphperals. We are currently developing support for an ARM platform. The framework itself is however independent of architecture so this could be used for creating machine models for any machine.

This patch series is a minimal patch series containing support for only microblaze and a handful of peripherals. Support for a more complete range of device models and other cpu architectures will come in future patches.

We would welcome any comments or questions about the approach so that we can get it merged upstream.

This is just another form of -readconfig AFAICT.

I don't think the data representation really has anything to do with why we have hard coded machines.  The real work needs to happen in the device model (see my QEMU Object Model patches).

I'm also not a big fan of the DTS syntax for machine representation since it makes it very hard to represent backends.

Regards,

Anthony Liguori

Regards,
Peter

Edgar E. Iglesias (2):
  microblaze: Make the MSR PVR bit non writable
  microblaze: Add an MSR_PVR constant and use it.

Peter A. G. Crosthwaite (12):
  qemu-coroutine: Add simple work queue support
  device_tree: Extended interface for fdt_generic
  fdt_generic: First revision
  xilinx_uartlite: Added fdt gen. platform support
  pflash_cfi01: Added fdt generic platform support
  qdev: Added fn for querying device property types
  fdt_generic_qdev: first revision
  xilinx_timer: Added fdt_generic platform support
  xilinx_intc: Added fdt generic platform support
  xilinx_ethlite: Added fdt generic platform support
  vl.c: Added hw_dtb/kern_dtb command line opts
  microblaze_generic_fdt: first revision

 Makefile.objs                 |    4 +
 Makefile.target               |    1 +
 device_tree.c                 |  202 +++++++++++++++++++
 device_tree.h                 |   30 +++
 hw/fdt_generic.c              |  199 +++++++++++++++++++
 hw/fdt_generic.h              |   92 +++++++++
 hw/fdt_generic_devices.h      |    8 +
 hw/fdt_generic_qdev.c         |   75 +++++++
 hw/fdt_generic_qdev.h         |   46 +++++
 hw/fdt_generic_util.c         |  196 ++++++++++++++++++
 hw/fdt_generic_util.h         |   43 ++++
 hw/microblaze_generic_fdt.c   |  439 +++++++++++++++++++++++++++++++++++++++++
 hw/pflash_cfi01.c             |   37 ++++
 hw/qdev-properties.c          |    9 +
 hw/qdev.h                     |    1 +
 hw/xilinx_ethlite.c           |   39 ++++-
 hw/xilinx_intc.c              |   35 ++++-
 hw/xilinx_timer.c             |   39 ++++-
 hw/xilinx_uartlite.c          |   24 +++
 qemu-coroutine-lock.c         |   13 ++
 qemu-coroutine.h              |    9 +
 qemu-options.hx               |   47 +++++
 sysemu.h                      |    4 +
 target-microblaze/cpu.h       |    1 +
 target-microblaze/translate.c |   11 +-
 vl.c                          |   19 ++
 26 files changed, 1617 insertions(+), 6 deletions(-)
 create mode 100644 hw/fdt_generic.c
 create mode 100644 hw/fdt_generic.h
 create mode 100644 hw/fdt_generic_devices.h
 create mode 100644 hw/fdt_generic_qdev.c
 create mode 100644 hw/fdt_generic_qdev.h
 create mode 100644 hw/fdt_generic_util.c
 create mode 100644 hw/fdt_generic_util.h
 create mode 100644 hw/microblaze_generic_fdt.c