Hello, All. Do I understand correctly: for the present it is possible to make domain live migration across two hosts, one of which is Intel-CPU-based and another is AMD-CPU-based? Does CPUID feature of Xen 3.3 permit live migration only between hosts with CPUs with different flags but produce by the same vendor? What is the difference (from domU perspective) between such CPUs, that prohibits live migration? Thank you. -- WBR, i.m.chubin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 2/12/08 09:05, "Igor Chubin" <igor@chub.in> wrote:> Hello, All. > > Do I understand correctly: > > for the present it is possible to make domain live migration > across two hosts, one of which is Intel-CPU-based and > another is AMD-CPU-based? > > Does CPUID feature of Xen 3.3 permit live migration only > between hosts with CPUs with different flags but > produce by the same vendor? > > What is the difference (from domU perspective) > between such CPUs, that prohibits live migration?Supported instructions differ (even at the basic level of SYSENTER versus SYSCALL in some situations). Supported architectural MSRs differ too. Actually it could be forced to work sometimes, but it''s not particularly something we want to be claiming to support. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> On 2/12/08 09:05, "Igor Chubin" <igor@chub.in> wrote: > > > Hello, All. > > > > Do I understand correctly: > > > > for the present it is possible to make domain live migration > > across two hosts, one of which is Intel-CPU-based and > > another is AMD-CPU-based? > > > > Does CPUID feature of Xen 3.3 permit live migration only > > between hosts with CPUs with different flags but > > produce by the same vendor? > > > > What is the difference (from domU perspective) > > between such CPUs, that prohibits live migration? > > Supported instructions differ (even at the basic level of SYSENTERversus> SYSCALL in some situations). Supported architectural MSRs differ too. > > Actually it could be forced to work sometimes, but it''s notparticularly> something we want to be claiming to support. >This appeared on slashdot a while ago... http://linux.slashdot.org/linux/08/11/07/1535235.shtml. I''m not sure that their source is that reputable though. If you were emulating a 486 it might work :) James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Di, Dez 02, 2008 at 08:44:53 +1100, James Harper wrote:> > On 2/12/08 09:05, "Igor Chubin" <igor@chub.in> wrote: > > > > > Hello, All. > > > > > > Do I understand correctly: > > > > > > for the present it is possible to make domain live migration > > > across two hosts, one of which is Intel-CPU-based and > > > another is AMD-CPU-based? > > > > > > Does CPUID feature of Xen 3.3 permit live migration only > > > between hosts with CPUs with different flags but > > > produce by the same vendor? > > > > > > What is the difference (from domU perspective) > > > between such CPUs, that prohibits live migration? > > > > Supported instructions differ (even at the basic level of SYSENTER > versus > > SYSCALL in some situations). Supported architectural MSRs differ too. > > > > Actually it could be forced to work sometimes, but it''s not > particularly > > something we want to be claiming to support. > > > > This appeared on slashdot a while ago... > http://linux.slashdot.org/linux/08/11/07/1535235.shtml. I''m not sure > that their source is that reputable though. If you were emulating a 486 > it might work :) >Thank you Keir and James, I know about this posting on slashdot. Also here is related video [1] with a small presentation. They claim there that live migration across AMD and Intel works on KVM. As far as I understand now it works in some particular (and rare) situations but it is not true in general. Thank you. [1] http://www.youtube.com/watch?v=EuhU6jJjpAQ> James-- WBR, i.m.chubin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tuesday 02 December 2008 10:44:53 James Harper wrote:> > On 2/12/08 09:05, "Igor Chubin" <igor@chub.in> wrote: > > > Hello, All. > > > > > > Do I understand correctly: > > > > > > for the present it is possible to make domain live migration > > > across two hosts, one of which is Intel-CPU-based and > > > another is AMD-CPU-based? > > > > > > Does CPUID feature of Xen 3.3 permit live migration only > > > between hosts with CPUs with different flags but > > > produce by the same vendor? > > > > > > What is the difference (from domU perspective) > > > between such CPUs, that prohibits live migration?You need to emulate SYSENTER for the 64bit case completely (including the MSRs MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP) for the 32bit compat and 64bit modes. The three MSRs also exist on AMD, but unlike on Intel they are always 32bit. So you have to emulate them with a 64bit storage. The SYSENTER fields in the vmcb are 64bit wide for alignment purpose, but only the lower 32bits are used (meaning the guest still only see''s a 32bit wide MSRs, upper 4-bytes are zero-filled by hw). So you can''t use them as 64bit storage to emulate them. Another issue are the x87 FPU instructions. Both AMD and Intel CPUs compute with more than 64bits internally and the results are different on the additional bits. If the FPU is heavily used, (e.g. in a loop), differences appear and comparisons of results will fail after migration which are intended to succeed. Attached is a fpu testprogram which shows the FPU differences. A third case is the idle-loop in the guests. Intel prefers monitor/mwait, AMD prefers hlt. Moreover, monitor/mwait has been introduced in AMD Family10h, so if you''re migrating to an AMD K8, Xen has to emulate the monitor/mwait instructions. Hope, that clearifies things up. Christoph -- AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Geschäftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplementär: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 2/12/08 10:07, "Igor Chubin" <igor@chub.in> wrote:>> This appeared on slashdot a while ago... >> http://linux.slashdot.org/linux/08/11/07/1535235.shtml. I''m not sure >> that their source is that reputable though. If you were emulating a 486 >> it might work :) > > Thank you Keir and James, > > I know about this posting on slashdot. > Also here is related video [1] with a small presentation. > > They claim there that live migration across AMD and Intel > works on KVM. As far as I understand now it works in > some particular (and rare) situations but it is not true in general.Yeah, it can definitely work in a range of cases. It''s definitely demo-able. But claiming it works in general in production environments is something else! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,> As far as I understand now it works in some particular (and rare) > situations but it is not true in general.mostly if you have one old and one modern CPU it works on one direction. During some prototyping a while ago I was always able to migrate from an old Intel P3-system to an "modern" AMD Athlon-system, while the way back most times result in a crash of the VM. But I had better success with Intel P4 and Intel Xeon CPUs (both with first generation of HVM-support), where I could do migration on both directions without any errors! -- Chau y hasta luego, Thorolf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel