From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMyIP-0002pP-AY for qemu-devel@nongnu.org; Thu, 19 May 2011 04:09:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMyIO-0003Dx-1P for qemu-devel@nongnu.org; Thu, 19 May 2011 04:09:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMyIN-0003Dq-Mo for qemu-devel@nongnu.org; Thu, 19 May 2011 04:09:23 -0400 Message-ID: <4DD4D02D.4050500@redhat.com> Date: Thu, 19 May 2011 11:09:17 +0300 From: Avi Kivity 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: 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: Anthony Liguori Cc: Jan Kiszka , qemu-devel , Peter Maydell On 05/18/2011 10:10 PM, 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 >>>>> 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 > Memory regions do the exact same thing, except at registration time. The nested if/elif/else tree is captured in the nested region tree. -- error compiling committee.c: too many arguments to function