qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alon Levy <alevy@redhat.com>
To: "Gerd Hoffmann" <kraxel@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async
Date: Tue, 6 Mar 2012 11:35:33 +0200	[thread overview]
Message-ID: <20120306093533.GD14238@garlic> (raw)
In-Reply-To: <4F55C658.9090403@redhat.com>

On Tue, Mar 06, 2012 at 09:10:00AM +0100, Gerd Hoffmann wrote:
> On 03/06/12 08:56, Alon Levy wrote:
> > On Tue, Mar 06, 2012 at 08:36:34AM +0100, Gerd Hoffmann wrote:
> >>   Hi,
> >>
> >>>> How would the parallel execution facility be opaque to the implementer?
> >>>> screendump returns, screendump_async needs to pass a closure. You can
> >>>> automatically generate any amount of code, but you can only have a
> >>>> single function implementation with longjmp/coroutine, or having a
> >>>> saparate thread per command but that would mean taking locks for
> >>>> anything not trivial, which avoids the no-change-to-implementation. Is
> >>>> this what you have in mind?
> >>>
> >>> It would not be opaque to the implementer.  But it would avoid
> >>> introducing new commands and events, instead we have a unified mechanism
> >>> to signal completion.
> >>
> >> Ok.  We have a async mechanism today: .mhandler.cmd_async = ...
> >>
> >> I know it has its problems like no cancelation and is deprecated and
> >> all.  But still: how about using it as interim until QAPI-based async
> >> monitor support is ready?  We could unbreak qxl screendumps without
> >> having to introduce a new (but temporary!) screendump_async command +
> >> completion event.
> > 
> > Actually, I'm not sure this doesn't reintroduce the original problem
> > (which I haven't been able to reproduce):
> > 
> > client: screenshot <-> client libvirt <-> host libvirt
> > 
> > host libvirt (screendump) <-> qemu monitor -> <- spice server <-> client
> 
> Hmm?  spice client can ask for a screendump via libvirt?
> 
> /me looks completely puzzled.

No, ok, bad attempt.

 "client" is a libvirt and spice client.
 client as a libvirt client asks for screenshot.
 libvirt (client side) asks from libvirt (host side)
 libvirt (host side) issues a screendump monitor command (the new
   internal async version)
 qxl_screen_dump asks spice server to render
 spice server waits for pipe to spice client to empty (lower then 50)

 but spice client, which is just "client", is blocking on completion of
 the screendump command.

 I have two problems with my own explanation:
  1. I didn't manage to reproduce it myself, and nor has Marc Andre (who
  first reported this problem) yesterday.
  2. I remember that the async monitor command I sent in October did fix
  the problem, so something with my description is wrong.

> 
> cheers,
>   Gerd
> 
> 

  reply	other threads:[~2012-03-06  9:35 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-05 14:16 [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async Alon Levy
2012-03-05 14:16 ` [Qemu-devel] [PATCH v2 2/2] add qmp screendump-async Alon Levy
2012-03-05 14:33 ` [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async Anthony Liguori
2012-03-05 15:17   ` Alon Levy
2012-03-05 15:56   ` [Qemu-devel] [PATCH v3 0/3] screendump async command Alon Levy
2012-03-05 15:56     ` [Qemu-devel] [PATCH v3 1/3] monitor, console: add QEVENT_SCREEN_DUMP_COMPLETE Alon Levy
2012-03-05 15:56     ` [Qemu-devel] [PATCH v3 2/3] console: add hw_screen_dump_async Alon Levy
2012-03-05 15:56     ` [Qemu-devel] [PATCH v3 3/3] add qmp screendump-async Alon Levy
2012-03-05 17:17     ` [Qemu-devel] [PATCH v3 0/3] screendump async command Anthony Liguori
2012-03-05 17:20   ` [Qemu-devel] [PATCH v2 1/2] console: add hw_screen_dump_async Avi Kivity
2012-03-05 17:27     ` Anthony Liguori
2012-03-05 17:29       ` Avi Kivity
2012-03-05 17:56         ` Luiz Capitulino
2012-03-05 18:16         ` Anthony Liguori
2012-03-05 18:22           ` Avi Kivity
2012-03-05 19:32             ` Anthony Liguori
2012-03-05 17:31       ` Luiz Capitulino
2012-03-05 18:09         ` Alon Levy
2012-03-05 18:17           ` Avi Kivity
2012-03-05 18:58             ` Alon Levy
2012-03-05 19:45               ` Luiz Capitulino
2012-03-06  7:36             ` Gerd Hoffmann
2012-03-06  7:43               ` Alon Levy
2012-03-06  7:56               ` Alon Levy
2012-03-06  8:10                 ` Gerd Hoffmann
2012-03-06  9:35                   ` Alon Levy [this message]
2012-03-06 12:24               ` Luiz Capitulino
2012-03-06 13:16                 ` Alon Levy
2012-03-06 13:51                   ` Anthony Liguori
2012-03-06 13:53                     ` Luiz Capitulino
2012-03-06 14:23                       ` Alon Levy
2012-03-06 15:07                         ` Anthony Liguori
2012-03-06 15:56                     ` Alon Levy
2012-03-06 16:02                       ` Alon Levy
2012-03-06 16:16                       ` Anthony Liguori
2012-03-06 16:26                         ` Alon Levy
2012-03-06 16:47                           ` Anthony Liguori
2012-03-07  6:57                         ` 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=20120306093533.GD14238@garlic \
    --to=alevy@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /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).