From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51248 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnSVM-0003BJ-Na for qemu-devel@nongnu.org; Thu, 10 Feb 2011 04:08:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PnSVG-0003hK-6X for qemu-devel@nongnu.org; Thu, 10 Feb 2011 04:07:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17881) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PnSVF-0003eu-Vn for qemu-devel@nongnu.org; Thu, 10 Feb 2011 04:07:54 -0500 Date: Thu, 10 Feb 2011 11:07:48 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Message-ID: <20110210090748.GD673@redhat.com> References: <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=us-ascii Content-Disposition: inline In-Reply-To: <4D539800.3070802@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , Chris Wright , Markus Armbruster , kvm@vger.kernel.org, qemu-devel@nongnu.org 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 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb.