Re: [Xen-devel] [PATCH v2 RFC 2/4] x86/PV: support data breakpoint extension registers

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/03/14 15:28, Ian Campbell wrote:
> On Wed, 2014-03-26 at 14:13 +0000, Jan Beulich wrote:
>> Introducing an extension to XEN_DOMCTL_[gs]et_ext_vcpucontext similar
>> to the generic MSR save/restore logic recently added for HVM.
> "x86: generic MSRs save/restore" I guess?
>
> Is the intention here that the extvcpu context is a blob of opaque data
> from the pov of the migration tools?
>
> Do the protocol docs in xg_save_restore need updating due to this
> change?
>
> How does N->N+1 migration work out?

Having just rewritten all of this code from scratch, the details are
painfully present in my brain.

The answer is badly.

The blob is exactly 128 bytes long, starting from the beginning of the
domctl union.  changeset e1dc98e3c "x86/vMCE: save/restore MCA
capabilities" introduced an explicit memset(0) on the content of the
struct domctl, meaning that this newly interpreted 'msr_count' shall
have the value 0.

Migration streams from before e1dc98e3c (Fri Feb 24 2012, Xen-4.2) will
have an uninitialised stack value instead of 0 for the newly interpreted
'msr_count' (unless the toolstack was complied with CONFIG_VALGRIND),
which will cause corruption in any migration stream from Xen-4.1 or before.

While I realise that this does technically fall within the statement of
supportability as far as upstream goes, it would be a show-stopper for
XenServer and I presume any other Xen based system with real customers
on older versions of Xen.

As this is a new feature, so not applicable for backport, can it wait
until my migration stream v2 work is submitted?  The migration code
churn to support this in v2 would be far less, and would also guarantee
no breakage of older migration streams.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel