Re: [Qemu-devel] KVM call minutes for Feb 8

[Blue Swirl]

On Thu, Feb 10, 2011 at 9:47 AM, Anthony Liguori <address@hidden> wrote:
> On 02/09/2011 09:15 PM, Blue Swirl wrote:
>>
>> On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<address@hidden>
>>  wrote:
>>
>>>
>>> On 02/09/2011 06:48 PM, Blue Swirl wrote:
>>>
>>>>>
>>>>> ISASerialState dev;
>>>>>
>>>>> isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
>>>>>
>>>>>
>>>>
>>>> Do you mean that there should be a generic way of doing that, like
>>>> sysbus_create_varargs() for qdev, or just add inline functions which
>>>> hide qdev property setup?
>>>>
>>>> I still think that FDT should be used in the future. That would
>>>> require that the properties can be set up mechanically, and I don't
>>>> see how your proposal would help that.
>>>>
>>>>
>>>
>>> Yeah, I don't think that is a good idea anymore.  I think this is part of
>>> why we're having so many problems with qdev.
>>>
>>> While (most?) hardware hierarchies can be represented by device tree
>>> syntax,
>>> not all valid device trees correspond to interface and/or useful hardware
>>> hierarchies.
>>>
>>
>> User creates a non-working machine and so gets to fix the problems?
>> How is that a problem for us?
>>
>
> It's not about creating a non-working machine.  It's about what user-level
> abstraction we need to provide.
>
> It's a whole lot easier to implement an i440fx device with a fixed set of
> parameters than it is to make every possible subdevice have a proper factory
> interface along with mechanisms to hook everything together.
>
> Basically, we're making things much harder for ourselves than we should.
>
>>> We want to have an interface to create large chunks of hardware (like an
>>> i440fx) which then results in a significant portion of a device tree.
>>>
>>
>> But how would this affect interface to devices? I don't see how that
>> would be any different with current model and the function call model.
>>
>
> If all composition is done through a factory interface, it doesn't.  But my
> main argument here is that we shouldn't try to make all composition done
> through a factory interface--only where it makes sense.
>
> So very concretely, I'm suggesting we do the following to target-i386:
>
> 1) make the i440fx device have an embedded ide controller, piix3, and usb
> controller that get initialized automatically.  The piix3 embeds the
> PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial,
> etc.).

This makes sense.

> 2) get rid of the entire concept of machines.  Creating a i440fx is
> essentially equivalent to creating a bare machine.

This doesn't make so much sense. There's still memory and the PCI
devices plugged to PCI bus created by i440fx. The various drives need
to be connected IDE channels, chardevs to serial ports etc., the
devices can't claim them in order of creation. The connections must be
managed at board level.

But I don't disagree completely, some time ago I proposed that
machines should be qdevified and also some of host functions.

> 3) just use the existing -device infrastructure to support all of this.  A
> very simple device config corresponds to a very complex device tree but
> that's the desired effect.

This depends on the above.

> 4) model the CPUs as devices that take a pointer to a host controller, for
> x86, the normal case would be giving it a pointer to i440fx.

For more precision, each CPUs should connect to its cache controller,
which should connect to local APIC, that to global bus for IOAPIC,
that to northbridge, which connects to both memory and southbridge.

Anyway, all of the above points 1 to 4 are orthogonal to qdev and its
API, they can be done either way.