From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMm8Y-0004an-OM for qemu-devel@nongnu.org; Wed, 18 May 2011 15:10:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMm8X-0001hs-Hd for qemu-devel@nongnu.org; Wed, 18 May 2011 15:10:26 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:62497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMm8X-0001hl-FJ for qemu-devel@nongnu.org; Wed, 18 May 2011 15:10:25 -0400 Received: by yib19 with SMTP id 19so756024yib.4 for ; Wed, 18 May 2011 12:10:24 -0700 (PDT) Message-ID: <4DD4199E.2000702@codemonkey.ws> Date: Wed, 18 May 2011 14:10:22 -0500 From: Anthony Liguori 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> In-Reply-To: <4DD3E610.1080201@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , Avi Kivity , qemu-devel 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 mmio >>>> 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. 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: static void i440fx_io_intercept(void *opaque, uint64_t addr, uint32_t value, int size, MemRegion *next) { I440FX *s = opaque; if (range_overlaps(addr, size, PAM_REGION)) { ... } else { dispatch_io(next, addr, value, size); } } There's no need for an explicit intercept mechanism if you make multiple levels have their own dispatch tables and register progressively larger regions. In fact.... You really don't need to register 90% of the time. In the case of a PC with i440fx, it's really quite simple: if an I/O is to the APIC page, it's handled by the APIC 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 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. And I think this is true for most other types of boards too. Regards, Anthony Liguori > > Jan >