From: Scott Wood <scottwood@freescale•com>
To: Alexander Graf <agraf@suse•de>
Cc: Mihai Caraman <mihai.caraman@freescale•com>,
linuxppc-dev@lists•ozlabs.org, kvm@vger•kernel.org,
kvm-ppc@vger•kernel.org
Subject: Re: [PATCH 2/2] KVM: PPC: Book3E: Get vcpu's last instruction for emulation
Date: Tue, 9 Jul 2013 19:06:37 -0500 [thread overview]
Message-ID: <1373414797.8183.212@snotra> (raw)
In-Reply-To: <BD85AACF-5975-459D-9D28-8DB672D6B5C3@suse.de> (from agraf@suse.de on Tue Jul 9 16:44:24 2013)
On 07/09/2013 04:44:24 PM, Alexander Graf wrote:
>=20
> On 09.07.2013, at 20:46, Scott Wood wrote:
> > I suspect that tlbsx is faster, or at worst similar. And unlike =20
> comparing tlbsx to lwepx (not counting a fix for the threading =20
> problem), we don't already have code to search the guest TLB, so =20
> testing would be more work.
>=20
> We have code to walk the guest TLB for TLB misses. This really is =20
> just the TLB miss search without host TLB injection.
>=20
> So let's say we're using the shadow TLB. The guest always has its say =20
> 64 TLB entries that it can count on - we never evict anything by =20
> accident, because we store all of the 64 entries in our guest TLB =20
> cache. When the guest faults at an address, the first thing we do is =20
> we check the cache whether we have that page already mapped.
>=20
> However, with this method we now have 2 enumeration methods for guest =20
> TLB searches. We have the tlbsx one which searches the host TLB and =20
> we have our guest TLB cache. The guest TLB cache might still contain =20
> an entry for an address that we already invalidated on the host. =20
> Would that impose a problem?
>=20
> I guess not because we're swizzling the exit code around to instead =20
> be an instruction miss which means we restore the TLB entry into our =20
> host's TLB so that when we resume, we land here and the tlbsx hits. =20
> But it feels backwards.
Any better way? Searching the guest TLB won't work for the LRAT case, =20
so we'd need to have this logic around anyway. We shouldn't add a =20
second codepath unless it's a clear performance gain -- and again, I =20
suspect it would be the opposite, especially if the entry is not in =20
TLB0 or in one of the first few entries searched in TLB1. The tlbsx =20
miss case is not what we should optimize for.
> At least this code has to become something more generic, such as =20
> kvmppc_read_guest(vcpu, addr, TYPE_INSN) and move into the host mmu =20
> implementation, as it's 100% host mmu specific.
I agree that e500_mmu_host.c is a better place for it (with an ifdef =20
for BOOKEHV), but supporting anything other than instruction fetches =20
could wait until we have a user for it (it means extra code to figure =20
out if permissions are correct).
-Scott=
next prev parent reply other threads:[~2013-07-10 0:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-28 9:20 [PATCH 1/2] KVM: PPC: e500mc: Revert "add load inst fixup" Mihai Caraman
2013-06-28 9:20 ` [PATCH 2/2] KVM: PPC: Book3E: Get vcpu's last instruction for emulation Mihai Caraman
2013-07-08 13:39 ` Alexander Graf
2013-07-09 17:13 ` Scott Wood
2013-07-09 17:44 ` Alexander Graf
2013-07-09 18:46 ` Scott Wood
2013-07-09 21:44 ` Alexander Graf
2013-07-10 0:06 ` Scott Wood [this message]
2013-07-10 10:15 ` Alexander Graf
2013-07-10 18:42 ` Scott Wood
2013-07-10 22:50 ` Alexander Graf
2013-07-11 0:15 ` Scott Wood
2013-07-11 0:17 ` Alexander Graf
2013-07-09 21:45 ` Alexander Graf
2013-07-10 0:12 ` Scott Wood
2013-07-10 10:18 ` Alexander Graf
2013-07-10 18:37 ` Scott Wood
2013-07-10 22:48 ` Alexander Graf
-- strict thread matches above, loose matches on Subject: below --
2013-06-06 16:11 [PATCH 1/2] KVM: PPC: e500mc: Revert "add load inst fixup" Mihai Caraman
2013-06-06 16:11 ` [PATCH 2/2] KVM: PPC: Book3E: Get vcpu's last instruction for emulation Mihai Caraman
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=1373414797.8183.212@snotra \
--to=scottwood@freescale$(echo .)com \
--cc=agraf@suse$(echo .)de \
--cc=kvm-ppc@vger$(echo .)kernel.org \
--cc=kvm@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mihai.caraman@freescale$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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