From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42637)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1WYDzx-0008Ve-Ve
	for qemu-devel@nongnu.org; Thu, 10 Apr 2014 08:22:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1WYDzr-00085h-Ry
	for qemu-devel@nongnu.org; Thu, 10 Apr 2014 08:22:29 -0400
Received: from mx1.redhat.com ([209.132.183.28]:14987)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1WYDzr-00085c-Ka
	for qemu-devel@nongnu.org; Thu, 10 Apr 2014 08:22:23 -0400
Message-ID: <1397132537.16790.116.camel@nilsson.home.kraxel.org>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Thu, 10 Apr 2014 14:22:17 +0200
In-Reply-To: <20140410110621.GD19546@redhat.com>
References: <1397120874-17166-1-git-send-email-kraxel@redhat.com>
	<1397120874-17166-6-git-send-email-kraxel@redhat.com>
	<20140410110621.GD19546@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH qemu 3/6] virtio-input: core code & base
	class
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>

On Do, 2014-04-10 at 14:06 +0300, Michael S. Tsirkin wrote:
> > +void virtio_input_send(VirtIOInput *vinput, virtio_input_event
> *event)
> > +{
> > +    VirtQueueElement elem;
> > +    int len;
> > +
> > +    if (!virtqueue_pop(vinput->evt, &elem)) {
> > +        fprintf(stderr, "%s: virtqueue empty, dropping event\n",
> __func__);
> > +        return;
> 
> Looks scary.
> 

It's not different from other input devices.  No buffer space -> drop
event.  What else do you think should happen?  We could signal "you lost
events" to the guest, but I suspect that buys us nothing.  Other input
devices don't have that capability, so guests are likely not prepared to
handle the situation.  Also, there isn't much they can actually do about
it.

cheers,
  Gerd