qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Blue Swirl <blauwirbel@gmail.com>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [5849] Change MMIO callbacks to use offsets, not absolute addresses.
Date: Wed, 25 Feb 2009 21:54:38 +0200	[thread overview]
Message-ID: <f43fc5580902251154r92cff22ufb1636a21ea5c0e4@mail.gmail.com> (raw)
In-Reply-To: <200902242228.11210.paul@codesourcery.com>

On 2/25/09, Paul Brook <paul@codesourcery.com> wrote:
> > > Bits of both. The TLB is tightly tied into the code generator. Once we
>  > > get out of the first-level TLB lookup you've not got anywhere near enough
>  > > information to be able to restore the CPU state. The only way to raise
>  > > exceptions from within an IO handler is to sync CPU state before every
>  > > memory access, and you really don't want to do that. This is why the
>  > > existing unassigned access fault code is busted.
>  >
>  > But because of possible MMU and unaligned access faults we already
>  > save PC and NPC (not in all cases).  Handling of those faults works,
>  > it's really needed for correct operation. For some faults PC/NPC save
>  > is not necessary, the fault handler can calculate env->pc from host
>  > PC. Why would the unassigned fault be different?
>
>
> I'm not sure how I can be any clearer.
>
>  You either have to explicitly sync state (In teh case of SPARC this means
>  saving PC and NPC), or you have to know about the fault in the low-level TLB
>  processing code where you still have enough information to recover this
>  information. Once you get into an IO handler you've no way of figuring out
>  what the current CPU state is. The "not in all cases"/"some faults" you
>  mention above is relatively rare instructions that may fault v.s. every
>  memory access.

Well, until r4431 we always saved PC and NPC for all memory access
instructions, but with that commit, some of the checks could be
removed and everything still work.

http://svn.savannah.gnu.org/viewvc?view=rev&root=qemu&revision=4431

I'm pretty sure that the instructions without checks generate faults
successfully, and also the 64/128 bit instructions where the checks
remain didn't work with the checks removed. And it was not possible to
remove the checks or state saving without the cpu_restore_state2 by
Fabrice. This area is still a bit murky for me.

  reply	other threads:[~2009-02-25 19:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-01 18:59 [Qemu-devel] [5849] Change MMIO callbacks to use offsets, not absolute addresses Paul Brook
2009-02-23 12:18 ` Robert Reif
2009-02-23 12:36   ` Paul Brook
2009-02-23 12:42     ` Robert Reif
2009-02-23 13:16       ` Paul Brook
2009-02-23 16:43         ` Robert Reif
2009-02-23 17:04           ` Paul Brook
2009-02-24  0:08             ` Robert Reif
2009-02-24  0:30               ` Paul Brook
2009-02-24  1:05                 ` Robert Reif
2009-02-24  1:12                   ` Paul Brook
2009-02-24  1:27                     ` Robert Reif
2009-02-24  1:50                       ` Paul Brook
2009-02-24 21:04                         ` Blue Swirl
2009-02-24 22:28                           ` Paul Brook
2009-02-25 19:54                             ` Blue Swirl [this message]
2009-02-26 15:19                               ` Paul Brook

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=f43fc5580902251154r92cff22ufb1636a21ea5c0e4@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --cc=paul@codesourcery.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 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).