From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMmPY-00087Z-Ey for qemu-devel@nongnu.org; Wed, 18 May 2011 15:28:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMmPX-0005AJ-0p for qemu-devel@nongnu.org; Wed, 18 May 2011 15:28:00 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:40275) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMmPW-0005A9-Km for qemu-devel@nongnu.org; Wed, 18 May 2011 15:27:58 -0400 Message-ID: <4DD41DBB.2020108@web.de> Date: Wed, 18 May 2011 21:27:55 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD3D236.90708@siemens.com> <4DD3D95E.2060105@redhat.com> <4DD3E1B3.3020405@siemens.com> <4DD3E610.1080201@siemens.com> <4DD4199E.2000702@codemonkey.ws> In-Reply-To: <4DD4199E.2000702@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig21862EAAEA589ABC6B9F7640" 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: Anthony Liguori Cc: Peter Maydell , Avi Kivity , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig21862EAAEA589ABC6B9F7640 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-05-18 21:10, Anthony Liguori wrote: > On 05/18/2011 10:30 AM, Jan Kiszka wrote: >> On 2011-05-18 17:17, Peter Maydell wrote: >>> On 18 May 2011 16:11, Jan Kiszka wrote: >>>> On 2011-05-18 16:36, Avi Kivity wrote: >>>>> There is nothing we can do with a return code. You can't fail an m= mio >>>>> that causes overlapping physical memory map. >>>> >>>> We must fail such requests to make progress with the API. That may >>>> happen either on caller side or in cpu_register_memory_region itself= >>>> (hwerror). Otherwise the new API will just be a shiny new facade for= on >>>> old and still fragile building. >>> >>> If we don't allow overlapping regions, then how do you implement >>> things like "on startup board maps ROM into lower addresses >>> over top of devices, but later it is unmapped and you can see >>> the underlying devices" ? (You can't currently do this AFAIK, >>> and it would be nice if the new API supported it.) >> >> Right, we can't do this properly, and that's why the attempt if the >> i440fx chipset model is so horribly broken ATM. >> >> Just allowing overlapping does not solve this problem either. It does >> not specify what region is on top and what is below (even worse if >> multiple regions overlap at the place). >> >> We need some managing instance here, and that is e.g. the chipset that= >> provide control over the overlap in reality. It could hook up a >> PhysMemClient to receive and redirect updates to subregions, or only >> allow to register them in disabled state. >=20 > I think that gets ugly pretty fast. The way this works IRL is that all= > I/O dispatches pass through the chipset. You literally need something > as simple as: >=20 > static void i440fx_io_intercept(void *opaque, uint64_t addr, uint32_t > value, int size, MemRegion *next) > { > I440FX *s =3D opaque; >=20 > if (range_overlaps(addr, size, PAM_REGION)) { > ... > } else { > dispatch_io(next, addr, value, size); > } > } >=20 > There's no need for an explicit intercept mechanism if you make multipl= e > levels have their own dispatch tables and register progressively larger= > regions. In fact.... >=20 > You really don't need to register 90% of the time. In the case of a PC= > with i440fx, it's really quite simple: >=20 > if an I/O is to the APIC page, > it's handled by the APIC That's not that simple. We need to tell apart: - if a cpu issued the request, and which one =3D> forward to APIC - if the range was addressed by a device (PCI or other system bus devices) =3D> forward to MSI or other MMIO handlers > elif the I/O is in ROM regions: > if PAM RE or WE > redirect to RAM appropriately > else: > send to ROMs > elif the I/O is in the PCI windows: > send to the PCI bus > else: > send to the PIIX3 >=20 > For x86, you could easily completely skip the explicit registration and= > just have a direct dispatch to the i440fx and implement something > slightly more fancy than the above. >=20 > And I think this is true for most other types of boards too. This all melts down that we need to stop accepting memory region mappings from everywhere at core level, but properly dispatch them up the device tree. A device should register against its bus which can then forward or handle the mapping directly. And that handling requires a central tool box to avoid reinventing wheels. That's a worthwhile change, though a much bigger one than I was originally hoping to get away with. Jan --------------enig21862EAAEA589ABC6B9F7640 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/ iEYEARECAAYFAk3UHbsACgkQitSsb3rl5xRhxACfb7b5a+b9jGiUPjiVgtrRV09x cpMAnA/dK6WryAz9lPPhucVFpCq3cDzX =l+4p -----END PGP SIGNATURE----- --------------enig21862EAAEA589ABC6B9F7640--