From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Tamas K Lengyel <tamas.lengyel@intel.com>
Cc: Tamas K Lengyel <tamas@tklengyel.com>,
Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Jan Beulich <jbeulich@suse.com>,
xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH v9 4/5] x86/mem_sharing: reset a fork
Date: Mon, 24 Feb 2020 16:12:50 +0100 [thread overview]
Message-ID: <20200224151250.GR4679@Air-de-Roger> (raw)
In-Reply-To: <818edf7f9407e377bba6564d58b9c65bce5e6493.1582310142.git.tamas.lengyel@intel.com>
On Fri, Feb 21, 2020 at 10:49:22AM -0800, Tamas K Lengyel wrote:
> Implement hypercall that allows a fork to shed all memory that got allocated
> for it during its execution and re-load its vCPU context from the parent VM.
> This allows the forked VM to reset into the same state the parent VM is in a
> faster way then creating a new fork would be. Measurements show about a 2x
> speedup during normal fuzzing operations. Performance may vary depending how
^ on
> much memory got allocated for the forked VM. If it has been completely
> deduplicated from the parent VM then creating a new fork would likely be more
> performant.
>
> Signed-off-by: Tamas K Lengyel <tamas.lengyel@intel.com>
> ---
> xen/arch/x86/mm/mem_sharing.c | 76 +++++++++++++++++++++++++++++++++++
> xen/include/public/memory.h | 1 +
> 2 files changed, 77 insertions(+)
>
> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
> index ad5db9d8d5..fb6892aaa6 100644
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -1636,6 +1636,59 @@ static int mem_sharing_fork(struct domain *d, struct domain *cd)
> return rc;
> }
>
> +/*
> + * The fork reset operation is intended to be used on short-lived forks only.
> + * There is no hypercall continuation operation implemented for this reason.
> + * For forks that obtain a larger memory footprint it is likely going to be
> + * more performant to create a new fork instead of resetting an existing one.
> + *
> + * TODO: In case this hypercall would become useful on forks with larger memory
> + * footprints the hypercall continuation should be implemented.
I'm afraid this is not safe, as users don't have an easy way to know
whether a fork will have a large memory footprint or not.
IMO you either need some kind of check that prevents this function
from being executed when the domain as too much memory assigned, or
you need to implement continuations.
Or else this is very likely to trip over the watchdog.
> + */
> +static int mem_sharing_fork_reset(struct domain *d, struct domain *cd)
No need for the mem_sharing prefix, as it's a static function.
> +{
> + int rc;
> + struct p2m_domain* p2m = p2m_get_hostp2m(cd);
> + struct page_info *page, *tmp;
> +
> + domain_pause(cd);
> +
> + page_list_for_each_safe(page, tmp, &cd->page_list)
You can use something like:
while ( (page = page_list_remove_head(&cd->page_list) != NULL )
{
...
}
And avoid the *tmp local variable.
> + {
> + p2m_type_t p2mt;
> + p2m_access_t p2ma;
> + gfn_t gfn;
> + mfn_t mfn = page_to_mfn(page);
> +
> + if ( !mfn_valid(mfn) )
> + continue;
> +
> + gfn = mfn_to_gfn(cd, mfn);
> + mfn = __get_gfn_type_access(p2m, gfn_x(gfn), &p2mt, &p2ma,
> + 0, NULL, false);
> +
> + if ( !p2m_is_ram(p2mt) || p2m_is_shared(p2mt) )
> + continue;
> +
> + /* take an extra reference */
> + if ( !get_page(page, cd) )
> + continue;
> +
> + rc = p2m->set_entry(p2m, gfn, INVALID_MFN, PAGE_ORDER_4K,
> + p2m_invalid, p2m_access_rwx, -1);
> + ASSERT(!rc);
Can you handle this gracefully?
> +
> + put_page_alloc_ref(page);
> + put_page(page);
> + }
> +
> + if ( !(rc = hvm_copy_context_and_params(cd, d)) )
> + fork_tsc(cd, d);
> +
> + domain_unpause(cd);
> + return rc;
> +}
> +
> int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
> {
> int rc;
> @@ -1920,6 +1973,29 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
> break;
> }
>
> + case XENMEM_sharing_op_fork_reset:
> + {
> + struct domain *pd;
> +
> + rc = -EINVAL;
> + if ( mso.u.fork._pad[0] || mso.u.fork._pad[1] ||
> + mso.u.fork._pad[2] )
> + goto out;
> +
> + rc = -ENOSYS;
> + if ( !d->parent )
Why not use mem_sharing_is_fork?
Also I think EINVAL would be more suitable here, as the passed domid
doesn't belong to a fork?
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-02-24 15:13 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-21 18:49 [Xen-devel] [PATCH v9 0/5] VM forking Tamas K Lengyel
2020-02-21 18:49 ` [Xen-devel] [PATCH v9 1/5] xen/x86: Make hap_get_allocation accessible Tamas K Lengyel
2020-02-24 15:20 ` Roger Pau Monné
2020-02-25 13:16 ` Jan Beulich
2020-02-25 13:21 ` Tamas K Lengyel
2020-02-21 18:49 ` [Xen-devel] [PATCH v9 2/5] xen: add parent_domid field to createdomain domctl Tamas K Lengyel
2020-02-21 21:02 ` Julien Grall
2020-02-21 21:35 ` Tamas K Lengyel
2020-02-21 22:34 ` Julien Grall
2020-02-21 22:53 ` Tamas K Lengyel
2020-02-21 23:18 ` Julien Grall
2020-02-21 23:31 ` Tamas K Lengyel
2020-02-24 15:44 ` Andrew Cooper
2020-02-24 15:55 ` Tamas K Lengyel
2020-02-21 18:49 ` [Xen-devel] [PATCH v9 3/5] xen/mem_sharing: VM forking Tamas K Lengyel
2020-02-24 12:39 ` Roger Pau Monné
2020-02-24 15:45 ` Tamas K Lengyel
2020-02-24 15:59 ` Roger Pau Monné
2020-02-24 22:14 ` Tamas K Lengyel
2020-02-25 9:40 ` Roger Pau Monné
2020-02-24 22:26 ` Tamas K Lengyel
2020-02-25 9:40 ` Roger Pau Monné
2020-02-25 13:30 ` Jan Beulich
2020-02-25 13:28 ` Jan Beulich
2020-02-25 13:39 ` Tamas K Lengyel
2020-02-25 10:04 ` Roger Pau Monné
2020-02-25 11:43 ` Tamas K Lengyel
2020-02-25 12:06 ` Roger Pau Monné
2020-02-25 12:23 ` Tamas K Lengyel
2020-02-25 14:23 ` Tamas K Lengyel
2020-02-21 18:49 ` [Xen-devel] [PATCH v9 4/5] x86/mem_sharing: reset a fork Tamas K Lengyel
2020-02-24 15:12 ` Roger Pau Monné [this message]
2020-02-24 15:35 ` Tamas K Lengyel
2020-02-24 15:42 ` Roger Pau Monné
2020-02-24 15:49 ` Tamas K Lengyel
2020-02-24 16:02 ` Roger Pau Monné
2020-02-25 13:39 ` Jan Beulich
2020-02-25 13:45 ` Tamas K Lengyel
2020-02-25 14:13 ` Jan Beulich
2020-02-25 14:26 ` Tamas K Lengyel
2020-02-21 18:49 ` [Xen-devel] [PATCH v9 5/5] xen/tools: VM forking toolstack side Tamas K Lengyel
2020-02-24 16:12 ` Julien Grall
2020-02-24 16:19 ` Tamas K Lengyel
2020-02-24 16:30 ` Julien Grall
2020-02-24 16:45 ` Tamas K Lengyel
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=20200224151250.GR4679@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=konrad.wilk@oracle.com \
--cc=sstabellini@kernel.org \
--cc=tamas.lengyel@intel.com \
--cc=tamas@tklengyel.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.