[Qemu-devel] regression between 0.12.1.2 and 0.12.2

[Qemu-devel] regression between 0.12.1.2 and 0.12.2

[Toralf Förster]

Hi,

under a mostly stable Gentoo I observed this new msg :

tfoerste@n22 ~/virtual/kvm $ qemu -hda gentoo_kdevm.img -hdb portage_kdeprefix.img -hdd swap.img -smp 2 -m 768 -vga std -soundhw es1370                                                                                           
BUG: kvm_dirty_pages_log_enable_slot: invalid parameters                                                         
BUG: kvm_dirty_pages_log_disable_slot: invalid parameters                                                        
..

The kvm image can be derived from http://dev.gentooexperimental.org/~wired/kvm/ .

My system is a :
tfoerste@n22 ~/virtual/kvm $ uname -a
Linux n22 2.6.32.4 #1 SMP Mon Jan 18 20:20:38 CET 2010 i686 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux


-- 
MfG/Sincerely
Toralf Förster

[Qemu-devel] Re: regression between 0.12.1.2 and 0.12.2

[Jan Kiszka]

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

Toralf Förster wrote:
> Hi,
> 
> under a mostly stable Gentoo I observed this new msg :
> 
> tfoerste@n22 ~/virtual/kvm $ qemu -hda gentoo_kdevm.img -hdb portage_kdeprefix.img -hdd swap.img -smp 2 -m 768 -vga std -soundhw es1370                                                                                           
> BUG: kvm_dirty_pages_log_enable_slot: invalid parameters                                                         
> BUG: kvm_dirty_pages_log_disable_slot: invalid parameters                                                        
> ..
> 
> The kvm image can be derived from http://dev.gentooexperimental.org/~wired/kvm/ .
> 
> My system is a :
> tfoerste@n22 ~/virtual/kvm $ uname -a
> Linux n22 2.6.32.4 #1 SMP Mon Jan 18 20:20:38 CET 2010 i686 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux
> 
> 

That's a pre-0.12.1.2 qemu-kvm issue, upstream is not affected - or is
at least not reporting it. It's already in my todo queue, just waiting
to be dequeued.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

[Qemu-devel] Re: regression between 0.12.1.2 and 0.12.2

[Jan Kiszka]

Jan Kiszka wrote:
> Toralf Förster wrote:
>> Hi,
>>
>> under a mostly stable Gentoo I observed this new msg :
>>
>> tfoerste@n22 ~/virtual/kvm $ qemu -hda gentoo_kdevm.img -hdb portage_kdeprefix.img -hdd swap.img -smp 2 -m 768 -vga std -soundhw es1370                                                                                           
>> BUG: kvm_dirty_pages_log_enable_slot: invalid parameters                                                         
>> BUG: kvm_dirty_pages_log_disable_slot: invalid parameters                                                        
>> ..
>>
>> The kvm image can be derived from http://dev.gentooexperimental.org/~wired/kvm/ .
>>
>> My system is a :
>> tfoerste@n22 ~/virtual/kvm $ uname -a
>> Linux n22 2.6.32.4 #1 SMP Mon Jan 18 20:20:38 CET 2010 i686 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux
>>
>>
> 
> That's a pre-0.12.1.2 qemu-kvm issue, upstream is not affected - or is
> at least not reporting it. It's already in my todo queue, just waiting
> to be dequeued.

I've looked into this a bit, and the bug message that pops up is in fact
new for your scenario (0.12.1.2->0.12.2, -vga std), it just happens to
trigger for me as well in a slightly different setup (CONFIG_FB_CIRRUS).

This is "mostly harmless" (the bug is gracefully handled), indicating
that qemu-kvm tries to enable/disable dirty logging for a VGA memory
area that was just unregistered. And that is because qemu-kvm tries to
keep support for old host kernels that had bugs and required workaround
approaches, but that code is bit-rotting a bit.

Avi, we should get rid of these messages, either by suppressing them in
qemu-kvm for now (stick your head into the sand...) or by finally
dropping all those dirty-logging diffs to upstream (in theory, there is
a third option: fixing the workaround code, but I don't think it's worth
the effort). What could be a road map for dropping? What distro kernels
are you aware of that may become unusable then?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux