All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xenproject.org>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.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>,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	"Jan Beulich" <JBeulich@suse.com>,
	"Ian Jackson" <ian.jackson@citrix.com>
Subject: [Xen-devel] [PATCH 06/12] docs/migration Specify migration v3 and STATIC_DATA_END
Date: Tue, 24 Dec 2019 15:19:26 +0000	[thread overview]
Message-ID: <20191224151932.6304-7-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <20191224151932.6304-1-andrew.cooper3@citrix.com>

Migration data can be split into two parts - that which is invariant of
guest execution, and that which is not.  Separate these two with the
STATIC_DATA_END record.

The short term, we want to move the x86 CPU Policy data into the stream.
In the longer term, we want to provisionally send the static data only
to the destination as a more robust compatibility check.  In both cases,
we will want a callback into the higher level toolstack.

Mandate the presence of the STATIC_DATA_END record, and declare this v3,
along with instructions for how to compatibly interpret a v2 stream.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: George Dunlap <George.Dunlap@eu.citrix.com>
CC: Ian Jackson <ian.jackson@citrix.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Wei Liu <wl@xen.org>
CC: Julien Grall <julien@xen.org>
CC: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
---
 docs/specs/libxc-migration-stream.pandoc | 39 +++++++++++++++++++++++++++++---
 tools/libxc/xc_sr_common.c               |  1 +
 tools/libxc/xc_sr_stream_format.h        |  1 +
 tools/python/xen/migration/libxc.py      |  2 ++
 4 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/docs/specs/libxc-migration-stream.pandoc b/docs/specs/libxc-migration-stream.pandoc
index a7a8a08936..22ff306e0b 100644
--- a/docs/specs/libxc-migration-stream.pandoc
+++ b/docs/specs/libxc-migration-stream.pandoc
@@ -127,7 +127,7 @@ marker      0xFFFFFFFFFFFFFFFF.
 
 id          0x58454E46 ("XENF" in ASCII).
 
-version     0x00000002.  The version of this specification.
+version     0x00000003.  The version of this specification.
 
 options     bit 0: Endianness.  0 = little-endian, 1 = big-endian.
 
@@ -620,6 +620,21 @@ The count of pfns is: record->length/sizeof(uint64_t).
 
 \clearpage
 
+STATIC_DATA_END
+---------------
+
+A static data end record marks the end of the static state.  I.e. state which
+is invariant of guest execution.
+
+
+     0     1     2     3     4     5     6     7 octet
+    +-------------------------------------------------+
+
+The end record contains no fields; its body_length is 0.
+
+\clearpage
+
+
 Layout
 ======
 
@@ -639,7 +654,9 @@ A typical save record for an x86 PV guest image would look like:
 
 * Image header
 * Domain header
-* X86_PV_INFO record
+* Static data records:
+    * X86_PV_INFO record
+    * STATIC_DATA_END
 * X86_PV_P2M_FRAMES record
 * Many PAGE_DATA records
 * X86_TSC_INFO
@@ -667,6 +684,8 @@ A typical save record for an x86 HVM guest image would look like:
 
 * Image header
 * Domain header
+* Static data records:
+    * STATIC_DATA_END
 * Many PAGE_DATA records
 * X86_TSC_INFO
 * HVM_PARAMS
@@ -675,9 +694,23 @@ A typical save record for an x86 HVM guest image would look like:
 HVM_PARAMS must precede HVM_CONTEXT, as certain parameters can affect
 the validity of architectural state in the context.
 
+Compatibility with older versions
+=================================
+
+v3 compat with v2
+-----------------
+
+A v3 stream is compatible with a v2 stream, but mandates the presense of a
+STATIC_DATA_END record ahead of any memory/register content.  This is to ease
+the introduction of new static configuration records over time.
+
+A v3-compatible reciever interpreting a v2 stream should infer the position of
+STATIC_DATA_END based on finding the first X86_PV_P2M_FRAMES record (for PV
+guests), or PAGE_DATA record (for HVM guests) and behave as if STATIC_DATA_END
+had been sent.
 
 Legacy Images (x86 only)
