All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.