From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Paolo Bonzini <pbonzini@redhat.com>, Alexander Graf <agraf@suse.de>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] TLB, cpu_mmu_index() and load/store vs ifetch
Date: Wed, 15 Jul 2015 08:50:34 +1000 [thread overview]
Message-ID: <1436914234.3948.276.camel@kernel.crashing.org> (raw)
Hi Paolo, Alex !
I was looking at the patches for speeding up ppc and was trying to
figure out if we could do things better, and reduce the number of modes
and flushes associated with them. While trying to understand it all, I
found something that might be a problem: How we handle the fact that we
can separately turn on/off translation on ppc for I and D side.
However, unless I missed something, qemu currently uses the same helper
to retrieve the mmu index for load/stores and instruction fetches.
Now, the TLB entry itself has different addresses for code, read and
write so it works. However that means that we have to use modes for
every combination of IR and DR in the MSR, which seems like quite a
waste. IE, ignoring PR and HV we already have 4 modes.
Would it be possible to have the target optionally provide a separate
accessor cpu_mmu_index_code() instead and use it in the few places
that actually try to fetch instructions such as get_page_addr_code() ?
That would allow us in effect to have just a single mode entry for
"real mode" (or two if we add support for HV) and simply point to
it appropriately for data or instructions separately.
Is there any reason why that wouldn't work ? I don't yet pretend to
fully understand that part of qemu/tcg :-) Anything I have overlooked ?
(Before I start hacking ...)
Cheers,
Ben.
reply other threads:[~2015-07-14 22:50 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1436914234.3948.276.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=pbonzini@redhat.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).