RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 962749 - Guest didn't load the vmmouse driver after 'system-reset' by hmp.
Summary: Guest didn't load the vmmouse driver after 'system-reset' by hmp.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 954261 962733 1272311 1272312 1293233
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-14 11:30 UTC by Qian Guo
Modified: 2017-03-14 13:42 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-14 13:42:24 UTC
Target Upstream Version:
Embargoed:

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

Description Qian Guo 2013-05-14 11:30:42 UTC 
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 11:32:22 UTC 
Created attachment 747654 [details]
Log after reboot guest
Comment 3 Hai Huang 2013-05-20 18:51:01 UTC 
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 09:30:29 UTC 
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 09:58:11 UTC 
Oops:

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

    reenable CONFIG_VMMOUSE and CONFIG_VMPORT
    
    RH-Author: Eduardo Habkost <ehabkost>
    Message-id: <20110215163134.GF29153.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 15:13:38 UTC 
Doesn't reproduce, please retest with latest qemu-kvm.
Comment 7 juzhang 2013-12-13 02:00:04 UTC 
(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 09:56:45 UTC 
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 11:15:38 UTC 
  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 11:23:42 UTC 
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 15:14:23 UTC 
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-10 01:58:18 UTC 
(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 10:22:49 UTC 
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 11:30:13 UTC 
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-11 03:28:40 UTC 
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 10:39:53 UTC 
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 13:42:24 UTC 
(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.