From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-devel@nongnu.org, Fabien Chouteau <chouteau@adacore.com>
Subject: Re: [Qemu-devel] [PATCH] Add e500 instructions dcblc, dcbtls and dcbtstl as no-op
Date: Thu, 30 Jun 2011 16:46:30 -0500 [thread overview]
Message-ID: <20110630164630.2bd57166@schlenkerla.am.freescale.net> (raw)
In-Reply-To: <86AF921C-3FD1-409A-ACFD-EEEA23BBE130@suse.de>
On Thu, 30 Jun 2011 23:34:37 +0200
Alexander Graf <agraf@suse.de> wrote:
> We could just keep an internal counter that memorizes how much memory is locked and sets the bit after exceeding the fake cache size.
And keep track of unlocks, decrementing the counter only if the address was
already locked... seems better to keep it simple and just be honest about
the failure until a real need for trickery arises.
> The only problem I could see remaining is that CAR could potentially fail, as it can access addresses in cache directly that don't have to have underlying RAM mapped. However, I'd hope that only firmware does this and we usually don't execute real firmware in qemu :)
This is a case where it would be nice for the guest to see the failure
indication, if we're lucky enough that it bothers to check.
But yeah, it's unlikely to happen outside of firmware.
> Also, lock set instructions seem to raise DSIs, so we need to generate some loads that don't go anywhere.
Yes.
Note that dcbtstls is treated as a store, which is a little trickier.
-Scott
next prev parent reply other threads:[~2011-06-30 21:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-27 13:15 [Qemu-devel] [PATCH] Add e500 instructions dcblc, dcbtls and dcbtstl as no-op Fabien Chouteau
2011-06-27 16:28 ` Scott Wood
2011-06-28 8:17 ` Fabien Chouteau
2011-06-28 16:20 ` Scott Wood
2011-06-30 8:25 ` Fabien Chouteau
2011-06-30 16:17 ` Scott Wood
2011-06-30 21:34 ` Alexander Graf
2011-06-30 21:46 ` Scott Wood [this message]
2011-06-30 21:56 ` Alexander Graf
2011-06-30 22:11 ` Scott Wood
2011-06-30 22:18 ` Alexander Graf
2011-06-30 22:23 ` Scott Wood
2011-06-30 22:28 ` Alexander Graf
2011-06-30 22:32 ` Scott Wood
2011-06-30 22:38 ` Alexander Graf
2011-07-01 14:59 ` Fabien Chouteau
2011-07-01 15:05 ` Alexander Graf
2011-07-01 15:39 ` Fabien Chouteau
2011-07-01 16:00 ` Scott Wood
2011-07-01 16:21 ` Fabien Chouteau
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=20110630164630.2bd57166@schlenkerla.am.freescale.net \
--to=scottwood@freescale.com \
--cc=agraf@suse.de \
--cc=chouteau@adacore.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).