[Qemu-devel] Live Migration of 32-bit Linux guest broken since 2.6.32-rc2

[Qemu-devel] Live Migration of 32-bit Linux guest broken since 2.6.32-rc2

[Peter Lieven]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

Hi,

I freshly installed kernel 2.6.32-rc2 using userspace qemu-kvm 0.12.4.

When I live migrate a 32-bit opensuse-11.2 VM, the incoming VM shows
the following error after the mem transfer has finished:

kvm: unhandled exit 80000022
kvm: kvm_run returned -22

cmdline:
/usr/bin/qemu-kvm-0.12.4  -net none  -drive format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-e1861b105-4cb000e7e8c4bf3b-opensuse-11-2-i586,if=ide,boot=on,cache=none,aio=native  -m 1024 -monitor tcp:0:4003,server,nowait -vnc :3 -name 'opensuse-11.2-i586'  -boot order=dc,menu=on  -k de  -incoming tcp:172.21.55.20:5003  -pidfile /var/run/qemu/vm-154.pid  -mem-path /hugepages -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -cpu qemu64,model_id='Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz'

Migrating the same VM worked with 2.6.34 kvm module.

Thanks,
Peter


[-- Attachment #2: Type: text/html, Size: 1371 bytes --]

[Qemu-devel] Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Peter Lieven]

sorry, the subject should read 2.6.35-rc2

Peter Lieven wrote:
> Hi,
>
> I freshly installed kernel 2.6.35-rc2 using userspace qemu-kvm 0.12.4.
>
> When I live migrate a 32-bit opensuse-11.2 VM, the incoming VM shows
> the following error after the mem transfer has finished:
>
> kvm: unhandled exit 80000022
> kvm: kvm_run returned -22
>
> cmdline:
> /usr/bin/qemu-kvm-0.12.4  -net none  -drive format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-e1861b105-4cb000e7e8c4bf3b-opensuse-11-2-i586,if=ide,boot=on,cache=none,aio=native  -m 1024 -monitor tcp:0:4003,server,nowait -vnc :3 -name 'opensuse-11.2-i586'  -boot order=dc,menu=on  -k de  -incoming tcp:172.21.55.20:5003  -pidfile /var/run/qemu/vm-154.pid  -mem-path /hugepages -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -cpu qemu64,model_id='Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz'
>
> Migrating the same VM worked with 2.6.34 kvm module.
>
> Thanks,
> Peter
>
>
>   

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Avi Kivity]

On 06/08/2010 12:13 PM, Peter Lieven wrote:
> sorry, the subject should read 2.6.35-rc2
>
> Peter Lieven wrote:
>> Hi,
>>
>> I freshly installed kernel 2.6.35-rc2 using userspace qemu-kvm 0.12.4.
>>
>> When I live migrate a 32-bit opensuse-11.2 VM, the incoming VM shows
>> the following error after the mem transfer has finished:
>>
>> kvm: unhandled exit 80000022
>> kvm: kvm_run returned -22
>>
>> cmdline:
>> /usr/bin/qemu-kvm-0.12.4  -net none  -drive 
>> format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-e1861b105-4cb000e7e8c4bf3b-opensuse-11-2-i586,if=ide,boot=on,cache=none,aio=native  
>> -m 1024 -monitor tcp:0:4003,server,nowait -vnc :3 -name 
>> 'opensuse-11.2-i586'  -boot order=dc,menu=on  -k de  -incoming 
>> tcp:172.21.55.20:5003  -pidfile /var/run/qemu/vm-154.pid  -mem-path 
>> /hugepages -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -cpu 
>> qemu64,model_id='Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz'
>>
>> Migrating the same VM worked with 2.6.34 kvm module.


Please provide you host /proc/cpuinfo.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Avi Kivity]

On 06/08/2010 02:29 PM, Avi Kivity wrote:
> On 06/08/2010 12:13 PM, Peter Lieven wrote:
>> sorry, the subject should read 2.6.35-rc2
>>
>> Peter Lieven wrote:
>>> Hi,
>>>
>>> I freshly installed kernel 2.6.35-rc2 using userspace qemu-kvm 0.12.4.
>>>
>>> When I live migrate a 32-bit opensuse-11.2 VM, the incoming VM shows
>>> the following error after the mem transfer has finished:
>>>
>>> kvm: unhandled exit 80000022
>>> kvm: kvm_run returned -22
>>>
>>> cmdline:
>>> /usr/bin/qemu-kvm-0.12.4  -net none  -drive 
>>> format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-e1861b105-4cb000e7e8c4bf3b-opensuse-11-2-i586,if=ide,boot=on,cache=none,aio=native  
>>> -m 1024 -monitor tcp:0:4003,server,nowait -vnc :3 -name 
>>> 'opensuse-11.2-i586'  -boot order=dc,menu=on  -k de  -incoming 
>>> tcp:172.21.55.20:5003  -pidfile /var/run/qemu/vm-154.pid  -mem-path 
>>> /hugepages -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -cpu 
>>> qemu64,model_id='Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz'
>>>
>>> Migrating the same VM worked with 2.6.34 kvm module.
>
>
> Please provide you host /proc/cpuinfo.
>

