From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMmYB-0002Wh-7F for qemu-devel@nongnu.org; Wed, 18 May 2011 15:36:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMmY9-0006mc-Vp for qemu-devel@nongnu.org; Wed, 18 May 2011 15:36:55 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:60932) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMmY9-0006mP-H4 for qemu-devel@nongnu.org; Wed, 18 May 2011 15:36:53 -0400 Message-ID: <4DD41FD2.8060303@web.de> Date: Wed, 18 May 2011 21:36:50 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD3E0E5.2030700@codemonkey.ws> <4DD3E7B4.9020802@redhat.com> In-Reply-To: <4DD3E7B4.9020802@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDF26186FE66D7142361BB931" Sender: jan.kiszka@web.de Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF26186FE66D7142361BB931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-05-18 17:37, Avi Kivity wrote: >>> void memory_region_init_ram(MemoryRegion *mr, >>> target_phys_addr_t size); >>> void memory_region_init_ram_ptr(MemoryRegion *mr, >>> target_phys_addr_t size, >>> void *ptr); >>> void memory_region_destroy(MemoryRegion *mr); >>> void memory_region_set_offset(MemoryRegion *mr, target_phys_addr_t >>> offset); >> >> What's "offset" mean? >=20 > It's the equivalent of cpu_register_physical_memory_offset(). >=20 > Note the intent is to have addresses always be relative to the innermos= t > container. Perhaps we can get away without offset. Offset is supposed to support the transition of devices that expect absolute I/O addresses in their callbacks to those that are fine with relative ones (based on the region start). This API change is a good chance to finally get rid of the former group. >=20 >> >>> void memory_region_set_log(MemoryRegion *mr, bool log); >>> void memory_region_clear_coalescing(MemoryRegion *mr); >>> void memory_region_add_coalescing(MemoryRegion *mr, >>> target_phys_addr_t offset, >>> target_phys_addr_t size); >> >> I don't think it's worth while to try to fit coalescing into this API.= >> It's a KVM specific hack. I think it's fine to be a hacked on API. >=20 > The problem is that only the device knows about coalescing, while the > region can be mapped, unmapped, or moved without device knowledge. So > if a PCI is unmapped and then remapped (possibly at a different address= ) > we need to tell kvm about it, but there is no device callback involved.= Doesn't Xen use coalescing as well, or could use? It looks like a generic optimization feature for hypervisors that want to build on top of QEMU. Jan --------------enigDF26186FE66D7142361BB931 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3UH9IACgkQitSsb3rl5xT0AACg2nKELNOFNwXkPzBYKA4lPiF/ NWgAnjGzQZeOhjZgzBe0FgqPztZQ+qXL =zSyN -----END PGP SIGNATURE----- --------------enigDF26186FE66D7142361BB931--