Re: [Qemu-devel] [PATCH v3 4/4] hw/qxl-render: drop cursor locks, replace with pipe

[Alon Levy <alevy@redhat.com>]

On Thu, Mar 17, 2011 at 03:19:28PM +0100, Jes Sorensen wrote:
> On 03/17/11 11:45, Alon Levy wrote:
> > On Thu, Mar 17, 2011 at 11:29:03AM +0100, Jes Sorensen wrote:
> >> On 03/17/11 11:27, Alon Levy wrote:
> >>> On Thu, Mar 17, 2011 at 10:48:43AM +0100, Jes Sorensen wrote:
> >>>>> Same for the asserts below, writes are from spice server thread, reads
> >>>>> are in iothread.
> >>>>
> >>>> But shouldn't this make it try to reconnect? Even if the reconnect
> >>>> fails, it shouldn't kill the guest IMHO.
> >>>
> >>> reconnect? between two threads in the qemu process? why would the write
> >>> fail to begin with? this is like saying if I'm failing a kvm ioctl I should
> >>> just retry.
> >>
> >> Ah ok, I missed that part, somehow I had in my mind it was two different
> >> processes, despite you mentioning threads.
> >>
> >> Still if gfx handling fails, it shouldn't nuke the guest.
> > 
> > ok, try to apply that logic to any other device - network, usb, etc., I don't
> > think it holds.
> 
> Maybe I am looking at the wrong angle - I would think that is network or
> usb breaks, we would still keep running, and for gfx the guest should be
> able to keep running even if the monitor is disconnected.
> 
> It's not a big issue so if you feel it is fine as is, I won't object.

I think it could be marginally useful - I mean if someone is running a vm with
spice it's for desktop use, and that means graphics is important. of course they
could be running a server vm and have it for debugging, but that would
be silly.

This could hide an actual bug, by not aborting here. Not a major point.

I'm also not sure what's the right thing to do - turn on a flag for stopping
handling requests? it would just open up a whole set of states we don't handle
currently, half-working states.

> 
> Cheers,
> Jes
>