[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 17:25:18 +0200 |
User-agent: |
Thunderbird 1.5.0.9 (X11/20070212) |
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/.
> [...]
Does it work with kqemu ? Did you make benchmarks ?
Regards,
Fabrice.