From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52064 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnWYf-0000w9-Kk for qemu-devel@nongnu.org; Thu, 10 Feb 2011 08:27:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PnWYY-0001OS-H5 for qemu-devel@nongnu.org; Thu, 10 Feb 2011 08:27:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PnWYY-0001OK-7t for qemu-devel@nongnu.org; Thu, 10 Feb 2011 08:27:34 -0500 Date: Thu, 10 Feb 2011 15:27:30 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] KVM call minutes for Feb 8 Message-ID: <20110210132730.GB24525@redhat.com> References: <4D52A86A.1030407@codemonkey.ws> <4D52F20A.7070009@codemonkey.ws> <4D539800.3070802@codemonkey.ws> <20110210090748.GD673@redhat.com> <4D53BD22.1040800@redhat.com> <20110210111354.GA21681@redhat.com> <4D53DF42.4030700@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D53DF42.4030700@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , kvm@vger.kernel.org, Markus Armbruster , qemu-devel@nongnu.org, Blue Swirl , Avi Kivity On Thu, Feb 10, 2011 at 01:51:14PM +0100, Anthony Liguori wrote: > On 02/10/2011 12:13 PM, Gleb Natapov wrote: > > > >Which spec? Even in this discussion we completely mixed different > >things. 440FX is not a chipset. > > Yes, it is. It's a single silicon package with a defined pinout. > If you don't believe me, re-read the spec. > > It's a MCM with the PIIX3 being internally connected. The > connection between the i440fx and PIIX3 happens to be PCI but that's > not always the case. Sometimes it's a proprietary bus. > Which one? 29054901.pdf describes memory controller and PCI host bridge only. > >Again you probably mean PIIX3. Even then removing unused ide will free > >one more PCI slot for my cool virtio disk array. The things is, from > >code point of view, it does not cost you extra to allow composition of > >ide since it is just a regular PCI device and we need to support composing > >those anyway. > > If this is useful, and it doesn't break guests, you can always do > -device i440fx,ide=off. However, it's an exception where we're > deviating from how hardware works. > I don't care how command line will look like, but I do not see how you will support ide=off without device composition unless you put ad-hoc ifs all over your i440fx device code. And I don't understand what do you mean by saying that this is not how hardware works. Presence or absence of PCI device does not change how hardware works. > And that's okay, but the base modelling ought to follow real > hardware closely with deviations being the exception. > You keep saying this without explaining why. But with device composition you will have exactly that, you will compose real chipsets using config files, not code. -- Gleb.