From xen-devel-bounces@lists.xen.org Tue Feb 18 03:20:58 2014 Received: (at maildrop) by bugs.xenproject.org; 18 Feb 2014 03:20:58 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WFbEw-0000wu-P9 for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 18 Feb 2014 03:20:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFb96-0002MN-Vl; Tue, 18 Feb 2014 03:14:56 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFb95-0002MI-DJ for xen-devel@lists.xen.org; Tue, 18 Feb 2014 03:14:55 +0000 Received: from [85.158.143.35:41124] by server-3.bemta-4.messagelabs.com id 12/B2-11539-E20D2035; Tue, 18 Feb 2014 03:14:54 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1392693293!6386710!1 X-Originating-IP: [192.55.52.93] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMyNDY2NQ==\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6475 invoked from network); 18 Feb 2014 03:14:53 -0000 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by server-4.tower-21.messagelabs.com with SMTP; 18 Feb 2014 03:14:53 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2014 19:14:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,499,1389772800"; d="scan'208";a="483185974" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by fmsmga002.fm.intel.com with ESMTP; 17 Feb 2014 19:14:50 -0800 Received: from fmsmsx101.amr.corp.intel.com (10.19.9.52) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 17 Feb 2014 19:14:49 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX101.amr.corp.intel.com (10.19.9.52) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 17 Feb 2014 19:14:49 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.227]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.202]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 11:14:48 +0800 From: "Zhang, Yang Z" To: Jan Beulich , George Dunlap , Tim Deegan Thread-Topic: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram Thread-Index: AQHPJjaWGU8BoIe0JUmrwANmd1LxUZquITGwgAIV/CWAAJImEIAIfYa+///GNICAAAOsgIABNL/w Date: Tue, 18 Feb 2014 03:14:47 +0000 Message-ID: References: <20140210080314.GA758@deinos.phlegethon.org> <20140211090202.GC92054@deinos.phlegethon.org> <20140211115553.GB97288@deinos.phlegethon.org> <52FA2C63020000780011B201@nat28.tlf.novell.com> <52FA480D.9040707@eu.citrix.com> <52FCE8BE.8050105@eu.citrix.com> <52FCF90F020000780011C29A@nat28.tlf.novell.com> <20140213162022.GE82703@deinos.phlegethon.org> <5301F000020000780011CCE0@nat28.tlf.novell.com> <53022209.1060005@eu.citrix.com> <5302332D020000780011CEF1@nat28.tlf.novell.com> In-Reply-To: <5302332D020000780011CEF1@nat28.tlf.novell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "andrew.cooper3@citrix.com" , "Dugger, Donald D" , "Zhang, Xiantao" , "xen-devel@lists.xen.org" Subject: Re: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org Jan Beulich wrote on 2014-02-17: >>>> On 17.02.14 at 15:51, George Dunlap > wrote: >> On 02/17/2014 10:18 AM, Jan Beulich wrote: >>> Actually I'm afraid there are two problems with this patch: >>> >>> For one, is enabling "global" log dirty mode still going to work >>> after VRAM-only mode already got enabled? I ask because the >>> paging_mode_log_dirty() check which paging_log_dirty_enable() does >>> first thing suggests otherwise to me (i.e. the now conditional >>> setting of all p2m entries to p2m_ram_logdirty would seem to never >>> get executed). IOW I would think that we're now lacking a control >>> operation allowing the transition from dirty VRAM tracking mode to >>> full log dirty mode. >> >> Hrm, will so far playing with this I've been unable to get a >> localhost migrate to fail with the vncviewer attached. Which seems a bit strange... > > Not necessarily - it may depend on how the tools actually do this: > They might temporarily disable log dirty mode altogether, just to > re-enable full mode again right away. But this specific usage of the > hypervisor interface wouldn't (to me) mean that other tool stacks > might not be doing this differently. You are right. Before migration, libxc will disable log dirty mode if it already enabled before and re-enable it. So when I am developing this patch, I think it is ok for migration. If there really have other tool stacks also will use this interface (Is it true?), perhaps my original patch is better which will check paging_mode_log_dirty(d) && log_global: diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c index ab5eacb..368c975 100644 --- a/xen/arch/x86/mm/paging.c +++ b/xen/arch/x86/mm/paging.c @@ -168,7 +168,7 @@ int paging_log_dirty_enable(struct domain *d, bool_t log_global) { int ret; - if ( paging_mode_log_dirty(d) ) + if ( paging_mode_log_dirty(d) && !log_global ) return -EINVAL; domain_pause(d); > > Jan Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel