From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIoDC-0000Hf-0g for qemu-devel@nongnu.org; Thu, 21 Mar 2013 18:43:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIoD8-0005GD-Gv for qemu-devel@nongnu.org; Thu, 21 Mar 2013 18:43:53 -0400 Date: Thu, 21 Mar 2013 17:43:32 -0500 From: Scott Wood In-Reply-To: <0738307B-4C19-4650-92F1-14B038202B6C@suse.de> (from agraf@suse.de on Thu Mar 21 06:51:57 2013) Message-ID: <1363905812.31522.28@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: Alexander Graf Cc: Peter Maydell , "qemu-ppc@nongnu.org list:PowerPC" , qemu-devel qemu-devel On 03/21/2013 06:51:57 AM, Alexander Graf wrote: >=20 > On 21.03.2013, at 12:49, Alexander Graf wrote: >=20 > > > > On 21.03.2013, at 12:44, Peter Maydell wrote: > > > >> On 21 March 2013 11:38, Alexander Graf wrote: > >>> > >>> On 21.03.2013, at 12:32, Peter Maydell wrote: > >>> > >>>> On 21 March 2013 11:29, Alexander Graf wrote: > >>>>> On 21.03.2013, at 12:22, Peter Maydell wrote: > >>>>>> We already nest the VGIC inside another memory region (the =20 > a15mpcore > >>>>>> container), and it works fine. This function is just iterating =20 > through > >>>>>> "everything any device asked me to tell the kernel about". > >>>>> > >>>>> So kda is the real physical offset? I'm having a hard time =20 > reading that code :). According to this function: > >>>>> > >>>>> static void kvm_arm_devlistener_add(MemoryListener *listener, > >>>>> MemoryRegionSection *section) > >>>>> { > >>>>> KVMDevice *kd; > >>>>> > >>>>> QSLIST_FOREACH(kd, &kvm_devices_head, entries) { > >>>>> if (section->mr =3D=3D kd->mr) { > >>>>> kd->kda.addr =3D section->offset_within_address_space; > >>>>> } > >>>>> } > >>>>> } What if the update is to a parent memory region, not to the one =20 directly associated with the device? Or does add() get called for all child regions (recursively) in such =20 cases? > >>> The distinction on whether a region is handled by KVM really needs > >>> to be done by the device model. > >> > >> It is -- the device model is what calls kvm_arm_register_device(). > >> It's just the mechanics of "how do we tell the kernel the right > >> address for this region at the point when we know it" that are > >> handled in kvm.c. > > > > I think I'm slowly grasping what you're aiming at :). Ok, that =20 > works. You do actually do the listener in the device model, just that =20 > you pass code responsibility over to kvm.c. > > > > That's perfectly valid and sounds like a good model that Scott =20 > probably wants to follow as well :). >=20 > s/follow/evaluate/ :). >=20 > The currently proposed device api doesn't have a generic notion of =20 > device regions. Regions are a per-device property, because a single =20 > device can have multiple regions. >=20 > However, maybe with a bit of brainstorming we could come up with a =20 > reasonably generic scheme. In the kernel API? Or do you mean a generic scheme within QEMU that =20 encodes any reasonably expected mechanism for setting the device adress =20 (e.g. assume that it is either a 64-bit attribute, or uses the legacy =20 ARM API), or perhaps a callback into device code? The MPIC's memory listener isn't that much code... I'm not sure there's =20 a great need for a central KVM registry. -Scott=