All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Jackson <ian.jackson@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: Wed, 15 Jan 2020 15:48:58 +0000	[thread overview]
Message-ID: <496b2405-5a1b-38ec-0a8b-d075748fbfe8@citrix.com> (raw)
In-Reply-To: <24093.59486.138192.313998@mariner.uk.xensource.com>

On 14/01/2020 16:12, Ian Jackson wrote:
> 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.

It was, and remains, very deliberate.

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

All records have explicit semantics as specified by their types.  This
includes the semantics as to whether it shall have zero or non-zero payload.

A data record with no payload is nonsensical.  It is prohibited
specifically because it helps the protocol verification logic spot bugs,
and we really did spot several hypercall (preexiting) and save-side bugs
because of this rule.

If a plausible use for payload-less data appears, then we can take a
judgement call as to whether it outweighs the utility of improved error
detection.  Making this change would require a change to the spec, and
an adjustment to the pre-exiting receive side logic.

~Andrew

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

  reply	other threads:[~2020-01-15 15:49 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
2020-01-15 15:48             ` Andrew Cooper [this message]
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=496b2405-5a1b-38ec-0a8b-d075748fbfe8@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=ian.jackson@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.