Bug 818048 - Guest can not wakeup from S3 after clicking PS/2 mouse inside guest with spice-vdagentd service starting in guest
Guest can not wakeup from S3 after clicking PS/2 mouse inside guest with spic...
Status: CLOSED UPSTREAM
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-vdagent (Show other bugs)
6.3
Unspecified Unspecified
low Severity low
: rc
: ---
Assigned To: Default Assignee for SPICE Bugs
Desktop QE
https://bugs.freedesktop.org/show_bug...
:
Depends On:
Blocks: 761491 912287
  Show dependency treegraph
 
Reported: 2012-05-02 01:32 EDT by Qunfang Zhang
Modified: 2015-03-19 07:56 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-19 07:56:29 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)

  None (edit)
Description Qunfang Zhang 2012-05-02 01:32:42 EDT
Description of problem:
As subject, if stop spice-vdagentd service, guest PS/2 mouse will be grabbed by guest and can resume successfully from s3 after the PS/2 mouse clicking.
But if start the spice-vdagentd service and re-try it, guest failed to resume from S3 as a response of PS/2 mouse action.

Version-Release number of selected component (if applicable):
Host:
kernel-2.6.32-262.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.288.el6.x86_64
seabios-0.6.1.2-19.el6.x86_64

Guest:
kernel-2.6.32-268.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Boot guest:
/usr/libexec/qemu-kvm -M rhel6.3.0 -cpu Penryn -enable-kvm -uuid 4c21b4e8-de85-4e31-89b6-8b746d1eeca2 -rtc base=localtime,driftfix=slew -m 2048 -smp 4,maxcpus=8,sockets=1,cores=2,threads=1 -name rhel6.3-64 -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x4 -drive file=/home/RHEL6.3-20120426.2-Server-x86_64-copy.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,serial=zhang,cache=none,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,scsi=off -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:42:0b:00,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/tmp/socket-1,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -monitor stdio -boot c -qmp tcp:0:5555,server,nowait -spice port=5930,disable-ticketing -global qxl-vga.vram_size=67108864 -vga qxl -device qxl,id=video1,vram_size=67108864,bus=pci.0,addr=0x7 -device sga -device virtio-balloon-pci,id=balloon0,bus=pci.0,id=0x6 -bios /usr/share/seabios/bios-pm.bin

2. Check if spice-vdagentd service is starting inside guest, if not, start it.
#service spice-vdagentd status
#service spice-vdagentd start

3. Suspend guest to mem in guest:
#pm-suspend

4. Resume guest by clicking mouse in guest desktop.
  
Actual results:
After step 4, failed to resume guest by clicking PS/2 mouse.

Expected results:
After step 4, guest should resume.

