Bug 962749 - Guest didn't load the vmmouse driver after 'system-reset' by hmp.
Guest didn't load the vmmouse driver after 'system-reset' by hmp.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.0
Unspecified Unspecified
low Severity medium
: rc
: ---
Assigned To: Gerd Hoffmann
Virtualization Bugs
:
Depends On: 954261 962733 1272311 1272312 1293233
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-14 07:30 EDT by Qian Guo
Modified: 2017-03-14 09:42 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-03-14 09:42:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xlog.* of the guest (29.25 KB, application/x-gzip)
2013-05-14 07:30 EDT, Qian Guo
no flags Details
Log after reboot guest (68.62 KB, text/plain)
2013-05-14 07:32 EDT, Qian Guo
no flags Details

  None (edit)
Description Qian Guo 2013-05-14 07:30:42 EDT
Created attachment 747650 [details]
Xlog.* of the guest

Description of problem:
Guest will out of control when test UDP_STREAM w/o vhost=on (bug #962733), and if try 'system-reset' by hmp, after bootup, the mouse can not used, from guest, found this info:
# vmmouse_detect ; echo $?
1


Version-Release number of selected component (if applicable):
# uname -r
3.9.0-0.55.el7.x86_64
# rpm -q qemu-kvm
qemu-kvm-1.4.0-4.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Boot guest w/ GUI, and after boot up check the mice:
# /usr/libexec/qemu-kvm -M pc  -enable-kvm -m 4096 -smp 4,sockets=1,cores=4,threads=1 -name rhel7  -drive file=/home/rhel7cp1.qcow3,if=none,id=drive-ide1-1-0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=threads -device ide-drive,bus=ide.1,drive=drive-ide1-1-0,id=ide1-1-0  -vnc :10 -vga qxl  -monitor stdio -nodefaults -nodefconfig -device virtio-balloon-pci,id=balloon1  -netdev tap,id=netdev1,script=/etc/qemu-ifup -device virtio-net-pci,netdev=netdev1,id=vnic1,mac=54:52:1a:23:0b:01

(qemu) info mice
  Mouse #0: QEMU PS/2 Mouse
* Mouse #1: vmmouse (absolute)

---
In guest,
guest# vmmouse_detect ; echo $?
0



2.Under hmp, do 'system-reset'

3.After reboot, check the mouse

Actual results:
(qemu) info mice
* Mouse #0: QEMU PS/2 Mouse

In guest:
# vmmouse_detect ; echo $?
1

Expected results:
After system-reset, should be

# vmmouse_detect ; echo $?
0

Additional info:

1.Will attach the Xorg log of the guest.
2.since after guest hang, there's no log in /var/log/messages, so will just attach the logs after reboot.
3.From Bug #962733, if wait for the response of the guest, after resume, will got logs as:
...
May 14 06:41:08 unused kernel: [  117.164075] psmouse serio1: Explorer Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
May 14 06:41:08 unused kernel: [  117.195621] psmouse serio1: resync failed, issuing reconnect request

....

Hope is helpful.
Comment 1 Qian Guo 2013-05-14 07:32:22 EDT
Created attachment 747654 [details]
Log after reboot guest
Comment 3 Hai Huang 2013-05-20 14:51:01 EDT
There is a workaround posted in BZ 907016 for Fedora 18:
  https://bugzilla.redhat.com/show_bug.cgi?id=907016
that causes a rescan of the device after each resume.
Comment 4 Paolo Bonzini 2013-05-22 05:30:29 EDT
We should disable vmmouse/vmport, see bug 616187.

That was done with RHEL-only patches.  The infrastructure to do dynamic probing of devices should now be upstream, but right now removing CONFIG_VMMOUSE/CONFIG_VMPORT gives:

$ x86_64-softmmu/qemu-system-x86_64
qemu-system-x86_64: Unknown device 'vmport' for bus 'ISA'
Annullato (core dumped)
Comment 5 Paolo Bonzini 2013-05-22 05:58:11 EDT
Oops:

commit e451e54c46ead55cc179d37d0410ab6f41b0cc00
Author: Eduardo Habkost <ehabkost@redhat.com>
Date:   Tue Feb 15 16:31:34 2011 -0200

    reenable CONFIG_VMMOUSE and CONFIG_VMPORT
    
    RH-Author: Eduardo Habkost <ehabkost@redhat.com>
    Message-id: <20110215163134.GF29153@otherpad.lan.raisama.net>
    Patchwork-id: 18223
    O-Subject: [RHEL6 qemu-kvm PATCH] reenable CONFIG_VMMOUSE and CONFIG_VMPORT
    Bugzilla: 677712

So we need them anyway for the 6.x machine types.
Comment 6 Gerd Hoffmann 2013-12-12 10:13:38 EST
Doesn't reproduce, please retest with latest qemu-kvm.
Comment 7 juzhang 2013-12-12 21:00:04 EST
(In reply to Gerd Hoffmann from comment #6)
> Doesn't reproduce, please retest with latest qemu-kvm.

Hi Qiguo,

Could you have a test and update the result in the bz?

Best Regards,
Junyi
Comment 8 Qian Guo 2013-12-16 04:56:45 EST
Reproduced by my side:

# uname -r
3.10.0-61.el7.x86_64
# rpm -q qemu-kvm
qemu-kvm-1.5.3-21.el7.x86_64

Steps:
1.Boot rhel7 guest:
# /usr/libexec/qemu-kvm -M pc  -enable-kvm -m 4096 -smp 4,sockets=1,cores=4,threads=1 -name rhel7  -drive file=/home/rhel7/rhel7.qcow3,if=none,id=drive-ide1-1-0,format=qcow2,werror=stop,rerror=stop,aio=threads -device ide-drive,bus=ide.1,drive=drive-ide1-1-0,id=ide1-1-0  -vnc :10 -vga qxl  -monitor stdio -nodefaults -nodefconfig -device virtio-balloon-pci,id=balloon1  -netdev tap,id=netdev1,script=/etc/qemu-ifup -device virtio-net-pci,netdev=netdev1,id=vnic1,mac=54:52:1a:23:0b:01

2.Inside guest do netperf UDP_STREAM test, at this time, the guest will hang (refer to bug #962733)

3.During the guest hanging, reboot guest via (qemu)system_reset

Result: after guest reboot up, the mouse is out of control, and from guest check the mouse
# vmmouse_detect ; echo $?
1
and from hmp:
(qemu) info mice
* Mouse #0: QEMU PS/2 Mouse


so this bug is reproduced.
Comment 9 Gerd Hoffmann 2013-12-16 06:15:38 EST
  Hi,

> 2.Inside guest do netperf UDP_STREAM test, at this time, the guest will hang
> (refer to bug #962733)

Where does this come from?  That isn't in the original report.
Is this needed to trigger the bug?
Comment 10 Qian Guo 2013-12-16 06:23:42 EST
In the description, I wrote this
> Description of problem:
> Guest will out of control when test UDP_STREAM w/o vhost=on (bug #962733),
> and if try 'system-reset' by hmp, after bootup, the mouse can not used, from
> guest, found this info:

the bug #962733 reports that the guest hangs.

sorry that not make so clear in this bug, hope this helps.

Thanks,
Comment 18 Gerd Hoffmann 2017-01-09 10:14:23 EST
Can you re-test whenever this still happens with 7.3 guests?

guest-side vmmouse handling has changed in 7.3 (uses a kernel driver now), so there is a chance this doesn't happen any more ...
Comment 19 juzhang 2017-01-09 20:58:18 EST
(In reply to Gerd Hoffmann from comment #18)
> Can you re-test whenever this still happens with 7.3 guests?
> 
> guest-side vmmouse handling has changed in 7.3 (uses a kernel driver now),
> so there is a chance this doesn't happen any more ...

Hi Zhiyi,

Could you handle this issue?

Best Regards,
Junyi
Comment 20 Guo, Zhiyi 2017-01-10 05:22:49 EST
Test against rhel7.3 host with kernel 3.10.0-514.el7.x86_64 and qemu-kvm-1.5.3-126.el7_3.3.x86_64, issue still can be reproduced.

The reproduce rate is 4/10.

Steps:
1. boot guest with cmd:
/usr/libexec/qemu-kvm -m 4096 -smp 4,sockets=1,cores=4,threads=1 -name rhel7 -drive file=/home/rhel7.3-create-user.qcow2,if=none,id=drive-ide1-1-0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=threads -device ide-drive,bus=ide.1,drive=drive-ide1-1-0,id=ide1-1-0 -vnc :0  -vga qxl  -monitor stdio -device virtio-balloon-pci,id=balloon1  -netdev tap,id=netdev1,script=/etc/qemu-ifup -device virtio-net-pci,netdev=netdev1,id=vnic1,mac=54:52:1a:23:0b:01 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -serial unix:/tmp/console,server,nowait

2.Query vmmouse device from guest and there are two vmmouse:
I: Bus=0011 Vendor=0002 Product=0012 Version=5868
N: Name="VirtualPS/2 VMware VMMouse"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input2
U: Uniq=
H: Handlers=mouse0 event2 
B: PROP=0
B: EV=b
B: KEY=70000 0 0 0 0
B: ABS=3

I: Bus=0011 Vendor=0002 Product=0012 Version=5868
N: Name="VirtualPS/2 VMware VMMouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input3
U: Uniq=
H: Handlers=mouse1 event3 
B: PROP=1
B: EV=7
B: KEY=30000 0 0 0 0
B: REL=103
 
Use a new xorg.conf to configure Xorg to use vmmouse and reboot, content example:
Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/devices/platform/i8042/serio1/input/input3"
        Option      "ZAxisMapping" "4 5 6 7"
EndSection

3. Execute "info mice" from hmp:
(qemu) info mice
  Mouse #0: QEMU PS/2 Mouse
* Mouse #1: vmmouse (absolute)


4. launch download netperf 2.7 and launch ./netserver from host
5. Do net perf test inside guest to interact with host netserver:
netperf -H host_ip -t UDP_STREAM -l 30
6. system_reset from hmp
7. reconnect to guest

Results:
After step 6, mouse cannot interact with guest.
Execute "info mice" from hmp, only ps/2 mouse there:
(qemu) info mice
* Mouse #0: QEMU PS/2 Mouse
(qemu) info mice
* Mouse #0: QEMU PS/2 Mouse

SSH to guest and recheck vmmouse device list, only one vmmouse left and it become to input2
Comment 21 Gerd Hoffmann 2017-01-10 06:30:13 EST
Hmm, I guess this means we'll go continue waiting for bug 962733 getting fixed.

Does this also happen with qemu-kvm-rhev?
Comment 22 Guo, Zhiyi 2017-01-10 22:28:40 EST
With the same steps, I really cannot reproduce this issue in 20 trials against qemu-kvm-rhev-2.6.0-28.el7_3.3.x86_64.

In vhost on/off, guest always response smooth after "netperf -H host_ip -t UDP_STREAM -l 30", and from my trial vmmouse always work.
During yesterday qemu-kvm test, vmmouse always work too without "netperf -H host_ip -t UDP_STREAM -l 30"
Comment 23 Gerd Hoffmann 2017-03-14 06:39:53 EDT
given that
  (a) customers apparently don't hit this (probably due to netperf test being
      needed to actually trigger this).
  (b) newer qemu versions seem not to be affected
I think we can consider closing this as wontfix.
areis?
Comment 24 Ademar Reis 2017-03-14 09:42:24 EDT
(In reply to Gerd Hoffmann from comment #23)
> given that
>   (a) customers apparently don't hit this (probably due to netperf test being
>       needed to actually trigger this).
>   (b) newer qemu versions seem not to be affected
> I think we can consider closing this as wontfix.
> areis?

Agree. Also, we don't support HMP.

Note You need to log in before you can comment on or make changes to this bug.