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.
next prev parent 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).