From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JvFC4-00041P-4I for qemu-devel@nongnu.org; Sun, 11 May 2008 13:18:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JvFC2-00040a-JE for qemu-devel@nongnu.org; Sun, 11 May 2008 13:18:39 -0400 Received: from [199.232.76.173] (port=56415 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JvFC2-00040W-DA for qemu-devel@nongnu.org; Sun, 11 May 2008 13:18:38 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]:17183) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JvFC1-0006g8-TW for qemu-devel@nongnu.org; Sun, 11 May 2008 13:18:38 -0400 Received: by ug-out-1314.google.com with SMTP id j40so576096ugd.4 for ; Sun, 11 May 2008 10:18:36 -0700 (PDT) Message-ID: Date: Sun, 11 May 2008 19:18:36 +0200 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] Re: IO_MEM_NB_ENTRIES limit In-Reply-To: <482717EF.10508@bellard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <482717EF.10508@bellard.org> 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 On 11/05/2008, Fabrice Bellard wrote: > 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/. > > > To be more precise, I am concerned about the increase of the TLB size > which is likely to have a performance impact. I wasn't really concerned about the size change because it only means shifting left one bit further for all the accesses. On the other hand, two fields have to be accessed instead of one on io accesses, but there's less masking and shifting to extract the index. > Moreover, unless you > modify kqemu, your changes will break it. For kqemu, my prefered > solution would be that QEMU uses an explicit ioctl to inform kqemu about > the memory mappings. Yes, unfortunately kqemu would need to be modified as well and I had fogotten about that. > > Regarding the limitation of the number of entries, a less intrusive > change could be to use something similar to the subpage system (i.e. the > same entry would be used for several devices depending on the physical > address). Yes, maybe that's a better idea for now, although it means a sure slowdown for the machine using it. Here are some benchmark results: times for qemu-system-x86_86 from start to first line-feed on serial port: $ time for i in `seq 1 100`; do x86_64-softmmu/qemu-system-x86_64 -hda /dev/null -kernel /usr/src/linux/arch/x86_64/boot/bzImage -no-kqemu -append "console=ttyS0" -nographic; done Before: real 2m43.693s user 2m34.830s sys 0m7.028s After patching: real 2m36.836s user 2m28.189s sys 0m6.996s (there was a music player running on the computer both times) and from qemu start to issuing WIN_SETMULT ide command: $ time for i in `seq 1 10`; do x86_64-softmmu/qemu-system-x86_64 -hda /dev/null -kernel /usr/src/linux/arch/x86_64/boot/bzImage -no-kqemu -append "console=ttyS0" -nographic; done Before: real 1m44.326s user 1m19.637s sys 0m1.168s After patching: real 1m45.654s user 1m20.685s sys 0m1.204s (no music player or anything else running) -- Please do not print this email unless absolutely necessary. Spread environmental awareness.