Also, after migration fails, the output of 'info registers' in the monitor.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Avi Kivity]

On 06/08/2010 02:31 PM, Avi Kivity wrote:
> On 06/08/2010 02:29 PM, Avi Kivity wrote:
>> On 06/08/2010 12:13 PM, Peter Lieven wrote:
>>> sorry, the subject should read 2.6.35-rc2
>>>
>>> Peter Lieven wrote:
>>>> Hi,
>>>>
>>>> I freshly installed kernel 2.6.35-rc2 using userspace qemu-kvm 0.12.4.
>>>>
>>>> When I live migrate a 32-bit opensuse-11.2 VM, the incoming VM shows
>>>> the following error after the mem transfer has finished:
>>>>
>>>> kvm: unhandled exit 80000022
>>>> kvm: kvm_run returned -22
>>>>
>>>> cmdline:
>>>> /usr/bin/qemu-kvm-0.12.4  -net none  -drive 
>>>> format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-e1861b105-4cb000e7e8c4bf3b-opensuse-11-2-i586,if=ide,boot=on,cache=none,aio=native  
>>>> -m 1024 -monitor tcp:0:4003,server,nowait -vnc :3 -name 
>>>> 'opensuse-11.2-i586'  -boot order=dc,menu=on  -k de  -incoming 
>>>> tcp:172.21.55.20:5003  -pidfile /var/run/qemu/vm-154.pid  -mem-path 
>>>> /hugepages -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -cpu 
>>>> qemu64,model_id='Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz'
>>>>
>>>> Migrating the same VM worked with 2.6.34 kvm module.
>>
>>
>> Please provide you host /proc/cpuinfo.
>>
>
> Also, after migration fails, the output of 'info registers' in the 
> monitor.
>

And finally, perhaps you have NX disabled in the bios of one of the 
machines?

What does 'dmesg | grep NX' show on both hosts?

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Peter Lieven]

Avi Kivity wrote:
> On 06/08/2010 02:31 PM, Avi Kivity wrote:
>> On 06/08/2010 02:29 PM, Avi Kivity wrote:
>>> On 06/08/2010 12:13 PM, Peter Lieven wrote:
>>>> sorry, the subject should read 2.6.35-rc2
>>>>
>>>> Peter Lieven wrote:
>>>>> Hi,
>>>>>
>>>>> I freshly installed kernel 2.6.35-rc2 using userspace qemu-kvm 
>>>>> 0.12.4.
>>>>>
>>>>> When I live migrate a 32-bit opensuse-11.2 VM, the incoming VM shows
>>>>> the following error after the mem transfer has finished:
>>>>>
>>>>> kvm: unhandled exit 80000022
>>>>> kvm: kvm_run returned -22
>>>>>
>>>>> cmdline:
>>>>> /usr/bin/qemu-kvm-0.12.4  -net none  -drive 
>>>>> format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-e1861b105-4cb000e7e8c4bf3b-opensuse-11-2-i586,if=ide,boot=on,cache=none,aio=native  
>>>>> -m 1024 -monitor tcp:0:4003,server,nowait -vnc :3 -name 
>>>>> 'opensuse-11.2-i586'  -boot order=dc,menu=on  -k de  -incoming 
>>>>> tcp:172.21.55.20:5003  -pidfile /var/run/qemu/vm-154.pid  
>>>>> -mem-path /hugepages -mem-prealloc  -rtc base=utc -usb -usbdevice 
>>>>> tablet -cpu qemu64,model_id='Intel(R) Xeon(R) CPU           E5430  
>>>>> @ 2.66GHz'
>>>>>
>>>>> Migrating the same VM worked with 2.6.34 kvm module.
>>>
>>>
>>> Please provide you host /proc/cpuinfo.
>>>
>>
>> Also, after migration fails, the output of 'info registers' in the 
>> monitor.
>>
>
> And finally, perhaps you have NX disabled in the bios of one of the 
> machines?
>
> What does 'dmesg | grep NX' show on both hosts?
>
nx was disabled on one of the nodes. i will retry the case later today 
and send info register output.
what is the recommended value for nx (and why)?
and why was it working with 2.6.34 and is not with 2.6.35-rc2?





-- 
Mit freundlichen Grüßen/Kind Regards

Peter Lieven

..........................................................................................................

   KAMP Netzwerkdienste GmbH
   Vestische Str. 89-91 | 46117 Oberhausen
   Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
   mailto:pl@kamp.de | http://www.kamp.de

   Geschäftsführer: Heiner Lante | Michael Lante
   Amtsgericht Duisburg | HRB Nr. 12154
   USt-Id-Nr.: DE 120607556

......................................................................................................... 

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Avi Kivity]

On 06/08/2010 03:49 PM, Peter Lieven wrote:
>>
>> And finally, perhaps you have NX disabled in the bios of one of the 
>> machines?
>>
>> What does 'dmesg | grep NX' show on both hosts?
>>
>
> nx was disabled on one of the nodes. 

That explains the problem.

> i will retry the case later today and send info register output.
> what is the recommended value for nx (and why)?

Enabled (so you get no-execute memory protection).

> and why was it working with 2.6.34 and is not with 2.6.35-rc2?

We fixed a different bug.  But you shouldn't live migrate from a machine 
with nx to a machine without nx, unless you use -cpu ...,-nx on both nodes.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Peter Lieven]

Avi Kivity wrote:
> On 06/08/2010 03:49 PM, Peter Lieven wrote:
>>>
>>> And finally, perhaps you have NX disabled in the bios of one of the 
>>> machines?
>>>
>>> What does 'dmesg | grep NX' show on both hosts?
>>>
>>
>> nx was disabled on one of the nodes. 
>
> That explains the problem.
>
>> i will retry the case later today and send info register output.
>> what is the recommended value for nx (and why)?
>
> Enabled (so you get no-execute memory protection).
mhh, i am at the moment back to 2.6.34. here i do not see the nx flag in 
the guest
of both 32-bit and 64-bit linux.
>
>> and why was it working with 2.6.34 and is not with 2.6.35-rc2?
>
> We fixed a different bug.  But you shouldn't live migrate from a 
> machine with nx to a machine without nx, unless you use -cpu ...,-nx 
> on both nodes.
>


-- 
Mit freundlichen Grüßen/Kind Regards

Peter Lieven

..........................................................................................................

   KAMP Netzwerkdienste GmbH
   Vestische Str. 89-91 | 46117 Oberhausen
   Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
   mailto:pl@kamp.de | http://www.kamp.de

   Geschäftsführer: Heiner Lante | Michael Lante
   Amtsgericht Duisburg | HRB Nr. 12154
   USt-Id-Nr.: DE 120607556

......................................................................................................... 

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Peter Lieven]

Avi Kivity wrote:
> On 06/08/2010 03:49 PM, Peter Lieven wrote:
>>>
>>> And finally, perhaps you have NX disabled in the bios of one of the 
>>> machines?
>>>
>>> What does 'dmesg | grep NX' show on both hosts?
>>>
>>
>> nx was disabled on one of the nodes. 
>
> That explains the problem.
>
>> i will retry the case later today and send info register output.
>> what is the recommended value for nx (and why)?
>
> Enabled (so you get no-execute memory protection).
do you have a guideline which flags should be identical to ensure proper 
live migration?
i would like to do an automatic compare before life migration to avoid 
crashes.

thanks
peter

>
>> and why was it working with 2.6.34 and is not with 2.6.35-rc2?
>
> We fixed a different bug.  But you shouldn't live migrate from a 
> machine with nx to a machine without nx, unless you use -cpu ...,-nx 
> on both nodes.
>


-- 
Mit freundlichen Grüßen/Kind Regards

Peter Lieven

..........................................................................................................

   KAMP Netzwerkdienste GmbH
   Vestische Str. 89-91 | 46117 Oberhausen
   Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
   mailto:pl@kamp.de | http://www.kamp.de

   Geschäftsführer: Heiner Lante | Michael Lante
   Amtsgericht Duisburg | HRB Nr. 12154
   USt-Id-Nr.: DE 120607556

......................................................................................................... 

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Avi Kivity]

On 06/08/2010 04:28 PM, Peter Lieven wrote:
>>
>>> i will retry the case later today and send info register output.
>>> what is the recommended value for nx (and why)?
>>
>> Enabled (so you get no-execute memory protection).
>
> do you have a guideline which flags should be identical to ensure 
> proper live migration?
> i would like to do an automatic compare before life migration to avoid 
> crashes.

All of them [1].  If you have an asymmetric machine, you can disable 
those flags with the -cpu switch.

Note the default qemu cpu disables many flags, so if one machine has 
sse4.2 and the other doesn't, migration will still work without 
disabling anything.


[1] Rather, all flags understood by qemu and kvm that are enabled by the 
cpu model that you gave to qemu with -cpu.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Peter Lieven]

Avi Kivity wrote:
> On 06/08/2010 04:28 PM, Peter Lieven wrote:
>>>
>>>> i will retry the case later today and send info register output.
>>>> what is the recommended value for nx (and why)?
>>>
>>> Enabled (so you get no-execute memory protection).
>>
>> do you have a guideline which flags should be identical to ensure 
>> proper live migration?
>> i would like to do an automatic compare before life migration to 
>> avoid crashes.
>
> All of them [1].  If you have an asymmetric machine, you can disable 
> those flags with the -cpu switch.
>
> Note the default qemu cpu disables many flags, so if one machine has 
> sse4.2 and the other doesn't, migration will still work without 
> disabling anything.
which cpu model do you suggest for 4 core xeon cpus? -cpu host ?

how important is the match of the virtualization extensions?

thanks,
peter

>
>
> [1] Rather, all flags understood by qemu and kvm that are enabled by 
> the cpu model that you gave to qemu with -cpu.
>


-- 
Mit freundlichen Grüßen/Kind Regards

Peter Lieven

..........................................................................................................

   KAMP Netzwerkdienste GmbH
   Vestische Str. 89-91 | 46117 Oberhausen
   Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
   mailto:pl@kamp.de | http://www.kamp.de

   Geschäftsführer: Heiner Lante | Michael Lante
   Amtsgericht Duisburg | HRB Nr. 12154
   USt-Id-Nr.: DE 120607556

......................................................................................................... 

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Avi Kivity]

On 06/08/2010 04:38 PM, Peter Lieven wrote:
> Avi Kivity wrote:
>> On 06/08/2010 04:28 PM, Peter Lieven wrote:
>>>>
>>>>> i will retry the case later today and send info register output.
>>>>> what is the recommended value for nx (and why)?
>>>>
>>>> Enabled (so you get no-execute memory protection).
>>>
>>> do you have a guideline which flags should be identical to ensure 
>>> proper live migration?
>>> i would like to do an automatic compare before life migration to 
>>> avoid crashes.
>>
>> All of them [1].  If you have an asymmetric machine, you can disable 
>> those flags with the -cpu switch.
>>
>> Note the default qemu cpu disables many flags, so if one machine has 
>> sse4.2 and the other doesn't, migration will still work without 
>> disabling anything.
> which cpu model do you suggest for 4 core xeon cpus? -cpu host ?

-cpu host is good if you have identical machines and don't plan to add 
new ones.

> how important is the match of the virtualization extensions?

The virtualization extensions on Intel aren't exposed to the guest, so 
they don't need to match.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Peter Lieven]

Avi Kivity wrote:
> On 06/08/2010 04:38 PM, Peter Lieven wrote:
>> Avi Kivity wrote:
>>> On 06/08/2010 04:28 PM, Peter Lieven wrote:
>>>>>
>>>>>> i will retry the case later today and send info register output.
>>>>>> what is the recommended value for nx (and why)?
>>>>>
>>>>> Enabled (so you get no-execute memory protection).
>>>>
>>>> do you have a guideline which flags should be identical to ensure 
>>>> proper live migration?
>>>> i would like to do an automatic compare before life migration to 
>>>> avoid crashes.
>>>
>>> All of them [1].  If you have an asymmetric machine, you can disable 
>>> those flags with the -cpu switch.
>>>
>>> Note the default qemu cpu disables many flags, so if one machine has 
>>> sse4.2 and the other doesn't, migration will still work without 
>>> disabling anything.
>> which cpu model do you suggest for 4 core xeon cpus? -cpu host ?
>
> -cpu host is good if you have identical machines and don't plan to add 
> new ones.
i will likely add new ones, but my plan would be to use qemu64 and then 
add all flags manually that
are common to all cpus in the pool.
would that be safe?

br,
peter

>
>> how important is the match of the virtualization extensions?
>
> The virtualization extensions on Intel aren't exposed to the guest, so 
> they don't need to match.
>


-- 
Mit freundlichen Grüßen/Kind Regards

Peter Lieven

..........................................................................................................

   KAMP Netzwerkdienste GmbH
   Vestische Str. 89-91 | 46117 Oberhausen
   Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
   mailto:pl@kamp.de | http://www.kamp.de

   Geschäftsführer: Heiner Lante | Michael Lante
   Amtsgericht Duisburg | HRB Nr. 12154
   USt-Id-Nr.: DE 120607556

......................................................................................................... 

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Avi Kivity]

On 06/08/2010 04:44 PM, Peter Lieven wrote:
>> -cpu host is good if you have identical machines and don't plan to 
>> add new ones.
>
> i will likely add new ones, but my plan would be to use qemu64 and 
> then add all flags manually that
> are common to all cpus in the pool.
> would that be safe?

Yes.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Peter Lieven]

Avi Kivity wrote:
> On 06/08/2010 04:44 PM, Peter Lieven wrote:
>>> -cpu host is good if you have identical machines and don't plan to 
>>> add new ones.
>>
>> i will likely add new ones, but my plan would be to use qemu64 and 
>> then add all flags manually that
>> are common to all cpus in the pool.
>> would that be safe?
>
> Yes.
>
2 last questions:

a) i remember that there (have been) are instructions that have a high 
virtualization penalty.
are there flags that should better not be offered to a VM?

b) you told you fixed another bug in 2.6.35. is the nx virtualization 
not working in guests
before 2.6.35 and therefore my case worked with 2.6.34?

thanks
peter

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Avi Kivity]

On 06/09/2010 11:29 AM, Peter Lieven wrote:
> Avi Kivity wrote:
>> On 06/08/2010 04:44 PM, Peter Lieven wrote:
>>>> -cpu host is good if you have identical machines and don't plan to 
>>>> add new ones.
>>>
>>> i will likely add new ones, but my plan would be to use qemu64 and 
>>> then add all flags manually that
>>> are common to all cpus in the pool.
>>> would that be safe?
>>
>> Yes.
>>
> 2 last questions:
>
> a) i remember that there (have been) are instructions that have a high 
> virtualization penalty.
> are there flags that should better not be offered to a VM?

Not that I know of.

> b) you told you fixed another bug in 2.6.35. is the nx virtualization 
> not working in guests
> before 2.6.35 and therefore my case worked with 2.6.34?

On 2.6.34, your guest lost nx protection after migration.  On 2.6.35, it 
died.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Gleb Natapov]

On Wed, Jun 09, 2010 at 06:08:23PM +0300, Avi Kivity wrote:
> On 06/09/2010 11:29 AM, Peter Lieven wrote:
> >Avi Kivity wrote:
> >>On 06/08/2010 04:44 PM, Peter Lieven wrote:
> >>>>-cpu host is good if you have identical machines and don't
> >>>>plan to add new ones.
> >>>
> >>>i will likely add new ones, but my plan would be to use qemu64
> >>>and then add all flags manually that
> >>>are common to all cpus in the pool.
> >>>would that be safe?
> >>
> >>Yes.
> >>
> >2 last questions:
> >
> >a) i remember that there (have been) are instructions that have a
> >high virtualization penalty.
> >are there flags that should better not be offered to a VM?
> 
> Not that I know of.
> 
rdtscp? I think it's always emulated.

--
			Gleb.

[Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Avi Kivity]

On 06/09/2010 06:12 PM, Gleb Natapov wrote:
>
>>> a) i remember that there (have been) are instructions that have a
>>> high virtualization penalty.
>>> are there flags that should better not be offered to a VM?
>>>        
>> Not that I know of.
>>
>>      
> rdtscp? I think it's always emulated.
>    

No, it executes natively.  It does increase the msr switching cost since 
we need to switch MSR_TSC_AUX in addition.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Re: Live Migration of 32-bit Linux guest broken since 2.6.35-rc2

[Peter Lieven]

