From SHM_OPEN(3):
For portable use, a shared memory object should be identified by a name
of the form /somename; that is, a null-terminated string of up to
NAME_MAX (i.e., 255) characters consisting of an initial slash,
followed by one or more characters, none of which are slashes.
---
We leave all the hard work of setting up the socket to qemu.
This will cause all of the TCP setsockopt calls to return ENOSUP
but that is okay.
---
server/reds.c| 21 +
server/spice-server.syms |1 +
server/spice.h |1 +
3 files changed, 23 inser
These patches are to allow listening on a UNIX socket rather
than a TCP port. Support is needed in QEMU.
Example QEMU patches (against a different QEMU tree) can be found at
https://github.com/nshalman/illumos-kvm-cmd
Feedback requested!
Nahum Shalman (2):
server: don't fail on ENOSUP
These are the only instances in the code base where functions fail as a
result of setsockopt calls returning ENOSUP.
Those calls will always return ENOSUP when we are listening on a UNIX
socket rather than a TCP port.
We'd prefer not to fail.
---
server/inputs_channel.c |1 -
server/spicevmc.c
On 03/09/2012 11:15 AM, Daniel P. Berrange wrote:
Huh. This code already avoids failure when you get ENOTSUP. You're
removing the code path where the errno is *not* ENOTSUP
You're right. I need to go back and figure out which error we were getting.
Thank you.
-Nahum
_
ts of different scenarios.
Nahum Shalman (2):
server: don't fail on ENOPROTOOPT from setsockopt
server: listen on a pre-opened file descriptor
server/inputs_channel.c |2 +-
server/reds.c| 21 +
server/spice-server.syms |1 +
server/spice.h
Allow applications to pre-open a file descriptor and have spice listen
on it.
Thanks to Daniel Berrange for his comments
---
server/reds.c| 21 +
server/spice-server.syms |1 +
server/spice.h |1 +
3 files changed, 23 insertions(+), 0 deletions(
If we allow listening on arbitrary sockets like unix sockets,
we can get ENOPROTOOPT errors from setsockopt calls that set TCP
specific options. This should be allowed to happen.
---
server/inputs_channel.c |2 +-
server/spicevmc.c |2 +-
2 files changed, 2 insertions(+), 2 deletion
, 2012 at 12:26:50PM -0500, Nahum Shalman wrote:
If we allow listening on arbitrary sockets like unix sockets,
we can get ENOPROTOOPT errors from setsockopt calls that set TCP
specific options. This should be allowed to happen.
I'm a little concerned that we will ignore actual errors for TCP
Hey everyone, I think I found a bug:
I've been living on the bleeding edge of the spice repos and a vm I was
running was tripping over
quic.c line 1242 (lots of errors spewing on the console).
It looks like a sane check for NULL pointers in the quic_encode function:
1241if (line == NULL) {
The price of living on the edge is I find the fun bugs... :)
I have VMs running that have been crashing when someone is watching
video (I'm pretty sure there's always sound at the same time).
I'm running on code from spice.git at
8cd92109d42db45fd5b3aa9674b2148550ffe17b
The last thing I get o
I'm much happier about this one since it now happens to me pretty much
every time I use a VM.
Once again, I'm using the latest bits as of a couple days ago with a
modified qemu running under illumos.
I'm reliably tripping an assert in red_worker.c
(it's annoying when that happens... qemu just s
On 05/01/2012 01:17 PM, Yonit Halperin wrote:
I'm doing some changes in this part of the code, but so far I haven't
tripped into this assert (before applying my changes, and without
pulling changes from the last week or two). Can you bisect this?
What guest are you running?
I probably can't bi
consolidate two separate chunks of library hunting that depend on the
same check, and check if we're actually building the client.
hide some of the final output if we're not building the client
---
configure.ac | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a
Consolidate two separate chunks of library hunting that depend on the
same check.
Check if we're actually building the client before looking for
client only libraries.
Hide some of the final output if we're not building the client.
---
I think this should address the rest of the concerns about
th
Jeremy White wrote:
I need to improve the performance of the xf86-video-qxl driver; aka
xspice; by a fairly substantial margin.
I've set up a test case - LibreOffice over an 80 ms latency connection -
that demonstrates that it's got quite a long way to go. (The current
case appears to suffer fr
I need help tracking this down:
((null):66324): SpiceWorker-ERROR **:
../spice-common/common/ring.h:56:ring_add: assertion `ring->next != NULL
&& ring->prev != NULL' failed
I've been seeing this from time to time on my VMs.
When it happens, the UI stops being responsive, but QEMU doesn't crash
If we allow listening on arbitrary sockets like unix sockets,
we can get ENOPROTOOPT errors from setsockopt calls that set TCP
specific options. This should be allowed to happen.
This time it's reds.c
see also: 20c7323c9efb22c1aae37557814f21cf58c2a322
---
server/reds.c |2 +-
1 files change
On 07/22/2012 02:14 PM, Yonit Halperin wrote:
Hi,
the trace implies some problem in the drawables tree structure. Please
describe in more details how you reproduce it: which web site, which
browser you use, what operations you execute on the web site? In
addition, what is the qxl driver versio
On 07/25/2012 07:39 AM, Yonit Halperin wrote:
Thanks for the detailed description. I've reproduced and found the
bug. Just sent the patch. You are welcomed to try it :)
That patch seems to be working for me as well.
+1
Thanks!
-Nahum
___
Spice-devel
Below I've pasted a stripped down version of a kickstart file I used to
get Fedora 17 working as a spice VM.
(original is at http://www.shalman.org/spice/fedora17.ks)
It gave me a working KDE VM.
A plain install of Fedora 17 seemed to freeze for me, but I haven't done
any digging into the diff
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index edda8e9..a549ed9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@ m4_define([SPICE_AGE], [8])
# Note on the library name on linux (SONAME) produced by libtool
This patch series includes one typo correction and one patch
for which I'd like feedback.
I don't fully understand the latency monitoring system, but I
did manage to figure out two interesting pieces of information:
1. TIOCOUTQ and SIOCOUTQ are the same number
$ grep TIOCOUTQ /usr/include/linux/s
The ioctl on sockets is actually named SIOCOUTQ though its value
is identical to TIOCOUTQ which is for terminals.
SIOCOUTQ is linux specific so we add a header check and ifdef based
on the presence of the header / macro
This prevents bogus ioctls on non-Linux platforms
---
configure.ac |
The ioctl on sockets is actually named SIOCOUTQ though its value
is identical to TIOCOUTQ which is for terminals.
SIOCOUTQ is linux specific so we add a header check and ifdef based
on the presence of the header
This prevents bogus ioctls on non-Linux platforms
---
configure.ac |1 +
s
On 07/28/2013 03:14 PM, Alon Levy wrote:
unused variable 'so_unsent_size' [-Werror=unused-variable]
---
Nahum, could you check that this works for you?
Works for me*. Sorry for introducing a compiler error!
-Nahum
* As much as the other patch works. It compiles and runs, but I get a
freeze the
Context:
Host is running qemu-kvm 1.1.2 and spice 0.12.2.
Fedora 16 VMs ran rock solid on these same virtualization hosts.
The Fedora 19 and 20(testing) VMs are running xf86-video-qxl compiled
from the master branch of the git repo.
We've been seeing a lot of X server crashes in Fedora 19 and 2
On 11/18/2013 05:32 PM, Dave Airlie wrote:
On Tue, Nov 19, 2013 at 7:04 AM, Nahum Shalman wrote:
Context:
Host is running qemu-kvm 1.1.2 and spice 0.12.2.
Fedora 16 VMs ran rock solid on these same virtualization hosts.
The Fedora 19 and 20(testing) VMs are running xf86-video-qxl compiled from
28 matches
Mail list logo
