xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Tim Deegan <tim@xen.org>
To: Xudong Hao <xudong.hao@intel.com>
Cc: keir@xen.org, haitao.shan@intel.com, JBeulich@suse.com,
	xiantao.zhang@intel.com, xen-devel@lists.xen.org
Subject: Re: [PATCH v2 3/4] xen: introduce new function update_dirty_bitmap
Date: Thu, 28 Jun 2012 14:42:04 +0100	[thread overview]
Message-ID: <20120628134204.GP34995@ocelot.phlegethon.org> (raw)
In-Reply-To: <1340157467-19553-4-git-send-email-xudong.hao@intel.com>

At 09:57 +0800 on 20 Jun (1340186266), Xudong Hao wrote:
> @@ -83,19 +84,31 @@ static int hap_enable_vram_tracking(struct domain *d)
>  static int hap_disable_vram_tracking(struct domain *d)
>  {
>      struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram;
> +    p2m_type_t p2mt = p2m_ram_rw;
>  
>      if ( !dirty_vram )
>          return -EINVAL;
>  
> +    /* With hap dirty bit, p2m type cannot be changed from p2m_ram_logdirty
> +     * to p2m_ram_rw when first fault is met. Actually, there is no such
> +     * fault occurred.
> +     */
> +    if ( hap_has_dirty_bit )
> +        p2mt = p2m_ram_logdirty;
> +
>      paging_lock(d);
>      d->arch.paging.mode &= ~PG_log_dirty;
>      paging_unlock(d);
>  
>      /* set l1e entries of P2M table with normal mode */
>      p2m_change_type_range(d, dirty_vram->begin_pfn, dirty_vram->end_pfn, 
> -                          p2m_ram_logdirty, p2m_ram_rw);
> +                          p2mt, p2m_ram_rw);

What's the intent of this change?  

AFAICS it will break the hap_has_dirty_bit==0 case, by basically making
that p2m_change_type_range() into a noop.

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -148,6 +148,15 @@ void p2m_change_entry_type_global(struct domain *d,
>      p2m_unlock(p2m);
>  }
>  
> +void p2m_query_entry_global(struct domain *d, int mask)
> +{
> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    ASSERT(p2m);
> +    p2m_lock(p2m);
> +    p2m->query_entry_global(p2m, mask);
> +    p2m_unlock(p2m);
> +}
> +

Given that when you implement this, it's basically just the same as
p2m_change_type_global() with p2m_ram_logdirty for both types:

 - Why not just use p2m_change_type_global() instead of adding the new
   function pointer?
 - If you do need a new function pointer, this name is very confusing:
   it's not doing any kind of query.

> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -335,9 +335,24 @@ int paging_log_dirty_op(struct domain *d, struct xen_domctl_shadow_op *sc)
>      int i4, i3, i2;
>  
>      domain_pause(d);
> -    paging_lock(d);
>  
>      clean = (sc->op == XEN_DOMCTL_SHADOW_OP_CLEAN);
> +    if ( clean )
> +    {
> +        /* We need to further call clean_dirty_bitmap() functions of specific
> +         * paging modes (shadow or hap).  Safe because the domain is paused.
> +         * And this call must be made before actually transferring the dirty
> +         * bitmap since with HW hap dirty bit support, dirty bitmap is
> +         * produced by hooking on this call. */
> +        d->arch.paging.log_dirty.clean_dirty_bitmap(d);
> +    }

> +    if ( peek && d->arch.paging.log_dirty.update_dirty_bitmap)
> +    {
> +        d->arch.paging.log_dirty.update_dirty_bitmap(d);
> +    }

Doesn't this end up doing _two_ passes over the p2m table?

I think it would be better to leave the clean() op at the end of the
function, and arrange for it to be a noop in the EPT/D-bit case.  Then
with the addition of this update_dirty_bitmap() call, the p2m only gets
walked once, for all configurations.

Cheers,

Tim.

  reply	other threads:[~2012-06-28 13:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-20  1:57 [PATCH v2 0/4] xen: enable EPT A/D bit feature Xudong Hao
2012-06-20  1:57 ` [PATCH v2 1/4] xen: Add EPT A/D bits definitions Xudong Hao
2012-06-20  1:57 ` [PATCH v2 2/4] xen: add xen parameter to control A/D bits support Xudong Hao
2012-06-20  1:57 ` [PATCH v2 3/4] xen: introduce new function update_dirty_bitmap Xudong Hao
2012-06-28 13:42   ` Tim Deegan [this message]
2012-06-29  8:46     ` Hao, Xudong
2012-06-20  1:57 ` [PATCH v2 4/4] xen: enable EPT dirty bit for guest live migration Xudong Hao
2012-06-28 13:52   ` Tim Deegan
2012-06-29  7:50     ` Hao, Xudong
2012-06-25  6:27 ` [PATCH v2 0/4] xen: enable EPT A/D bit feature Hao, Xudong
2012-06-25  7:22   ` Keir Fraser
2012-06-25  9:02 ` Tim Deegan
2012-06-26  5:31   ` Hao, Xudong
2012-06-28 10:30     ` Tim Deegan
2012-06-29  9:27       ` Hao, Xudong
2012-06-28 12:14     ` George Dunlap
2012-06-29  9:31       ` Hao, Xudong

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=20120628134204.GP34995@ocelot.phlegethon.org \
    --to=tim@xen.org \
    --cc=JBeulich@suse.com \
    --cc=haitao.shan@intel.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xen.org \
    --cc=xiantao.zhang@intel.com \
    --cc=xudong.hao@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).