From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN7hG-00011x-GI for qemu-devel@nongnu.org; Thu, 19 May 2011 14:11:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN7hF-0008Th-9e for qemu-devel@nongnu.org; Thu, 19 May 2011 14:11:42 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:44083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN7hE-0008Tb-VC for qemu-devel@nongnu.org; Thu, 19 May 2011 14:11:41 -0400 Message-ID: <4DD55D5B.30008@web.de> Date: Thu, 19 May 2011 20:11:39 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD420A5.2020606@web.de> <4DD51CF3.5040306@codemonkey.ws> <4DD51D36.7040504@siemens.com> <20110519173923.GF27310@redhat.com> In-Reply-To: <20110519173923.GF27310@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0B3958745BDBD371C183AF13" 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: Gleb Natapov Cc: Avi Kivity , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0B3958745BDBD371C183AF13 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-05-19 19:39, Gleb Natapov wrote: > On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote: >> On 2011-05-19 15:36, Anthony Liguori wrote: >>> On 05/18/2011 02:40 PM, Jan Kiszka wrote: >>>> On 2011-05-18 15:12, Avi Kivity wrote: >>>>> void cpu_register_memory_region(MemoryRegion *mr, target_phys_addr_= t >>>>> addr); >>>> >>>> OK, let's allow overlapping, but make it explicit: >>>> >>>> void cpu_register_memory_region_overlap(MemoryRegion *mr, >>>> target_phys_addr_t addr, >>>> int priority); >>> >>> The device doesn't actually know how overlapping is handled. This is= >>> based on the bus hierarchy. >> >> Devices don't register their regions, buses do. >> > Today PCI device may register region that overlaps with any other > registered memory region without even knowing it. Guest can write any > RAM address into PCI BAR and this RAM address will be come mmio are. Mo= re > interesting is what happens when guest reprogram PCI BAR to other addre= ss > - the RAM that was at the previous address just disappears. Obviously > this is crazy behaviour, but the question is how do we want to handle= > it? One option is to disallow such overlapping registration, another is= > to restore RAM mapping after PCI BAR is reprogrammed. If we chose secon= d > one the PCI will not know that _overlap() should be called. BARs may overlap with other BARs or with RAM. That's well-known, so PCI bridged need to register their regions with the _overlap variant unconditionally. In contrast to the current PhysPageDesc mechanism, the new region management will not cause any harm to overlapping regions so that they can "recover" when the overlap is gone. >=20 > Another example may be APIC region and PCI. They overlap, but neither > CPU nor PCI knows about it. And they do not need to. The APIC regions will be managed by the per-CPU region management, reusing the tool box we need for all bridges. It will register the APIC page with a priority higher than the default one, thus overriding everything that comes from the host bridge. I think that reflects pretty well real machine behaviour. Jan --------------enig0B3958745BDBD371C183AF13 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/ iEYEARECAAYFAk3VXVsACgkQitSsb3rl5xS+sgCgraRPqsp5VcUg/LO/nvpj5yDk 8MIAoNehhvuXo7d48VogH/7CU5fxxeIH =1+xU -----END PGP SIGNATURE----- --------------enig0B3958745BDBD371C183AF13--