[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devi
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices |
Date: |
Mon, 13 Jun 2011 23:59:15 +0300 |
On Sun, Jun 12, 2011 at 10:21 PM, Anthony Liguori <address@hidden> wrote:
> On 06/12/2011 12:12 PM, Avi Kivity wrote:
>>
>> On 06/10/2011 06:43 PM, Anthony Liguori wrote:
>>>
>>>> What exactly is so very wrong about buses that they need to die?
>>>
>>> They force a device tree. The device model shouldn't be a tree, but a
>>> directed graph.
>>
>> Right. As an example, you configure PCI interrupt routing and the memory
>> controller by writing to a PCI device, which logically doesn't have
>> access to any of this stuff if it's behind the PCI bus.
>>
>> However, I don't think buses should die. They should be available as an
>> easy way to model the devices that do follow the rules. But we should
>> also expose everything else for the exceptional cases.
>>
>>> It's perfectly fine to have a type called PCIBus that I440FX extends,
>>> but qdev shouldn't have explicit knowledge of something called a "bus"
>>> IMHO. Doing this forces a limited mechanism of connecting devices
>>> because it creates an artificial tree (by implying a parent/child
>>> relationship). It makes composition difficult if not impossible.
>>
>> I think qdev buses are useful as long as they don't enforce their
>> interfaces. That is, a qdev that is a child of a qbus has access to the
>> qbus's interfaces, but also access to other stuff.
>
> I see two independent data structures. The first is the "instantiation
> tree".
>
> The instantiation tree may look like this:
>
> +-- i440fx
> | |
> | +-- PIIX3
> | | |
> | | +-- mc146818a
> | | +-- uart
> | | +-- DMA
> | | +-- keyboard controller
> | | +-- (remaining platform ISA devices
> | |
> | +-- UHCI USB controller
> | +-- IDE controller
> |
> +-- e1000
> +-- cirrus-vga
> +-- virtio-balloon-pci
> +-- IDE disk0
>
> Instantiating i440fx makes a bunch of default stuff. This is composition.
> Everything else requires explicit instantiation. This is, strictly
> speaking, the parent/child relationships. If you destroy i440fx, all of
> it's children have to also go away (by definition). Nothing about bus
> relationship is implied here. Even if i440fx exposes a PCI bus, the PIIX3
> is a child of i440fx even though e1000 is not (even if they're both PCI
> devices).
I actually like this slot idea in place of buses. But wouldn't there
be two classes of devices (or two APIs), slot devices and composable
devices?
> That said, there absolutely should be the following paths:
>
> /i440fx/IDE controller/primary/master -> IDE disk0
> /i440fx/slot3 -> cirrus-vga
>
> The expression of bus should just be a bidirectional path (when that makes
> sense). IOW:
>
> /i440fx/slot3 -> cirrus-vga
> /cirrus-vga/bus -> i440fx
>
> There, of course, can be all sorts of crazy paths through the graph. The
> following should be valid:
>
> /i440fx/slot2 -> IDE controller
> /cirrus-vga/bus/slot2/primary/master
>
> But separating out hw paths from instantiation tree has some nice
> characteristics. The instantiation tree is the obvious place to implement
> live migration whereas reset would probably walk device paths.
>
> Regards,
>
> Anthony Liguori
>
>
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, (continued)
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Anthony Liguori, 2011/06/10
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Markus Armbruster, 2011/06/10
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Anthony Liguori, 2011/06/10
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Avi Kivity, 2011/06/12
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Anthony Liguori, 2011/06/12
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Avi Kivity, 2011/06/13
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Anthony Liguori, 2011/06/13
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices,
Blue Swirl <=
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Anthony Liguori, 2011/06/14
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Blue Swirl, 2011/06/15
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Anthony Liguori, 2011/06/15
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Blue Swirl, 2011/06/15
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Paul Brook, 2011/06/20
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Blue Swirl, 2011/06/20
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Avi Kivity, 2011/06/21
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Paul Brook, 2011/06/26
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Gleb Natapov, 2011/06/13
- Re: [Qemu-devel] [PATCH RFC 0/3] basic support for composing sysbus devices, Andreas Färber, 2011/06/10