Hi,
Win7 guest hangs all the time while doing shutdown. Noticed this behaviour with
Upstream Spice.
Issue happens:
when guest is launched with dual monitors in full-screen with Auto-conf mode
Issue doesn't happens:
1.) when guest is launched with single monitor in full-screen with Auto-
On 2/17/2012 9:08 AM, Marc-André Lureau wrote:
>> On 2/14/2012 6:44 PM, Marc-André Lureau wrote:
>> (sadly, with the old win32 spicec implementation, --secure-channels
>> main,display,inputs,cursor,playback,record did not work...something
>> about mismatched SSL versions.)
>
> Spice-gtk doesn't ha
On Fri, Feb 17, 2012 at 04:10:32PM +0100, Gerd Hoffmann wrote:
> Add two properties to specify bar sizes in megabytes instead of bytes,
> which is alot more user-friendly.
>
ACK.
> Signed-off-by: Gerd Hoffmann
> ---
> hw/qxl.c |8
> hw/qxl.h |4
> 2 files changed, 12 inse
On Fri, Feb 17, 2012 at 04:10:33PM +0100, Gerd Hoffmann wrote:
> This patch adds an 64bit pci bar for vram. It is turned off by default.
> It can be enabled by setting the size of the 64bit bar to be larger than
> the 32bit bar. Both 32bit and 64bit bar refer to the same memory. Only
> the first
On Fri, Feb 17, 2012 at 04:10:31PM +0100, Gerd Hoffmann wrote:
> Factor memory bar sizing bits out to a separate function.
ACK.
>
> Signed-off-by: Gerd Hoffmann
> ---
> hw/qxl.c | 41 ++---
> 1 files changed, 22 insertions(+), 19 deletions(-)
>
> diff --g
On Fri, Feb 17, 2012 at 04:10:30PM +0100, Gerd Hoffmann wrote:
> There is no reason to require a minimum size of 16 MB for the vram.
> Lower the limit to 4096 (one page). Make it disapper completely would
> break guests.
NM my nitpick, more readable this way, ACK.
> ---
> hw/qxl.c |4 ++--
>
On Fri, Feb 17, 2012 at 04:10:30PM +0100, Gerd Hoffmann wrote:
> There is no reason to require a minimum size of 16 MB for the vram.
> Lower the limit to 4096 (one page). Make it disapper completely would
> break guests.
> ---
> hw/qxl.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletion
On Fri, Feb 17, 2012 at 01:08:42PM +0100, Paolo Bonzini wrote:
> On 02/17/2012 10:08 AM, Alon Levy wrote:
> > Isn't this another candidate for ifdeferry?
>
> It actually applies to Linux too, except that IOV_MAX is 1024.
>
> See in fs/read_write.c
>
> 709 static ssize_t do_readv_writev(int type,
This patch adds an 64bit pci bar for vram. It is turned off by default.
It can be enabled by setting the size of the 64bit bar to be larger than
the 32bit bar. Both 32bit and 64bit bar refer to the same memory. Only
the first part of the memory is available via 32bit bar.
The intention is to al
Add two properties to specify bar sizes in megabytes instead of bytes,
which is alot more user-friendly.
Signed-off-by: Gerd Hoffmann
---
hw/qxl.c |8
hw/qxl.h |4
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 38bb90e..87ad49a 100
There is no reason to require a minimum size of 16 MB for the vram.
Lower the limit to 4096 (one page). Make it disapper completely would
break guests.
---
hw/qxl.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 5c6b556..4de4b8d 100644
--- a/
Factor memory bar sizing bits out to a separate function.
Signed-off-by: Gerd Hoffmann
---
hw/qxl.c | 41 ++---
1 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 4de4b8d..38bb90e 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@
Hi,
This patch series tweaks the qxl memory bar size configuration a bit.
The first three are pretty straigt forward. I'm looking for comments
on the last one which adds a 64bit vram bar.
cheers,
Gerd
Gerd Hoffmann (4):
qxl: drop vram bar minimum size
qxl: move ram size init to new func
Hi
- Mensaje original -
> On 2/14/2012 6:44 PM, Marc-André Lureau wrote:
> (sadly, with the old win32 spicec implementation, --secure-channels
> main,display,inputs,cursor,playback,record did not work...something
> about mismatched SSL versions.)
Spice-gtk doesn't have similar option, as
On 02/17/2012 02:18 PM, Alon Levy wrote:
>> > - guaranteed bitrot in the poll() path :)
>> >
> Yeah, I guess you are right. I'm worried since I don't know the
> difference in performance between epoll and poll
You can assume it to be zero unless you have a lot of descriptors (50 is
probably not e
On Fri, Feb 17, 2012 at 12:53:48PM +0100, Paolo Bonzini wrote:
> On 02/17/2012 10:05 AM, Alon Levy wrote:
> > The patch itself looks ok, but I'm not sure I like the direction. Why
> > not specialize, have epoll for linux and poll if epoll isn't supported?
> > - double the code
> > + no possible r
I am trying to enable spice for qemu and can't get past the check it does by
compiling a c file. Contents below:
#include
int main(void) { spice_server_new(); return 0; }
Error is:
gcc -fPIE -DPIE -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototype
On 02/17/2012 12:59 PM, Daniel P. Berrange wrote:
>>> > > The patch itself looks ok, but I'm not sure I like the direction. Why
>>> > > not specialize, have epoll for linux and poll if epoll isn't supported?
>>> > > - double the code
>>> > > + no possible regression
>> >
>> > - guaranteed bitrot
On 02/17/2012 10:08 AM, Alon Levy wrote:
> Isn't this another candidate for ifdeferry?
It actually applies to Linux too, except that IOV_MAX is 1024.
See in fs/read_write.c
709 static ssize_t do_readv_writev(int type, struct file *file,
710const struct iovec __use
On Fri, Feb 17, 2012 at 12:53:48PM +0100, Paolo Bonzini wrote:
> On 02/17/2012 10:05 AM, Alon Levy wrote:
> > The patch itself looks ok, but I'm not sure I like the direction. Why
> > not specialize, have epoll for linux and poll if epoll isn't supported?
> > - double the code
> > + no possible r
On 02/17/2012 10:05 AM, Alon Levy wrote:
> The patch itself looks ok, but I'm not sure I like the direction. Why
> not specialize, have epoll for linux and poll if epoll isn't supported?
> - double the code
> + no possible regression
- guaranteed bitrot in the poll() path :)
Paolo
_
On Thu, Feb 16, 2012 at 11:30:13PM -0600, Dan McGee wrote:
> This is provided by on all platforms as long as _XOPEN_SOURCE
> is defined. On Linux, this is 1024, on Solaris, this is 16, and on any
> other platform, we now respect the value supported by the OS.
>
ACK
> Signed-off-by: Dan McGee
>
On Thu, Feb 16, 2012 at 11:30:07PM -0600, Dan McGee wrote:
> This is supported by the GNU linker, but not the Solaris linker, which
> is used as the default on that platform even when compiling with GCC.
> Omit passing the option to the linker on platforms that do not support
> it.
>
> Signed-off-
On Thu, Feb 16, 2012 at 11:30:12PM -0600, Dan McGee wrote:
> Solaris has a pitiful maximum writev vector size of only 16, so the ping
> request at initial startup destroyed this call and broke things
> immediately. Reimplement stream_writev_cb() to respect IOV_MAX and break
> the writev() calls int
On Thu, Feb 16, 2012 at 11:30:06PM -0600, Dan McGee wrote:
The title says non-linux, when in fact it's obvious from the rest of
what you write that the use case is Solaris. Why not say that?
> This is a set of patches to enable building the server library on a non-Linux,
> non-pure-GNU toolchain
On Thu, Feb 16, 2012 at 11:30:11PM -0600, Dan McGee wrote:
> This removes the epoll dependency we had in red_worker, which was the
> last Linux-specific call we were using in the entire Spice server. Given
> we never have more than 10 file descriptors involved, there is little
> performance gain ha
On Thu, Feb 16, 2012 at 11:30:10PM -0600, Dan McGee wrote:
> Rather than assign the callbacks one-by-one, we can just memcpy the
> struct into the one we have allocated in our RedChannel object, which is
> much more efficient, not to mention future-proof when more callbacks are
> added.
ACK.
>
>
On Thu, Feb 16, 2012 at 11:30:09PM -0600, Dan McGee wrote:
> We had multiple stub methods that simply called other disconnect
> methods, making my head hurt with the indirection. Call the right
> methods at the right time and rip out the stub methods; if they are
> truely needed later they can be a
On Thu, Feb 16, 2012 at 11:30:08PM -0600, Dan McGee wrote:
> With future patches in mind that will allow for some other
> non-Linux-specific event polling sytem to be used, rename this to a more
> generic name. All of the select/poll/epoll/kqueue family of calls are
> related to evented I/O, so 'ev
29 matches
Mail list logo
