[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: IO_MEM_NB_ENTRIES limit
From: |
Fabrice Bellard |
Subject: |
Re: [Qemu-devel] Re: IO_MEM_NB_ENTRIES limit |
Date: |
Sun, 11 May 2008 19:39:59 +0200 |
User-agent: |
Thunderbird 1.5.0.9 (X11/20070212) |
andrzej zaborowski wrote:
> On 11/05/2008, Fabrice Bellard <address@hidden> wrote:
>> andrzej zaborowski wrote:
>> > On 15/04/2008, andrzej zaborowski <address@hidden> 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.