Re: [Qemu-devel] [PATCH 2/2] qxl: add QXL_IO_UPDATE_MEM for guest S3&S4 support

[Alon Levy <alevy@redhat.com>]

On Thu, Jun 30, 2011 at 12:46:59PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> >>Right - the whole ring assumes that the same side removes. of course we
> >>can add an IO for that (two - FREEZE and UNFREEZE). But I think this is
> >>the wrong approach. Instead, rendering all the commands, and dropping the
> >>wait for the client. Right now if we flush we do actually wait for the
> >>client,
> >>but I plan to remove this later. (we do this right now for update_area as
> >>well and that's much higher frequency).
> 
> >To conclude, we still need to flush the command ring before stop. We
> >don't want to change migration. So we still need to change spice server
> >api. Gerd?
> 
> Yes, looks like there is no way around that to flush the command rings.
> 
> When we have to change the spice-server api anyway, then we should
> support async I/O at libspice-server API level I think.  Drop the
> qxl async thread, have a way to submit async requests to the worker,
> let libspice call us back on completion.
> 
> comments?

My thoughts exactly. Any reason to support the old non async messages if we
do this? i.e. do we add _ASYNC versions or just change the meaning of the existing ones?
as long as we change the major version of the server (it will be 0.10) I think it isn't
problematic, right?

The only difference with this approach is that we will have to do the reads from the
io thread of qemu, which means a single thread reading for multiple qxl devices, but
since it will just be doing very minimal work I don't think it should be a problem (it
will just be setting the irq).

> 
> cheers,
>   Gerd