From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mario Smarduch Subject: Clarification for patch 7 Date: Tue, 16 Dec 2014 19:40:09 -0800 Message-ID: <5490FB19.5050406@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" To: "christoffer.dall@linaro.org" , Marc Zyngier Return-path: Received: from mailout2.w2.samsung.com ([211.189.100.12]:47574 "EHLO usmailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751225AbaLQDk2 (ORCPT ); Tue, 16 Dec 2014 22:40:28 -0500 Received: from uscpsbgex2.samsung.com (u123.gpu85.samsung.co.kr [203.254.195.123]) by mailout2.w2.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NGP002INJJEA640@mailout2.w2.samsung.com> for kvm@vger.kernel.org; Tue, 16 Dec 2014 22:40:26 -0500 (EST) Sender: kvm-owner@vger.kernel.org List-ID: 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. - Mario