Re: [Qemu-devel] Re: IO_MEM_NB_ENTRIES limit

["andrzej zaborowski" <balrogg@gmail.com>]

On 11/05/2008, Fabrice Bellard <fabrice@bellard.org> wrote:
> andrzej zaborowski wrote:
>  > On 15/04/2008, andrzej zaborowski <balrogg@gmail.com> 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.