From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JvDRJ-0002VO-7I for qemu-devel@nongnu.org; Sun, 11 May 2008 11:26:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JvDRI-0002V6-CY for qemu-devel@nongnu.org; Sun, 11 May 2008 11:26:16 -0400 Received: from [199.232.76.173] (port=52528 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JvDRI-0002V3-AF for qemu-devel@nongnu.org; Sun, 11 May 2008 11:26:16 -0400 Received: from relay2-v.mail.gandi.net ([217.70.178.76]:48590) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JvDRH-0003jP-OU for qemu-devel@nongnu.org; Sun, 11 May 2008 11:26:16 -0400 Received: from localhost (mfilter1-c.gandi.net [217.70.182.21]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id 20540135BD for ; Sun, 11 May 2008 17:26:14 +0200 (CEST) Received: from relay2-v.mail.gandi.net ([217.70.178.76]) by localhost (mfilter1-c.mgt.gandi.net [217.70.182.21]) (amavisd-new, port 10024) with ESMTP id SVZ0R4i4iIR8 for ; Sun, 11 May 2008 17:26:08 +0200 (CEST) Received: from [84.99.204.158] (158.204.99-84.rev.gaoland.net [84.99.204.158]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id 4D850135AB for ; Sun, 11 May 2008 17:26:08 +0200 (CEST) Message-ID: <48270FDE.3040405@bellard.org> Date: Sun, 11 May 2008 17:25:18 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: IO_MEM_NB_ENTRIES limit References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org andrzej zaborowski wrote: > On 15/04/2008, andrzej zaborowski wrote: >> the maximum number of memory-mapped IO regions in qemu is >> IO_MEM_NB_ENTRIES which is defined using TARGET_PAGE_BITS. Due to >> tiny pages available on ARM, IO_MEM_NB_ENTRIES is only 64 there. >> OMAP2 cpu has many more logical IO regions than 64 and it makes sense >> to register them as separate. >> >> To be able to set IO_MEM_NB_ENTRIES higher, the io region index and >> the address bits would have to be stored in separate fields in >> PhysPageDesc and in CPUTLBEntry structs, instead of io index being >> stored in the lower bits of addresses. This would double the size of >> both structs. I'd like to hear if there are any other ideas for >> removing the upper limit for IO_MEM_NB_ENTRIES. > > Here's a less hacky patch to store the IO region number in a separate > field from the page start address, in PhysPageDesc and CPUTLBEntry, > thus simplifying a couple of things. It's intrusive but will ease any > further extension and I'd like to commit it some time if there are no > better ideas. It works in my tests but there may be corner cases that > I broke. > > The maximum number of IO_MEM_ROMD regions is still dependent on page > size because the API to register these uses the same value to store > the address and the io_index, so removing this would require api > change that affects hw/. > [...] Does it work with kqemu ? Did you make benchmarks ? Regards, Fabrice.