Avi Kivity wrote:
> On 06/08/2010 12:13 PM, Peter Lieven wrote:
>> sorry, the subject should read 2.6.35-rc2
>>
>> Peter Lieven wrote:
>>> Hi,
>>>
>>> I freshly installed kernel 2.6.35-rc2 using userspace qemu-kvm 0.12.4.
>>>
>>> When I live migrate a 32-bit opensuse-11.2 VM, the incoming VM shows
>>> the following error after the mem transfer has finished:
>>>
>>> kvm: unhandled exit 80000022
>>> kvm: kvm_run returned -22
>>>
>>> cmdline:
>>> /usr/bin/qemu-kvm-0.12.4  -net none  -drive 
>>> format=host_device,file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-e1861b105-4cb000e7e8c4bf3b-opensuse-11-2-i586,if=ide,boot=on,cache=none,aio=native  
>>> -m 1024 -monitor tcp:0:4003,server,nowait -vnc :3 -name 
>>> 'opensuse-11.2-i586'  -boot order=dc,menu=on  -k de  -incoming 
>>> tcp:172.21.55.20:5003  -pidfile /var/run/qemu/vm-154.pid  -mem-path 
>>> /hugepages -mem-prealloc  -rtc base=utc -usb -usbdevice tablet -cpu 
>>> qemu64,model_id='Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz'
>>>
>>> Migrating the same VM worked with 2.6.34 kvm module.
>
>
> Please provide you host /proc/cpuinfo.
>
#cat /proc/cpuinfo
processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 26
model name    : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
stepping    : 5
cpu MHz        : 2261.168
cache size    : 8192 KB
physical id    : 1
siblings    : 4
core id        : 0
cpu cores    : 4
apicid        : 16
initial apicid    : 16
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology 
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority 
ept vpid
bogomips    : 4522.33
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

processor    : 1
vendor_id    : GenuineIntel
cpu family    : 6
model        : 26
model name    : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
stepping    : 5
cpu MHz        : 2261.168
cache size    : 8192 KB
physical id    : 0
siblings    : 4
core id        : 0
cpu cores    : 4
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology 
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority 
ept vpid
bogomips    : 4521.29
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

processor    : 2
vendor_id    : GenuineIntel
cpu family    : 6
model        : 26
model name    : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
stepping    : 5
cpu MHz        : 2261.168
cache size    : 8192 KB
physical id    : 1
siblings    : 4
core id        : 1
cpu cores    : 4
apicid        : 18
initial apicid    : 18
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology 
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority 
ept vpid
bogomips    : 4521.27
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

processor    : 3
vendor_id    : GenuineIntel
cpu family    : 6
model        : 26
model name    : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
stepping    : 5
cpu MHz        : 2261.168
cache size    : 8192 KB
physical id    : 0
siblings    : 4
core id        : 1
cpu cores    : 4
apicid        : 2
initial apicid    : 2
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology 
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority 
ept vpid
bogomips    : 4521.29
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

processor    : 4
vendor_id    : GenuineIntel
cpu family    : 6
model        : 26
model name    : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
stepping    : 5
cpu MHz        : 2261.168
cache size    : 8192 KB
physical id    : 1
siblings    : 4
core id        : 2
cpu cores    : 4
apicid        : 20
initial apicid    : 20
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology 
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority 
ept vpid
bogomips    : 4521.27
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

processor    : 5
vendor_id    : GenuineIntel
cpu family    : 6
model        : 26
model name    : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
stepping    : 5
cpu MHz        : 2261.168
cache size    : 8192 KB
physical id    : 0
siblings    : 4
core id        : 2
cpu cores    : 4
apicid        : 4
initial apicid    : 4
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology 
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority 
ept vpid
bogomips    : 4521.29
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

processor    : 6
vendor_id    : GenuineIntel
cpu family    : 6
model        : 26
model name    : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
stepping    : 5
cpu MHz        : 2261.168
cache size    : 8192 KB
physical id    : 1
siblings    : 4
core id        : 3
cpu cores    : 4
apicid        : 22
initial apicid    : 22
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology 
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority 
ept vpid
bogomips    : 4521.27
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

processor    : 7
vendor_id    : GenuineIntel
cpu family    : 6
model        : 26
model name    : Intel(R) Xeon(R) CPU           E5520  @ 2.27GHz
stepping    : 5
cpu MHz        : 2261.168
cache size    : 8192 KB
physical id    : 0
siblings    : 4
core id        : 3
cpu cores    : 4
apicid        : 6
initial apicid    : 6
fpu        : yes
fpu_exception    : yes
cpuid level    : 11
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology 
nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority 
ept vpid
bogomips    : 4521.29
clflush size    : 64
cache_alignment    : 64
address sizes    : 40 bits physical, 48 bits virtual
power management:

dest: