From: Wanpeng Li <wanpeng.li@linux.intel.com>
To: Andres Lagar-Cavilla <andreslc@google.com>
Cc: Gleb Natapov <gleb@kernel.org>, Radim Krcmar <rkrcmar@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Rik van Riel <riel@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Peter Feiner <pfeiner@google.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v4] kvm: Fix page ageing bugs
Date: Wed, 24 Sep 2014 10:27:29 +0800 [thread overview]
Message-ID: <20140924022729.GA2889@kernel> (raw)
In-Reply-To: <1411422882-16245-1-git-send-email-andreslc@google.com>
Hi Andres,
On Mon, Sep 22, 2014 at 02:54:42PM -0700, Andres Lagar-Cavilla wrote:
>1. We were calling clear_flush_young_notify in unmap_one, but we are
>within an mmu notifier invalidate range scope. The spte exists no more
>(due to range_start) and the accessed bit info has already been
>propagated (due to kvm_pfn_set_accessed). Simply call
>clear_flush_young.
>
>2. We clear_flush_young on a primary MMU PMD, but this may be mapped
>as a collection of PTEs by the secondary MMU (e.g. during log-dirty).
>This required expanding the interface of the clear_flush_young mmu
>notifier, so a lot of code has been trivially touched.
>
>3. In the absence of shadow_accessed_mask (e.g. EPT A bit), we emulate
>the access bit by blowing the spte. This requires proper synchronizing
>with MMU notifier consumers, like every other removal of spte's does.
>
[...]
>---
>+ BUG_ON(!shadow_accessed_mask);
>
> for (sptep = rmap_get_first(*rmapp, &iter); sptep;
> sptep = rmap_get_next(&iter)) {
>+ struct kvm_mmu_page *sp;
>+ gfn_t gfn;
> BUG_ON(!is_shadow_present_pte(*sptep));
>+ /* From spte to gfn. */
>+ sp = page_header(__pa(sptep));
>+ gfn = kvm_mmu_page_get_gfn(sp, sptep - sp->spt);
>
> if (*sptep & shadow_accessed_mask) {
> young = 1;
> clear_bit((ffs(shadow_accessed_mask) - 1),
> (unsigned long *)sptep);
> }
>+ trace_kvm_age_page(gfn, slot, young);
IIUC, all the rmapps in this for loop are against the same gfn which
results in the above trace point dump the message duplicated.
Regards,
Wanpeng Li
next prev parent reply other threads:[~2014-09-24 2:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-22 18:34 [PATCH] kvm: Fix page ageing bugs Andres Lagar-Cavilla
2014-09-22 20:00 ` [PATCH v2] " Andres Lagar-Cavilla
2014-09-22 20:26 ` [PATCH v3] " Andres Lagar-Cavilla
2014-09-22 21:48 ` Paolo Bonzini
2014-09-22 21:54 ` Andres Lagar-Cavilla
2014-09-22 21:54 ` [PATCH v4] " Andres Lagar-Cavilla
2014-09-23 7:49 ` Paolo Bonzini
2014-09-23 17:04 ` Andres Lagar-Cavilla
2014-09-23 17:05 ` Paolo Bonzini
2014-09-24 2:27 ` Wanpeng Li [this message]
2014-09-24 7:04 ` Paolo Bonzini
2014-09-24 7:20 ` Wanpeng Li
2014-09-24 8:27 ` Paolo Bonzini
2014-09-24 17:17 ` Andres Lagar-Cavilla
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=20140924022729.GA2889@kernel \
--to=wanpeng.li@linux.intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andreslc@google.com \
--cc=gleb@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pbonzini@redhat.com \
--cc=pfeiner@google.com \
--cc=riel@redhat.com \
--cc=rkrcmar@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox