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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.03.14 at 17:03, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

As just written to Ian in another reply - this new field isn't even being
looked at when the size stored at the beginning of the structure doesn't
indicate the presence of the msrs[] handle.

> 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.

I wouldn't want to postpone this by too much (and certainly not past
a re-write of the migration code) because - other than upstream Xen -
we may want/need to backport this for SLE12.

Jan


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