Re: [Qemu-devel] Re: IO_MEM_NB_ENTRIES limit

[Fabrice Bellard <fabrice@bellard.org>]

andrzej zaborowski wrote:
> 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.

My concern was the larger size necessary in the L1 cache.

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

Until kqemu is modified, it could be possible to keep a duplicated
legacy physical mapping for kqemu in QEMU.

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

Right.

> [...]

Fabrice.