From: Julien Grall <julien@xen.org>
To: Tamas K Lengyel <tamas.lengyel@intel.com>,
xen-devel@lists.xenproject.org
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
"Wei Liu" <wl@xen.org>,
"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
"George Dunlap" <George.Dunlap@eu.citrix.com>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Ian Jackson" <ian.jackson@eu.citrix.com>,
"Tamas K Lengyel" <tamas@tklengyel.com>,
"Jan Beulich" <jbeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking
Date: Thu, 9 Jan 2020 10:28:57 +0000 [thread overview]
Message-ID: <5084334f-7ed6-6095-e31a-d530454357a4@xen.org> (raw)
In-Reply-To: <b816ff21d1156eeb5d68b35932ad23f4e5891bdb.1578503483.git.tamas.lengyel@intel.com>
Hi Tamas,
On 08/01/2020 17:14, Tamas K Lengyel wrote:
> +static int mem_sharing_fork(struct domain *d, struct domain *cd)
> +{
> + int rc;
> +
> + if ( !d->controller_pause_count &&
> + (rc = domain_pause_by_systemcontroller(d)) )
AFAIU, the parent domain will be paused if it wasn't paused before and
this will not be unpaused by the same hypercall. Right?
If so, this brings two questions:
- What would happen if the toolstack decide to unpause the domain?
- How does the caller knows whether this was paused by the
hypercall or not?
I would also suggest to document the behavior of the hypercall as this
is not entirely obvious that the domain will be paused here.
> + return rc;
> +
> + cd->max_pages = d->max_pages;
> + cd->max_vcpus = d->max_vcpus;
> +
> + /* this is preemptible so it's the first to get done */
> + if ( (rc = fork_hap_allocation(d, cd)) )
> + return rc;
> +
> + if ( (rc = bring_up_vcpus(cd, d->cpupool)) )
> + return rc;
> +
> + if ( (rc = hvm_copy_context_and_params(d, cd)) )
> + return rc;
> +
> + fork_tsc(d, cd);
> +
> + cd->parent = d;
How do you ensure that the parent domain will not get destroyed before
the forked domain? Do you have a refcount somewhere?
> +
> + return 0;
> +}
> +
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-01-09 10:29 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-08 17:13 [Xen-devel] [PATCH v4 00/18] VM forking Tamas K Lengyel
2020-01-08 17:13 ` [Xen-devel] [PATCH v4 01/18] x86/hvm: introduce hvm_copy_context_and_params Tamas K Lengyel
2020-01-16 12:27 ` Jan Beulich
2020-01-16 14:06 ` Tamas K Lengyel
2020-01-08 17:13 ` [Xen-devel] [PATCH v4 02/18] xen/x86: Make hap_get_allocation accessible Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 03/18] x86/mem_sharing: make get_two_gfns take locks conditionally Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 04/18] x86/mem_sharing: drop flags from mem_sharing_unshare_page Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 05/18] x86/mem_sharing: don't try to unshare twice during page fault Tamas K Lengyel
2020-01-16 14:53 ` Jan Beulich
2020-01-16 15:59 ` Tamas K Lengyel
2020-01-16 16:03 ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 06/18] x86/mem_sharing: define mem_sharing_domain to hold some scattered variables Tamas K Lengyel
2020-01-16 15:23 ` Jan Beulich
2020-01-16 16:05 ` Tamas K Lengyel
2020-01-16 16:08 ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 07/18] x86/mem_sharing: Use INVALID_MFN and p2m_is_shared in relinquish_shared_pages Tamas K Lengyel
2020-01-16 15:40 ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 08/18] x86/mem_sharing: Make add_to_physmap static and shorten name Tamas K Lengyel
2020-01-16 15:40 ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 09/18] x86/mem_sharing: Convert MEM_SHARING_DESTROY_GFN to a bool Tamas K Lengyel
2020-01-16 15:42 ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 10/18] x86/mem_sharing: Replace MEM_SHARING_DEBUG with gdprintk Tamas K Lengyel
2020-01-16 16:01 ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 11/18] x86/mem_sharing: ASSERT that p2m_set_entry succeeds Tamas K Lengyel
2020-01-16 16:07 ` Jan Beulich
2020-01-16 16:12 ` Tamas K Lengyel
2020-01-17 9:23 ` Jan Beulich
2020-01-17 16:59 ` Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 12/18] x86/mem_sharing: Enable mem_sharing on first memop Tamas K Lengyel
2020-01-16 16:18 ` Jan Beulich
2020-01-16 16:34 ` Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 13/18] x86/mem_sharing: Skip xen heap pages in memshr nominate Tamas K Lengyel
2020-01-20 16:23 ` Jan Beulich
2020-01-20 16:32 ` Tamas K Lengyel
2020-01-20 16:38 ` Jan Beulich
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 14/18] x86/mem_sharing: check page type count earlier Tamas K Lengyel
2020-01-20 16:34 ` Jan Beulich
2020-01-20 16:46 ` Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 15/18] xen/mem_sharing: VM forking Tamas K Lengyel
2020-01-09 10:28 ` Julien Grall [this message]
2020-01-09 13:41 ` Tamas K Lengyel
2020-01-09 15:10 ` Roger Pau Monné
2020-01-09 15:34 ` Jan Beulich
2020-01-09 15:57 ` Tamas K Lengyel
2020-01-09 16:03 ` Jan Beulich
2020-01-09 16:06 ` Tamas K Lengyel
2020-01-09 15:54 ` Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 16/18] xen/mem_access: Use __get_gfn_type_access in set_mem_access Tamas K Lengyel
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 17/18] x86/mem_sharing: reset a fork Tamas K Lengyel
2020-01-09 10:30 ` Julien Grall
2020-01-08 17:14 ` [Xen-devel] [PATCH v4 18/18] xen/tools: VM forking toolstack side Tamas K Lengyel
2020-01-16 15:47 ` [Xen-devel] [PATCH v4 00/18] VM forking Jan Beulich
2020-01-16 16:24 ` Tamas K Lengyel
2020-01-17 9:12 ` Jan Beulich
2020-01-17 11:15 ` Anthony PERARD
2020-01-17 14:22 ` Tamas K Lengyel
2020-01-17 14:25 ` 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=5084334f-7ed6-6095-e31a-d530454357a4@xen.org \
--to=julien@xen.org \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=roger.pau@citrix.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.