From xen-devel-bounces@lists.xen.org Wed Feb 19 11:09:26 2014 Received: (at maildrop) by bugs.xenproject.org; 19 Feb 2014 11:09:26 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WG51q-0003pS-K1 for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Wed, 19 Feb 2014 11:09:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WG4wZ-00031i-Lf; Wed, 19 Feb 2014 11:03:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WG4wY-00031c-9b for xen-devel@lists.xen.org; Wed, 19 Feb 2014 11:03:58 +0000 Received: from [193.109.254.147:6644] by server-5.bemta-14.messagelabs.com id ED/64-16688-D9F84035; Wed, 19 Feb 2014 11:03:57 +0000 X-Env-Sender: George.Dunlap@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1392807835!5393855!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32766 invoked from network); 19 Feb 2014 11:03:56 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 19 Feb 2014 11:03:56 -0000 X-IronPort-AV: E=Sophos;i="4.97,505,1389744000"; d="scan'208";a="103847181" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 19 Feb 2014 11:03:55 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Wed, 19 Feb 2014 06:03:54 -0500 Received: from elijah.uk.xensource.com ([10.80.2.24]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1WG4wT-00049H-MP; Wed, 19 Feb 2014 11:03:53 +0000 Message-ID: <53048F96.7010503@eu.citrix.com> Date: Wed, 19 Feb 2014 11:03:50 +0000 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jan Beulich , Yang Z Zhang 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> <53047F74020000780011D8E4@nat28.tlf.novell.com> In-Reply-To: <53047F74020000780011D8E4@nat28.tlf.novell.com> X-DLP: MIA1 Cc: "andrew.cooper3@citrix.com" , Tim Deegan , Xiantao Zhang , Donald D Dugger , "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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On 02/19/2014 08:55 AM, Jan Beulich wrote: >>>> On 19.02.14 at 02:28, "Zhang, Yang Z" wrote: >> George Dunlap wrote on 2014-02-18: >>> On 02/18/2014 03:14 AM, Zhang, Yang Z wrote: >>> 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? > This simplistic variant is just calling for problems. As was already > said elsewhere on this thread, we should simply do the mode change > properly: Track that a partial log-dirty mode is in use, and allow > switching to global log-dirty mode (converting all entries to R/O). I think Yang was asking you for your opinion on my suggestion that nothing actually needed to be done. Enabling full logdirty mode for migration when dirty vram tracking was enabled has *always* returned an error (or at least for a long time now), and *always* resulted in the toolstack disabling and re-enabling logdirty mode; Yang's patch doesn't change that at all. If you think that's an interface we need to improve in the future, we can put it on the list of improvements. But at this point it seems to me more like a nice-to-have. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel