[Qemu-devel] TLB collision

[Qemu-devel] TLB collision

[Michael Rolnik]

[-- Attachment #1: Type: text/plain, Size: 1125 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1473 bytes --]

Re: [Qemu-devel] TLB collision

[Andreas Färber]

Hi,

Am 24.11.2011 10:53, schrieb Michael Rolnik:
> I have a question regarding MMU.
> I've built a SPARC based small embedded system.

You've already sent this two times. What you keep forgetting is to cc
the sparc maintainer and to tell us whether this is sparc32 or sparc64.
The latter was rather incomplete, so you might be hitting a corner case.

Also when building new machines you are generally well advised to use an
up-to-date git version.

Regards,
Andreas

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


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] TLB collision

[Blue Swirl]

On Thu, Nov 24, 2011 at 09:53, Michael Rolnik <mrolnik@gmail.com> 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
>