All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org, balrogg@gmail.com
Subject: Re: [Qemu-devel] [PATCH] PXA-specific ARM hacks.
Date: Sat, 17 Mar 2007 15:03:59 +0000	[thread overview]
Message-ID: <200703171503.59810.paul@codesourcery.com> (raw)
In-Reply-To: <fb249edb0703161506v765216c9jaf7a9e85e3c4cf40@mail.gmail.com>

On Friday 16 March 2007 22:06, andrzej zaborowski wrote:
> This patch contains some ugly but very useful chnages:
>  - in cpu-exec.c, halt the arm CPU on CPU_INTERRUPT_HALT like in other
> architectures.

This is ok. Though I'd prefer it to actually be common code (like 
CPU_INTERRUPT_DEBUG).

>  - wake the cpu up on CPU_INTERRUPT_EXITTB - this serves waking the
> CPU up without asserting IRQ or FIQ, which is possible on PXA. Would
> it be better to add a separate interrupt type instead?

I think this is probably ok. Could do with a comment somewhere saying so.

>  - in target-arm/translate.c, don't terminate the TB after a CP15
> write. The purpose of this is to imitate the real processor's
> instruction cache (to some degree). OSes should never need rely on the
> cache prefetch but unfortunately Linux for pxa does when it's waking
> up from sleep or deep idle, when enabling the MMU (simplifies things a
> lot for Linux).

This is not acceptable in its current form. IIRC on arm cores the effects take 
effect once all insn have worked through the pipeline (typically a few 
cycles), and I bet there's code that relies on this. ie:
mcr cp15, ...;nop;nop;nop;nop;@expect cp15 write to have taken effect by now

A more acceptable solution would be:
- Only extend the TB for the specific instruction that linux abuses
- Limit the number of instructions that can follow before the end of the TB.
- Add a comment saying what this hack is for.

Paul

  reply	other threads:[~2007-03-17 15:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-16 22:06 [Qemu-devel] [PATCH] PXA-specific ARM hacks andrzej zaborowski
2007-03-17 15:03 ` Paul Brook [this message]
2007-03-17 19:32   ` andrzej zaborowski
2007-03-17 20:16     ` andrzej zaborowski

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=200703171503.59810.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=balrogg@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.