public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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

  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