xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@eu.citrix.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>,
	Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
Cc: "andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"Dugger, Donald D" <donald.d.dugger@intel.com>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] Don't track all memory when enabling log dirty to track vram
Date: Tue, 18 Feb 2014 10:26:12 +0000	[thread overview]
Message-ID: <53033544.2000409@eu.citrix.com> (raw)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0A9ED8B0@SHSMSX104.ccr.corp.intel.com>

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 <george.dunlap@eu.citrix.com>
>> 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.

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.

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
>
>

  reply	other threads:[~2014-02-18 10:26 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-10  6:14 [PATCH] Don't track all memory when enabling log dirty to track vram Yang Zhang
2014-02-10  8:03 ` Tim Deegan
2014-02-10  8:15   ` Zhang, Yang Z
2014-02-11  9:02     ` Tim Deegan
2014-02-11 10:59       ` George Dunlap
2014-02-11 11:55         ` Tim Deegan
2014-02-11 12:57           ` Jan Beulich
2014-02-11 15:55             ` George Dunlap
2014-02-12  0:53               ` Zhang, Yang Z
2014-02-13 15:46                 ` George Dunlap
2014-02-13 15:55                   ` Jan Beulich
2014-02-13 16:20                     ` Tim Deegan
2014-02-13 16:25                       ` George Dunlap
2014-02-13 16:45                         ` Processed: " xen
2014-02-17 10:18                       ` Jan Beulich
2014-02-17 12:23                         ` George Dunlap
2014-02-17 12:37                           ` Jan Beulich
2014-02-17 14:51                         ` George Dunlap
2014-02-17 15:05                           ` Jan Beulich
2014-02-18  3:14                             ` Zhang, Yang Z
2014-02-18 10:26                               ` George Dunlap [this message]
2014-02-19  1:28                                 ` Zhang, Yang Z
2014-02-19  8:55                                   ` Jan Beulich
2014-02-19 11:03                                     ` George Dunlap
2014-02-19 11:13                                       ` Jan Beulich
2014-02-19 11:17                                         ` George Dunlap
2014-02-17 15:00                         ` Jan Beulich
2014-02-18  3:25                           ` Zhang, Yang Z
2014-02-18  8:45                             ` Jan Beulich
2014-02-18 11:46                             ` Jan Beulich
2014-02-18 15:28                               ` Jan Beulich
2014-02-19  6:40                                 ` Xu, Dongxiao
2014-02-19  1:17                               ` Zhang, Yang Z
2014-02-19  8:50                                 ` Jan Beulich
2014-02-18  8:30                           ` Jan Beulich
2014-05-19  7:48                       ` Zhang, Yang Z
2014-05-19  9:03                         ` Jan Beulich
2014-05-20  3:09                           ` Zhang, Yang Z
2014-05-20  7:17                             ` Jan Beulich
2014-05-19 13:27                         ` George Dunlap
2014-05-19 13:50                           ` Jan Beulich
2014-05-19 13:59                             ` George Dunlap
2014-05-19 14:19                               ` Jan Beulich
2014-05-20  3:13                           ` Zhang, Yang Z
2014-05-20  7:20                             ` Jan Beulich
2014-05-20 10:12                               ` George Dunlap
2014-05-20 10:46                                 ` Jan Beulich
2014-05-21  1:02                                   ` Zhang, Yang Z
2014-05-21  7:49                                     ` Jan Beulich
2014-05-21  8:37                                       ` Zhang, Yang Z
2014-05-21  9:58                                         ` Jan Beulich
2014-05-23  6:42                                         ` Jan Beulich
2014-05-26  8:16                                           ` Zhang, Yang Z
2014-05-26  9:04                                             ` Jan Beulich
2014-05-31  1:26                                               ` Nakajima, Jun
2014-06-02  6:55                                                 ` Jan Beulich
2014-06-02 14:06                                                   ` George Dunlap
2014-06-02 14:27                                                     ` Jan Beulich
2014-06-02 15:03                                                       ` George Dunlap
2014-02-10 10:42   ` Andrew Cooper
2014-02-10 16:13 ` George Dunlap
2014-02-10 16:30   ` Processed: " xen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53033544.2000409@eu.citrix.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=donald.d.dugger@intel.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    --cc=xiantao.zhang@intel.com \
    --cc=yang.z.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).