[Qemu-devel] [bisected] VNC server can't get all sent chars correctly

[Qemu-devel] [bisected] VNC server can't get all sent chars correctly

[Michael Tokarev]

There's a bug filed against debian qemu package, there:

 http://bugs.debian.org/758881

which says about problems sending keypress events over VNC to
a qemu guest, -- some keypresses gets lost, at least.

The bisection between qemu 2.0 and 2.1 leads to this commit:

commit 2858ab09e6f708e381fc1a1cc87e747a690c4884
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Thu Apr 24 20:06:19 2014 +0800

    ps2: set ps/2 output buffer size as the same as kernel

    According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt buffer size
    is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from the very
    beginning.

    When I started a  redhat5.6 32bit guest, meanwhile tapped the keyboard as quickly as
    possible, the screen would show me "i8042.c: No controller found". As a result,
    I couldn't use the keyboard in the VNC client.

    Previous discussion about the issue in maillist:
    http://thread.gmane.org/gmane.comp.emulators.qemu/43294/focus=47180

    This patch has been tested on redhat5.6 32-bit/suse11sp3 64-bit guests.
    More easy meathod to reproduce:
    1.boot a guest with libvirt.
    2.connect to VNC client.
    3.as you see the BIOS, bootloader, Linux booting, run the follow simply shell script:
    for((i=0;i<10000000;i++)) do virsh send-key redhat5.6 KEY_A; done

    Actual results:
    dmesg show "i8042.c: No controller found." And the keyboard is out of work.

    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>


So it looks like something else is not right here.  Before this patch,
it wasn't possible to use keyboard with VNC client with redhat 5 guest.
Now, it isn't possible to use keyboard with VNC in another scenario which
worked before (so it is a regression compared with 2.0 version).

What do we do with this? :)

Thanks,

/mjt

Re: [Qemu-devel] [bisected] VNC server can't get all sent chars correctly

[Gonglei (Arei)]

Hi,

> From: Michael Tokarev [mailto:mjt@tls.msk.ru]
> Sent: Saturday, August 23, 2014 4:56 PM
> To: qemu-devel
> Cc: Gerd Hoffmann; Gonglei (Arei); 758881@bugs.debian.org; Gabriele
> Giacone
> Subject: [bisected] VNC server can't get all sent chars correctly
> 
> There's a bug filed against debian qemu package, there:
> 
>  http://bugs.debian.org/758881
> 
> which says about problems sending keypress events over VNC to
> a qemu guest, -- some keypresses gets lost, at least.
> 
> The bisection between qemu 2.0 and 2.1 leads to this commit:
> 
> commit 2858ab09e6f708e381fc1a1cc87e747a690c4884
> Author: Gonglei <arei.gonglei@huawei.com>
> Date:   Thu Apr 24 20:06:19 2014 +0800
> 
>     ps2: set ps/2 output buffer size as the same as kernel
> 
>     According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt
> buffer size
>     is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from
> the very
>     beginning.
> 
>     When I started a  redhat5.6 32bit guest, meanwhile tapped the keyboard
> as quickly as
>     possible, the screen would show me "i8042.c: No controller found". As a
> result,
>     I couldn't use the keyboard in the VNC client.
> 
>     Previous discussion about the issue in maillist:
> 
> http://thread.gmane.org/gmane.comp.emulators.qemu/43294/focus=47180
> 
>     This patch has been tested on redhat5.6 32-bit/suse11sp3 64-bit guests.
>     More easy meathod to reproduce:
>     1.boot a guest with libvirt.
>     2.connect to VNC client.
>     3.as you see the BIOS, bootloader, Linux booting, run the follow simply
> shell script:
>     for((i=0;i<10000000;i++)) do virsh send-key redhat5.6 KEY_A; done
> 
>     Actual results:
>     dmesg show "i8042.c: No controller found." And the keyboard is out of
> work.
> 
>     Signed-off-by: Gonglei <arei.gonglei@huawei.com>
>     Reviewed-by: Juan Quintela <quintela@redhat.com>
>     Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> 
> 
> So it looks like something else is not right here.  Before this patch,
> it wasn't possible to use keyboard with VNC client with redhat 5 guest.
> Now, it isn't possible to use keyboard with VNC in another scenario which
> worked before (so it is a regression compared with 2.0 version).
> 
> What do we do with this? :)
> 
I tested the same command line with the reported Bug, as below: 

./qemu-system-x86_64 -vnc :10 -enable-kvm -cpu host -m 1024 --kernel \
/home/linux --initrd /home/initrd.gz --append "locale=en_US keymap=us \ 
video=vesa:ywrap,mtrr vga=788"

And the VNC client I tested are TightVNC and RealVNC.

But I could not reproduce this issue.

So, I think maybe vncdotool client once send too many characters
(and ps2 queue length > PS2_QUEUE_SIZE), which leading to some 
characters are discarded by QEMU. More test cases will be useful IMHO.

Best regards,
-Gonglei

Re: [Qemu-devel] [bisected] VNC server can't get all sent chars correctly

[Markus Armbruster]

Michael Tokarev <mjt@tls.msk.ru> writes:

> There's a bug filed against debian qemu package, there:
>
>  http://bugs.debian.org/758881
>
> which says about problems sending keypress events over VNC to
> a qemu guest, -- some keypresses gets lost, at least.
>
> The bisection between qemu 2.0 and 2.1 leads to this commit:
>
> commit 2858ab09e6f708e381fc1a1cc87e747a690c4884
> Author: Gonglei <arei.gonglei@huawei.com>
> Date:   Thu Apr 24 20:06:19 2014 +0800
>
>     ps2: set ps/2 output buffer size as the same as kernel
>
>     According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt buffer size
>     is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from the very
>     beginning.
>
>     When I started a  redhat5.6 32bit guest, meanwhile tapped the keyboard as quickly as
>     possible, the screen would show me "i8042.c: No controller found". As a result,
>     I couldn't use the keyboard in the VNC client.
>
>     Previous discussion about the issue in maillist:
>     http://thread.gmane.org/gmane.comp.emulators.qemu/43294/focus=47180
>
>     This patch has been tested on redhat5.6 32-bit/suse11sp3 64-bit guests.
>     More easy meathod to reproduce:
>     1.boot a guest with libvirt.
>     2.connect to VNC client.
>     3.as you see the BIOS, bootloader, Linux booting, run the follow simply shell script:
>     for((i=0;i<10000000;i++)) do virsh send-key redhat5.6 KEY_A; done
>
>     Actual results:
>     dmesg show "i8042.c: No controller found." And the keyboard is out of work.
>
>     Signed-off-by: Gonglei <arei.gonglei@huawei.com>
>     Reviewed-by: Juan Quintela <quintela@redhat.com>
>     Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>
>
> So it looks like something else is not right here.  Before this patch,
> it wasn't possible to use keyboard with VNC client with redhat 5 guest.
> Now, it isn't possible to use keyboard with VNC in another scenario which
> worked before (so it is a regression compared with 2.0 version).
>
> What do we do with this? :)

Suggest to add a tracepoint to the place that drops keystrokes due to
buffer being full, to verify that's really what happens.  Quick glance
at the code suggests ps2_queue().

Re: [Qemu-devel] [bisected] VNC server can't get all sent chars correctly

[Gonglei (Arei)]

