All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Jackson <ian.jackson@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Wei Liu" <wl@xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	"George Dunlap" <George.Dunlap@citrix.com>,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	"Julien Grall" <julien.grall@arm.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 10/12] docs/migration: Specify X86_{CPUID, MSR}_POLICY records
Date: Tue, 14 Jan 2020 16:12:14 +0000	[thread overview]
Message-ID: <24093.59486.138192.313998@mariner.uk.xensource.com> (raw)
In-Reply-To: <94245c21-3e0b-4099-fe22-f2639651f1db@citrix.com>

Andrew Cooper writes ("Re: [PATCH 10/12] docs/migration: Specify X86_{CPUID,MSR}_POLICY records"):
> The migration stream is split into records with no playload (markers
> with external control flow meaning), and data records, which have a payload.

I remember thinking at the time you specified this (some time ago, in
migration v2) that this was anomalous.

At the time it made no difference in practice, because all existing
payload types required nonempty payloads anyway, so I didn't argue.

> It is an error for a data record to have no payload, because it means
> there is a source side generation bug.  In the case of Xen returning 0
> MSRs, the record would be omitted entirely, rather than be sent with 0
> MSRs worth of data.

I think it would be better to say instead that data records may have a
0-length payload.  This allows a record with a 0-length payload to
have a different semantic meaning ("here is this information and the
information is the empty set") from an omitted record ("this
information is not available/provided").

Whether a record is a marker ought to be inferred from its type.

Ian.

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

  reply	other threads:[~2020-01-14 16:12 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 ` [Xen-devel] [PATCH 06/12] docs/migration Specify migration v3 and STATIC_DATA_END Andrew Cooper
2020-01-03 14:44   ` 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 [this message]
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=24093.59486.138192.313998@mariner.uk.xensource.com \
    --to=ian.jackson@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=konrad.wilk@oracle.com \
    --cc=marmarek@invisiblethingslab.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.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.