[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH qemu 3/6] virtio-input: core code & base class
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH qemu 3/6] virtio-input: core code & base class |
Date: |
Thu, 10 Apr 2014 17:56:03 +0300 |
On Thu, Apr 10, 2014 at 02:22:17PM +0200, Gerd Hoffmann wrote:
> 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.
For assigned device input events, how about we don't read events off the
input device file if there's nowhere to put them?
For things like sync that qemu generates, I suspect it's a good idea
to buffer them in QEMU otherwise guest will get out of sync, right?
I'm also pretty sure whoever's running the hypervisor does not
want to see the fprintf.
> Also, there isn't much they can actually do about
> it.
>
> cheers,
> Gerd
--
MST
- Re: [Qemu-devel] [PATCH qemu 6/6] virtio-input: evdev passthrough, (continued)
[Qemu-devel] [PATCH qemu 4/6] virtio-input: emulated devices, Gerd Hoffmann, 2014/04/10
[Qemu-devel] [PATCH qemu 3/6] virtio-input: core code & base class, Gerd Hoffmann, 2014/04/10
[Qemu-devel] [PATCH spec] Add virtio input device specification, Gerd Hoffmann, 2014/04/10