> From: Markus Armbruster [mailto:armbru@redhat.com]
> Sent: Monday, August 25, 2014 3:30 PM
> To: Michael Tokarev
> Cc: qemu-devel; Gonglei (Arei); Gabriele Giacone; Gerd Hoffmann;
> 758881@bugs.debian.org
> Subject: Re: [Qemu-devel] [bisected] VNC server can't get all sent chars
> correctly
> 
> Michael Tokarev <mjt@tls.msk.ru> writes:
> 
> > There's a bug filed against debian qemu package, there:
> >
> >  http://bugs.debian.org/758881
> >
> > which says about problems sending keypress events over VNC to
> > a qemu guest, -- some keypresses gets lost, at least.
> >
> > The bisection between qemu 2.0 and 2.1 leads to this commit:
> >
> > commit 2858ab09e6f708e381fc1a1cc87e747a690c4884
> > Author: Gonglei <arei.gonglei@huawei.com>
> > Date:   Thu Apr 24 20:06:19 2014 +0800
> >
> >     ps2: set ps/2 output buffer size as the same as kernel
> >
> >     According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt
> buffer size
> >     is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from
> the very
> >     beginning.
> >
> >     When I started a  redhat5.6 32bit guest, meanwhile tapped the
> keyboard as quickly as
> >     possible, the screen would show me "i8042.c: No controller found". As a
> result,
> >     I couldn't use the keyboard in the VNC client.
> >
> >     Previous discussion about the issue in maillist:
> >
> http://thread.gmane.org/gmane.comp.emulators.qemu/43294/focus=47180
> >
> >     This patch has been tested on redhat5.6 32-bit/suse11sp3 64-bit
> guests.
> >     More easy meathod to reproduce:
> >     1.boot a guest with libvirt.
> >     2.connect to VNC client.
> >     3.as you see the BIOS, bootloader, Linux booting, run the follow simply
> shell script:
> >     for((i=0;i<10000000;i++)) do virsh send-key redhat5.6 KEY_A; done
> >
> >     Actual results:
> >     dmesg show "i8042.c: No controller found." And the keyboard is out of
> work.
> >
> >     Signed-off-by: Gonglei <arei.gonglei@huawei.com>
> >     Reviewed-by: Juan Quintela <quintela@redhat.com>
> >     Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> >
> >
> > So it looks like something else is not right here.  Before this patch,
> > it wasn't possible to use keyboard with VNC client with redhat 5 guest.
> > Now, it isn't possible to use keyboard with VNC in another scenario which
> > worked before (so it is a regression compared with 2.0 version).
> >
> > What do we do with this? :)
> 
> Suggest to add a tracepoint to the place that drops keystrokes due to
> buffer being full, to verify that's really what happens.  Quick glance
> at the code suggests ps2_queue().

+1  :)

Best regards,
-Gonglei

Re: [Qemu-devel] [bisected] VNC server can't get all sent chars correctly

[Gerd Hoffmann]

On Sa, 2014-08-23 at 12:56 +0400, Michael Tokarev wrote:
> There's a bug filed against debian qemu package, there:
> 
>  http://bugs.debian.org/758881
> 
> which says about problems sending keypress events over VNC to
> a qemu guest, -- some keypresses gets lost, at least.

> So it looks like something else is not right here.  Before this patch,
> it wasn't possible to use keyboard with VNC client with redhat 5 guest.
> Now, it isn't possible to use keyboard with VNC in another scenario which
> worked before (so it is a regression compared with 2.0 version).

qemu 2.1 hardware emulation is more correct (ps/2 kbd queue size being
16 bytes instead of 256, matching real hardware).  That may trip up
software depending on old, broken behavior.

IMO vncdotool should be fixed to add small delays between keyboard
events, as if a real person is typing, instead of sending the key events
at the maximum possible speed.

I'm sure you can hit the issue with qemu 2.0 too, you just need longer
user input strings to trigger it, so it is less likely to happen.

cheers,
  Gerd

Re: [Qemu-devel] Bug#758881: [bisected] VNC server can't get all sent chars correctly

[Gabriele Giacone]

