[Xen-devel] Live migration fails due to c/s 20627

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Keir, please consider backing out c/s 20627.  I don't believe
all the cases have been properly thought through, and
the consequences have impact on applications and thus
on existing customers.  As far as I can tell, there is
no urgency to get this into Xen 4.0 since existing apps
and guest OS's that use rdtscp must check cpuid to see
if the instruction is present on the hardware.  But putting
a partial solution into 4.0 may cause Xen versioning
issues that affect apps for years to come.   This
is an ABI, not a feature!

> From: Xu, Dongxiao [mailto:dongxiao.xu@xxxxxxxxx]
> Sent: Friday, December 11, 2009 5:24 PM
> Subject: RE: [Xen-devel][PATCH 02/02] VMX: Add HVM RDTSCP support
> 
> Whether a system has rdtscp support is indicated by
> the cpuid. Management tool or system admin should
> use CPUIDdetermine whether the migration is allowed. 
> I think besides RDTSCP, we already have such cases.

This may be true in concept, but existing tools (including
the default xm tools) do NOT check for this... I just
tested a live migration between a Nehalem (which supports
rdtscp) and a Conroe (which does not).  The live migration
works fine and the app using rdtscp runs fine on the
Nehalem and then crashes when the live migration completes
on the Conroe.  I *know* of existing code in Oracle
that will be broken by this!

List of "open" discussions:
- virtualization of rdtscp on processors that don't
  support it (PV does, HVM doesn't)
- virtualizing (or not) TSC-AUX
- the Xen 32-bit vs Xen 64-bit inconsistency
- how to communicate pcpu vs vcpu and pnode vs vnode
  (and whether this has any relevance for TSC-AUX)
- hvm support of the pvrdtscp algorithm
- toolset capability and compatibility

On any of these points, I'm not saying I am right and
anyone else is wrong, I'm just saying further discussion
is warranted and getting it wrong in 4.0 has significant
risk and consequences if we proceed haphazardly.

I am only urging caution and proper design.

Thanks,
Dan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel