On Sat, Dec 12, 2009 at 1:31 PM, Anthony Liguori wrote:
> Soeren Sandmann wrote:
>>
>> Hi,
>>
>> Here is an overview of what the current QXL driver does and does not
>> do. The parts of X rendering that are currently being used by cairo
>> and Qt are:
>>
>> - Most of XRender - Image compos
hi guy,which file in QEMU is related with I/O activity ?
On Fri, 11 Dec 2009 21:31:34 -0600
Anthony Liguori wrote:
>
> Okay, that's in line with what my expectations were. So what's the
> future of Spice for X? Anything clever or is Windows the only target
> right now?
Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.
I dont unders
Paolo Bonzini wrote:
On 12/11/2009 10:58 PM, Anthony Liguori wrote:
The concerns have been 1) they will be abused with the introduction
of proprietary plugins
How so?
A typical scenario is someone develops a closed source plugin, but does
not distribute it with the original piece of softwar
Paolo Bonzini wrote:
On 12/11/2009 10:54 PM, Anthony Liguori wrote:
The point is, there isn't a "draw a rectangle" primitive in X. There
also isn't a "draw some text using this font" in X.[1]
Not necessarily, the X server can support the render extension which
allows compositing operations
Soeren Sandmann wrote:
Hi,
Here is an overview of what the current QXL driver does and does not
do. The parts of X rendering that are currently being used by cairo
and Qt are:
- Most of XRender
- Image compositing
- Glyphs
Does anything use Xrender for drawing glyphs the
Chris Wright wrote:
* Anthony Liguori (anth...@codemonkey.ws) wrote:
Izik Eidus wrote:
Ok, I guess you think VDI-interfaces are doing much more than they do
in reiality.
It is just simple interface to Allow Spice / VNC / whatever not have to
de-duplicate code in order to get informatio
Oops gmail send this, silly laptop has a mind of its own sometimes.
On Sat, Dec 12, 2009 at 11:58 AM, Dave Airlie wrote:
> So I've been musing on the addition of some sort of 3D passthrough for
> qemu (as I'm sure have lots of ppl)
>
> But I think the goals of such an addition need to be discusse
So I've been musing on the addition of some sort of 3D passthrough for
qemu (as I'm sure have lots of ppl)
But I think the goals of such an addition need to be discussed prior
to anyone writing a line of code.
Current existing solutions in the area:
a) VMware virtual graphics adapter - based on D
On Sat, 12 Dec 2009 02:08:05 +0100
Alexander Graf wrote:
> So the thing I dislike is the "take all of QXL and SPICE or leave
> everything" sort of attitude that's coming over. I'd love to use QXL,
> but I don't want to use SPICE :-). Thus I want to make sure we're
> going in a really modular dire
The proper logging is handled by generic code.
Signed-off-by: Richard Henderson
---
target-alpha/translate.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 3773ab4..e426677 100644
--- a/target-alpha/translate.c
Similar in difficulty to ext*l, already expanded.
Signed-off-by: Richard Henderson
---
target-alpha/helper.h|4
target-alpha/op_helper.c | 20
target-alpha/translate.c | 38 ++
3 files changed, 30 insertions(+), 32 deleti
The architecture manual specifies the EXT instructions
in terms of the ZAPNOT operation; writing it that way in
the translator makes things a bit clearer.
Signed-off-by: Richard Henderson
---
target-alpha/translate.c | 57 -
1 files changed, 25 inse
Similar in difficulty to ext*l, already expanded.
Signed-off-by: Richard Henderson
---
target-alpha/helper.h|4 --
target-alpha/op_helper.c | 24 -
target-alpha/translate.c | 87 +++---
3 files changed, 59 insertions(+), 56 deletio
The old fcmov implementation had a typo:
-tcg_gen_mov_i64(cpu_fir[rc], cpu_fir[ra]);
which moved the condition, not the second source, to the destination.
But it's also easy to implement the simplified fp comparison inline.
Signed-off-by: Richard Henderson
---
target-alpha/helper.h
Signed-off-by: Richard Henderson
---
target-alpha/helper.h|3 --
target-alpha/op_helper.c | 18
target-alpha/translate.c | 51 -
3 files changed, 45 insertions(+), 27 deletions(-)
diff --git a/target-alpha/helper.h b/targe
The instructions use a disp21 like all other branch insns,
not the disp16 that was being passed.
Signed-off-by: Richard Henderson
---
target-alpha/translate.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
ind
When emulating user-mode only, there's no reason to exit
the translation block to effect a call_pal. We can generate
a move to/from the unique slot directly.
Signed-off-by: Richard Henderson
---
hw/alpha_palcode.c | 11 +--
target-alpha/translate.c | 39 ++
Properly handle move from the zero register.
Signed-off-by: Richard Henderson
---
target-alpha/translate.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index d361ffe..3773ab4 100644
--- a/target-alpha/trans
Signed-off-by: Richard Henderson
---
target-alpha/helper.h|3 --
target-alpha/op_helper.c | 15 ---
target-alpha/translate.c | 63 +++--
3 files changed, 49 insertions(+), 32 deletions(-)
diff --git a/target-alpha/helper.h b/target-alp
There are two -d flags fixes herein, which helps with the rest.
Otherwise the improvements are in 3 categories:
(1) Implement the rd/wrunique PALcall in the translator, at least for
usermode. There's no reason to break the TB for a register move.
(2) Implement the byte manipulation instruct
The vast majority of zap instructions have an immediate operand,
since zapnot is the canonical method to zero-extend from u16 or u32.
Signed-off-by: Richard Henderson
---
target-alpha/translate.c | 61 -
1 files changed, 59 insertions(+), 2 deletion
Signed-off-by: Richard Henderson
---
target-alpha/helper.h| 14
target-alpha/op_helper.c | 168 ++
target-alpha/translate.c | 79 +
3 files changed, 231 insertions(+), 30 deletions(-)
diff --git a/target-alpha/helper.
Generic disassembly was incorrectly keyed on ALPHA_DEBUG_DISAS
rather than the generic DEBUG_DISAS. Use qemu_log_mask for
additional LOG_DISAS output. Delete some random insn_count
logging noise from gen_intermediate_code_internal.
Signed-off-by: Richard Henderson
---
target-alpha/translate.c
Am 06.12.2009 um 07:37 schrieb malc:
On Sun, 6 Dec 2009, Andreas F?rber wrote:
Am 06.12.2009 um 06:14 schrieb malc:
On Sun, 6 Dec 2009, Andreas Faerber wrote:
qemu-system-sparc64 works on ppc64 while it didn't on ppc!
Does it work on linux ppc64? If so
Haven't had a chance to test on
On 12.12.2009, at 01:53, Izik Eidus wrote:
> On Sat, 12 Dec 2009 01:27:09 +0100
> Alexander Graf wrote:
>
>>
>> On 12.12.2009, at 01:14, Izik Eidus wrote:
>>
>>> On Sat, 12 Dec 2009 00:54:47 +0100
>>> Alexander Graf wrote:
>>>
On 11.12.2009, at 23:46, Izik Eidus wrote:
On 12/11/2009 10:58 PM, Anthony Liguori wrote:
The concerns have been 1) they will be abused with the introduction
of proprietary plugins
How so?
2) we would have tremendous difficulty maintaining a stable plugin abi
Then don't promise it. GCC doesn't for example. (And it solves problem
On 12/11/2009 10:54 PM, Anthony Liguori wrote:
The point is, there isn't a "draw a rectangle" primitive in X. There
also isn't a "draw some text using this font" in X.[1]
Not necessarily, the X server can support the render extension which
allows compositing operations on an X pixmap. Firef
On Sat, 12 Dec 2009 01:27:09 +0100
Alexander Graf wrote:
>
> On 12.12.2009, at 01:14, Izik Eidus wrote:
>
> > On Sat, 12 Dec 2009 00:54:47 +0100
> > Alexander Graf wrote:
> >
> >>
> >> On 11.12.2009, at 23:46, Izik Eidus wrote:
> >>
> >>> On Fri, 11 Dec 2009 23:08:01 +0100
> >>> Alexander G
On Fri, Dec 11, 2009 at 7:33 PM, Aurelien Jarno wrote:
> On Fri, Dec 11, 2009 at 05:54:06PM +0900, Jun Koi wrote:
>> Hi,
>>
>> Thanks to everybody helping me to have more understanding on QEmu
>> internals. This community is great!
>>
>> This trivial patch removes some unused params in tcg_out_st(
On 12.12.2009, at 01:31, Izik Eidus wrote:
> On Sat, 12 Dec 2009 01:05:36 +0100
> Alexander Graf wrote:
>
>
>>
>> What does performance look like in comparison to Xrdp? That one does
>> implement bitmap caches. It should be really really close, right?
>
> Untill Spice wont have the opengl su
On Sat, 12 Dec 2009 01:05:36 +0100
Alexander Graf wrote:
>
> What does performance look like in comparison to Xrdp? That one does
> implement bitmap caches. It should be really really close, right?
Untill Spice wont have the opengl support merged, I dont think it fair
to compare it into other
On 12.12.2009, at 01:14, Izik Eidus wrote:
> On Sat, 12 Dec 2009 00:54:47 +0100
> Alexander Graf wrote:
>
>>
>> On 11.12.2009, at 23:46, Izik Eidus wrote:
>>
>>> On Fri, 11 Dec 2009 23:08:01 +0100
>>> Alexander Graf wrote:
>>>
On 11.12.2009, at 22:13, Izik Eidus wrote:
On Sat, 12 Dec 2009 00:54:47 +0100
Alexander Graf wrote:
>
> On 11.12.2009, at 23:46, Izik Eidus wrote:
>
> > On Fri, 11 Dec 2009 23:08:01 +0100
> > Alexander Graf wrote:
> >
> >>
> >> On 11.12.2009, at 22:13, Izik Eidus wrote:
> >>
> >>> On Fri, 11 Dec 2009 14:46:55 -0600
> >>> Anthony Lig
On 12 Dec 2009 00:58:13 +0100
Soeren Sandmann wrote:
>
> However, as things stand right now, there is not much point in adding
> this support, because X applications essentially always work like
> this:
>
> - render to offscreen pixmap
> - copy pixmap to screen
>
> There is not
On 12.12.2009, at 00:58, Soeren Sandmann wrote:
> Hi,
>
> Here is an overview of what the current QXL driver does and does not
> do. The parts of X rendering that are currently being used by cairo
> and Qt are:
>
> - Most of XRender
>- Image compositing
>- Glyphs
>- Tr
Hi,
Here is an overview of what the current QXL driver does and does not
do. The parts of X rendering that are currently being used by cairo
and Qt are:
- Most of XRender
- Image compositing
- Glyphs
- Trapezoids
- Bits of the core protocol:
- Solid fills
On 11.12.2009, at 23:46, Izik Eidus wrote:
> On Fri, 11 Dec 2009 23:08:01 +0100
> Alexander Graf wrote:
>
>>
>> On 11.12.2009, at 22:13, Izik Eidus wrote:
>>
>>> On Fri, 11 Dec 2009 14:46:55 -0600
>>> Anthony Liguori wrote:
>>>
Izik Eidus wrote:
> I personaly dont like mjpeg, and y
On 12/11/2009 02:08 AM, Tristan Gingold wrote:
just in case you weren't aware and are interested: I was able to make
an es40 emulation in qemu good enough to start Linux. I did this
work several months ago, so it need revival. At this time the main
limitation was the absence of IOMMU abstraction
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> Izik Eidus wrote:
>> Ok, I guess you think VDI-interfaces are doing much more than they do
>> in reiality.
>>
>> It is just simple interface to Allow Spice / VNC / whatever not have to
>> de-duplicate code in order to get information from - lets sa
On Fri, 11 Dec 2009 23:08:01 +0100
Alexander Graf wrote:
>
> On 11.12.2009, at 22:13, Izik Eidus wrote:
>
> > On Fri, 11 Dec 2009 14:46:55 -0600
> > Anthony Liguori wrote:
> >
> >> Izik Eidus wrote:
> >>> I personaly dont like mjpeg, and yes in the end of the day you can
> >>> add the video s
The WLAN USB stick ZyXEL NWD271N (0586:3417) uses very large
usb control transfers of more than 2048 bytes which won't fit
into the buffer of the ctrl_struct. This results in an error message
"husb: ctrl buffer too small" and a non-working device.
Increasing the buffer size to 8192 seems to be a sa
On Fri, 11 Dec 2009 15:54:52 -0600
Anthony Liguori wrote:
> Izik Eidus wrote:
> By the time we get to video memory, the display server has
> already straightened out what portions of the screen are visible
> and what aren't. It will not render a hidden window and then
> rende
On 12/12/2009 12:08 AM, Alexander Graf wrote:
On 11.12.2009, at 22:13, Izik Eidus wrote:
On Fri, 11 Dec 2009 14:46:55 -0600
Anthony Liguori wrote:
Izik Eidus wrote:
I personaly dont like mjpeg, and yes in the end of the day you can
add the video streaming into vnc, but what is the point he
On 11.12.2009, at 22:13, Izik Eidus wrote:
> On Fri, 11 Dec 2009 14:46:55 -0600
> Anthony Liguori wrote:
>
>> Izik Eidus wrote:
>>> I personaly dont like mjpeg, and yes in the end of the day you can
>>> add the video streaming into vnc, but what is the point here?
>>>
>>
>> What I'm trying to
Izik Eidus wrote:
Ok, I guess you think VDI-interfaces are doing much more than they do
in reiality.
It is just simple interface to Allow Spice / VNC / whatever not have to
de-duplicate code in order to get information from - lets say the
keyboard
Is it really diffrence from any other funct
Izik Eidus wrote:
By the time we get to video memory, the display server has already
straightened out what portions of the screen are visible and what
aren't. It will not render a hidden window and then render
another window on top of it.
I dont understand, if you have applciati
On Thu, 10 Dec 2009, Andreas Färber wrote:
I don't know about MIPS, but have you tried any of my --whole-archive patches
for Solaris? Not having things initialized properly can lead to mysterious
crashes at startup.
I will have a look a your patches
(http://lists.gnu.org/archive/html/qem
On Fri, 11 Dec 2009, Aurelien Jarno wrote:
Which version are you using? Both stable-0.12 and trunk are working fine
here, at least on a Linux host.
I've been tracking trunk for the last couple of weeks and the problem has
been present all the time.
Probably af host issue then... for refere
Am 06.12.2009 um 07:37 schrieb malc:
will try system-ppc later..
I've tried Debian 4.0r4a ppc netinst CD on Linux/ppc64 and spotted
different but similar deviations:
ppc64 qemu-system-ppc segfaults after "returning from prom_init".
ppc64 qemu-system-ppc64 boots the default "install" optio
On Fri, 11 Dec 2009 14:48:53 -0600
Anthony Liguori wrote:
> Izik Eidus wrote:
> > On Fri, 11 Dec 2009 13:51:53 -0600
> > Anthony Liguori wrote:
> >
> >
> >> libc is not a plugin. It implements very well defined behaviors
> >> that have well understood behaviors. Also, glibc generally does
>
On Wed, Dec 09, 2009 at 01:10:18PM -0800, Andrew Farmer wrote:
> Right now, if an incoming migrate through exec fails, the qemu process
> will end up chewing CPU indefinitely - it looks like it closes the
> migration FD but doesn't remove its IO handler properly. An easy way
> to reproduce this
On Fri, 11 Dec 2009 14:46:55 -0600
Anthony Liguori wrote:
> Izik Eidus wrote:
> > I personaly dont like mjpeg, and yes in the end of the day you can
> > add the video streaming into vnc, but what is the point here?
> >
>
> What I'm trying to understand is, what can we do with Spice that we
>
If a UNIX migration command is attempt to a UNIX socket which does
not exist, then the monitor is suspended, but never resumed. This
prevents any further use of the monitor
* migration-unix.c: Only call migrate_fd_monitor_suspend() once
connected to the UNIX socket.
Signed-off-by: Daniel P.
On Fri, Dec 11, 2009 at 08:49:31PM +, Daniel P. Berrange wrote:
> If a UNIX migration command is attempt to a UNIX socket which does
> not exist, then the monitor is suspended, but never resumed. This
> prevents any further use of the monitor
>
> * migration-unix.c: Only call migrate_fd_monito
If a UNIX migration command is attempt to a UNIX socket which does
not exist, then the monitor is suspended, but never resumed. This
prevents any further use of the monitor
* migration-unix.c: Only call migrate_fd_monitor_suspend() once
connected to the UNIX socket.
---
migration-unix.c | 12
Izik Eidus wrote:
On Fri, 11 Dec 2009 13:51:53 -0600
Anthony Liguori wrote:
libc is not a plugin. It implements very well defined behaviors that
have well understood behaviors. Also, glibc generally does not crash
:-) I would not want a user to replace glibc with a different libc.
Izik Eidus wrote:
I personaly dont like mjpeg, and yes in the end of the day you can add
the video streaming into vnc, but what is the point here?
What I'm trying to understand is, what can we do with Spice that we
couldn't possibly do with vnc. That means understanding each feature
and t
On Fri, 11 Dec 2009 13:51:53 -0600
Anthony Liguori wrote:
> libc is not a plugin. It implements very well defined behaviors that
> have well understood behaviors. Also, glibc generally does not crash
> :-) I would not want a user to replace glibc with a different libc.
I think it problomati
On Fri, 11 Dec 2009 22:53:25 +0300 (MSK)
malc wrote:
> On Fri, 11 Dec 2009, Izik Eidus wrote:
>
> > On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
> > malc wrote:
> >
> > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > >
> > > > On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> > > > malc wrote:
> > > >
>
On Fri, 11 Dec 2009 13:51:53 -0600
Anthony Liguori wrote:
> Izik Eidus wrote:
> > On Fri, 11 Dec 2009 13:30:22 -0600
> > Anthony Liguori wrote:
> >
> >
> >> Izik Eidus wrote:
> >>
> >>> I should speek with the marketing guys, will be able to answer on
> >>> that specific question in few
In working to try to get Sparc64 system emulation developed, we seem to have
run into an issue with the IDE code in Qemu. The OpenBIOS folks have been
working quite a few issues with the OpenBIOS code that need to be resolved in
order to boot 64-bit Solaris kernels correctly, but the most recen
On Fri, 11 Dec 2009, Izik Eidus wrote:
> On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
> malc wrote:
>
> > On Fri, 11 Dec 2009, Izik Eidus wrote:
> >
> > > On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> > > malc wrote:
> > >
> > > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > >
> > > > > On Fri, 11
Mark McLoughlin wrote:
I don't doubt there are challenges.
I think your requirement that old clients work with new servers and new
clients work with old servers is a good one. Maybe extending VNC is the
best way to get there, but it should be recognized there is another way
of achieving the same
Izik Eidus wrote:
On Fri, 11 Dec 2009 13:30:22 -0600
Anthony Liguori wrote:
Izik Eidus wrote:
I should speek with the marketing guys, will be able to answer on
that specific question in few days.
But simple 2D Commands are just not enougth for spice.
We have multiple drawing surface
On Fri, Dec 11, 2009 at 07:20:12AM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >Please don't do that. libvirt is adding support for new features all the
> >time. I don't want to be in the situation where we can't add a new feature
> >because it is missing in the JSON impl. If we're
On Fri, 2009-12-11 at 13:38 -0600, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > On Fri, 2009-12-11 at 13:04 -0600, Anthony Liguori wrote:
> >
> >> But to introduce another protocol where a user has to make a choice to
> >> use Spice over VNC, I think we need a really good justification f
* Glauber Costa (glom...@gmail.com) wrote:
> >
> > But to introduce another protocol where a user has to make a choice to use
> > Spice over VNC, I think we need a really good justification for that. It's
> > really about complexity. A user shouldn't have to know about Spice or VNC.
> > They sho
On Fri, 11 Dec 2009 13:30:22 -0600
Anthony Liguori wrote:
> Izik Eidus wrote:
> > I should speek with the marketing guys, will be able to answer on
> > that specific question in few days.
> >
> >
> > But simple 2D Commands are just not enougth for spice.
> > We have multiple drawing surfaces, tha
Mark McLoughlin wrote:
On Fri, 2009-12-11 at 13:04 -0600, Anthony Liguori wrote:
But to introduce another protocol where a user has to make a choice to
use Spice over VNC, I think we need a really good justification for
that. It's really about complexity. A user shouldn't have to know
abo
On Fri, Dec 11, 2009 at 5:22 PM, Izik Eidus wrote:
> On Fri, 11 Dec 2009 13:06:47 -0600
> Anthony Liguori wrote:
>
>> Izik Eidus wrote:
>> > I want to add that qemu is not the sole user of spice, Spice will be
>> > used as a protocol to connect into physical windows/linux
>> > machines
>> >
>
On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
malc wrote:
> On Fri, 11 Dec 2009, Izik Eidus wrote:
>
> > On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> > malc wrote:
> >
> > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > >
> > > > On Fri, 11 Dec 2009 09:57:48 -0600
> > > > Anthony Liguori wrote:
> > >
Izik Eidus wrote:
I should speek with the marketing guys, will be able to answer on that
specific question in few days.
But simple 2D Commands are just not enougth for spice.
We have multiple drawing surfaces, that are depended on each other.
We Dont renender untill the very moment that the gue
On Fri, 11 Dec 2009 17:15:02 -0200
Glauber Costa wrote:
> >
> > But to introduce another protocol where a user has to make a choice
> > to use Spice over VNC, I think we need a really good justification
> > for that. It's really about complexity. A user shouldn't have to
> > know about Spice or
On Fri, 2009-12-11 at 13:04 -0600, Anthony Liguori wrote:
> But to introduce another protocol where a user has to make a choice to
> use Spice over VNC, I think we need a really good justification for
> that. It's really about complexity. A user shouldn't have to know
> about Spice or VNC. Th
On Fri, 11 Dec 2009, Izik Eidus wrote:
> On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> malc wrote:
>
> > On Fri, 11 Dec 2009, Izik Eidus wrote:
> >
> > > On Fri, 11 Dec 2009 09:57:48 -0600
> > > Anthony Liguori wrote:
> > >
> > [..snip..]
> >
> > >
[..snip..]
> >
> > Any particular reason f
On Fri, 11 Dec 2009 17:07:13 -0200
Glauber Costa wrote:
> >>
> >> Spice is a library, it is library for remote display, it handle by
> >> itself all the connection between the spice client to the host that
> >> run the guest, it include:
> >> sound, display, keyboard, usb, network tunneling (for
On Fri, 11 Dec 2009 13:06:47 -0600
Anthony Liguori wrote:
> Izik Eidus wrote:
> > I want to add that qemu is not the sole user of spice, Spice will be
> > used as a protocol to connect into physical windows/linux
> > machines
> >
> > So how can we change the library just for qemu?
> >
> A
On Fri, 11 Dec 2009 13:04:02 -0600
Anthony Liguori wrote:
> Hi Izik,
>
> Thanks for the explanation.
>
> Izik Eidus wrote:
> >> So from a protocol perspective, what are the advantages of Spice
> >> over VNC?
> >>
> >
> >
> > Spice desgien is highly diffrence than VNC
> > The first thing ab
On Fri, 11 Dec 2009, Nathan Froyd wrote:
>
> Signed-off-by: Nathan Froyd
Works here.
[..snip..]
--
mailto:av1...@comtv.ru
>
> But to introduce another protocol where a user has to make a choice to use
> Spice over VNC, I think we need a really good justification for that. It's
> really about complexity. A user shouldn't have to know about Spice or VNC.
> They shouldn't have to contemplate the trade-offs of whether
On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
malc wrote:
> On Fri, 11 Dec 2009, Izik Eidus wrote:
>
> > On Fri, 11 Dec 2009 09:57:48 -0600
> > Anthony Liguori wrote:
> >
> [..snip..]
>
> >
> > Spice desgien is highly diffrence than VNC
> > The first thing about spice is that it isnt just a frame
>> I think we should allow freedom of choice to the users to decide what
>> protcol they want to use, Spice and VNC are all diffrent and were born
>> to meet diffrent goals.
>>
>> I would happy to answer more questions if anyone have
>
> I think the simple point is that, AFAICS, the spice folks are
>>
>> Spice is a library, it is library for remote display, it handle by
>> itself all the connection between the spice client to the host that
>> run the guest, it include:
>> sound, display, keyboard, usb, network tunneling (for printers) and so
>> on...
>>
>
> I want to add that qemu is not the
Izik Eidus wrote:
I want to add that qemu is not the sole user of spice, Spice will be
used as a protocol to connect into physical windows/linux machines
So how can we change the library just for qemu?
A library is not necessarily a problem.
What would be a probably is if the library ma
On Fri, 11 Dec 2009 18:57:17 +
Ben Taylor wrote:
> I think the simple point is that, AFAICS, the spice folks are
> expecting the qemu team to integrate their big ugly tarball, instead
> of doing what everyone else does, which is forward port everything to
> current head and then provide a cur
Hi Izik,
Thanks for the explanation.
Izik Eidus wrote:
So from a protocol perspective, what are the advantages of Spice over
VNC?
Spice desgien is highly diffrence than VNC
The first thing about spice is that it isnt just a framebuffer drawing
and not a bitmaps protocol.
Spice protocl
On Fri, 11 Dec 2009, Izik Eidus wrote:
> On Fri, 11 Dec 2009 09:57:48 -0600
> Anthony Liguori wrote:
>
[..snip..]
>
> Spice desgien is highly diffrence than VNC
> The first thing about spice is that it isnt just a framebuffer drawing
> and not a bitmaps protocol.
>
> Spice protocl support mul
On Fri, Dec 11, 2009 at 12:37 PM, pei duan wrote:
> Hi guy,
> I am not very clear qemu architecture,and the relationship between
> modules.
> who can help me?
>
Have you read the discussion started by Jun recently?
--
regards,
Mulyadi Santosa
Freelance Linux trainer and consultan
On Fri, 11 Dec 2009 20:48:28 +0200
Izik Eidus wrote:
> On Fri, 11 Dec 2009 09:57:48 -0600
> Anthony Liguori wrote:
>
> > Yaniv Kamay wrote:
> > > Hi,
> > >
> > > Spice project is now open, for more information visit
> > > http://spice-space.org, due to a server relocation the site will
> > > be
On Fri, Dec 11, 2009 at 6:48 PM, Izik Eidus wrote:
> On Fri, 11 Dec 2009 09:57:48 -0600
> Anthony Liguori wrote:
>
>> Yaniv Kamay wrote:
>> > Hi,
>> >
>> > Spice project is now open, for more information visit
>> > http://spice-space.org, due to a server relocation the site will be
>> > down duri
>> It already has. It's not a git tree with staged patches. It's a
>> tarball release of a really old version of kvm-userspace that's called
>>
>> 'vdesktop'.
>
>
> This guy is evil and he is motivate by personal agenda. I hope you all will
> wakeup.
>
I don't see anthony with any specific agend
On Fri, 11 Dec 2009 09:57:48 -0600
Anthony Liguori wrote:
> Yaniv Kamay wrote:
> > Hi,
> >
> > Spice project is now open, for more information visit
> > http://spice-space.org, due to a server relocation the site will be
> > down during this weekend.
> >
> > Spice ship patched QEMU based on fairl
On Fri, Dec 11, 2009 at 05:54:06PM +0900, Jun Koi wrote:
> Hi,
>
> Thanks to everybody helping me to have more understanding on QEmu
> internals. This community is great!
>
> This trivial patch removes some unused params in tcg_out_st() and
> tcg_out_ld(). Probably this remains from dyngen time?
On Thu, Dec 10, 2009 at 05:51:40PM +, Palle Lyckegaard wrote:
> Hi,
>
> what is the current state of the qemu-system-malta?
>
> When I try to run a NetBSD or Linux kernel the following message appears:
>
> ./git/qemu/mips-softmmu/qemu-system-mips -kernel ./netbsd_malta -m 64
> -nographic
>
> q
Signed-off-by: Nathan Froyd
---
linux-user/elfload.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 3551d34..97dc3a7 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -539,6 +539,3
Hi,
On Fri, 11 Dec 2009, Anthony Liguori wrote:
> > I'm not getting into this discussion and is not going to happen, you
> > have all the necessary information on spiec-space.org in order to take
> > intelligent decision. The QEMU community can choose to reject Spice if
> > it decide to do so.
* Anthony Liguori (anth...@codemonkey.ws) wrote:
> Chris Wright wrote:
>>> That's a fork like it or not.
>>>
>>
>> It is a branch of work. The branch has been done without community
>> interaction, so yes, it looks like a fork.
>
> Branches don't carry independent names like "vdesktop". They
There's no sense in separately declaring target_{elf_greg,uid,gid,pid}_t
for every architecture. Just declare them once with appropriate
USE_UID16 handling.
Signed-off-by: Nathan Froyd
---
linux-user/elfload.c | 32 ++--
1 files changed, 10 insertions(+), 22 deleti
Running programs with the MIPS user-mode emulator fails during dynamic
loading, as floating-point instructions are not enabled in in
env->hflags. Move the code for doing so from fpu_init to cpu_reset so
the MIPS_HFLAG_{FPU,F64} setting doesn't get clobbered by cpu_reset
setting env->hflags to MIPS
1 - 100 of 142 matches
Mail list logo
