From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdjau-0007i5-6v for qemu-devel@nongnu.org; Thu, 22 Dec 2011 09:26:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rdjap-0006d3-Sz for qemu-devel@nongnu.org; Thu, 22 Dec 2011 09:26:04 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:41602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdjap-0006cp-Po for qemu-devel@nongnu.org; Thu, 22 Dec 2011 09:25:59 -0500 Received: by iagj37 with SMTP id j37so15420675iag.4 for ; Thu, 22 Dec 2011 06:25:59 -0800 (PST) Message-ID: <4EF33DF2.3090607@codemonkey.ws> Date: Thu, 22 Dec 2011 08:25:54 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4EF0DDB5.9040806@calxeda.com> <4EF20B67.2070502@calxeda.com> <4EF30320.7050605@redhat.com> <4EF325FB.9010801@redhat.com> In-Reply-To: <4EF325FB.9010801@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/9] arm: add missing v7 cp15 registers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Peter Maydell , "qemu-devel@nongnu.org" , Mark Langsdorf On 12/22/2011 06:43 AM, Avi Kivity wrote: > On 12/22/2011 02:37 PM, Peter Maydell wrote: >> On 22 December 2011 10:14, Avi Kivity wrote: >>> On 12/21/2011 11:10 PM, Peter Maydell wrote: >>>> Avi: is there a way for a device (sysbus device in this case) to >>>> find out for one of its memory regions where it has been mapped >>>> in the address space? >>> >>> Where and if. >>> >>>> The context here is that the Cortex-A9 >>>> has a cp15 register whose value is "base address of the private >>>> peripherals", and it would be nice not to have to have boards >>>> saying both "map mmio region at X" and "set property so register >>>> reads as X"... [You could argue that hardware implementations >>>> have to do the equivalent of both of these things separately, >>>> I suppose, but it's still not very pretty.] >>> >>> I don't really follow, can you explain? >> >> So in real hardware, these devices (interrupt controller, >> timers, etc) are an integral part of the CPU. They appear in >> the memory map at an address which is configured by hardwiring >> the CPU's PERIPHBASE signals to specify that address. Since >> obviously software needs to know where the devices are, there >> is a coprocessor register which simply returns the value >> of PERIPHBASE. (So I was wrong that hardware does the mapping >> and the register separately -- sorry.) >> >> Part of the problem we have is that in QEMU we don't model >> the CPU as a single qdev device which includes both the >> core and its builtin devices -- the two are completely >> separate and the board model ends up having to do a lot of >> the work of wiring things up, and in cases like this where >> one bit of config affects both the core CPU and the builtin >> devices you end up having to specify it twice. > > Sounds like a qom Link or some other magic should handle it? > #include "cc/aliguori". First, we need to actually model the CPUs. The general trouble with that today is that everything needs to live on a bus after we get QOM merged, that requirement will be relaxed. Once the CPUs are objects, they can create children devices (builtin interrupt controller for instance) in their instance_init function. It would be a child<> property in this case. This is how I want to model the local apic, for instance. Regards, Anthony Liguori