From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKC3h-0008Or-NK for qemu-devel@nongnu.org; Mon, 25 Mar 2013 14:23:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKC3e-0005dM-Ii for qemu-devel@nongnu.org; Mon, 25 Mar 2013 14:23:49 -0400 Date: Mon, 25 Mar 2013 13:23:02 -0500 From: Scott Wood In-Reply-To: (from peter.maydell@linaro.org on Sat Mar 23 06:24:49 2013) Message-ID: <1364235782.26945.12@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "qemu-ppc@nongnu.org list:PowerPC" , Alexander Graf , qemu-devel qemu-devel On 03/23/2013 06:24:49 AM, Peter Maydell wrote: > On 22 March 2013 22:05, Scott Wood wrote: > > On 03/22/2013 08:08:57 AM, Peter Maydell wrote: > >> The memory API flattens the tree of memory regions down into a flat > >> view of the address space. These callbacks get called for the > >> final flattened view (so you'll never see a pure container in the > >> callback, only leaves). The callbacks happen for every region which > >> appears in the address space, in linear order. When an update =20 > happens > >> memory.c identifies the changes between the old flat view and the > >> new one and calls callbacks appropriately. > > > > OK, so .add and .del will be sufficient to capture any manipulation =20 > that > > would affect whether and where the region we care about is mapped? >=20 > Yes. Note that if the board (brokenly) maps the region so it is > 'hidden' by another region, this manifests as a .del [since it > is no longer accessible]. Also I think if the board maps something > small on top and in the middle of the region you get an add for > each of the partially visible fragments. Personally I'm happy to > not worry about either of these cases Yeah, if we do check for those cases it should just be to print an =20 error. > on the basis that they would be board model bugs. In some cases it could be guest code doing something screwy, but if you =20 need to support that then turn off the in-kernel pic. > >> > The MPIC's memory listener isn't that much code... I'm not sure > >> > there's a great need for a central KVM registry. > >> > >> Well, nor is the ARM memory listener, but why have two bits of > >> code doing the same thing when you could have one? > > > > They're not doing quite the same thing, though, and the effort =20 > required to > > unify them is non-zero. The two main issues are the way that the =20 > address is > > communicated to KVM, and the ability to change the mapping after =20 > the guest > > starts. >=20 > Ah, guest-programmable mappings are a real use case and not a =20 > hypothetical? It's real in terms of how the hardware works. QEMU doesn't yet =20 implement it, but it should, especially with Alex occasionally saying =20 he'd like to see QEMU capable of running U-Boot. > Do we run into synchronisation issues with making sure that QEMU and > the kernel both agree simultaneously about where the mapping is? I don't think so -- the guest CPU that is doing the moving is stopped =20 for QEMU MMIO, and if the other CPUs try to access it in the meantime, =20 it would be undefined even on real hardware whether it happens before =20 or after the move takes effect. > Can the mapping be different between different CPU cores? [let's > hope not :-)] Not in a way that's relevant here. There's some per-cpu magic internal =20 to the region, but that's handled within the kernel. > Is the mapping controlled by a register within the > mapping itself, or is there some separate non-moving register which > defines the location of the mappable registers? There's a separate moving register. :-P MPIC is combined with a bunch of other devices into a large region =20 called CCSR, and that region can be moved as a whole by writing to a =20 register at the beginning of CCSR. -Scott=