qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] TLB collision


From: Blue Swirl
Subject: Re: [Qemu-devel] TLB collision
Date: Sat, 26 Nov 2011 07:45:25 +0000

On Thu, Nov 24, 2011 at 09:53, Michael Rolnik <address@hidden> wrote:
> Hi all,
> I have a question regarding MMU.
> I've built a SPARC based small embedded system.
> at this system addresses 0x00000000-0x00008000  (32KB) belong to ROM and
> 0x80000000 - 0x80010000 to RAM.
> the problem is that when a code from first ROM page accesses a memory at the
> address 0x80000000 there is an infinite loop.
>    - cpu_sparc_handle_mmu_fault is called to bring addres 0x00000000
>    - cpu_sparc_handle_mmu_fault is called to bring 0x80000000 and flushes
> 0x00000000
>    - cpu_sparc_handle_mmu_fault is called to bring 0x00000000 and flushes
> 0x80000000
>  ...
> this can be fixed if I set CPU_TLB_BITS to be 20 bits (assuming page size of
> 4KB).
> is there a better solution?

I don't think this should be the case, the TLB is not accessed
simultaneously for code and data accesses so progress should always be
made. But (assuming Sparc32), the CPU is in boot mode at startup. This
means that all non ASI accesses will be directed to boot ROM which
could explain what you see. Maybe your ROM should clear the boot mode,
or the CPU (which one?) doesn't have the mode.

> I was thinking about 2-way TLB so two virtual addresses sharing same TLB
> entry will be resident.
> in order not to degrade performance
>     1. tcg_out_qemu_ld and tcg_out_qemu_st should remain as it, which mean
> they will always look into way0.
>     2. tlb_set_page should copy way0 to way1 and program way0 with new
> values
>     3. all other routines dealing with TLB should search both ways.
> what do you think?
> --
> Best Regards,
> Michael Rolnik
>



reply via email to

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