From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: Frediano Ziglio <frediano.ziglio@citrix.com>,
David Vrabel <david.vrabel@citrix.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH v5 RFC 13/14] tools/libxc: noarch save code
Date: Thu, 19 Jun 2014 10:19:57 +0100 [thread overview]
Message-ID: <53A2AB3D.2080203@citrix.com> (raw)
In-Reply-To: <53A24F77.6020005@cn.fujitsu.com>
On 19/06/14 03:48, Wen Congyang wrote:
> At 06/12/2014 02:14 AM, Andrew Cooper Wrote:
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> ---
>> tools/libxc/saverestore/save.c | 545 +++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 544 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/libxc/saverestore/save.c b/tools/libxc/saverestore/save.c
>> index f6ad734..9ad43a5 100644
>> --- a/tools/libxc/saverestore/save.c
>> +++ b/tools/libxc/saverestore/save.c
>> @@ -1,11 +1,554 @@
>> +#include <assert.h>
>> +#include <arpa/inet.h>
>> +
>> #include "common.h"
>>
>> +/*
>> + * Writes an Image header and Domain header into the stream.
>> + */
>> +static int write_headers(struct context *ctx, uint16_t guest_type)
>> +{
>> + xc_interface *xch = ctx->xch;
>> + int32_t xen_version = xc_version(xch, XENVER_version, NULL);
>> + struct ihdr ihdr =
>> + {
>> + .marker = IHDR_MARKER,
>> + .id = htonl(IHDR_ID),
>> + .version = htonl(IHDR_VERSION),
>> + .options = htons(IHDR_OPT_LITTLE_ENDIAN),
>> + };
>> + struct dhdr dhdr =
>> + {
>> + .type = guest_type,
>> + .page_shift = XC_PAGE_SHIFT,
>> + .xen_major = (xen_version >> 16) & 0xffff,
>> + .xen_minor = (xen_version) & 0xffff,
>> + };
>> +
>> + if ( xen_version < 0 )
>> + {
>> + PERROR("Unable to obtain Xen Version");
>> + return -1;
>> + }
>> +
>> + if ( write_exact(ctx->fd, &ihdr, sizeof(ihdr)) )
>> + {
>> + PERROR("Unable to write Image Header to stream");
>> + return -1;
>> + }
>> +
>> + if ( write_exact(ctx->fd, &dhdr, sizeof(dhdr)) )
>> + {
>> + PERROR("Unable to write Domain Header to stream");
>> + return -1;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * Writes an END record into the stream.
>> + */
>> +static int write_end_record(struct context *ctx)
>> +{
>> + struct record end = { REC_TYPE_END, 0, NULL };
>> +
>> + return write_record(ctx, &end);
>> +}
>> +
>> +/*
>> + * Writes a batch of memory as a PAGE_DATA record into the stream. The batch
>> + * is constructed in ctx->save.batch_pfns.
>> + *
>> + * This function:
>> + * - gets the types for each pfn in the batch.
>> + * - for each pfn with real data:
>> + * - maps and attempts to localise the pages.
>> + * - construct and writes a PAGE_DATA record into the stream.
>> + */
>> +static int write_batch(struct context *ctx)
>> +{
>> + xc_interface *xch = ctx->xch;
>> + xen_pfn_t *mfns = NULL, *types = NULL;
>> + void *guest_mapping = NULL;
>> + void **guest_data = NULL;
>> + void **local_pages = NULL;
>> + int *errors = NULL, rc = -1;
>> + unsigned i, p, nr_pages = 0;
>> + unsigned nr_pfns = ctx->save.nr_batch_pfns;
>> + void *page, *orig_page;
>> + uint64_t *rec_pfns = NULL;
>> + struct rec_page_data_header hdr = { 0 };
>> + struct record rec =
>> + {
>> + .type = REC_TYPE_PAGE_DATA,
>> + };
>> +
>> + assert(nr_pfns != 0);
>> +
>> + /* Mfns of the batch pfns. */
>> + mfns = malloc(nr_pfns * sizeof(*mfns));
>> + /* Types of the batch pfns. */
>> + types = malloc(nr_pfns * sizeof(*types));
>> + /* Errors from attempting to map the mfns. */
>> + errors = malloc(nr_pfns * sizeof(*errors));
>> + /* Pointers to page data to send. Either mapped mfns or local allocations. */
>> + guest_data = calloc(nr_pfns, sizeof(*guest_data));
>> + /* Pointers to locally allocated pages. Need freeing. */
>> + local_pages = calloc(nr_pfns, sizeof(*local_pages));
> This function is called too many times, so we will allocate/free
> memory again and again. It may affect the performance.
>
> I think we can allocate at setup stage, and only clear guest_data/
> local_pages here.
We likely can. It is currently like this because it allowed valgrind to
do a fantastic job of spotting errors when flushing an incomplete batch
at the end of each iteration.
It should be possible to consolidate the allocations and use valgrind
client requests to achieve the same effect, although at this point my
effort is far more focused to getting something which works correctly
ready in the 4.5 timeframe.
>
>> +
>> + if ( !mfns || !types || !errors || !guest_data || !local_pages )
>> + {
>> + ERROR("Unable to allocate arrays for a batch of %u pages",
>> + nr_pfns);
>> + goto err;
>> + }
>> +
>> + for ( i = 0; i < nr_pfns; ++i )
>> + {
>> + types[i] = mfns[i] = ctx->ops.pfn_to_gfn(ctx, ctx->save.batch_pfns[i]);
>> +
>> + /* Likely a ballooned page. */
>> + if ( mfns[i] == INVALID_MFN )
>> + set_bit(ctx->save.batch_pfns[i], ctx->save.deferred_pages);
>> + }
>> +
>> + rc = xc_get_pfn_type_batch(xch, ctx->domid, nr_pfns, types);
>> + if ( rc )
>> + {
>> + PERROR("Failed to get types for pfn batch");
>> + goto err;
>> + }
>> + rc = -1;
>> +
>> + for ( i = 0; i < nr_pfns; ++i )
>> + {
>> + switch ( types[i] )
>> + {
>> + case XEN_DOMCTL_PFINFO_BROKEN:
>> + case XEN_DOMCTL_PFINFO_XALLOC:
>> + case XEN_DOMCTL_PFINFO_XTAB:
>> + continue;
>> + }
>> +
>> + mfns[nr_pages++] = mfns[i];
>> + }
>> +
>> + if ( nr_pages > 0 )
>> + {
>> + guest_mapping = xc_map_foreign_bulk(
>> + xch, ctx->domid, PROT_READ, mfns, errors, nr_pages);
>> + if ( !guest_mapping )
>> + {
>> + PERROR("Failed to map guest pages");
>> + goto err;
>> + }
> To support remus, we will map/unmap guest memory again and again. It
> also affects the performance. We can cache guest mapping here.
>
> Thanks
> Wen Congyang
>
>
I am not aware of the current code caching mappings into the guest.
64bit toolstacks would be fine setting up mappings for every gfn and
reusing the mappings, but this really won't work for 32bit toolstacks.
What remus does appear to do is have a limited cache of
previously-written pages for XOR+RLE compression.
~Andrew
next prev parent reply other threads:[~2014-06-19 9:19 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 18:14 [PATCH v5 0/14] Migration Stream v2 Andrew Cooper
2014-06-11 18:14 ` [PATCH v5 RFC 01/14] docs: libxc migration stream specification Andrew Cooper
2014-06-12 9:45 ` David Vrabel
2014-06-12 15:26 ` David Vrabel
2014-06-17 15:20 ` Ian Campbell
2014-06-17 17:42 ` Andrew Cooper
2014-06-17 16:40 ` Ian Campbell
2014-06-17 18:04 ` Andrew Cooper
2014-06-19 9:13 ` Hongyang Yang
2014-06-19 9:36 ` Andrew Cooper
2014-06-19 10:23 ` Hongyang Yang
2014-06-19 10:44 ` Andrew Cooper
2014-06-22 14:36 ` Shriram Rajagopalan
2014-06-22 16:01 ` Andrew Cooper
2014-06-11 18:14 ` [PATCH v5 RFC 02/14] scripts: Scripts for inspection/valdiation of legacy and new streams Andrew Cooper
2014-06-12 9:48 ` David Vrabel
2014-06-11 18:14 ` [PATCH v5 RFC 03/14] [HACK] tools/libxc: save/restore v2 framework Andrew Cooper
2014-06-17 16:00 ` Ian Campbell
2014-06-17 16:17 ` Andrew Cooper
2014-06-17 16:47 ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 04/14] tools/libxc: C implementation of stream format Andrew Cooper
2014-06-12 9:52 ` David Vrabel
2014-06-12 15:31 ` David Vrabel
2014-06-17 15:55 ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 05/14] tools/libxc: noarch common code Andrew Cooper
2014-06-12 9:55 ` David Vrabel
2014-06-17 16:10 ` Ian Campbell
2014-06-17 16:28 ` Andrew Cooper
2014-06-17 16:53 ` Ian Campbell
2014-06-17 18:26 ` Andrew Cooper
2014-06-18 9:19 ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 06/14] tools/libxc: x86 " Andrew Cooper
2014-06-12 9:57 ` David Vrabel
2014-06-17 16:11 ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 07/14] tools/libxc: x86 PV " Andrew Cooper
2014-06-12 9:59 ` David Vrabel
2014-06-11 18:14 ` [PATCH v5 RFC 08/14] tools/libxc: x86 PV save code Andrew Cooper
2014-06-12 10:04 ` David Vrabel
2014-06-11 18:14 ` [PATCH v5 RFC 09/14] tools/libxc: x86 PV restore code Andrew Cooper
2014-06-12 10:08 ` David Vrabel
2014-06-12 15:49 ` David Vrabel
2014-06-12 17:01 ` Andrew Cooper
2014-06-17 16:22 ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 10/14] tools/libxc: x86 HVM common code Andrew Cooper
2014-06-12 10:11 ` David Vrabel
2014-06-17 16:22 ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 11/14] tools/libxc: x86 HVM save code Andrew Cooper
2014-06-12 10:12 ` David Vrabel
2014-06-12 15:55 ` David Vrabel
2014-06-12 17:07 ` Andrew Cooper
2014-06-17 16:25 ` Ian Campbell
2014-06-11 18:14 ` [PATCH v5 RFC 12/14] tools/libxc: x86 HVM restore code Andrew Cooper
2014-06-12 10:14 ` David Vrabel
2014-06-11 18:14 ` [PATCH v5 RFC 13/14] tools/libxc: noarch save code Andrew Cooper
2014-06-12 10:24 ` David Vrabel
2014-06-17 16:28 ` Ian Campbell
2014-06-17 16:38 ` David Vrabel
2014-06-17 16:54 ` Ian Campbell
2014-06-18 6:59 ` Hongyang Yang
2014-06-18 7:08 ` Hongyang Yang
2014-06-19 2:48 ` Wen Congyang
2014-06-19 9:19 ` Andrew Cooper [this message]
2014-06-22 14:02 ` Shriram Rajagopalan
2014-06-11 18:14 ` [PATCH v5 RFC 14/14] tools/libxc: noarch restore code Andrew Cooper
2014-06-12 10:27 ` David Vrabel
2014-06-12 16:05 ` David Vrabel
2014-06-12 17:16 ` Andrew Cooper
2014-06-19 6:16 ` Hongyang Yang
2014-06-19 9:00 ` Andrew Cooper
2014-06-12 3:17 ` [PATCH v5 0/14] Migration Stream v2 Hongyang Yang
2014-06-12 13:27 ` Andrew Cooper
2014-06-12 13:49 ` Wei Liu
2014-06-12 14:18 ` Andrew Cooper
2014-06-12 14:27 ` Wei Liu
2014-06-12 9:38 ` David Vrabel
2014-06-17 15:57 ` Ian Campbell
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=53A2AB3D.2080203@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=david.vrabel@citrix.com \
--cc=frediano.ziglio@citrix.com \
--cc=wency@cn.fujitsu.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.