qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Amos Kong <akong@redhat.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 1/6] qerror: add MAX_KEYCODES 16
Date: Tue, 19 Jun 2012 17:52:45 +0800	[thread overview]
Message-ID: <4FE04BED.4080407@redhat.com> (raw)
In-Reply-To: <4FDF49AD.3040806@redhat.com>

On 18/06/12 23:30, Amos Kong wrote:
> On 06/15/2012 09:35 PM, Luiz Capitulino wrote:
>> On Fri, 15 Jun 2012 09:57:49 +0200
>> Gerd Hoffmann<kraxel@redhat.com>  wrote:
>>
>>>    Hi,
>>>
>>>>> It seems we need to notice user when inputted keys are more than 16.
>>>>
>>>> Hi Gerd,
>>>>
>>>> When I use 'sendkey' command to send key-series to guest, some keyboard
>>>> events will be send. There is a limitation (16) that was introduced by this
>>>> old commit c8256f9d (without description). Do you know the reason?
>>>
>>> Probably hardware limitation, ps/2 keyboards can buffer up to 16 keys IIRC.
>>
>> Then the perfect thing to do would be to drop the MAX_KEYCODES check from
>> the sendkey command and move bounds checking down to the device emulation code.
>>
>>
>> However, this will require a bit of code churn if we do it for all devices,
>> and won't buy us much, as the most likely reason for the error is a client/user
>> trying to send too many keys in parallel to the guest, right?
>
> Agree, we can notice in stderr when the redundant keys are ignored as hid.
>
>
> #define QUEUE_LENGTH    16 /* should be enough for a triple-click */
>
> static void hid_keyboard_event(void *opaque, int keycode)
> {
>      ...
>      if (hs->n == QUEUE_LENGTH) {
>          fprintf(stderr, "usb-kbd: warning: key event queue full\n");
>          return;
>      }


I dropped the limitation in sendkey command,
and didn't change current ps2.c, executed some
tests in different environments.

environment             max inputted key number
------------            -----------------------
win7 notepad            100
rhel6 grub              15
rhel6 pxe               15
rhel6 login window      10
rhel6 vim               16
rhel6 terminal(init 3)  200


It seems original 256 queue limitation in ps2.c is fine.
I would only drop limitation(16) in old sendkey command,
it's secure.


>> If this is right, then I think that the best thing to do would be to drop the
>> MAX_KEYCODES check from the sendkey command and document that devices can drop
>> keys if too many of them are sent in parallel or too fast (we can mention ps/2
>> as an example of a 16 bytes limit).
>>
>>>
>>> Likewise the usb hid devices can buffer up to 16 events.  In that case
>>> it is just a qemu implementation detail and not a property of the
>>> hardware we are emulating, so it can be changed.  Not trivially though
>>> as the buffer is part of the migration data, so it is more work that
>>> just changing a #define.


-- 
			Amos.

  reply	other threads:[~2012-06-19  9:53 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-01 22:54 [Qemu-devel] [PATCH v2 0/6] convert sendkey to qapi Amos Kong
2012-06-01 22:54 ` [Qemu-devel] [PATCH v2 1/6] qerror: add QERR_OVERFLOW Amos Kong
2012-06-04  5:27   ` Anthony Liguori
2012-06-05 14:29     ` [Qemu-devel] [PATCH v2 1/6] qerror: add MAX_KEYCODES 16 Amos Kong
     [not found]       ` <4FD0326F.3010806@redhat.com>
     [not found]         ` <20120611140642.06be2ee8@doriath.home>
     [not found]           ` <4FD62827.4060900@us.ibm.com>
     [not found]             ` <20120611142546.66871522@doriath.home>
2012-06-14 10:20               ` Amos Kong
2012-06-15  7:46                 ` Amos Kong
2012-06-15  7:57                   ` Gerd Hoffmann
2012-06-15 13:35                     ` Luiz Capitulino
2012-06-18 15:30                       ` Amos Kong
2012-06-19  9:52                         ` Amos Kong [this message]
2012-06-01 22:54 ` [Qemu-devel] [PATCH v2 2/6] fix doc of using raw values with sendkey Amos Kong
2012-06-06 18:16   ` Luiz Capitulino
2012-06-01 22:54 ` [Qemu-devel] [PATCH v2 3/6] rename keyname '<' to 'less' Amos Kong
2012-06-06 18:22   ` Luiz Capitulino
2012-06-06 23:12     ` Amos Kong
2012-06-01 22:54 ` [Qemu-devel] [PATCH v2 4/6] hmp: rename arguments Amos Kong
2012-06-01 22:54 ` [Qemu-devel] [PATCH v2 5/6] qapi: generate list struct and visit_list for enum Amos Kong
2012-06-05 15:01   ` Amos Kong
2012-06-06 18:40   ` Luiz Capitulino
2012-06-07  0:26     ` Michael Roth
2012-06-07  2:52       ` Amos Kong
2012-06-11 17:00         ` Luiz Capitulino
2012-06-07  0:15   ` Michael Roth
2012-06-07  3:33     ` Amos Kong
2012-06-01 22:54 ` [Qemu-devel] [PATCH v2 6/6] qapi: convert sendkey Amos Kong
2012-06-04 17:09   ` Eric Blake
2012-06-05 14:55     ` Amos Kong
2012-06-05 15:05       ` Eric Blake
2012-06-06  7:13         ` Amos Kong
2012-06-06 11:58           ` Eric Blake
2012-06-07  4:51             ` Anthony Liguori
2012-06-07 13:08               ` Eric Blake
2012-06-01 23:03 ` [Qemu-devel] [PATCH v2 0/6] convert sendkey to qapi Amos Kong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FE04BED.4080407@redhat.com \
    --to=akong@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=kraxel@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).