On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote: > On 02/09/2011 09:15 PM, Blue Swirl wrote: > >On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@xxxxxxxxxxxxx> 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. > So what if it is easier, it doesn't mean it is correct thing to do. What you are proposing is just a huge step backwards. May be we shouldn't support hooking everything together in completely arbitrary ways, but we shouldn't force isa/pci devices upon our users just because they are non-removable on real chip. > 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 may be a problem even from security point of view. What if usb code (ide, serial, parallel) has guest exploitable bug? Currently I can happily continue running guests if they do not need affected subsystem. If we'll get it your way I will no longer be able to do so. > > 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 > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
