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 11:13:23 +0100 Message-ID: <4D53BA43.2000708@codemonkey.ws> 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> <4D53A39D.8000108@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Blue Swirl , Chris Wright , Markus Armbruster , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Peter Maydell Return-path: Received: from mail-fx0-f46.google.com ([209.85.161.46]:64874 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751934Ab1BJKNa (ORCPT ); Thu, 10 Feb 2011 05:13:30 -0500 Received: by fxm20 with SMTP id 20so1280091fxm.19 for ; Thu, 10 Feb 2011 02:13:29 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 02/10/2011 10:04 AM, Peter Maydell wrote: > On 10 February 2011 08:36, Anthony Liguori wrote: > >> On 02/10/2011 09:16 AM, Peter Maydell wrote: >> >>> On 10 February 2011 07:47, Anthony Liguori wrote: >>> >>>> 2) get rid of the entire concept of machines. Creating a i440fx is >>>> essentially equivalent to creating a bare machine. >>>> >>> Does that make any sense for anything other than target-i386? >>> The concept of a machine model seems a pretty obvious one >>> for ARM boards, for instance, and I'm not sure we'd gain much >>> by having i386 be different to the other architectures... >>> >> Yes, it makes a lot of sense, I just don't know the component names as well >> so bear with me :-) >> >> There are two types of Versatile machines today, Versatile/AB and >> Versatile/PB. They are both made with the same core, ARM926EJ-S, with >> different expansions. >> >> So you would model arm926ej-s as the chipset and then build up the machines >> by modifying parameters of the chipset (like the board id) and/or adding >> different components on top of it. >> > Er, ARM926 is the CPU, it's not a chipset. The board ID is definitely > not a property of an ARM926, it's a property of the board (clue is in > the name :-)). I don't think versatile boards have a "chipset" really... > As I said, I'm not well versed in the component names in ARM. But that said, an actual processor doesn't connect directly to a bunch of devices. It almost always go through some chipset and that chipset implements a lot of functionality typically. I think the name of the component I'm trying to refer to PL300 which I believe is the Northbridge used for the Versatile boards. > In my understanding the "machine" is the thing that says "I need a > 926, and an MMC controller at this address, and some UARTS, > and..." ie it is the thing that does the "modifying parameters" > and "adding different components". So if we'd still be doing that > I don't see how we've "got rid of the concept". I guess I'm missing > the point somehow. > A machine today is basically the northbridge, southbridge, plus a bunch of default components to make the virtual hardware useful. I'm suggesting that we model a proper northbridge/southbridge. >> A good way to think about what I'm proposing is that machine->init really >> should be a constructor for a device object. >> > If you mean that you want machines to be implemented under the > hood as a single huge "device" you can only have one of that spans > the entire memory map, well I guess that's an implementation > detail. But conceptually machines really do exist, and we definitely > still want users to be able to say "I want a beagle machine; I want > a versatile; I want an n900". > An n900 is a very specific hardware configuration that is best represented by some sort of configuration file vs. something hard coded in QEMU. The question is, what level of component modelling do we need to do in order to make it practical to create such configurations from a file. Regards, Anthony Liguori > -- PMM >