-========================
+------------------------
 
 Restoring legacy images from older tools shall be handled by
 translating the legacy format image into this new format.
diff --git a/tools/libxc/xc_sr_common.c b/tools/libxc/xc_sr_common.c
index dd9a11b4b5..7f22cf0365 100644
--- a/tools/libxc/xc_sr_common.c
+++ b/tools/libxc/xc_sr_common.c
@@ -36,6 +36,7 @@ static const char *const mandatory_rec_types[] =
     [REC_TYPE_VERIFY]                       = "Verify",
     [REC_TYPE_CHECKPOINT]                   = "Checkpoint",
     [REC_TYPE_CHECKPOINT_DIRTY_PFN_LIST]    = "Checkpoint dirty pfn list",
+    [REC_TYPE_STATIC_DATA_END]              = "Static data end",
 };
 
 const char *rec_type_to_str(uint32_t type)
diff --git a/tools/libxc/xc_sr_stream_format.h b/tools/libxc/xc_sr_stream_format.h
index ae7c0de393..81c9765b0a 100644
--- a/tools/libxc/xc_sr_stream_format.h
+++ b/tools/libxc/xc_sr_stream_format.h
@@ -73,6 +73,7 @@ struct xc_sr_rhdr
 #define REC_TYPE_VERIFY                     0x0000000dU
 #define REC_TYPE_CHECKPOINT                 0x0000000eU
 #define REC_TYPE_CHECKPOINT_DIRTY_PFN_LIST  0x0000000fU
+#define REC_TYPE_STATIC_DATA_END            0x00000010U
 
 #define REC_TYPE_OPTIONAL             0x80000000U
 
diff --git a/tools/python/xen/migration/libxc.py b/tools/python/xen/migration/libxc.py
index 63b3558029..d0c4f3527d 100644
--- a/tools/python/xen/migration/libxc.py
+++ b/tools/python/xen/migration/libxc.py
@@ -56,6 +56,7 @@
 REC_TYPE_verify                     = 0x0000000d
 REC_TYPE_checkpoint                 = 0x0000000e
 REC_TYPE_checkpoint_dirty_pfn_list  = 0x0000000f