[ CC'ing Marc Sibson, vncdotool developer ]

Hi Marc, thread starts at
http://thread.gmane.org/gmane.comp.emulators.qemu/292614

On Mon, Aug 25, 2014 at 11:37 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Sa, 2014-08-23 at 12:56 +0400, Michael Tokarev wrote:
>> There's a bug filed against debian qemu package, there:
>>
>>  http://bugs.debian.org/758881
>>
>> which says about problems sending keypress events over VNC to
>> a qemu guest, -- some keypresses gets lost, at least.
>
>> So it looks like something else is not right here.  Before this patch,
>> it wasn't possible to use keyboard with VNC client with redhat 5 guest.
>> Now, it isn't possible to use keyboard with VNC in another scenario which
>> worked before (so it is a regression compared with 2.0 version).
>
> qemu 2.1 hardware emulation is more correct (ps/2 kbd queue size being
> 16 bytes instead of 256, matching real hardware).  That may trip up
> software depending on old, broken behavior.
>
> IMO vncdotool should be fixed to add small delays between keyboard
> events, as if a real person is typing, instead of sending the key events
> at the maximum possible speed.
>
> I'm sure you can hit the issue with qemu 2.0 too, you just need longer
> user input strings to trigger it, so it is less likely to happen.

I do confirm some chars don't get received with qemu 2.0 as well, e.g.
by sending "insecureinsecure": received string is "ecure", first 11
missing.

Thanks,
-- 
G..e

Re: [Qemu-devel] Bug#758881: [bisected] VNC server can't get all sent chars correctly

[Marc]

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

Hi,

On August 25, 2014 at 3:40:01 AM, Gabriele Giacone (1o5g4r8o@gmail.com) wrote:
> IMO vncdotool should be fixed to add small delays between keyboard 
> events, as if a real person is typing, instead of sending the key events 
> at the maximum possible speed. 
vncdotool does have a —delay=MILLISECONDS switch that inserts a delay between commands.  Currently, the two behaviours causing trouble seem to be that delay defaults to 0 and "type insecure” is considered one command, so there is  no delay between key presses :(  

Is there a non-zero value for —delay that makes sense?  I’m somewhat hesitant to change —delay  as it would be a behavioural change for other users, but if the value is sufficiently small it could be a net usability gain.

Are you requesting that the type command be fixed to insert delays after every character or that default for —delay should be non-zero?

-- 

Marc

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

Re: [Qemu-devel] Bug#758881: [bisected] VNC server can't get all sent chars correctly

[Gerd Hoffmann]

On Mo, 2014-08-25 at 21:11 -0700, Marc wrote:
> Hi,
> 
> 
> On August 25, 2014 at 3:40:01 AM, Gabriele Giacone
> (1o5g4r8o@gmail.com) wrote:
> > 
> > > IMO vncdotool should be fixed to add small delays between
> > keyboard 
> > > events, as if a real person is typing, instead of sending the key
> > events 
> > > at the maximum possible speed. 
> vncdotool does have a —delay=MILLISECONDS switch that inserts a delay
> between commands.  Currently, the two behaviours causing trouble seem
> to be that delay defaults to 0 and "type insecure” is considered one
> command, so there is  no delay between key presses :(  
> 
> Is there a non-zero value for —delay that makes sense?  I’m somewhat
> hesitant to change —delay  as it would be a behavioural change for
> other users, but if the value is sufficiently small it could be a net
> usability gain.
> 
> Are you requesting that the type command be fixed to insert delays
> after every character or that default for —delay should be non-zero?

There should be a delay after every character.  It can be pretty small.
10ms should be enough (you should set TCP_NODELAY though to make sure
the key events are not buffered in the network stack).

I guess it makes sense to decouple that from the delay between commands
as the time a qemu guest needs to process a command can be much higher
than the time it needs to process a key event.

cheers,
  Gerd

Re: [Qemu-devel] Bug#758881: [bisected] VNC server can't get all sent chars correctly

[Michael Tokarev]

26.08.2014 09:40, Gerd Hoffmann wrote:
> There should be a delay after every character.  It can be pretty small.
> 10ms should be enough (you should set TCP_NODELAY though to make sure
> the key events are not buffered in the network stack).

Is this delay qemu-specific (or, rather, virtualization-specific, so to say,
when the target - the VNC server - is working with a hardware being emulated),
or applies to all VNC servers equally?

/mjt

Re: [Qemu-devel] Bug#758881: [bisected] VNC server can't get all sent chars correctly

[Gerd Hoffmann]

On Di, 2014-08-26 at 09:55 +0400, Michael Tokarev wrote:
> 26.08.2014 09:40, Gerd Hoffmann wrote:
> > There should be a delay after every character.  It can be pretty small.
> > 10ms should be enough (you should set TCP_NODELAY though to make sure
> > the key events are not buffered in the network stack).
> 
> Is this delay qemu-specific (or, rather, virtualization-specific, so to say,
> when the target - the VNC server - is working with a hardware being emulated),
> or applies to all VNC servers equally?

Dunno, didn't try.  Maybe you can hit it with xvnc too.  But I'd expect
that software (xvnc) has larger buffers than (emulated) hardware, so it
doesn't trigger that easily.

cheers,
  Gerd