From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Date: Thu, 10 Feb 2011 08:47:12 +0100 Message-ID: <4D539800.3070802@codemonkey.ws> References: <20110208155557.GM6198@x200.localdomain> <4D51B1C9.3080507@codemonkey.ws> <4D526D0D.9020507@codemonkey.ws> <4D52A86A.1030407@codemonkey.ws> <4D52F20A.7070009@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , Markus Armbruster , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Blue Swirl Return-path: Received: from mail-fx0-f46.google.com ([209.85.161.46]:39374 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752341Ab1BJHrZ (ORCPT ); Thu, 10 Feb 2011 02:47:25 -0500 Received: by fxm20 with SMTP id 20so1144485fxm.19 for ; Wed, 09 Feb 2011 23:47:23 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 02/09/2011 09:15 PM, Blue Swirl wrote: > On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori 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