From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN8O0-0004Wh-Tr for qemu-devel@nongnu.org; Thu, 19 May 2011 14:55:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN8Nz-0007R2-EG for qemu-devel@nongnu.org; Thu, 19 May 2011 14:55:52 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:35691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN8Ny-0007Nd-WE for qemu-devel@nongnu.org; Thu, 19 May 2011 14:55:51 -0400 Message-ID: <4DD567B5.1060205@web.de> Date: Thu, 19 May 2011 20:55:49 +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> <4DD55D5B.30008@web.de> <20110519182203.GH27310@redhat.com> <4DD56126.20808@web.de> <20110519184056.GJ27310@redhat.com> <4DD56543.9020404@web.de> <20110519185019.GK27310@redhat.com> In-Reply-To: <20110519185019.GK27310@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig82B9B734AEFA549D01ED04F2" 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) --------------enig82B9B734AEFA549D01ED04F2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-05-19 20:50, Gleb Natapov wrote: > On Thu, May 19, 2011 at 08:45:23PM +0200, Jan Kiszka wrote: >> On 2011-05-19 20:40, Gleb Natapov wrote: >>> On Thu, May 19, 2011 at 08:27:50PM +0200, Jan Kiszka wrote: >>>> On 2011-05-19 20:22, Gleb Natapov wrote: >>>>> On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote: >>>>>> 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 ad= dr, >>>>>>>>>> int priority); >>>>>>>>> >>>>>>>>> The device doesn't actually know how overlapping is handled. T= his 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 a= re. More >>>>>>> interesting is what happens when guest reprogram PCI BAR to other= address >>>>>>> - the RAM that was at the previous address just disappears. Obvio= usly >>>>>>> this is crazy behaviour, but the question is how do we want to = handle >>>>>>> it? One option is to disallow such overlapping registration, anot= her is >>>>>>> to restore RAM mapping after PCI BAR is reprogrammed. If we chose= second >>>>>>> one the PCI will not know that _overlap() should be called. >>>>>> >>>>>> BARs may overlap with other BARs or with RAM. That's well-known, s= o PCI >>>>>> bridged need to register their regions with the _overlap variant >>>>>> unconditionally. In contrast to the current PhysPageDesc mechanism= , the >>>>> With what priority? If it needs to call _overlap unconditionally wh= y not >>>>> always call _overlap and drop not _overlap variant? >>>> >>>> Because we should catch accidental overlaps in all those non PCI dev= ices >>>> with hard-wired addressing. That's a bug in the device/machine model= and >>>> should be reported as such by QEMU. >>> Why should we complicate API to catch unlikely errors? If you want to= >>> debug that add capability to dump memory map from the monitor. >> >> Because we need to switch tons of code that so far saw a fairly >> different reaction of the core to overlapping regions. >> > How so? Today if there is accidental overlap device will not function p= roperly. > With new API it will be the same. I rather expect subtle differences as overlapping registration changes existing regions, in the future those will recover. >=20 >>> >>>> >>>>> >>>>>> new region management will not cause any harm to overlapping regio= ns so >>>>>> that they can "recover" when the overlap is gone. >>>>>> >>>>>>> >>>>>>> Another example may be APIC region and PCI. They overlap, but nei= ther >>>>>>> CPU nor PCI knows about it. >>>>>> >>>>>> And they do not need to. The APIC regions will be managed by the p= er-CPU >>>>>> region management, reusing the tool box we need for all bridges. I= t will >>>>>> register the APIC page with a priority higher than the default one= , thus >>>>>> overriding everything that comes from the host bridge. I think tha= t >>>>>> reflects pretty well real machine behaviour. >>>>>> >>>>> What is "higher"? How does it know that priority is high enough? >>>> >>>> Because no one else manages priorities at a specific hierarchy level= =2E >>>> There is only one. >>>> >>> PCI and CPU are on different hierarchy levels. PCI is under the PIIX = and >>> CPU is on a system BUS. >> >> The priority for the APIC mapping will be applied at CPU level, of >> course. So it will override everything, not just PCI. >> > So you do not need explicit priority because the place in hierarchy > implicitly provides you with one. Yes. Alternatively, you could add a prio offset to all mappings when climbing one level up, provided that offset is smaller than the prio range locally available to each level. Jan --------------enig82B9B734AEFA549D01ED04F2 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/ iEYEARECAAYFAk3VZ7UACgkQitSsb3rl5xSG5gCdGZb8xfAYSSwHfCe6mepES5VG hfEAn09ynNeuSL68d3cHgUs0eWDV9Q1r =yMIR -----END PGP SIGNATURE----- --------------enig82B9B734AEFA549D01ED04F2--