From mboxrd@z Thu Jan 1 00:00:00 1970 From: Blue Swirl Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Date: Fri, 11 Feb 2011 19:54:38 +0200 Message-ID: References: <20110208155557.GM6198@x200.localdomain> <4D51B1C9.3080507@codemonkey.ws> <4D526D0D.9020507@codemonkey.ws> <4D52A86A.1030407@codemonkey.ws> <4D52F20A.7070009@codemonkey.ws> <4D539800.3070802@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Chris Wright , Markus Armbruster , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Anthony Liguori Return-path: Received: from mail-vw0-f46.google.com ([209.85.212.46]:42064 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757429Ab1BKRzB convert rfc822-to-8bit (ORCPT ); Fri, 11 Feb 2011 12:55:01 -0500 Received: by vws16 with SMTP id 16so1802631vws.19 for ; Fri, 11 Feb 2011 09:55:01 -0800 (PST) In-Reply-To: <4D539800.3070802@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Feb 10, 2011 at 9:47 AM, Anthony Liguori wrote: > On 02/09/2011 09:15 PM, Blue Swirl wrote: >> >> On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori >> =C2=A0wrote: >> >>> >>> 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 whi= ch >>>> 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. =C2=A0I think this= is part of >>> why we're having so many problems with qdev. >>> >>> While (most?) hardware hierarchies can be represented by device tre= e >>> syntax, >>> not all valid device trees correspond to interface and/or useful ha= rdware >>> 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. =C2=A0It's about what = user-level > abstraction we need to provide. > > It's a whole lot easier to implement an i440fx device with a fixed se= t 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 shou= ld. > >>> We want to have an interface to create large chunks of hardware (li= ke an >>> i440fx) which then results in a significant portion of a device tre= e. >>> >> >> 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 mode= l. >> > > If all composition is done through a factory interface, it doesn't. =C2= =A0But my > main argument here is that we shouldn't try to make all composition d= one > 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. =C2=A0The piix3 embeds= the > PCI-to-ISA bridge along with all of the default ISA devices (rtc, ser= ial, > etc.). This makes sense. > 2) get rid of the entire concept of machines. =C2=A0Creating a i440fx= is > essentially equivalent to creating a bare machine. This doesn't make so much sense. There's still memory and the PCI devices plugged to PCI bus created by i440fx. The various drives need to be connected IDE channels, chardevs to serial ports etc., the devices can't claim them in order of creation. The connections must be managed at board level. But I don't disagree completely, some time ago I proposed that machines should be qdevified and also some of host functions. > 3) just use the existing -device infrastructure to support all of thi= s. =C2=A0A > very simple device config corresponds to a very complex device tree b= ut > that's the desired effect. This depends on the above. > 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. =46or more precision, each CPUs should connect to its cache controller, which should connect to local APIC, that to global bus for IOAPIC, that to northbridge, which connects to both memory and southbridge. Anyway, all of the above points 1 to 4 are orthogonal to qdev and its API, they can be done either way.