qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alon Levy <alevy@redhat.com>
To: Yonit Halperin <yhalperi@redhat.com>
Cc: qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] qxl: add QXL_IO_UPDATE_MEM for guest S3&S4 support
Date: Sun, 26 Jun 2011 19:47:15 +0200	[thread overview]
Message-ID: <20110626174715.GJ2731@bow.redhat.com> (raw)
In-Reply-To: <730034918.33031.1309107546747.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

On Sun, Jun 26, 2011 at 12:59:06PM -0400, Yonit Halperin wrote:
> Sorry for the late response, wasn't available.
> I'm afraid  that (1) and (2) will indeed wakeup the worker, but will not assure emptying the command ring, as it depends on the client pipe size.
> 

I actually can't figure out what wakeup does (that's what both NOTIFY and
NOTIFY_CURSOR do, see hw/qxl.c). What we did in prepare_to_sleep before was
call flush_all_qxl_commands, which reads the command and cursor rings until
they are empty (calling flush_cursor_commands and flush_display_commands), waiting
whenever the pipe is too large. (avoiding this wait still needs to be done, but
after ensuring suspend is correct).

More to the point this flush is done from handle_dev_destroy_surfaces, but
this is not good enough since this also destroys the surfaces, before we have
a chance to actually render the surfaces.

Perhaps RED_WORKER_MESSAGE_STOP should do a flush_all_qxl_commands?

> 
> ----- Original Message -----
> From: "Alon Levy" <alevy@redhat.com>
> To: "Gerd Hoffmann" <kraxel@redhat.com>
> Cc: qemu-devel@nongnu.org, yhalperi@redhat.com
> Sent: Wednesday, June 22, 2011 11:57:54 AM
> Subject: Re: [Qemu-devel] [PATCH 2/2] qxl: add QXL_IO_UPDATE_MEM for guest S3&S4 support
> 
> On Wed, Jun 22, 2011 at 11:13:19AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > >>worker call.  We can add a I/O command to ask qxl to push the
> > >>release queue head to the release ring.
> > >
> > >So you suggest to replace QXL_IO_UPDATE_MEM with what, two io commands instead
> > >of using the val parameter?
> > 
> > I'd like to (a) avoid updating the libspice-server API if possible
> > and (b) have one I/O command for each logical step.  So going into
> > S3 could look like this:
> > 
> >   (0) stop putting new commands into the rings
> >   (1) QXL_IO_NOTIFY_CMD
> >   (2) QXL_IO_NOTIFY_CURSOR
> >       qxl calls notify(), to make the worker thread empty the command
> >       rings before it processes the next dispatcher request.
> >   (3) QXl_IO_FLUSH_SURFACES (to be implemented)
> >       qxl calls stop()+start(), spice-server renders all surfaces,
> >       thereby flushing state to device memory.
> >   (4) QXL_IO_DESTROY_ALL_SURFACES
> >       zap surfaces
> >   (5) QXL_IO_FLUSH_RELEASE (to be implemented)
> >       push release queue head into the release ring, so the guest
> >       will see it and can release everything.
> > 
> > (1)+(2)+(4) exist already.
> > (3)+(5) can be done without libspice-server changes.
> > 
> > Looks workable?
> 
> yeah. Yonit?
> 
> > 
> > cheers,
> >   Gerd
> > 
> > 
> 

  reply	other threads:[~2011-06-26 17:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-20 11:11 [Qemu-devel] [PATCH 0/2] Suspend (S3) support Alon Levy
2011-06-20 11:11 ` [Qemu-devel] [PATCH 1/2] qxl: interface_get_command: fix reported mode Alon Levy
2011-06-20 11:11 ` [Qemu-devel] [PATCH 2/2] qxl: add QXL_IO_UPDATE_MEM for guest S3&S4 support Alon Levy
2011-06-20 12:13   ` Gerd Hoffmann
2011-06-20 12:57     ` Alon Levy
2011-06-20 12:58     ` Alon Levy
2011-06-20 14:07       ` Gerd Hoffmann
2011-06-20 15:11         ` Alon Levy
2011-06-20 15:48           ` Alon Levy
2011-06-20 15:50           ` Gerd Hoffmann
2011-06-20 16:32             ` Alon Levy
2011-06-20 20:53               ` Alon Levy
2011-06-21  6:29               ` Yonit Halperin
2011-06-22  9:13               ` Gerd Hoffmann
2011-06-22  9:57                 ` Alon Levy
2011-06-26 16:59                   ` Yonit Halperin
2011-06-26 17:47                     ` Alon Levy [this message]
2011-06-27  6:28                       ` yhalperi
2011-06-27  8:16                         ` Alon Levy
2011-06-27  8:25                           ` yhalperi
2011-06-27  9:20                             ` Alon Levy
2011-06-29  9:01                               ` Gerd Hoffmann
2011-06-29  9:21                                 ` Alon Levy
2011-06-29 10:25                                   ` Gerd Hoffmann
2011-06-29 11:38                                     ` Alon Levy
2011-06-30 10:26                                       ` Yonit Halperin
2011-06-30 10:46                                         ` Gerd Hoffmann
2011-06-30 11:41                                           ` Alon Levy
2011-06-30 12:12                                             ` Gerd Hoffmann
2011-06-30 12:50                                               ` Alon Levy
2011-06-30 13:17                                                 ` Gerd Hoffmann

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=20110626174715.GJ2731@bow.redhat.com \
    --to=alevy@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yhalperi@redhat.com \
    /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).