From xen-devel-bounces@lists.xen.org Wed Feb 19 01:34:35 2014 Received: (at maildrop) by bugs.xenproject.org; 19 Feb 2014 01:34:35 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WFw3X-0006LH-4g for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Wed, 19 Feb 2014 01:34:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFvyF-0002sy-H7; Wed, 19 Feb 2014 01:29:07 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WFvyC-0002st-5v for xen-devel@lists.xen.org; Wed, 19 Feb 2014 01:29:06 +0000 Received: from [85.158.143.35:49985] by server-2.bemta-4.messagelabs.com id 64/02-10891-FD804035; Wed, 19 Feb 2014 01:29:03 +0000 X-Env-Sender: yang.z.zhang@intel.com X-Msg-Ref: server-2.tower-21.messagelabs.com!1392773342!6644694!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 22819 invoked from network); 19 Feb 2014 01:29:02 -0000 Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by server-2.tower-21.messagelabs.com with SMTP; 19 Feb 2014 01:29:02 -0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 18 Feb 2014 17:29:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,503,1389772800"; d="scan'208";a="483770159" Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by fmsmga002.fm.intel.com with ESMTP; 18 Feb 2014 17:29:01 -0800 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Feb 2014 17:29:00 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Feb 2014 17:29:00 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.227]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.26]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 09:28:59 +0800 From: "Zhang, Yang Z" To: George Dunlap , Jan Beulich , Tim Deegan Thread-Topic: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram Thread-Index: AQHPJjaWGU8BoIe0JUmrwANmd1LxUZquITGwgAIV/CWAAJImEIAIfYa+///GNICAAAOsgIABNL/wgAAPrwCAAX+DcA== Date: Wed, 19 Feb 2014 01:28:59 +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> <53033544.2000409@eu.citrix.com> In-Reply-To: <53033544.2000409@eu.citrix.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 George Dunlap wrote on 2014-02-18: > On 02/18/2014 03:14 AM, Zhang, Yang Z wrote: >> 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: > > It turns out that the reason I couldn't get a crash was because libxc > was actually paying attention to the -EINVAL return value, and > disabling and then re-enabling logdirty. That's what would happen > before your dirty vram patch, and that's what happens after. And > arguably, that's the correct behavior for any toolstack, given that the interface returns an error. Agree. > > This patch would actually change the interface; if we check this in, > then if you enable logdirty when dirty vram tracking is enabled, you > *won't* get an error, and thus *won't* disable and re-enable logdirty mode. > So actually, this patch would be more disruptive. > Jan, do you have any comment? > Thanks for the patch, though. :-) > > -George >> >> 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 >> >> Best regards, Yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel