From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35008) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdhzz-0006rJ-9V for qemu-devel@nongnu.org; Thu, 22 Dec 2011 07:43:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rdhzt-0004BQ-J0 for qemu-devel@nongnu.org; Thu, 22 Dec 2011 07:43:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rdhzt-0004BK-9m for qemu-devel@nongnu.org; Thu, 22 Dec 2011 07:43:45 -0500 Message-ID: <4EF325FB.9010801@redhat.com> Date: Thu, 22 Dec 2011 14:43:39 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4EF0DDB5.9040806@calxeda.com> <4EF20B67.2070502@calxeda.com> <4EF30320.7050605@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Peter Maydell Cc: "qemu-devel@nongnu.org" , Mark Langsdorf 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". > > Anyway, with the new MemoryListener API (not yet merged), you can > > register a callback to be called when MemoryRegions become visible or > > invisible. You can filter there for your pet region and get all the > > info about it. > > Mmm, that would work. Now that I better understand the issue, I think it's overkill. You just want to replicate a register between devices. The MemoryListener API is designed to allow you to see the memory map from the cpu's side, after a region has been transformed by overlapping regions, address transformation by bridges, enables/disables, etc. You just want to copy a value from one object to another, you don't care about any of this. -- error compiling committee.c: too many arguments to function