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

[Anthony Liguori <anthony@codemonkey.ws>]

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