Hi John,
See my comments below.
Arnon
John A. Sullivan III wrote:
Hello, all. I'm spinning this off of the "Unfair Comparisons with RDP"
thread as that one is getting a bit long. However, in it, Yaniv
identified that we were not using vdagent in our Windows guest based
upon the packet traces w
Hi John,
See my comments below.
Arnon
John A. Sullivan III wrote:
Hello, all. Being a Windows ignoramus, I am having a nightmare of a
time compiling the Windows client on our Windows 7 build system. I'll
recount them for other ignorami and to ask for help for the things I
could not figure out.
Hello, all. I'm spinning this off of the "Unfair Comparisons with RDP"
thread as that one is getting a bit long. However, in it, Yaniv
identified that we were not using vdagent in our Windows guest based
upon the packet traces we submitted. That sounded plausible as we have
noticed the agent bei
Hello, all. Being a Windows ignoramus, I am having a nightmare of a
time compiling the Windows client on our Windows 7 build system. I'll
recount them for other ignorami and to ask for help for the things I
could not figure out.
I installed the Windows SDK 7.1 and it installed without compilers
On 07/04/2011 07:33 PM, John A. Sullivan III wrote:
On Mon, 2011-07-04 at 17:48 +0300, Yonit Halperin wrote:
On 07/04/2011 05:21 PM, John A. Sullivan III wrote:
Very helpful and interesting. I'll respond in-line - John
On Sun, 2011-07-03 at 10:38 +0300, Yaniv Kaul wrote:
On 06/30/2011 10:10
On Jul 4, 2011 6:25 PM, "John A. Sullivan III" <
jsulli...@opensourcedevel.com> wrote:
> However, spicec looks like it is in 0.8.1 whereas the download page says
> gtk is experimental and provides a link with the latest versio being 0.6
> from April. Thanks - John
>
Hi,
I believe that spice-gtk f
On Mon, Jul 04, 2011 at 01:25:01PM -0400, John A. Sullivan III wrote:
> Which client should one use? I'm a little confused reading the
> documentation version looking at the download page.
>
> http://spice-space.org/page/DeveloperStartPage says, "client - this is
> the old spice client. It is stil
Which client should one use? I'm a little confused reading the
documentation version looking at the download page.
http://spice-space.org/page/DeveloperStartPage says, "client - this is
the old spice client. It is still supported but is being phased out in
favor of a new widgetized gtk/glib based
> How does /proc/iomem look like with 128Mb?
I couldn't log in to the guest, since the host was overloaded with the MSI-X
message. I should try with logging deactivated.
Anyway, the problem occured again (still with 64Mb), and here is iomem :
- : reserved
0001-0009f3ff : Sy
On Mon, 2011-07-04 at 17:48 +0300, Yonit Halperin wrote:
> On 07/04/2011 05:21 PM, John A. Sullivan III wrote:
> > Very helpful and interesting. I'll respond in-line - John
> >
> > On Sun, 2011-07-03 at 10:38 +0300, Yaniv Kaul wrote:
> >> On 06/30/2011 10:10 AM, Yaniv Kaul wrote:
> >>> On 06/30/20
When the cursor channel creates a new cursor, if the message
indicates not to cache it, the cursor is leaked after being used.
This commit fixes that, though I'm not really satisfied with it.
==22568== 378,432 bytes in 162 blocks are definitely lost in loss record 7,699
of 7,699
==22568==at 0
On 07/04/2011 05:21 PM, John A. Sullivan III wrote:
Very helpful and interesting. I'll respond in-line - John
On Sun, 2011-07-03 at 10:38 +0300, Yaniv Kaul wrote:
On 06/30/2011 10:10 AM, Yaniv Kaul wrote:
On 06/30/2011 05:33 AM, John A. Sullivan III wrote:
On Wed, 2011-06-29 at 20:22 -0400,
Very helpful and interesting. I'll respond in-line - John
On Sun, 2011-07-03 at 10:38 +0300, Yaniv Kaul wrote:
> On 06/30/2011 10:10 AM, Yaniv Kaul wrote:
> > On 06/30/2011 05:33 AM, John A. Sullivan III wrote:
> >> On Wed, 2011-06-29 at 20:22 -0400, Andrew Cathrow wrote:
> >>>
> >>> - Origin
On 07/04/11 14:08, Yonit Halperin wrote:
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
Added to spice patch queue.
thanks,
Gerd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freede
Hi,
I see, thanks. In this case, the change adds new messages and new methods
for the Playback and Record channels, so nothing should change unless these
new methods are explicitly called from qemu, which means raising the minor
version number was probably not strictly needed (but not harmful
Hi,
On Mon, Jul 04, 2011 at 01:27:16PM +0200, Gerd Hoffmann wrote:
> On 07/01/11 15:58, Christophe Fergeau wrote:
> >if (strcmp(interface->type, SPICE_INTERFACE_RECORD) == 0) {
> > red_printf("SPICE_INTERFACE_RECORD");
> > if (interface->major_version != SPICE_INTERFACE_RECORD_MAJOR ||
> >
On migration, destroy_surfaces is called from qxl (qxl_hard_reset), before the
device was loaded (on destination).
handle_dev_destroy_surfaces led to red_process_commands, which read the qxl
command ring
(which appeared to be not empty), and then when processing the command
it accessed unmapped m
On 06/24/2011 02:52 PM, Alon Levy wrote:
ret = read(d->aio_pipe[0],&io, sizeof(io));
+if (ret< 0&& (errno == EAGAIN || errno == EINTR)) {
+continue;
+}
This means you'd be busy waiting if you get EAGAIN. If you really need
EAGAIN, perhaps there is anoth
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..b3a3507 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_c
Hi,
+qxl_set_dirty(devram_addr, devram_addr + qxl->rom->surface0_area_size);
s/rom/shadow_rom/, then it is perfect. rom points directly to guest
memory, better don't trust that.
cheers,
Gerd
___
Spice-devel mailing list
Spice-devel@li
On 07/03/11 15:12, Frédéric Grelot wrote:
[ 664.762] Out of surfaces [ 664.802] Out of surfaces
I suspected that this was somewhat related to the resolution I did
set in X : 1920x1080. I then set the VRAM size to 128Mb instead of
64Mb : unfortunately, the host was overloaded with the f
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..cff95a4 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_c
On 07/01/11 15:58, Christophe Fergeau wrote:
Hi,
While looking at a crash in qemu when SPICE_INTERFACE_PLAYBACK_MINOR was
increased, I came across the version checking code in spice_server_add_interface
in server/reds.c which does stuff like
if (strcmp(interface->type, SPICE_INTERFACE_RECORD) =
On Mon, Jul 04, 2011 at 12:01:02PM +0200, Alon Levy wrote:
> > I was about to mention that these warnings are probably one of the smallest
> > issue you'll encounter on a 32 bit spice-server build. However, the patch
> > doesn't hurt, it's actually a first step in the right direction, and I
> > ass
Hi,
+qxl_set_dirty(devram_addr, devram_addr + qxl->vga.vram_size);
It is enougth to dirty the surface0 area.
Otherwise the patch looks fine.
cheers,
Gerd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedes
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..9fdeffb 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
qemu_spice_vm_c
On Mon, Jul 04, 2011 at 10:53:33AM +0200, Christophe Fergeau wrote:
> On Mon, Jul 04, 2011 at 09:37:53AM +0300, Uri Lublin wrote:
> > On 07/03/2011 04:27 PM, Rami Vaknin wrote:
> > > From: root
> > >
> > > Compiling with gcc-c++-4.6.0-9.fc15.i686 on Fedora 15
> >
> > The spice server is compiled
Hi
- Original Message -
> On Sat, Jul 02, 2011 at 05:06:39AM +0200, Alon Levy wrote:
> > --- a/gtk/spice-channel-priv.h
> > +++ b/gtk/spice-channel-priv.h
> > @@ -123,6 +123,8 @@ struct spice_channel {
> > GArray *common_caps;
> > GArray *remote_caps;
> > GArray *remote_comm
On 07/04/2011 12:23 PM, Gerd Hoffmann wrote:
On 07/04/11 10:51, Yonit Halperin wrote:
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset), flush_all_qxl_comma
On 07/04/11 10:51, Yonit Halperin wrote:
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is
called. When attempting to process a co
On 07/04/2011 11:54 AM, Yonit Halperin wrote:
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is
called. When attempting to process
On Sun, Jul 03, 2011 at 05:57:08PM +0200, Alon Levy wrote:
> On Sun, Jul 03, 2011 at 04:27:57PM +0300, Rami Vaknin wrote:
> > From: root
> >
>
> ACK. I'll push this.
This adds warnings on 64 bit builds:
main_channel.c: In function 'main_channel_handle_parsed':
main_channel.c:736:21: error: for
On Mon, Jul 04, 2011 at 09:37:53AM +0300, Uri Lublin wrote:
> On 07/03/2011 04:27 PM, Rami Vaknin wrote:
> > From: root
> >
> > Compiling with gcc-c++-4.6.0-9.fc15.i686 on Fedora 15
>
> The spice server is compiled for 64 bit machines (at least currently).
> Try compiling with gcc-c++-*.fc15.x86_
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is
called. When attempting to process a command we receive
id 0, group 0, virt star
On Sat, Jul 02, 2011 at 05:06:39AM +0200, Alon Levy wrote:
> --- a/gtk/spice-channel-priv.h
> +++ b/gtk/spice-channel-priv.h
> @@ -123,6 +123,8 @@ struct spice_channel {
> GArray *common_caps;
> GArray *remote_caps;
> GArray
In addition (1) make handle_dev_destroy_surfaces call red_release_cursor
(2) call red_wait_outgoing_item(cursor_channel) only after adding msgs to pipe
---
server/red_worker.c | 71 +-
1 files changed, 24 insertions(+), 47 deletions(-)
diff --git
When the worker was stoped, the cursor was copied from guest ram to the host
ram,
and its corresponding qxl command was released.
This is unecessary, since the qxl ram still exists (we keep references
to the surfaces in the same manner).
It also led to BSOD on guest upon migration: the device trac
37 matches
Mail list logo
