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 21:44:49 +0200

On 22.07.2013, at 21:38, Anthony Liguori wrote:

> Alexander Graf <address@hidden> writes:
> 
>> 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?
>> 
>> 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.
>> 
>> 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.
>> 
>> The actual pressing issue this solves is that today it's impossible to spawn
>> serial ports from the command line. With this patch set, it's possible to
>> do so. But it lays the groundwork for much more...
> 
> tl;dr, this is a PV bus for the e500 described as something more
> generic.  I don't buy it.  I don't think there are many platforms or
> devices out there where you can arbitrarily hook up devices at random
> offsets/IRQs and expect things to work in any meaningful way.
> 
> So I'll suggest one of three things:
> 
> 1) Just use PCI and call it a day

If only the world was this easy. We already use PCI for everything where it 
makes sense today, but some devices I want to create dynamically from the 
command line simply aren't on PCI.

> 2) Rename this to E500PlatformBus and call it a day

This could be used just the same for ARM's mach-virt, so I'd rather not make it 
e500 specific.

> 3) If you really want to solve the general problem of platform devices,
>   I think the approach needs to involve:
> 
>   a) Forget about any bus at all, just inherit from a common base class
> 
>   b) Use the common base class to expose interfaces to enumerate IRQs
>      and MemoryRegions
> 
>   c) Have machine-specific logic (in the post init hook) that looks for
>      any device of the type defined in (a) and connects their
>      IRQs/MemoryRegions as appropriate.

Ok, I have something very similar for the device tree walker anyways, just that 
I'm walking a bus instead of the global device pool. But the idea is probably 
still the same. I suppose I'd still inherit from PlatBusDevice (which obviously 
would be called PlatformDevice or SimpleDevice by then) to get me my 
interfaces, right?

I'll see what I can come up with.


Alex




reply via email to

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