From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: Clarification for patch 7 Date: Wed, 7 Jan 2015 13:39:54 +0100 Message-ID: <20150107123954.GB21092@cbox> References: <5490FB19.5050406@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marc Zyngier , Paolo Bonzini , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" To: Mario Smarduch Return-path: Received: from mail-lb0-f172.google.com ([209.85.217.172]:58695 "EHLO mail-lb0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751275AbbAGMjl (ORCPT ); Wed, 7 Jan 2015 07:39:41 -0500 Received: by mail-lb0-f172.google.com with SMTP id z12so973572lbi.31 for ; Wed, 07 Jan 2015 04:39:33 -0800 (PST) Content-Disposition: inline In-Reply-To: <5490FB19.5050406@samsung.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Dec 16, 2014 at 07:40:09PM -0800, Mario Smarduch wrote: > Hi Christoffer, Marc - > in stage2_dissolve_pmd() CONFIG_SMP is > unnecessary. At the time huge page is write protected, > until it faults and is cleared any page in the range > may be dirty not just the gpa access that caused the > fault. > > The comment on another CPU is wrong, I > confused myself while testing it should not be possible for > another CPU to write to same PMD range while > another is handling its PMD fault. I ran a test with > only initrd which exposed an issue using my > test scenario, QEMU appears fine. > > It also depends on user space if you first turn > on logging, do pre-copy then marking just the page > is enough. It's hard to interpret the API in this > case. It just says dirty pages since the last > call. > > That patch could be resent without upsetting > the rest. > I think I raised all these issues on your patch, let's discuss it there. -Christoffer