Hi Thomas,
thats interesting, could you, please, check by the cpuid utility (link
in my mail below) if
it really works in your case ?
>From /proc/cpuid on Xeon host i get:
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) D CPU 2.80GHz
flags : fpu de tsc msr pae cx8 apic sep cmov pat clflush acpi
mmx fxsr sse sse2 ss ht constant_tsc cx16 popcnt hypervisor
and exactly the same output on PentiumD host.
But the cpuid utility (which uses directly the cpuid instruction) gives
CPU 0:
vendor_id = "GenuineIntel"
version information (1/eax):
processor type = primary processor (0)
family = Intel Pentium Pro/II/III/Celeron/Core/Core
2/Atom, AMD Athlon/Duron, Cyrix M2, VIA C3 (6)
model = 0xe (14)
stepping id = 0x5 (5)
extended family = 0x0 (0)
extended model = 0x1 (1)
(simple synth) = Intel Intel Core i5-700 / i7-800 (Lynnfield B1)
/ Core i7-700/800/900 Mobile (Clarksfield B1) / Xeon Processor 3400
(Lynnfield B1), 45nm
in domU on xeon
and
CPU 0:
vendor_id = "GenuineIntel"
version information (1/eax):
processor type = primary processor (0)
family = Intel Pentium 4/Pentium D/Pentium Extreme
Edition/Celeron/Xeon/Xeon MP/Itanium2, AMD Athlon 64/Athlon
XP-M/Opteron/Sempron/Turion (15)
model = 0x4 (4)
stepping id = 0x4 (4)
extended family = 0x0 (0)
extended model = 0x0 (0)
(simple synth) = Intel Pentium D Processor 8x0 (Smithfield A0) /
Pentium Extreme Edition Processor 840 (Smithfield A0), 90nm
on PentiumD host. ... Huh ?
My cpuid config at he moment is:
# Downgrade the cpuid to make a better compatibility for migration
cpuid =
['0:eax=0x00000005,ebx=0x756e6547,ecx=0x6c65746e,edx=0x49656e69',
#ok
'1:eax=0x00000f44,ebx=0x00020800,ecx=xxxxxxxx1xx00xxxxxxxxx0xxxxxxxx0,edx=xxxxxxxxxxx0xxxxx0x0xxxx0xxxxxxx'
, #ecx=0x0000641d,edx=0xbfebfbff
'2:eax=0x605b5101,ebx=0x00000000,ecx=0x00000000,edx=0x007c7040', #ok
'3:eax=0x00000000,ebx=0x00000000,ecx=0x00000000,edx=0x00000000', #ok
#
'4:eax=0x04000121,ebx=0x01c0003f,ecx=0x0000001f,edx=0x00000000',#crash
during boot
'5:eax=0x00000040,ebx=0x00000040,ecx=0x00000000,edx=0x00000000', #ok
'0x80000000:eax=0x80000008,ebx=0x0,ecx=0x0,edx=0x0',
'0x80000001:eax=0x00000000,ebx=0x00000000,ecx=0x00000000,edx=0x0',#edx=0x20000800
'0x80000002:eax=0x20202020,ebx=0x20202020,ecx=0x20202020,edx=0x6e492020',
'0x80000003:eax=0x286c6574,ebx=0x50202952,ecx=0x69746e65,edx=0x52286d75',
'0x80000004:eax=0x20442029,ebx=0x20555043,ecx=0x30382e32,edx=0x007a4847',
'0x80000005:eax=0x00000000,ebx=0x00000000,ecx=0x00000000,edx=0x00000000',
'0x80000006:eax=0x00000000,ebx=0x00000000,ecx=0x04006040,edx=0x00000000',
'0x80000007:eax=0x00000000,ebx=0x00000000,ecx=0x00000000,edx=0x00000000',
'0x80000008:eax=0x00003024,ebx=0x00000000,ecx=0x00000000,edx=0x00000000']
regards,
Sam
On 01/03/2011 06:11 PM, Thomas Halinka wrote:
> Hi,
>
> its just works fine with pvm. I needed this Feature for running F11-PVM
> under XEN 4.01 - pvops and suse-kernel.
>
> Could your post your corresponding line from domu.cfg?
>
> tia,
>
> thomas
>
> Am Montag, den 03.01.2011, 17:24 +0100 schrieb Samuel Kvasnica:
>> Hello,
>>
>> I got into troubles with the live migration of a Xen domU pvm running a
>> java application.
>>
>> There are 2 host systems. One is a newer Xeon3450 system, the other one
>> is a 2-core PentiumD.
>> Both are running xenified 2.6.34.7 kernel, xen is 4.0.1. If the java
>> application was initially started
>> when domU is located on weaker node, i.e. PentiumD, it can be
>> sucessfully migrated back and forth.
>> But if the application was first started when on newer Xeon node, jvm
>> will crash with internal invalid instruction
>> error while migrating to PentiumD.
>>
>> That seems like java jit compiler is performing some
>> cpu-code-optimizations which are based
>> on cpu model/features determined upon jvm start. (Unfortunately there
>> does not seem to be any explicit option
>> to disable such optimization or select particular cpu model).
>>
>> Given this conclusion, I started to tweak the cpuid settings in domU
>> config. I managed to get
>> a common subset of cpu features for both nodes. These are visible in
>> /proc/cpuinfo on both nodes
>> and seem to be correct.
>> However, jvm will still crash in course of migration, so it seems like
>> the cpuid does not really work
>> on low level.
>>
>> Indeed, I tried the cpuid utility:
>> http://www.etallen.com/cpuid.html
>> and it reports real cpu model/features independent what do I set in
>> cpuid config !
>>
>> Whats wrong here ? Is cpuid not supposed to work in paravirt domain ?
>> Are cpuid registers not really emulated ?
>>
>>
>> best regards,
>>
>> Sam
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|