qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] MIPS CP0 random register strategy


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [RFC] MIPS CP0 random register strategy
Date: Sat, 3 Jan 2009 13:29:43 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Thu, Jan 01, 2009 at 08:38:35PM +0100, Hervé Poussineau wrote:
> Hello,
Hi!

> MIPS TLBWR instruction asks the CPU to randomly overwrite a TLB entry by  
> the one we want to write. The TLB index needs to be between number of  
> wired TLB entries and TLB count - 1.
> However, algorithm to choose which one to overwrite is implementation  
> dependant.
>
> After checking MIPS CPU documentations, 4 algorithms are emerging:
> - Random register is decremented once at each clock tick
> - Random register is decremented once after 'number of wired TLB  
> entries' clock ticks
> - Random register is decremented only after TLBWR instruction
> - Random register uses a Not Last Used algorithm, ie whatever value  
> which is not the previous one
>
> At the moment, Qemu implementation seems to be more the 4th one, but can  
> return the same value more than once.
> Due to this, NetBSD 1.6.2 on MIPS Magnum emulation crashes.
>
> Attached patch tries to fix the problem by adding 4 methods to update  
> Random value.
> Each CPU needs to define which Random algorithm it is using.

After looking to the patch, I am not sure we really want to implement
the 4 different methods. On the 4 different methods, only the one which
decrement the random register actually corresponds to what the real CPU
does. The instruction rate in QEMU is not related to the clock ticks,
which makes the two algorithms based on clock ticks non-accurate, and
the LRU algorithm which is implemented is actually a random algorithm.

If we look at the 4 algorithm, what seems to be important is:
- having something more or less random
- not returning the same value twice

What about only modifying the current algorithm to fix the second point?

> Patch also optimizes CP0_Random access, by not requiring call to a  
> helper function

This seems to be wrong, two reads from CP0_Random will return the same
value, which is wrong at least for some algorithms.

> Finally, it initializes CP0_Random even in user mode emulation, which  
> was not the case before.

Also please note, that you patch breaks the read from CP0_Count.

Aurelien

-- 
  .''`.  Aurelien Jarno             | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   address@hidden         | address@hidden
   `-    people.debian.org/~aurel32 | www.aurel32.net




reply via email to

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