Re: [Qemu-devel] Re: IO_MEM_NB_ENTRIES limit

[Fabrice Bellard <fabrice@bellard.org>]

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. 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.

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).

Regards,

Fabrice.