From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [RESEND PATCH v15 07/11] KVM: arm: page logging 2nd stage fault handling Date: Thu, 8 Jan 2015 11:45:10 +0100 Message-ID: <20150108104510.GI21092@cbox> References: <1418628488-3696-1-git-send-email-m.smarduch@samsung.com> <1418868449-23397-1-git-send-email-m.smarduch@samsung.com> <20150107123844.GA21092@cbox> <54ADE0B6.1060703@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: marc.zyngier@arm.com, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, pbonzini@redhat.com, catalin.marinas@arm.com To: Mario Smarduch Return-path: Received: from mail-lb0-f173.google.com ([209.85.217.173]:45075 "EHLO mail-lb0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755851AbbAHKot (ORCPT ); Thu, 8 Jan 2015 05:44:49 -0500 Received: by mail-lb0-f173.google.com with SMTP id z12so2150954lbi.4 for ; Thu, 08 Jan 2015 02:44:47 -0800 (PST) Content-Disposition: inline In-Reply-To: <54ADE0B6.1060703@samsung.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jan 07, 2015 at 05:43:18PM -0800, Mario Smarduch wrote: > Hi Christoffer, > before going through your comments, I discovered that > in 3.18.0-rc2 - a generic __get_user_pages_fast() > was implemented, now ARM picks this up. This causes > gfn_to_pfn_prot() to return meaningful 'writable' > value for a read fault, provided the region is writable. > > Prior to that the weak version returned 0 and 'writable' > had no optimization effect to set pte/pmd - RW on > a read fault. > > As a consequence dirty logging broke in 3.18, I was seeing > weird but very intermittent issues. I just put in the > additional few lines to fix it, prevent pte RW (only R) on > read faults while logging writable region. > > On 01/07/2015 04:38 AM, Christoffer Dall wrote: > > On Wed, Dec 17, 2014 at 06:07:29PM -0800, Mario Smarduch wrote: > >> This patch is a followup to v15 patch series, with following changes: > >> - When clearing/dissolving a huge, PMD mark huge page range dirty, since > >> the state of whole range is unknown. After the huge page is dissolved > >> dirty page logging is at page granularity. > > > > What is the sequence of events where you could have dirtied another page > > within the PMD range after the user initially requested dirty page > > logging? > > No there is none. My issue was the start point for tracking dirty pages > and that would be second call to dirty log read. Not first > call after initial write protect where any page in range can > be assumed dirty. I'll remove this, not sure if there would be any > use case to call dirty log only once. > Calling dirty log once can not give you anything meaningful, right? You must assume all memory is 'dirty' at this point, no? -Christoffer