+REC_TYPE_static_data_end            = 0x00000010
 
 rec_type_to_str = {
     REC_TYPE_end                        : "End",
@@ -74,6 +75,7 @@
     REC_TYPE_verify                     : "Verify",
     REC_TYPE_checkpoint                 : "Checkpoint",
     REC_TYPE_checkpoint_dirty_pfn_list  : "Checkpoint dirty pfn list",
+    REC_TYPE_static_data_end            : "Static data end",
 }
 
 # page_data
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  parent reply	other threads:[~2019-12-24 15:20 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-24 15:19 [Xen-devel] [PATCH 00/12] Support CPUID/MSR data in migration streams Andrew Cooper
2019-12-24 15:19 ` [Xen-devel] [PATCH 01/12] libxc/save: Shrink code volume where possible Andrew Cooper
2020-01-14 16:48   ` Ian Jackson
2020-01-14 16:55     ` Ian Jackson
2020-01-15 19:22     ` Andrew Cooper
2020-04-27 17:19       ` Ian Jackson
2020-04-27 19:55         ` Wei Liu
2020-04-27 20:00           ` Andrew Cooper
2020-04-28  9:46             ` Wei Liu
2019-12-24 15:19 ` [Xen-devel] [PATCH 02/12] libxc/restore: Introduce functionality to simplify blob handling Andrew Cooper
2020-01-14 16:50   ` Ian Jackson
2019-12-24 15:19 ` [Xen-devel] [PATCH 03/12] libxc/migration: Rationalise the 'checkpointed' field to 'stream_type' Andrew Cooper
2020-01-14 15:58   ` Ian Jackson
2019-12-24 15:19 ` [Xen-devel] [PATCH 04/12] libxc/migration: Adjust layout of struct xc_sr_context Andrew Cooper
2020-01-14 16:04   ` Ian Jackson
2019-12-24 15:19 ` [Xen-devel] [PATCH 05/12] tools/migration: Drop IHDR_VERSION constant from libxc and python Andrew Cooper
2020-01-14 16:05   ` Ian Jackson
2020-01-15 15:29     ` Andrew Cooper
2019-12-24 15:19 ` Andrew Cooper [this message]
2020-01-03 14:44   ` [Xen-devel] [PATCH 06/12] docs/migration Specify migration v3 and STATIC_DATA_END Jan Beulich
2020-01-09 14:54     ` Andrew Cooper
2020-01-14 16:07   ` Ian Jackson
2019-12-24 15:19 ` [Xen-devel] [PATCH 07/12] python/migration: Update validation logic to understand a v3 stream Andrew Cooper
2019-12-24 15:19 ` [Xen-devel] [PATCH 08/12] libxc/restore: Support v3 streams, and cope with v2 compatibilty Andrew Cooper
2020-01-14 17:02   ` Ian Jackson
2019-12-24 15:19 ` [Xen-devel] [PATCH 09/12] libxc/save: Write a v3 stream Andrew Cooper
2020-01-14 17:05   ` Ian Jackson
2019-12-24 15:19 ` [Xen-devel] [PATCH 10/12] docs/migration: Specify X86_{CPUID, MSR}_POLICY records Andrew Cooper
2020-01-03 14:49   ` Jan Beulich
2020-01-03 14:55     ` Andrew Cooper
2020-01-03 15:30       ` Jan Beulich
2020-01-09 15:30         ` Andrew Cooper
2020-01-14 16:12           ` Ian Jackson
2020-01-15 15:48             ` Andrew Cooper
2020-01-14 16:08   ` Ian Jackson
2020-01-15 15:36     ` Andrew Cooper
2019-12-24 15:19 ` [Xen-devel] [PATCH 11/12] libxc/restore: Handle X86_{CPUID, MSR}_DATA records Andrew Cooper
2020-01-14 17:16   ` Ian Jackson
2019-12-24 15:19 ` [Xen-devel] [PATCH 12/12] libxc/save: Write " Andrew Cooper
2020-01-14 17:21   ` Ian Jackson
2020-01-15 15:52     ` Andrew Cooper
2020-01-03 13:06 ` [Xen-devel] [PATCH] Use CPUID/MSR data from migration streams Andrew Cooper
2020-01-03 13:06   ` [Xen-devel] [PATCH 15/20] fixup tools/migration: Formatting and style cleanup Andrew Cooper
2020-01-03 13:06   ` [Xen-devel] [PATCH 16/20] tools/libxl: Simplify callback handling in libxl-save-helper Andrew Cooper
2020-01-14 17:27     ` Ian Jackson
2020-01-15 16:16       ` Andrew Cooper
2020-01-03 13:06   ` [Xen-devel] [PATCH 17/20] tools/libx[cl]: Plumb static_data_done() up into libxl Andrew Cooper
2020-01-14 17:30     ` Ian Jackson
2020-01-15 16:34       ` Andrew Cooper
2020-05-29 15:58         ` Ian Jackson
2020-01-03 13:06   ` [Xen-devel] [PATCH 18/20] tools/libxl: Plumb domain_create_state down into libxl__build_pre() Andrew Cooper
2020-01-14 17:32     ` Ian Jackson
2020-01-03 13:06   ` [Xen-devel] [PATCH 19/20] tools/libxl: Re-position CPUID handling during domain construction Andrew Cooper
2020-01-14 17:33     ` Ian Jackson
2020-01-14 17:51       ` Andrew Cooper
2020-01-14 18:12         ` Ian Jackson
2020-01-03 13:06   ` [Xen-devel] [PATCH 20/20] tools/libxc: Restore CPUID/MSR data found in the migration stream Andrew Cooper
2020-01-14 17:34     ` Ian Jackson
2020-01-15 18:53 ` [Xen-devel] [PATCH 0.5/12] tools/migration: Formatting and style cleanup Andrew Cooper
2020-01-15 21:26   ` Ian Jackson

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=20191224151932.6304-7-andrew.cooper3@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=ian.jackson@citrix.com \
    --cc=julien@xen.org \
    --cc=konrad.wilk@oracle.com \
    --cc=marmarek@invisiblethingslab.com \
    --cc=sstabellini@kernel.org \
    --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.