qemu-devel
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]