Hi,
Yes. Backward compatibility.
So at least deprecate it to be dropped later? I don't like that the code just
gets
bigger and bigger.
Deprecate them is fine.
I was thinking of a different solution - one in which the same "READY" messages
are
written, but read from a different place.
On Thu, Jun 30, 2011 at 02:12:52PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >My thoughts exactly. Any reason to support the old non async messages if we
> >do this?
>
> Yes. Backward compatibility.
So at least deprecate it to be dropped later? I don't like that the code just
gets
bigger and big
Hi,
My thoughts exactly. Any reason to support the old non async messages if we
do this?
Yes. Backward compatibility.
The only difference with this approach is that we will have to do the reads
from the
io thread of qemu,
Hmm? Which reads?
I'd add a completion callback to QXLInterfac
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
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
c
On 06/29/2011 02:38 PM, Alon Levy wrote:
On Wed, Jun 29, 2011 at 12:25:00PM +0200, Gerd Hoffmann wrote:
On 06/29/11 11:21, Alon Levy wrote:
On Wed, Jun 29, 2011 at 11:01:11AM +0200, Gerd Hoffmann wrote:
Hi,
I think it will receive them after migration, since the command ring
was stored.
On Wed, Jun 29, 2011 at 12:25:00PM +0200, Gerd Hoffmann wrote:
> On 06/29/11 11:21, Alon Levy wrote:
> >On Wed, Jun 29, 2011 at 11:01:11AM +0200, Gerd Hoffmann wrote:
> >> Hi,
> >>
> I think it will receive them after migration, since the command ring
> was stored.
> >>>Our confusion here
On 06/29/11 11:21, Alon Levy wrote:
On Wed, Jun 29, 2011 at 11:01:11AM +0200, Gerd Hoffmann wrote:
Hi,
I think it will receive them after migration, since the command ring
was stored.
Our confusion here is because you think there is still seemless migration.
Unfortunately
it doesn't work
On Wed, Jun 29, 2011 at 11:01:11AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >>I think it will receive them after migration, since the command ring
> >>was stored.
> >Our confusion here is because you think there is still seemless migration.
> >Unfortunately
> >it doesn't work right now, unless you
Hi,
I think it will receive them after migration, since the command ring
was stored.
Our confusion here is because you think there is still seemless migration.
Unfortunately
it doesn't work right now, unless you plan to fix it the only form of migration
right
now is switch-host, and for tha
reat the client as seemless you are completely
right.
> >
> >stop is called before hw/qxl.c:qxl_pre_save, from
> >ui/spice-display.c:qemu_spice_vm_change_state_handler
> >
> >
> >>
> >>Cheers,
> >>Yonit.
> >>
> >>>&g
ted before migration doesn't get some of
the messages it was supposed to get.
stop is called before hw/qxl.c:qxl_pre_save, from
ui/spice-display.c:qemu_spice_vm_change_state_handler
>
> Cheers,
> Yonit.
>
> >>
> >>----- Original Message -
> >>From
d before hw/qxl.c:qxl_pre_save, from
ui/spice-display.c:qemu_spice_vm_change_state_handler
Cheers,
Yonit.
- Original Message -
From: "Alon Levy"
To: "Gerd Hoffmann"
Cc: qemu-devel@nongnu.org, yhalp...@redhat.com
Sent: Wednesday, June 22, 2011 11:57:54 AM
Subject: Re: [Qemu-devel] [P
ot;
Cc: qemu-devel@nongnu.org, yhalp...@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
ly render the surfaces.
Perhaps RED_WORKER_MESSAGE_STOP should do a flush_all_qxl_commands?
>
> - Original Message -
> From: "Alon Levy"
> To: "Gerd Hoffmann"
> Cc: qemu-devel@nongnu.org, yhalp...@redhat.com
> Sent: Wednesday, June 22, 2011 11:57:54
: qemu-devel@nongnu.org, yhalp...@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
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 param
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) h
On 06/20/2011 07:32 PM, Alon Levy wrote:
On Mon, Jun 20, 2011 at 05:50:32PM +0200, Gerd Hoffmann wrote:
On 06/20/11 17:11, Alon Levy wrote:
On Mon, Jun 20, 2011 at 04:07:59PM +0200, Gerd Hoffmann wrote:
What is the difference to one worker->stop() + worker->start() cycle?
ok, stop+start won
On Mon, Jun 20, 2011 at 06:32:30PM +0200, Alon Levy wrote:
> On Mon, Jun 20, 2011 at 05:50:32PM +0200, Gerd Hoffmann wrote:
> > On 06/20/11 17:11, Alon Levy wrote:
> > >On Mon, Jun 20, 2011 at 04:07:59PM +0200, Gerd Hoffmann wrote:
> > What is the difference to one worker->stop() + worker->star
On Mon, Jun 20, 2011 at 05:50:32PM +0200, Gerd Hoffmann wrote:
> On 06/20/11 17:11, Alon Levy wrote:
> >On Mon, Jun 20, 2011 at 04:07:59PM +0200, Gerd Hoffmann wrote:
> What is the difference to one worker->stop() + worker->start() cycle?
>
> >>>
> >>>ok, stop+start won't disconnect any cl
On 06/20/11 17:11, Alon Levy wrote:
On Mon, Jun 20, 2011 at 04:07:59PM +0200, Gerd Hoffmann wrote:
What is the difference to one worker->stop() + worker->start() cycle?
ok, stop+start won't disconnect any clients either. But does stop render all
waiting commands?
I'll have to look, I don't k
On Mon, Jun 20, 2011 at 05:11:07PM +0200, Alon Levy wrote:
> On Mon, Jun 20, 2011 at 04:07:59PM +0200, Gerd Hoffmann wrote:
> > >>What is the difference to one worker->stop() + worker->start() cycle?
> > >>
> > >
> > >ok, stop+start won't disconnect any clients either. But does stop render
> > >al
On Mon, Jun 20, 2011 at 04:07:59PM +0200, Gerd Hoffmann wrote:
> >>What is the difference to one worker->stop() + worker->start() cycle?
> >>
> >
> >ok, stop+start won't disconnect any clients either. But does stop render all
> >waiting commands?
> >I'll have to look, I don't know if it does.
>
>
What is the difference to one worker->stop() + worker->start() cycle?
ok, stop+start won't disconnect any clients either. But does stop render all
waiting commands?
I'll have to look, I don't know if it does.
It does. This is what qemu uses to flush all spice server state to
device memory
On Mon, Jun 20, 2011 at 02:13:36PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >+case QXL_IO_UPDATE_MEM:
> >+switch (val) {
> >+case (QXL_UPDATE_MEM_RENDER_ALL):
> >+d->ssd.worker->update_mem(d->ssd.worker);
> >+break;
>
> What is the difference to one work
On Mon, Jun 20, 2011 at 02:13:36PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >+case QXL_IO_UPDATE_MEM:
> >+switch (val) {
> >+case (QXL_UPDATE_MEM_RENDER_ALL):
> >+d->ssd.worker->update_mem(d->ssd.worker);
> >+break;
>
> What is the difference to one work
Hi,
+case QXL_IO_UPDATE_MEM:
+switch (val) {
+case (QXL_UPDATE_MEM_RENDER_ALL):
+d->ssd.worker->update_mem(d->ssd.worker);
+break;
What is the difference to one worker->stop() + worker->start() cycle?
cheers,
Gerd
Add QXL_IO_UPDATE_MEM. Used to reduce vmexits from the guest when it resets the
spice server state before going to sleep.
The implementation requires an updated spice-server (0.8.2) with the new
worker function update_mem.
Cc: Yonit Halperin
---
hw/qxl.c | 26 ++
1 fil
29 matches
Mail list logo
