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

Anthony Liguori
2011-02-10T07:47:25Z

On 02/09/2011 09:15 PM, Blue Swirl wrote:
> On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@codemonkey.ws> 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.).

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

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.

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.

Regards,

Anthony Liguori