All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Juergen Gross <jgross@suse.com>, Wei Liu <wei.liu2@citrix.com>
Cc: stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com,
	Ian.Campbell@citrix.com, xen-devel@lists.xen.org
Subject: Re: [PATCH] libxc: try to find last used pfn when migrating
Date: Fri, 27 Nov 2015 17:16:17 +0000	[thread overview]
Message-ID: <56588FE1.1060606@citrix.com> (raw)
In-Reply-To: <56587C71.3080007@suse.com>

On 27/11/15 15:53, Juergen Gross wrote:
> On 27/11/15 16:33, Wei Liu wrote:
>> On Fri, Nov 27, 2015 at 03:50:53PM +0100, Juergen Gross wrote:
>>> For migration the last used pfn of a guest is needed to size the
>>> logdirty bitmap and as an upper bound of the page loop. Unfortunately
>>> there are pv-kernels advertising a much higher maximum pfn as they
>>> are really using in order to support memory hotplug. This will lead
>>> to allocation of much more memory in Xen tools during migration as
>>> really needed.
>>>
>>> Try to find the last used guest pfn of a pv-domu by scanning the p2m
>>> tree from the last entry towards it's start and search for an entry
>>> not being invalid.
>>>
>>> Normally the mid pages of the p2m tree containing all invalid entries
>>> are being reused, so we can just scan the top page for identical
>>> entries and skip them but the first one.
>>>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>> ---
>>>  tools/libxc/xc_sr_save.c        |  8 ++++----
>>>  tools/libxc/xc_sr_save_x86_pv.c | 34 +++++++++++++++++++++++++++++++---
>>>  2 files changed, 35 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
>>> index 0c12e56..22b3f18 100644
>>> --- a/tools/libxc/xc_sr_save.c
>>> +++ b/tools/libxc/xc_sr_save.c
>>> @@ -677,6 +677,10 @@ static int setup(struct xc_sr_context *ctx)
>>>      DECLARE_HYPERCALL_BUFFER_SHADOW(unsigned long, dirty_bitmap,
>>>                                      &ctx->save.dirty_bitmap_hbuf);
>>>  
>>> +    rc = ctx->save.ops.setup(ctx);
>>> +    if ( rc )
>>> +        goto err;
>>> +
>>>      dirty_bitmap = xc_hypercall_buffer_alloc_pages(
>>>                     xch, dirty_bitmap, NRPAGES(bitmap_size(ctx->save.p2m_size)));
>>>      ctx->save.batch_pfns = malloc(MAX_BATCH_SIZE *
>>> @@ -692,10 +696,6 @@ static int setup(struct xc_sr_context *ctx)
>>>          goto err;
>>>      }
>>>  
>> p2m_size is set in two places for PV guest.  Since we are now relying on
>> ops.setup to set p2m_size, the invocation to xc_domain_nr_gpfns in
>> xc_domain_save should be removed, so that we only have one place to set
>> p2m_size.
> I wasn't sure this is needed in save case only. If it is I can make
> the change, of course. Andrew?
>
>> You then also need to call xc_domain_nr_gpfns in HVM's ops.setup
>> (x86_hvm_setup).
> Sure.

That is most likely a byproduct of this codes somewhat-organic growth
over 18 months.

The check in xc_domain_save() is a check left over from legacy
migration.  It was present in legacy migration as legacy merged the page
type into the upper 4 bits of the unsigned long pfn, meaning that a pfn
of (2^28)-1 was the INVALID_PFN representation in the 32bit stream.

The check is less important for migration v2, but I left it in as an
upper sanity check.

I am not aversed to removing the check if we are no longer going to
believe the result of XENMEM_maximum_gpfn, and requiring that setup()
get and sanity check the domain size.

(Incidently, it seems crazy that we make a XENMEM_maximum_gpfn hypercall
to read a value from the shared info page, which is also (about to be)
mapped locally.)

~Andrew

  reply	other threads:[~2015-11-27 17:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-27 14:50 [PATCH] libxc: try to find last used pfn when migrating Juergen Gross
2015-11-27 15:01 ` David Vrabel
2015-11-27 15:11   ` Juergen Gross
2015-11-27 15:18     ` Ian Campbell
2015-11-27 15:20     ` David Vrabel
2015-11-27 15:22     ` Ian Jackson
2015-11-27 15:50       ` Juergen Gross
2015-11-27 15:33 ` Wei Liu
2015-11-27 15:53   ` Juergen Gross
2015-11-27 17:16     ` Andrew Cooper [this message]
2015-11-30  8:17       ` Juergen Gross
2015-11-30  9:47         ` Andrew Cooper
2015-11-30 12:16           ` Juergen Gross
2015-11-27 16:42 ` Andrew Cooper
2015-11-27 16:51   ` Juergen Gross

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=56588FE1.1060606@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jgross@suse.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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.