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

[Anthony Liguori]

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.).

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