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: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Date: Mon, 22 Jul 2013 20:55:40 +0200

On 22.07.2013, at 20:21, Peter Maydell wrote:

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

He doesn't. That's the point.

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

This is basically what this patch set does, just by trimming down the problem 
to a bearable set. "Links" become PlatBus device properties. That makes it easy 
to model everything.

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

Device trees usually come from firmware. ARM is screwed up in that sense, since 
kernel developers randomly extend and modify device trees to their needs. So 
for ARM you'd also need a machine option to tell the generator which kernel 
flavor of the day you want to generate the device tree for.


Alex




reply via email to

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