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 19:03:12 +0000 [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
WARNING: multiple messages have this Message-ID (diff)
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: 20+ 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 ` Alexander Graf
2013-01-18 2:34 ` [PATCH 1/6] KVM: PPC: E500: Move write_stlbe higher Alexander Graf
2013-01-18 2:34 ` Alexander Graf
2013-01-18 2:34 ` [PATCH 2/6] KVM: PPC: E500: Explicitly mark shadow maps invalid Alexander Graf
2013-01-18 2:34 ` Alexander Graf
2013-01-18 3:05 ` Scott Wood
2013-01-18 3:05 ` Scott Wood
2013-01-18 14:08 ` Alexander Graf
2013-01-18 14:08 ` Alexander Graf
2013-01-18 19:03 ` Scott Wood [this message]
2013-01-18 19:03 ` Scott Wood
2013-01-18 2:34 ` [PATCH 3/6] KVM: PPC: E500: Propagate errors when shadow mapping Alexander Graf
2013-01-18 2:34 ` 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 ` 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 ` Alexander Graf
2013-01-18 2:34 ` [PATCH 6/6] KVM: PPC: e500: Implement TLB1-in-TLB0 mapping Alexander Graf
2013-01-18 2:34 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.