From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: <kvm-ppc@vger.kernel.org>, <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/6] KVM: PPC: E500: Explicitly mark shadow maps invalid
Date: Fri, 18 Jan 2013 13:03:12 -0600 [thread overview]
Message-ID: <1358535792.27354.4@snotra> (raw)
In-Reply-To: <67C46908-05AE-4902-97C2-FB8401FA09D0@suse.de> (from agraf@suse.de on Fri Jan 18 08:08:01 2013)
On 01/18/2013 08:08:01 AM, Alexander Graf wrote:
>
> On 18.01.2013, at 04:05, Scott Wood wrote:
>
> > Invalidation paths that call kvmppc_e500_tlbil_all(), such as
> MMUCSR0 and tlbivax, need a call to clear_tlb_refs() in order to get
> the valid bits cleared.
>
> Yeah, instead of kvmppc_e500_tlbil_all(). This might need a bit of
> rework, since we end up flushing the full host TLB / cache even when
> only evicting a single page at times.
I assume you're talking about the tlbivax single-page case. That could
certainly be improved, but I'd consider it a low priority until we have
a guest that actually uses it (Linux does tlbsx+tlbwe to locally
invalidate single pages on e500v2).
> So one more question I have here is why kvmppc_core_flush_tlb() calls
> clear_tlb1_bitmap().
> That function looks like a better candidate for "flush all of the
> pending host translation" than clear_tlb_refs() which to me sounds
> more like an implementation detail of the host TLB implementation.
I don't quite follow. The implementation of kvmppc_core_flush_tlb() is
also an implementation detail of the host TLB implementation.
> After clear_tlb_refs() there shouldn't be any pending bitmaps lying
> around, right?
clear_tlb_refs() doesn't clear the bitmap. It does a bulk invalidation
rather than calling inval_gtlbe_on_host(). Perhaps we should move the
clear_tlb1_bitmap() call into clear_tlb_refs() and rename the latter to
kvmppc_core_flush_tlb(). The dirty_tlb ioctl calls clear_tlb_refs()
without clearing the bitmap, but that's probably a bug.
> > In looking this up, I also saw that tlbilxlpid (T=0) seems to be
> broken; it compares PID/TID as if it were T=1. Don't be fooled by
> the "lpid" in the name; it's still relevant (and different from T=1)
> in the absence of E.HV, and should be treated as "tlbilx all". Once
> implemented, that will also presumably use kvmppc_e500_tlbil_all().
>
> Yay :). That's a follow-up patch though. Let me put it on the todo
> list.
Never mind, I wasn't reading the code closely enough. T=0 will use
inval_gtlbe_on_host() for all entries, though kvmppc_e500_tlbil_all()
would be more efficient.
-Scott
next prev parent reply other threads:[~2013-01-18 19:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-18 2:34 [PATCH v2 0/6] KVM: PPC: e500: Shadow TLB Improvements v2 Alexander Graf
2013-01-18 2:34 ` [PATCH 1/6] KVM: PPC: E500: Move write_stlbe higher Alexander Graf
2013-01-18 2:34 ` [PATCH 2/6] KVM: PPC: E500: Explicitly mark shadow maps invalid Alexander Graf
2013-01-18 3:05 ` Scott Wood
2013-01-18 14:08 ` Alexander Graf
2013-01-18 19:03 ` Scott Wood [this message]
2013-01-18 2:34 ` [PATCH 3/6] KVM: PPC: E500: Propagate errors when shadow mapping Alexander Graf
2013-01-18 2:34 ` [PATCH 4/6] KVM: PPC: e500: Call kvmppc_mmu_map for initial mapping Alexander Graf
2013-01-18 2:34 ` [PATCH 5/6] KVM: PPC: E500: Split host and guest MMU parts Alexander Graf
2013-01-18 2:34 ` [PATCH 6/6] KVM: PPC: e500: Implement TLB1-in-TLB0 mapping Alexander Graf
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=1358535792.27354.4@snotra \
--to=scottwood@freescale.com \
--cc=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.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