From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri4wf-0006Jk-7C for qemu-devel@nongnu.org; Tue, 03 Jan 2012 09:02:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ri4wa-00009A-Pa for qemu-devel@nongnu.org; Tue, 03 Jan 2012 09:02:29 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:60301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ri4wa-000094-MB for qemu-devel@nongnu.org; Tue, 03 Jan 2012 09:02:24 -0500 Received: by iagj37 with SMTP id j37so35905772iag.4 for ; Tue, 03 Jan 2012 06:02:23 -0800 (PST) Message-ID: <4F030A6B.2060809@codemonkey.ws> Date: Tue, 03 Jan 2012 08:02:19 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <87ehvis3uj.fsf@trasno.mitica> <4F01B542.8000800@suse.de> <4F02567F.6080701@codemonkey.ws> <4F0304AD.6010800@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Chris Wright , quintela@redhat.com, Developers qemu-devel , KVM devel mailing list , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 01/03/2012 07:57 AM, Peter Maydell wrote: > On 3 January 2012 13:37, Anthony Liguori wrote: >> For what you're getting at, you actually want to model the CPUs in QOM such >> that you would have an ARM926 is-a ARMCPU is-a CPUCommon. >> >> Then you could have the beagle machine have a link. If it always >> has a single CPU, you make it a child and the user can't change it. > > The CPU should always be a child of the board, surely, even if the user > might want to use a different one? That's just basic composition. > The links should be for "the CPU has two input IRQ lines" and so on. Not in the PC world. You buy a motherboard with an empty CPU socket and then purchase a CPU separately and plug it in. link<> essentially models any type of socket whereas child<> basically means "soldered to the board or embedded in silicon". It may be true for SoCs that CPUs are always child<> but that's not universal. > > (Beagle is an A8, incidentally.) > >>> For instance, >>> in a fully QOM world, trying to run a beagle machine with (say) a 926 >>> CPU should fail to instantiate, because the 926 CPU won't have the right >>> set of irq/gpio inputs and outputs that the beagle machine needs to >>> connect up to. (This is the QOM equivalent of trying to ram a 486 >>> into a Pentium CPU socket.) >>> >>> I don't think we even have syntax for 2 at the moment except for the >>> weird special case of "-cpu foo". >> >> >> Yeah, it's still not clear to me how much we want to model CPUs in QOM. We >> could do it very simply and flat or model the individual CPUs as proper >> types which lets you do fancier things with links. > > What I definitely want is that an ARM CPU should look like any other > device in that it has input (and maybe output) GPIO lines, and (for > MP cores) it exposes MemoryRegion(s) that the board (or SOC) maps. > And instantiating and wiring up 926 (a "simple" unicore) should look > pretty much the same at machine model level as wiring up an A9MP > (a "complicated" multicore with built-in peripheral devices, interrupt > controller, etc, which we'd presumably model as a QOM object which > uses composition for all its peripherals and the "actual CPU"). I think I agree with all of this. Regards, Anthony Liguori > -- PMM >