qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Aurelien Jarno <aurelien@aurel32.net>
To: "Hervé Poussineau" <hpoussin@reactos.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] MIPS CP0 random register strategy
Date: Sat, 3 Jan 2009 13:29:43 +0100	[thread overview]
Message-ID: <20090103122943.GA18974@volta.aurel32.net> (raw)
In-Reply-To: <495D1BBB.6090204@reactos.org>

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
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

      reply	other threads:[~2009-01-03 12:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-01 19:38 [Qemu-devel] [RFC] MIPS CP0 random register strategy Hervé Poussineau
2009-01-03 12:29 ` Aurelien Jarno [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090103122943.GA18974@volta.aurel32.net \
    --to=aurelien@aurel32.net \
    --cc=hpoussin@reactos.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).