qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/9] Add platform bus


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Date: Mon, 22 Jul 2013 19:21:02 +0100

On 22 July 2013 18:50, Alexander Graf <address@hidden> wrote:
> Platforms without ISA and/or PCI have had a seriously hard time in the dynamic
> device creation world of QEMU. Devices on these were modeled as SysBus devices
> which can only be instantiated in machine files, not through -device.
>
> Why is that so?

Because you can't as a user of this sort of hardware
plug in an extra serial port to a SoC, because there's just nowhere
to plug it in. So why should it be possible to plug an extra
serial port into the QEMU model of the SoC? And why should
the user of QEMU have to know very low hardware level detail
like what a particular devboard's IRQ and memory map are?

One thing that is missing is the ability to nicely support
configuring the devices the board model creates (-global doesn't
really cut it).

> Well, SysBus is trying to be incredibly generic. It allows you to plug any
> interrupt sender into any other interrupt receiver. It allows you to map
> a device's memory regions into any other random memory region. All of that
> only works from C code.
>
> But do we need that level of complexity for normal devices usually? In a
> normal platform world (SoCs, PV machines) we have a flat memory layout we
> can plug our device memory into. We also have a flat IRQ model where we
> can plug our device IRQs into.
>
> This platform bus creates a simple bus that models the easy world. It allows
> for dynamic device creation through -device. A device may or may not explictly
> request to be mapped at a specific IRQ and/or memory address. If no explicit
> mapping is requested, platform devices just get mapped at convenient places.

I think this is going in the wrong direction. We should (longterm)
be getting rid of sysbus in favour of having enough QOM support
for a device to provide both IRQ lines and memory regions as QOM
properties or links or whatever they're called. Sysbus only exists
because when it was put in the qdev infrastructure implicitly assumed
that everything had to be on a bus. It still exists today just because
it's the easy way to declare that you have some IRQ lines and
memory regions that can be wired up by the device creator.

> This goes hand in hand with automatic device tree generation. When QEMU
> places devices somewhere and also generates a device tree to tell the guest
> where exactly those devices are, we close the cycle and everyone knows
> everything and lives happily ever after.

Autogenerating device trees is going to require more than this,
for example where do we figure out how to specify clocks and
voltage regulators for each device? (And more generally how
do you handle adding whatever random extra info the kernel of
the day decides it needs?)

thanks
-- PMM



reply via email to

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