From xen-devel-bounces@lists.xen.org Wed Feb 19 11:18:23 2014 Received: (at maildrop) by bugs.xenproject.org; 19 Feb 2014 11:18:23 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1WG5AV-0003vW-Lb for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Wed, 19 Feb 2014 11:18:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WG55V-0003NP-AM; Wed, 19 Feb 2014 11:13:13 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WG55U-0003NK-DR for xen-devel@lists.xen.org; Wed, 19 Feb 2014 11:13:12 +0000 Received: from [193.109.254.147:17850] by server-5.bemta-14.messagelabs.com id 26/F3-16688-7C194035; Wed, 19 Feb 2014 11:13:11 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1392808390!5346081!1 X-Originating-IP: [130.57.49.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTMwLjU3LjQ5LjI4ID0+IDQ4MDU=\n X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2083 invoked from network); 19 Feb 2014 11:13:11 -0000 Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Feb 2014 11:13:11 -0000 Received: from EMEA1-MTA by nat28.tlf.novell.com with Novell_GroupWise; Wed, 19 Feb 2014 11:13:10 +0000 Message-Id: <53049FD3020000780011DA37@nat28.tlf.novell.com> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Wed, 19 Feb 2014 11:13:07 +0000 From: "Jan Beulich" To: "George Dunlap" , "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> <53048F96.7010503@eu.citrix.com> In-Reply-To: <53048F96.7010503@eu.citrix.com> Mime-Version: 1.0 Content-Disposition: inline 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-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 >>> On 19.02.14 at 12:03, George Dunlap wrote: > 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. I agree - for 4.4.0 we shouldn't need any further adjustments. And I hoped to imply that I don't see a need for this incremental change to go in by having said "This simplistic variant is just calling for problems". Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel