From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54079 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnRFT-0006EY-0J for qemu-devel@nongnu.org; Thu, 10 Feb 2011 02:47:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PnRFN-0005Zb-29 for qemu-devel@nongnu.org; Thu, 10 Feb 2011 02:47:26 -0500 Received: from mail-fx0-f45.google.com ([209.85.161.45]:37414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PnRFM-0005Z5-TD for qemu-devel@nongnu.org; Thu, 10 Feb 2011 02:47:25 -0500 Received: by fxm12 with SMTP id 12so1174403fxm.4 for ; Wed, 09 Feb 2011 23:47:23 -0800 (PST) Message-ID: <4D539800.3070802@codemonkey.ws> Date: Thu, 10 Feb 2011 08:47:12 +0100 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 References: <20110208155557.GM6198@x200.localdomain> <4D51B1C9.3080507@codemonkey.ws> <4D526D0D.9020507@codemonkey.ws> <4D52A86A.1030407@codemonkey.ws> <4D52F20A.7070009@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Chris Wright , Markus Armbruster , kvm@vger.kernel.org, qemu-devel@nongnu.org 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