Additional info:
If stop the spice-vdagentd service, this issue does not happen.
Comment 1 Gerd Hoffmann 2012-05-03 07:14:09 EDT
Well, there simply is no ps/2 mouse event with spice guest agent being active as all mouse events get routed to the agent instead of the ps/2 mouse ...
Comment 2 Qunfang Zhang 2012-05-03 22:17:09 EDT
Hi, Gerd
So is this an expected behaviour?
Comment 3 Ademar Reis 2012-07-12 10:06:08 EDT
(In reply to comment #2)
> Hi, Gerd
> So is this an expected behaviour?

NEEDINFO
Comment 4 Gerd Hoffmann 2012-07-12 10:33:37 EDT
Yes, this is expected behavior.  Mouse event data travels via spice virtio-serial channel instead of ps/2 mouse.

We maybe could make the guest disconnect spice agent vmchannel on suspend (don't know whenever apps can be notified on that), so mouse events would be routed via ps/2 device again and wakeup works.  Additional benefit would be that the spice client can figure the other side isn't listening at the moment and there is no point in sending stuff like cut&paste notifications via spice agent vmchannel.  Hans?

Once qemu can handle s3 wakeups from any pci device (not implemented yet) we could also wakeup the guest on any spice agent message.
Comment 5 Hans de Goede 2012-07-23 04:48:20 EDT
Hi,

(In reply to comment #4)
> Yes, this is expected behavior.  Mouse event data travels via spice
> virtio-serial channel instead of ps/2 mouse.
> 
> We maybe could make the guest disconnect spice agent vmchannel on suspend
> (don't know whenever apps can be notified on that), so mouse events would be
> routed via ps/2 device again and wakeup works.  Additional benefit would be
> that the spice client can figure the other side isn't listening at the
> moment and there is no point in sending stuff like cut&paste notifications
> via spice agent vmchannel.  Hans?

Does the spice-server somehow get notified of the suspend / resume? If so we could indeed
drop to server mouse mode, as for signalling agent disconnect to the client, that
is something which needs more thinking. Disadvantage of both approaches is that
the client will grab the mouse on the client-machine on the first click, otoh it will
release it again as soon as the agent is  back ...

> Once qemu can handle s3 wakeups from any pci device (not implemented yet) we
> could also wakeup the guest on any spice agent message.

This seems like the right solution to me.

Regards,

Hans
Comment 6 Gerd Hoffmann 2012-08-06 06:12:36 EDT
  Hi,

> > moment and there is no point in sending stuff like cut&paste notifications
> > via spice agent vmchannel.  Hans?
> 
> Does the spice-server somehow get notified of the suspend / resume? If so we
> could indeed
> drop to server mouse mode, as for signalling agent disconnect to the client,
> that
> is something which needs more thinking. Disadvantage of both approaches is
> that
> the client will grab the mouse on the client-machine on the first click,
> otoh it will
> release it again as soon as the agent is  back ...

I was thinking about a fully guest-side solution, i.e. have spice-agent listen on dbus for "going-to-s3" notifications or something simliar if they exist (not sure they do).

Spice server is not notified in case the guest enters s3 mode.

> > Once qemu can handle s3 wakeups from any pci device (not implemented yet) we
> > could also wakeup the guest on any spice agent message.
> 
> This seems like the right solution to me.

Drawback would be that we would wakeup the guest on *any* virtio-serial message then, including cut+paste messages for example.  I don't think we want this ...
Comment 7 Hans de Goede 2012-08-09 07:39:25 EDT
(In reply to comment #6)
> > > Once qemu can handle s3 wakeups from any pci device (not implemented yet) we
> > > could also wakeup the guest on any spice agent message.
> > 
> > This seems like the right solution to me.
> 
> Drawback would be that we would wakeup the guest on *any* virtio-serial
> message then, including cut+paste messages for example.  I don't think we
> want this ...

True, but cut and paste messages are only generated on user io, so when suspend no cut and paste messages are generated ...

The only problem scenario I can think of is:
1) user does a paste of a large clipboard item
2) user suspends immediately afterward

Which is just plain silly to do, and the only adverse side effect will be an immediate unsuspend, which I think we can live with.
Comment 8 Gerd Hoffmann 2012-08-09 08:28:23 EDT
This is not about guest->host, but host->guest.

Guest is suspended, spice client running on the host.
Any message from the spice client will wakeup the guest then.

For mouse events we actually want that, if the user clicks into the spice client window it probably wants the guest wakeup.

I think for cut&paste we don't.  Otherwise you'll wakeup the guest each time you put something new into the clipboard in case you have automagic cut&paste forwarding enabled.
Comment 9 Hans de Goede 2012-08-10 04:43:34 EDT
(In reply to comment #8)
> This is not about guest->host, but host->guest.
> 
> Guest is suspended, spice client running on the host.
> Any message from the spice client will wakeup the guest then.
> 
> For mouse events we actually want that, if the user clicks into the spice
> client window it probably wants the guest wakeup.
> 
> I think for cut&paste we don't.  Otherwise you'll wakeup the guest each time
> you put something new into the clipboard in case you have automagic
> cut&paste forwarding enabled.

You're right.

So I see 2 solutions to this:

1) Handling this at the qemu / spice-server level by dropping to server mouse mode on suspend.

2.1) Adding wakeup support to virtio-serial *and*
2,2) Adding a new agent message telling the client the guest has suspended / unsuspended *and*
2.3) Modifying qemu / spice-server to send this message *and*
2.4) Modifying the client to inhibit sending clipboard messages when the guest is suspended *and*
2.5) Modifying the client repeat the last relevant clipboard message after unsuspend 

Given the obvious difference in complexity between the 2 solutions I vote for 1).
Comment 10 RHEL Product and Program Management 2012-12-14 02:18:01 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 12 RHEL Product and Program Management 2013-10-14 01:01:12 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 15 Marc-Andre Lureau 2014-12-15 07:23:05 EST
I think this bug could be considered an RFE upstream.
Comment 16 Marc-Andre Lureau 2015-03-19 07:56:29 EDT
Given that s3/s4 is disabled and unsupported on RHEL (unless WHQL fails), and that the bug is not critical (afair, you can resume guest by using keyboard for ex), let's move this upstream.

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