All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Jones <drjones@redhat.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>,
	kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v3 0/3] arm/arm64: KVM: Random selection of cache related fixes
Date: Mon, 26 Jan 2015 18:09:45 +0100	[thread overview]
Message-ID: <20150126170945.GC3536@hawk.usersys.redhat.com> (raw)
In-Reply-To: <1421865588-19761-1-git-send-email-marc.zyngier@arm.com>

On Wed, Jan 21, 2015 at 06:39:45PM +0000, Marc Zyngier wrote:
> This small series fixes a number of issues that Christoffer and I have
> been trying to nail down for a while, having to do with the host dying
> under load (swapping), and also with the way we deal with caches in
> general (and with set/way operation in particular):
> 
> - The first one changes the way we handle cache ops by set/way,
>   basically turning them into VA ops for the whole memory. This allows
>   platforms with system caches to boot a 32bit zImage, for example.
> 
> - The second one fixes a corner case that could happen if the guest
>   used an uncached mapping (or had its caches off) while the host was
>   swapping it out (and using a cache-coherent IO subsystem).
> 
> - Finally, the last one fixes this stability issue when the host was
>   swapping, by using a kernel mapping for cache maintenance instead of
>   the userspace one.
> 
> With these patches (and both the TLB invalidation and HCR fixes that
> are on their way to mainline), the APM platform seems much more robust
> than it previously was. Fingers crossed.
> 
> The first round of review has generated a lot of traffic about
> ASID-tagged icache management for guests, but I've decided not to
> address this issue as part of this series. The code is broken already,
> and there isn't any virtualization capable, ASID-tagged icache core in
> the wild, AFAIK. I'll try to revisit this in another series, once I
> have wrapped my head around it (or someone beats me to it).
> 
> Based on 3.19-rc5, tested on Juno, X-Gene, TC-2 and Cubietruck.
> 
> Also at git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git kvm-arm64/mm-fixes-3.19
> 
> * From v2: [2]
> - Reworked the algorithm that tracks the state of the guest's caches,
>   as there is some cases I didn't anticipate. In the end, the
>   algorithm is simpler.
> 
> * From v1: [1]
> - Dropped Steve's patch after discussion with Andrea
> - Refactor set/way support to avoid code duplication, better comments
> - Much improved comments in patch #2, courtesy of Christoffer
> 
> [1]: http://www.spinics.net/lists/kvm-arm/msg13008.html
> [2]: http://www.spinics.net/lists/kvm-arm/msg13161.html
> 
> Marc Zyngier (3):
>   arm/arm64: KVM: Use set/way op trapping to track the state of the
>     caches
>   arm/arm64: KVM: Invalidate data cache on unmap
>   arm/arm64: KVM: Use kernel mapping to perform invalidation on page
>     fault
> 
>  arch/arm/include/asm/kvm_emulate.h   |  10 +++
>  arch/arm/include/asm/kvm_host.h      |   3 -
>  arch/arm/include/asm/kvm_mmu.h       |  77 +++++++++++++---
>  arch/arm/kvm/arm.c                   |  10 ---
>  arch/arm/kvm/coproc.c                |  64 +++-----------
>  arch/arm/kvm/coproc_a15.c            |   2 +-
>  arch/arm/kvm/coproc_a7.c             |   2 +-
>  arch/arm/kvm/mmu.c                   | 164 ++++++++++++++++++++++++++++++-----
>  arch/arm/kvm/trace.h                 |  39 +++++++++
>  arch/arm64/include/asm/kvm_emulate.h |  10 +++
>  arch/arm64/include/asm/kvm_host.h    |   3 -
>  arch/arm64/include/asm/kvm_mmu.h     |  34 ++++++--
>  arch/arm64/kvm/sys_regs.c            |  75 +++-------------
>  13 files changed, 321 insertions(+), 172 deletions(-)
> 
> -- 
> 2.1.4
> 
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Hi Marc,

checkpatch found some whitespace issues (not just the false alarms
that trace.h files generate). Also a loosing vs. losing typo in 2/3's
commit message.

Thanks,
Drew (trivial comments) Jones

      parent reply	other threads:[~2015-01-26 17:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 18:39 [PATCH v3 0/3] arm/arm64: KVM: Random selection of cache related fixes Marc Zyngier
2015-01-21 18:39 ` [PATCH v3 1/3] arm/arm64: KVM: Use set/way op trapping to track the state of the caches Marc Zyngier
2015-01-26 22:58   ` Christoffer Dall
2015-01-27 11:21     ` Marc Zyngier
2015-01-27 13:17       ` Christoffer Dall
2015-01-27 13:44         ` Marc Zyngier
2015-01-29 13:40           ` Christoffer Dall
2015-01-21 18:39 ` [PATCH v3 2/3] arm/arm64: KVM: Invalidate data cache on unmap Marc Zyngier
2015-01-29 14:02   ` Christoffer Dall
2015-01-21 18:39 ` [PATCH v3 3/3] arm/arm64: KVM: Use kernel mapping to perform invalidation on page fault Marc Zyngier
2015-01-29 14:28   ` Christoffer Dall
2015-01-26 17:09 ` Andrew Jones [this message]

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=20150126170945.GC3536@hawk.usersys.redhat.com \
    --to=drjones@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=marc.zyngier@arm.com \
    /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.