Re: [Qemu-devel] X support for QXL and SPICE
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 compositing >> - Glyphs >> > > Does anything use Xrender for drawing glyphs these days? Yes all of cairo apps and gtk, pretty much anything doing anti-aliased fonts on a modern Linux desktop uses X render to draw glyps. I think QT can use Xrender also but not 100% sure what the default is. > > Certainly, with a compositing window manager, nothing is getting rendered by > X... Yes there is, with a GL compositing window manager nothing is rendered by X, with an Xrender compositing window manager (metacity or kwin xrender mode). Also allanti-aliased font operations, and a number of cairo operations are done using xrender, which means most of the modern desktop, I actually broke sw fallbacks to the frontbuffer on my driver last week and it took me nearly a half a day to realise it. X rendering in modern apps is like Soeren describes, render to offscreen pixmap, copy to onscreen. > Scrolling is accelerated in VNC. In the Cirrus adapter, both X and Windows > use a video-to-video bitblt, we use this to create a VNC CopyRect which > makes scrolling and Window movement smooth. Firefox scrolling? (though I'm not sure anyone deals with it sainly). > >> 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 yet support for offscreen pixmaps in SPICE, so at the >> moment, solid fill and CopyArea are the two main things that actually >> make a difference. >> > > 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? > If spice grows offscreen surfaces along with some a few more rendering operations I expect we can make it go fairly fast for most X apps. Since at RH we have both spice and X teams I think we can probably produce some sort of collaborative plan in the short term on how to go forward. Dave.
[Qemu-devel] I/O
hi guy,which file in QEMU is related with I/O activity ?
Re: [Qemu-devel] X support for QXL and SPICE
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 understand what you want here? Spice is not responsible for how X work the fact that X doesnt have many things that windows have - doesnt mean it is bad spice DOES have them... Btw Xrender is used by cario hardware accelration... > > Regards, > > Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
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 software thinking that they aren't creating a derived work because there's no combination. But it's not necessary to get too tied up in this one. The later are more important. 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 1 too!...) GCC is not the best example since it's support for plugins are relatively new. It's bad for users. They start using a plugin for one version and they really like it, they want to update to a new version of the base program and now their plugin no longer works. The plugin has gone unmaintained and now they have to choose between the plugin and updating the base program. 3) they would create stability issues in qemu because the plugin quality cannot be controlled. How is this different from 3rd party modules in the kernel? I don't think the kernel is an example of it working smoothly. It's a constant source of frustration for users and people are constantly doing ugly things wrt licensing. Regards, Anthony Liguori
Re: [Qemu-devel] Re: Spice project is now open
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 on an X pixmap. Firefox uses that extensively, for example to render tiled backgrounds (though probably GTK user interface elements can do so less successfully). Yes, but this is just a single application. The point is that these things are not as widely standardized on X as they are on Windows. Regards, Anthony Liguori Paolo
Re: [Qemu-devel] X support for QXL and SPICE
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 these days? Certainly, with a compositing window manager, nothing is getting rendered by X... The X driver for the QXL device is not yet very sophisticated. What it does is basically this: - It keeps a separate memory framebuffer uptodate using software - Solid fills and CopyArea requests are turned into SPICE commands. - The cursor is drawn using cursor commands - For other things, bitmaps are sent across the wire - It uses the hashing feature of SPICE to only send hashcodes for those bitmaps if it can get away with it. Even this simple support provides a better user experience than VNC because scrolling is accelerated and doesn't result in a huge bitmap getting sent across the wire. Scrolling is accelerated in VNC. In the Cirrus adapter, both X and Windows use a video-to-video bitblt, we use this to create a VNC CopyRect which makes scrolling and Window movement smooth. 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 yet support for offscreen pixmaps in SPICE, so at the moment, solid fill and CopyArea are the two main things that actually make a difference. 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? Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 information from - lets say the keyboard Is it really diffrence from any other function callbacks that used for such purpuse? Plugin interfaces have been discussed a few times in the past. The concerns have been 1) they will be abused with the introduction of proprietary plugins 2) we would have tremendous difficulty maintaining a stable plugin abi 3) they would create stability issues in qemu because the plugin quality cannot be controlled. I think you're talking about dlopen() vs. direct linkage of .so? Here's some code to ground things a bit. ifdef CONFIG_SPICE CFLAGS+=$(SPICE_CFLAGS) LIBS+=$(SPICE_LIBS) endif And specifically, there's a notion of the VDI interface added to core qemu, which can be extended by simply registering callbacks to that interface: vl.c::main() ... #ifdef CONFIG_SPICE ... spice_init(&core_interface);. #endif Ah, that's entirely reasonable. When user provided libraries was mentioned, I assumed dlopen() style plugins. Regards, Anthony Liguori
[Qemu-devel] Re: approaches to 3D virtualisation
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 discussed prior > to anyone writing a line of code. > > Current existing solutions in the area: > a) VMware virtual graphics adapter - based on DX9, has an open > KMS/Gallium3D driver stack recently released by vmware, has certified > Windows drivers and has a documented vGPU interface (it could be > documented a lot better) > > b) VirtualBox - seems to be GL based passthrough based on a Chromium > backend. DX9 support, looks to be done via Wine DX->GL converter built > into a Windows driver (not confirmed code base is crazy) I'm assuming > chromium is being used to stream GL through the passthru but this > definitely requires more investigation. > > Now both of these seem to be local only rendering solutions, though I > might be underselling the vbox/chromium fun. > > Now to add a remoting 3D rendering protocol is where things get ugly > fast, and very different from current 2D rendering with offscreen > pixmaps. The major difference is most server farms will not contain > any 3D hardware and will not want to contain any 3D hw due to power > considerations. Now if you have a remote protocol, and the client > disconnects, you have to keep some sort of transaction log, and either > replay the transactions when a client reconnects, or have some sort of > sw rendering kick in on the server as a fallback. Now 3D sw rendering > solutions are insanely slow and quite CPU intensive. VMware are > working on an llvm based 3D renderer for something like this situation > but I'm not convinced of how useable it will be. > > Also with remoting you need to come up with a minimum acceptable level > of 3D you want to expose to guests OSes depending on what the > capabilities of the client side hw, or refuse connections unless the > client can run all the features that you've exposed in side the guest. > This ranges from DX7->DX11, and GL1.5 to GL3.0 situations. > > I'm not sure how ppl who work with VNC see VNC fitting in with this > sort of protocol, I expect SPICE is better placed with proper design > to address this. Though it would firstly be nice to design a vGPU > interface for the guest OS to work against, I lean towards the VMware > because of the availability of guest drivers, however the Virtualbox > one is probably also acceptable if anyone can find where it is > documented. > > This is just a sort of a brain dump from me, but I'd like to get ppl > talking about this, since 3D is not to be considered some simple > extension of 2D functionality, > its a whole different world, modern GPUs are 98% of silicon dedicated > to 3D processing, most of the current 2D type accel such as QXL > interface provides are done using 3D engines on most GPUs, and the > inability to render 3D on the server side of a link with any useful > speed in current server hw. > > So I suppose the main questions to answer up front are: > 1) Rendering done on same hw as VM is running? > just use VNC to dump the final answer over the network. This requires 3D rendering hw on the client, this could be your laptop or desktop in the office, in which case its probably fine nto so good if its server hw in a rack. > 2) Rendering done on the client viewing end of the link where the viewer is, Have to transport 3D to the client, but more likely the client end will have 3D hardware to actually render stuff at a reasonable speed. So I suppose lets discuss ;-) Dave. (btw I work for Red Hat but not in this capacity or near virt teams, this is purely a personal itch).
[Qemu-devel] approaches to 3D virtualisation
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 DX9, has an open KMS/Gallium3D driver stack recently released by vmware, has certified Windows drivers and has a documented vGPU interface (it could be documented a lot better) b) VirtualBox - seems to be GL based passthrough based on a Chromium backend. DX9 support, looks to be done via Wine DX->GL converter built into a Windows driver (not confirmed code base is crazy) I'm assuming chromium is being used to stream GL through the passthru but this definitely requires more investigation. Now both of these seem to be local only rendering solutions, though I might be underselling the vbox/chromium fun. Now to add a remoting 3D rendering protocol is where things get ugly fast, and very different from current 2D rendering with offscreen pixmaps. The major difference is most server farms will not contain any 3D hardware and will not want to contain any 3D hw due to power considerations. Now if you have a remote protocol, and the client disconnects, you have to keep some sort of transaction log, and either replay the transactions when a client reconnects, or have some sort of sw rendering kick in on the server as a fallback. Now 3D sw rendering solutions are insanely slow and quite CPU intensive. VMware are working on an llvm based 3D renderer for something like this situation but I'm not convinced of how useable it will be. Also with remoting you need to come up with a minimum acceptable level of 3D you want to expose to guests OSes depending on what the capabilities of the client side hw, or refuse connections unless the client can run all the features that you've exposed in side the guest. This ranges from DX7->DX11, and GL1.5 to GL3.0 situations. I'm not sure how ppl who work with VNC see VNC fitting in with this sort of protocol, I expect SPICE is better placed with proper design to address this. Though it would firstly be nice to design a vGPU interface for the guest OS to work against, I lean towards the VMware because of the availability of guest drivers, however the Virtualbox one is probably also acceptable if anyone can find where it is documented. This is just a sort of a brain dump from me, but I'd like to get ppl talking about this, since 3D is not to be considered some simple extension of 2D functionality, its a whole different world, modern GPUs are 98% of silicon dedicated to 3D processing, most of the current 2D type accel such as QXL interface provides are done using 3D engines on most GPUs, and the inability to render 3D on the server side of a link with any useful speed in current server hw. So I suppose the main questions to answer up front are: 1) Rendering done on same hw as VM is running? just use VNC to dump the final answer over the network. 2) Rendering done on the client viewing end of the link where
Re: [Qemu-devel] Spice project is now open
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 direction, so all the bits can be combined > to every users' liking. Thus creating choice. We are palning to add local rendering support for qxl inside qemu... > > > Alex >
[Qemu-devel] [PATCH 12/13] alpha: Fix double log_cpu_state.
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
+++ b/target-alpha/translate.c
@@ -2648,7 +2648,6 @@ static inline void gen_intermediate_code_internal(CPUState *env,
tb->icount = num_insns;
}
#ifdef DEBUG_DISAS
-log_cpu_state_mask(CPU_LOG_TB_CPU, env, 0);
if (qemu_loglevel_mask(CPU_LOG_TB_IN_ASM)) {
qemu_log("IN: %s\n", lookup_symbol(pc_start));
log_target_disas(pc_start, ctx.pc - pc_start, 1);
[Qemu-devel] [PATCH 08/13] alpha: Expand msk*l inline.
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 deletions(-)
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index 8004aa1..8db73b0 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -17,12 +17,8 @@ DEF_HELPER_1(ctpop, i64, i64)
DEF_HELPER_1(ctlz, i64, i64)
DEF_HELPER_1(cttz, i64, i64)
-DEF_HELPER_2(mskbl, i64, i64, i64)
-DEF_HELPER_2(mskwl, i64, i64, i64)
-DEF_HELPER_2(mskll, i64, i64, i64)
DEF_HELPER_2(zap, i64, i64, i64)
DEF_HELPER_2(zapnot, i64, i64, i64)
-DEF_HELPER_2(mskql, i64, i64, i64)
DEF_HELPER_2(mskwh, i64, i64, i64)
DEF_HELPER_2(inswh, i64, i64, i64)
DEF_HELPER_2(msklh, i64, i64, i64)
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index d2e43a5..591adbd 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -175,21 +175,6 @@ static inline uint64_t byte_zap(uint64_t op, uint8_t mskb)
return op & ~mask;
}
-uint64_t helper_mskbl(uint64_t val, uint64_t mask)
-{
-return byte_zap(val, 0x01 << (mask & 7));
-}
-
-uint64_t helper_mskwl(uint64_t val, uint64_t mask)
-{
-return byte_zap(val, 0x03 << (mask & 7));
-}
-
-uint64_t helper_mskll(uint64_t val, uint64_t mask)
-{
-return byte_zap(val, 0x0F << (mask & 7));
-}
-
uint64_t helper_zap(uint64_t val, uint64_t mask)
{
return byte_zap(val, mask);
@@ -200,11 +185,6 @@ uint64_t helper_zapnot(uint64_t val, uint64_t mask)
return byte_zap(val, ~mask);
}
-uint64_t helper_mskql(uint64_t val, uint64_t mask)
-{
-return byte_zap(val, 0xFF << (mask & 7));
-}
-
uint64_t helper_mskwh(uint64_t val, uint64_t mask)
{
return byte_zap(val, (0x03 << (mask & 7)) >> 8);
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 631b31f..3e50d27 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -655,6 +655,32 @@ static inline void gen_ins_l(int ra, int rb, int rc, int islit,
}
}
+/* MSKBL, MSKWL, MSKLL, MSKQL */
+static inline void gen_msk_l(int ra, int rb, int rc, int islit,
+ uint8_t lit, uint8_t byte_mask)
+{
+if (unlikely(rc == 31))
+return;
+else if (unlikely(ra == 31))
+tcg_gen_movi_i64(cpu_ir[rc], 0);
+else if (islit) {
+gen_zapnoti (cpu_ir[rc], cpu_ir[ra], ~(byte_mask << (lit & 7)));
+} else {
+TCGv shift = tcg_temp_new();
+TCGv mask = tcg_temp_new();
+
+tcg_gen_andi_i64(shift, cpu_ir[rb], 7);
+tcg_gen_shli_i64(shift, shift, 3);
+tcg_gen_movi_i64(mask, zapnot_mask (byte_mask));
+tcg_gen_shl_i64(mask, mask, shift);
+
+tcg_gen_andc_i64(cpu_ir[rc], cpu_ir[ra], mask);
+
+tcg_temp_free(mask);
+tcg_temp_free(shift);
+}
+}
+
/* Code to call arith3 helpers */
#define ARITH3(name) \
static inline void glue(gen_, name)(int ra, int rb, int rc, int islit,\
@@ -686,10 +712,6 @@ ARITH3(addlv)
ARITH3(sublv)
ARITH3(addqv)
ARITH3(subqv)
-ARITH3(mskbl)
-ARITH3(mskwl)
-ARITH3(mskll)
-ARITH3(mskql)
ARITH3(mskwh)
ARITH3(inswh)
ARITH3(msklh)
@@ -1314,7 +1336,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
switch (fn7) {
case 0x02:
/* MSKBL */
-gen_mskbl(ra, rb, rc, islit, lit);
+gen_msk_l(ra, rb, rc, islit, lit, 0x01);
break;
case 0x06:
/* EXTBL */
@@ -1326,7 +1348,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x12:
/* MSKWL */
-gen_mskwl(ra, rb, rc, islit, lit);
+gen_msk_l(ra, rb, rc, islit, lit, 0x03);
break;
case 0x16:
/* EXTWL */
@@ -1338,7 +1360,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x22:
/* MSKLL */
-gen_mskll(ra, rb, rc, islit, lit);
+gen_msk_l(ra, rb, rc, islit, lit, 0x0f);
break;
case 0x26:
/* EXTLL */
@@ -1358,7 +1380,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x32:
/* MSKQL */
-gen_mskql(ra, rb, rc, islit, lit);
+gen_msk_l(ra, rb, rc, islit, lit, 0xff);
break;
case 0x34:
/* SRL */
[Qemu-devel] [PATCH 04/13] alpha: Rewrite gen_ext_[hl] in terms of zapnot.
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 insertions(+), 32 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index bd193da..5e139e6 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -567,46 +567,41 @@ static inline void gen_zap(int ra, int rb, int rc, int islit, uint8_t lit)
/* EXTWH, EXTWH, EXTLH, EXTQH */
-static inline void gen_ext_h(void(*tcg_gen_ext_i64)(TCGv t0, TCGv t1),
- int ra, int rb, int rc, int islit, uint8_t lit)
+static inline void gen_ext_h(int ra, int rb, int rc, int islit,
+ uint8_t lit, uint8_t byte_mask)
{
if (unlikely(rc == 31))
return;
-
-if (ra != 31) {
+else if (unlikely(ra == 31))
+tcg_gen_movi_i64(cpu_ir[rc], 0);
+else {
if (islit) {
-if (lit != 0)
-tcg_gen_shli_i64(cpu_ir[rc], cpu_ir[ra], 64 - ((lit & 7) * 8));
-else
-tcg_gen_mov_i64(cpu_ir[rc], cpu_ir[ra]);
+lit = (64 - (lit & 7) * 8) & 0x3f;
+tcg_gen_shli_i64(cpu_ir[rc], cpu_ir[ra], lit);
} else {
-TCGv tmp1;
-tmp1 = tcg_temp_new();
-
+TCGv tmp1 = tcg_temp_new();
tcg_gen_andi_i64(tmp1, cpu_ir[rb], 7);
tcg_gen_shli_i64(tmp1, tmp1, 3);
tcg_gen_neg_i64(tmp1, tmp1);
tcg_gen_andi_i64(tmp1, tmp1, 0x3f);
tcg_gen_shl_i64(cpu_ir[rc], cpu_ir[ra], tmp1);
-
tcg_temp_free(tmp1);
}
-if (tcg_gen_ext_i64)
-tcg_gen_ext_i64(cpu_ir[rc], cpu_ir[rc]);
-} else
-tcg_gen_movi_i64(cpu_ir[rc], 0);
+gen_zapnoti(rc, rc, byte_mask);
+}
}
/* EXTBL, EXTWL, EXTWL, EXTLL, EXTQL */
-static inline void gen_ext_l(void(*tcg_gen_ext_i64)(TCGv t0, TCGv t1),
- int ra, int rb, int rc, int islit, uint8_t lit)
+static inline void gen_ext_l(int ra, int rb, int rc, int islit,
+ uint8_t lit, uint8_t byte_mask)
{
if (unlikely(rc == 31))
return;
-
-if (ra != 31) {
+else if (unlikely(ra == 31))
+tcg_gen_movi_i64(cpu_ir[rc], 0);
+else {
if (islit) {
-tcg_gen_shri_i64(cpu_ir[rc], cpu_ir[ra], (lit & 7) * 8);
+tcg_gen_shri_i64(cpu_ir[rc], cpu_ir[ra], (lit & 7) * 8);
} else {
TCGv tmp = tcg_temp_new();
tcg_gen_andi_i64(tmp, cpu_ir[rb], 7);
@@ -614,10 +609,8 @@ static inline void gen_ext_l(void(*tcg_gen_ext_i64)(TCGv t0, TCGv t1),
tcg_gen_shr_i64(cpu_ir[rc], cpu_ir[ra], tmp);
tcg_temp_free(tmp);
}
-if (tcg_gen_ext_i64)
-tcg_gen_ext_i64(cpu_ir[rc], cpu_ir[rc]);
-} else
-tcg_gen_movi_i64(cpu_ir[rc], 0);
+gen_zapnoti(rc, rc, byte_mask);
+}
}
/* Code to call arith3 helpers */
@@ -1276,7 +1269,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x06:
/* EXTBL */
-gen_ext_l(&tcg_gen_ext8u_i64, ra, rb, rc, islit, lit);
+gen_ext_l(ra, rb, rc, islit, lit, 0x01);
break;
case 0x0B:
/* INSBL */
@@ -1288,7 +1281,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x16:
/* EXTWL */
-gen_ext_l(&tcg_gen_ext16u_i64, ra, rb, rc, islit, lit);
+gen_ext_l(ra, rb, rc, islit, lit, 0x03);
break;
case 0x1B:
/* INSWL */
@@ -1300,7 +1293,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x26:
/* EXTLL */
-gen_ext_l(&tcg_gen_ext32u_i64, ra, rb, rc, islit, lit);
+gen_ext_l(ra, rb, rc, islit, lit, 0x0f);
break;
case 0x2B:
/* INSLL */
@@ -1336,7 +1329,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x36:
/* EXTQL */
-gen_ext_l(NULL, ra, rb, rc, islit, lit);
+gen_ext_l(ra, rb, rc, islit, lit, 0xff);
break;
case 0x39:
/* SLL */
@@ -1384,7 +1377,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x5A:
/* EXTWH */
-gen_ext_h(&tcg_gen_ext16u_i64, ra, rb, rc, islit, lit);
+gen_ext_h(ra, rb, rc, islit, lit, 0x03);
break;
case 0x62:
/* MSKLH */
@@ -1396,7 +1389,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x6A:
/* EXTLH */
-
[Qemu-devel] [PATCH 07/13] alpha: Expand ins*l inline.
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 deletions(-)
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index 850ba0d..8004aa1 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -18,15 +18,11 @@ DEF_HELPER_1(ctlz, i64, i64)
DEF_HELPER_1(cttz, i64, i64)
DEF_HELPER_2(mskbl, i64, i64, i64)
-DEF_HELPER_2(insbl, i64, i64, i64)
DEF_HELPER_2(mskwl, i64, i64, i64)
-DEF_HELPER_2(inswl, i64, i64, i64)
DEF_HELPER_2(mskll, i64, i64, i64)
-DEF_HELPER_2(insll, i64, i64, i64)
DEF_HELPER_2(zap, i64, i64, i64)
DEF_HELPER_2(zapnot, i64, i64, i64)
DEF_HELPER_2(mskql, i64, i64, i64)
-DEF_HELPER_2(insql, i64, i64, i64)
DEF_HELPER_2(mskwh, i64, i64, i64)
DEF_HELPER_2(inswh, i64, i64, i64)
DEF_HELPER_2(msklh, i64, i64, i64)
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index 08d5924..d2e43a5 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -180,34 +180,16 @@ uint64_t helper_mskbl(uint64_t val, uint64_t mask)
return byte_zap(val, 0x01 << (mask & 7));
}
-uint64_t helper_insbl(uint64_t val, uint64_t mask)
-{
-val <<= (mask & 7) * 8;
-return byte_zap(val, ~(0x01 << (mask & 7)));
-}
-
uint64_t helper_mskwl(uint64_t val, uint64_t mask)
{
return byte_zap(val, 0x03 << (mask & 7));
}
-uint64_t helper_inswl(uint64_t val, uint64_t mask)
-{
-val <<= (mask & 7) * 8;
-return byte_zap(val, ~(0x03 << (mask & 7)));
-}
-
uint64_t helper_mskll(uint64_t val, uint64_t mask)
{
return byte_zap(val, 0x0F << (mask & 7));
}
-uint64_t helper_insll(uint64_t val, uint64_t mask)
-{
-val <<= (mask & 7) * 8;
-return byte_zap(val, ~(0x0F << (mask & 7)));
-}
-
uint64_t helper_zap(uint64_t val, uint64_t mask)
{
return byte_zap(val, mask);
@@ -223,12 +205,6 @@ uint64_t helper_mskql(uint64_t val, uint64_t mask)
return byte_zap(val, 0xFF << (mask & 7));
}
-uint64_t helper_insql(uint64_t val, uint64_t mask)
-{
-val <<= (mask & 7) * 8;
-return byte_zap(val, ~(0xFF << (mask & 7)));
-}
-
uint64_t helper_mskwh(uint64_t val, uint64_t mask)
{
return byte_zap(val, (0x03 << (mask & 7)) >> 8);
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index b53737a..631b31f 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -514,36 +514,41 @@ FCMOV(cmpfge)
FCMOV(cmpfle)
FCMOV(cmpfgt)
+static inline uint64_t zapnot_mask(uint8_t lit)
+{
+uint64_t mask = 0;
+int i;
+
+for (i = 0; i < 8; ++i) {
+if ((lit >> i) & 1)
+mask |= 0xffull << (i * 8);
+}
+return mask;
+}
+
/* Implement zapnot with an immediate operand, which expands to some
form of immediate AND. This is a basic building block in the
definition of many of the other byte manipulation instructions. */
-static inline void gen_zapnoti(int ra, int rc, uint8_t lit)
+static void gen_zapnoti(TCGv dest, TCGv src, uint8_t lit)
{
-uint64_t mask;
-int i;
-
switch (lit) {
case 0x00:
-tcg_gen_movi_i64(cpu_ir[rc], 0);
+tcg_gen_movi_i64(dest, 0);
break;
case 0x01:
-tcg_gen_ext8u_i64(cpu_ir[rc], cpu_ir[ra]);
+tcg_gen_ext8u_i64(dest, src);
break;
case 0x03:
-tcg_gen_ext16u_i64(cpu_ir[rc], cpu_ir[ra]);
+tcg_gen_ext16u_i64(dest, src);
break;
case 0x0f:
-tcg_gen_ext32u_i64(cpu_ir[rc], cpu_ir[ra]);
+tcg_gen_ext32u_i64(dest, src);
break;
case 0xff:
-tcg_gen_mov_i64(cpu_ir[rc], cpu_ir[ra]);
+tcg_gen_mov_i64(dest, src);
break;
default:
-for (mask = i = 0; i < 8; ++i) {
-if ((lit >> i) & 1)
-mask |= 0xffull << (i * 8);
-}
-tcg_gen_andi_i64 (cpu_ir[rc], cpu_ir[ra], mask);
+tcg_gen_andi_i64 (dest, src, zapnot_mask (lit));
break;
}
}
@@ -555,7 +560,7 @@ static inline void gen_zapnot(int ra, int rb, int rc, int islit, uint8_t lit)
else if (unlikely(ra == 31))
tcg_gen_movi_i64(cpu_ir[rc], 0);
else if (islit)
-gen_zapnoti(ra, rc, lit);
+gen_zapnoti(cpu_ir[rc], cpu_ir[ra], lit);
else
gen_helper_zapnot (cpu_ir[rc], cpu_ir[ra], cpu_ir[rb]);
}
@@ -567,13 +572,13 @@ static inline void gen_zap(int ra, int rb, int rc, int islit, uint8_t lit)
else if (unlikely(ra == 31))
tcg_gen_movi_i64(cpu_ir[rc], 0);
else if (islit)
-gen_zapnoti(ra, rc, ~lit);
+gen_zapnoti(cpu_ir[rc], cpu_ir[ra], ~lit);
else
gen_helper_zap (cpu_ir[rc], cpu_ir[ra], cpu_ir[rb]);
}
-/* EXTWH, EXTWH, EXTLH, EXTQH */
+/* EXTWH, EXTLH, EXTQH */
static inline void gen_ext_h(int ra, int rb, int rc, int islit,
uint8_t lit, uint8_t byte_mask)
[Qemu-devel] [PATCH 13/13] alpha: Implement fp branch/cmov inline.
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|7 --
target-alpha/op_helper.c | 31 ---
target-alpha/translate.c | 197 ++
3 files changed, 110 insertions(+), 125 deletions(-)
diff --git a/target-alpha/helper.h b/target-alpha/helper.h
index 4eb3b6f..bedd3c0 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -77,13 +77,6 @@ DEF_HELPER_2(cmpgeq, i64, i64, i64)
DEF_HELPER_2(cmpgle, i64, i64, i64)
DEF_HELPER_2(cmpglt, i64, i64, i64)
-DEF_HELPER_1(cmpfeq, i64, i64)
-DEF_HELPER_1(cmpfne, i64, i64)
-DEF_HELPER_1(cmpflt, i64, i64)
-DEF_HELPER_1(cmpfle, i64, i64)
-DEF_HELPER_1(cmpfgt, i64, i64)
-DEF_HELPER_1(cmpfge, i64, i64)
-
DEF_HELPER_2(cpys, i64, i64, i64)
DEF_HELPER_2(cpysn, i64, i64, i64)
DEF_HELPER_2(cpyse, i64, i64, i64)
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index d7f4fb2..8eba5ec 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -884,37 +884,6 @@ uint64_t helper_cmpglt(uint64_t a, uint64_t b)
return 0;
}
-uint64_t helper_cmpfeq (uint64_t a)
-{
-return !(a & 0x7FFFULL);
-}
-
-uint64_t helper_cmpfne (uint64_t a)
-{
-return (a & 0x7FFFULL);
-}
-
-uint64_t helper_cmpflt (uint64_t a)
-{
-return (a & 0x8000ULL) && (a & 0x7FFFULL);
-}
-
-uint64_t helper_cmpfle (uint64_t a)
-{
-return (a & 0x8000ULL) || !(a & 0x7FFFULL);
-}
-
-uint64_t helper_cmpfgt (uint64_t a)
-{
-return !(a & 0x8000ULL) && (a & 0x7FFFULL);
-}
-
-uint64_t helper_cmpfge (uint64_t a)
-{
-return !(a & 0x8000ULL) || !(a & 0x7FFFULL);
-}
-
-
/* Floating point format conversion */
uint64_t helper_cvtts (uint64_t a)
{
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index e426677..5b34fc6 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -294,77 +294,98 @@ static inline void gen_store_mem(DisasContext *ctx,
tcg_temp_free(addr);
}
-static inline void gen_bcond(DisasContext *ctx, TCGCond cond, int ra,
- int32_t disp, int mask)
+static void gen_bcond_pcload(DisasContext *ctx, int32_t disp, int lab_true)
{
-int l1, l2;
+int lab_over = gen_new_label();
+
+tcg_gen_movi_i64(cpu_pc, ctx->pc);
+tcg_gen_br(lab_over);
+gen_set_label(lab_true);
+tcg_gen_movi_i64(cpu_pc, ctx->pc + (int64_t)(disp << 2));
+gen_set_label(lab_over);
+}
+
+static void gen_bcond(DisasContext *ctx, TCGCond cond, int ra,
+ int32_t disp, int mask)
+{
+int lab_true = gen_new_label();
-l1 = gen_new_label();
-l2 = gen_new_label();
if (likely(ra != 31)) {
if (mask) {
TCGv tmp = tcg_temp_new();
tcg_gen_andi_i64(tmp, cpu_ir[ra], 1);
-tcg_gen_brcondi_i64(cond, tmp, 0, l1);
+tcg_gen_brcondi_i64(cond, tmp, 0, lab_true);
tcg_temp_free(tmp);
-} else
-tcg_gen_brcondi_i64(cond, cpu_ir[ra], 0, l1);
+} else {
+tcg_gen_brcondi_i64(cond, cpu_ir[ra], 0, lab_true);
+}
} else {
/* Very uncommon case - Do not bother to optimize. */
TCGv tmp = tcg_const_i64(0);
-tcg_gen_brcondi_i64(cond, tmp, 0, l1);
+tcg_gen_brcondi_i64(cond, tmp, 0, lab_true);
tcg_temp_free(tmp);
}
-tcg_gen_movi_i64(cpu_pc, ctx->pc);
-tcg_gen_br(l2);
-gen_set_label(l1);
-tcg_gen_movi_i64(cpu_pc, ctx->pc + (int64_t)(disp << 2));
-gen_set_label(l2);
+gen_bcond_pcload(ctx, disp, lab_true);
}
-static inline void gen_fbcond(DisasContext *ctx, int opc, int ra, int32_t disp)
+/* Generate a forward TCG branch to LAB_TRUE if RA cmp 0.0.
+ This is complicated by the fact that -0.0 compares the same as +0.0. */
+
+static void gen_fbcond_internal(TCGCond cond, TCGv src, int lab_true)
{
-int l1, l2;
+int lab_false = -1;
+uint64_t mzero = 1ull << 63;
TCGv tmp;
-TCGv src;
-
-l1 = gen_new_label();
-l2 = gen_new_label();
-if (ra != 31) {
+
+switch (cond) {
+case TCG_COND_LE:
+case TCG_COND_GT:
+/* For <= or >, the -0.0 value directly compares the way we want. */
+tcg_gen_brcondi_i64(cond, src, 0, lab_true);
+break;
+
+case TCG_COND_EQ:
+case TCG_COND_NE:
+/* For == or !=, we can simply mask off the sign bit and compare. */
+/* ??? Assume that the temporary is reclaimed at the branch. */
tmp = tcg_temp_new();
-src = cpu_fir[ra];
-} else {
-tmp = tcg_const_i64(0);
-src = tmp;
-}
-switch (opc) {
-case 0x31: /* FBEQ */
-gen_helper_cmpfeq(
[Qemu-devel] [PATCH 10/13] alpha: Expand ins*h inline.
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/target-alpha/helper.h
index a545c5c..4eb3b6f 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -19,9 +19,6 @@ DEF_HELPER_1(cttz, i64, i64)
DEF_HELPER_2(zap, i64, i64, i64)
DEF_HELPER_2(zapnot, i64, i64, i64)
-DEF_HELPER_2(inswh, i64, i64, i64)
-DEF_HELPER_2(inslh, i64, i64, i64)
-DEF_HELPER_2(insqh, i64, i64, i64)
DEF_HELPER_2(cmpbge, i64, i64, i64)
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index b6ec0e8..d7f4fb2 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -185,24 +185,6 @@ uint64_t helper_zapnot(uint64_t val, uint64_t mask)
return byte_zap(val, ~mask);
}
-uint64_t helper_inswh(uint64_t val, uint64_t mask)
-{
-val >>= 64 - ((mask & 7) * 8);
-return byte_zap(val, ~((0x03 << (mask & 7)) >> 8));
-}
-
-uint64_t helper_inslh(uint64_t val, uint64_t mask)
-{
-val >>= 64 - ((mask & 7) * 8);
-return byte_zap(val, ~((0x0F << (mask & 7)) >> 8));
-}
-
-uint64_t helper_insqh(uint64_t val, uint64_t mask)
-{
-val >>= 64 - ((mask & 7) * 8);
-return byte_zap(val, ~((0xFF << (mask & 7)) >> 8));
-}
-
uint64_t helper_cmpbge (uint64_t op1, uint64_t op2)
{
uint8_t opa, opb, res;
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 92d001d..d361ffe 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -625,6 +625,48 @@ static void gen_ext_l(int ra, int rb, int rc, int islit,
}
}
+/* INSWH, INSLH, INSQH */
+static void gen_ins_h(int ra, int rb, int rc, int islit,
+ uint8_t lit, uint8_t byte_mask)
+{
+if (unlikely(rc == 31))
+return;
+else if (unlikely(ra == 31) || (islit && (lit & 7) == 0))
+tcg_gen_movi_i64(cpu_ir[rc], 0);
+else {
+TCGv tmp = tcg_temp_new();
+
+/* The instruction description has us left-shift the byte mask
+ and extract bits <15:8> and apply that zap at the end. This
+ is equivalent to simply performing the zap first and shifting
+ afterward. */
+gen_zapnoti (tmp, cpu_ir[ra], byte_mask);
+
+if (islit) {
+/* Note that we have handled the lit==0 case above. */
+tcg_gen_shri_i64 (cpu_ir[rc], tmp, 64 - (lit & 7) * 8);
+} else {
+TCGv shift = tcg_temp_new();
+
+/* If (B & 7) == 0, we need to shift by 64 and leave a zero.
+ Do this portably by splitting the shift into two parts:
+ shift_count-1 and 1. Arrange for the -1 by using
+ ones-complement instead of twos-complement in the negation:
+ ~((B & 7) * 8) & 63. */
+
+tcg_gen_andi_i64(shift, cpu_ir[rb], 7);
+tcg_gen_shli_i64(shift, shift, 3);
+tcg_gen_not_i64(shift, shift);
+tcg_gen_andi_i64(shift, shift, 0x3f);
+
+tcg_gen_shr_i64(cpu_ir[rc], tmp, shift);
+tcg_gen_shri_i64(cpu_ir[rc], cpu_ir[rc], 1);
+tcg_temp_free(shift);
+}
+tcg_temp_free(tmp);
+}
+}
+
/* INSBL, INSWL, INSLL, INSQL */
static void gen_ins_l(int ra, int rb, int rc, int islit,
uint8_t lit, uint8_t byte_mask)
@@ -750,9 +792,6 @@ ARITH3(addlv)
ARITH3(sublv)
ARITH3(addqv)
ARITH3(subqv)
-ARITH3(inswh)
-ARITH3(inslh)
-ARITH3(insqh)
ARITH3(umulh)
ARITH3(mullv)
ARITH3(mulqv)
@@ -1479,7 +1518,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x57:
/* INSWH */
-gen_inswh(ra, rb, rc, islit, lit);
+gen_ins_h(ra, rb, rc, islit, lit, 0x03);
break;
case 0x5A:
/* EXTWH */
@@ -1491,7 +1530,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x67:
/* INSLH */
-gen_inslh(ra, rb, rc, islit, lit);
+gen_ins_h(ra, rb, rc, islit, lit, 0x0f);
break;
case 0x6A:
/* EXTLH */
@@ -1503,7 +1542,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x77:
/* INSQH */
-gen_insqh(ra, rb, rc, islit, lit);
+gen_ins_h(ra, rb, rc, islit, lit, 0xff);
break;
case 0x7A:
/* EXTQH */
[Qemu-devel] [PATCH 05/13] alpha: Fix fbcond branch offset.
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
index 5e139e6..cabf75a 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -314,8 +314,7 @@ static inline void gen_bcond(DisasContext *ctx, TCGCond cond, int ra,
gen_set_label(l2);
}
-static inline void gen_fbcond(DisasContext *ctx, int opc, int ra,
- int32_t disp16)
+static inline void gen_fbcond(DisasContext *ctx, int opc, int ra, int32_t disp)
{
int l1, l2;
TCGv tmp;
@@ -356,7 +355,7 @@ static inline void gen_fbcond(DisasContext *ctx, int opc, int ra,
tcg_gen_movi_i64(cpu_pc, ctx->pc);
tcg_gen_br(l2);
gen_set_label(l1);
-tcg_gen_movi_i64(cpu_pc, ctx->pc + (int64_t)(disp16 << 2));
+tcg_gen_movi_i64(cpu_pc, ctx->pc + (int64_t)(disp << 2));
gen_set_label(l2);
}
@@ -2335,7 +2334,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
case 0x31: /* FBEQ */
case 0x32: /* FBLT */
case 0x33: /* FBLE */
-gen_fbcond(ctx, opc, ra, disp16);
+gen_fbcond(ctx, opc, ra, disp21);
ret = 1;
break;
case 0x34:
@@ -2348,7 +2347,7 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
case 0x35: /* FBNE */
case 0x36: /* FBGE */
case 0x37: /* FBGT */
-gen_fbcond(ctx, opc, ra, disp16);
+gen_fbcond(ctx, opc, ra, disp21);
ret = 1;
break;
case 0x38:
[Qemu-devel] [PATCH 06/13] alpha: Implement RD/WRUNIQUE in the translator
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 +--
2 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/hw/alpha_palcode.c b/hw/alpha_palcode.c
index 44b2ca4..4cc37fe 100644
--- a/hw/alpha_palcode.c
+++ b/hw/alpha_palcode.c
@@ -1060,7 +1060,6 @@ void call_pal (CPUState *env, int palcode)
{
target_long ret;
-qemu_log("%s: palcode %02x\n", __func__, palcode);
switch (palcode) {
case 0x80:
/* BPT */
@@ -1093,14 +1092,14 @@ void call_pal (CPUState *env, int palcode)
break;
case 0x9E:
/* RDUNIQUE */
-env->ir[IR_V0] = env->unique;
qemu_log("RDUNIQUE: " TARGET_FMT_lx "\n", env->unique);
-break;
+/* Handled in the translator for usermode. */
+abort ();
case 0x9F:
/* WRUNIQUE */
-env->unique = env->ir[IR_A0];
-qemu_log("WRUNIQUE: " TARGET_FMT_lx "\n", env->unique);
-break;
+qemu_log("WRUNIQUE: " TARGET_FMT_lx "\n", env->ir[IR_A0]);
+/* Handled in the translator for usermode. */
+abort ();
case 0xAA:
/* GENTRAP */
qemu_log("GENTRAP: " TARGET_FMT_lx "\n", env->ir[IR_A0]);
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index cabf75a..b53737a 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -57,6 +57,9 @@ static TCGv cpu_ir[31];
static TCGv cpu_fir[31];
static TCGv cpu_pc;
static TCGv cpu_lock;
+#ifdef CONFIG_USER_ONLY
+static TCGv cpu_uniq;
+#endif
/* register names */
static char cpu_reg_names[10*4+21*5 + 10*5+21*6];
@@ -93,6 +96,11 @@ static void alpha_translate_init(void)
cpu_lock = tcg_global_mem_new_i64(TCG_AREG0,
offsetof(CPUState, lock), "lock");
+#ifdef CONFIG_USER_ONLY
+cpu_uniq = tcg_global_mem_new_i64(TCG_AREG0,
+ offsetof(CPUState, unique), "uniq");
+#endif
+
/* register helpers */
#define GEN_HELPER 2
#include "helper.h"
@@ -751,23 +759,34 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
switch (opc) {
case 0x00:
/* CALL_PAL */
+#ifdef CONFIG_USER_ONLY
+if (palcode == 0x9E) {
+/* RDUNIQUE */
+tcg_gen_mov_i64(cpu_ir[IR_V0], cpu_uniq);
+break;
+} else if (palcode == 0x9F) {
+/* WRUNIQUE */
+tcg_gen_mov_i64(cpu_uniq, cpu_ir[IR_A0]);
+break;
+}
+#endif
if (palcode >= 0x80 && palcode < 0xC0) {
/* Unprivileged PAL call */
gen_excp(ctx, EXCP_CALL_PAL + ((palcode & 0x3F) << 6), 0);
-#if !defined (CONFIG_USER_ONLY)
-} else if (palcode < 0x40) {
+ret = 3;
+break;
+}
+#ifndef CONFIG_USER_ONLY
+if (palcode < 0x40) {
/* Privileged PAL code */
if (ctx->mem_idx & 1)
goto invalid_opc;
-else
-gen_excp(ctx, EXCP_CALL_PALP + ((palcode & 0x3F) << 6), 0);
-#endif
-} else {
-/* Invalid PAL call */
-goto invalid_opc;
+gen_excp(ctx, EXCP_CALL_PALP + ((palcode & 0x3F) << 6), 0);
+ret = 3;
}
-ret = 3;
-break;
+#endif
+/* Invalid PAL call */
+goto invalid_opc;
case 0x01:
/* OPC01 */
goto invalid_opc;
[Qemu-devel] [PATCH 11/13] alpha: Fix FMOV.
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/translate.c
+++ b/target-alpha/translate.c
@@ -1834,12 +1834,16 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
break;
case 0x020:
if (likely(rc != 31)) {
-if (ra == rb)
+if (ra == rb) {
/* FMOV */
-tcg_gen_mov_i64(cpu_fir[rc], cpu_fir[ra]);
-else
+if (ra == 31)
+tcg_gen_movi_i64(cpu_fir[rc], 0);
+else
+tcg_gen_mov_i64(cpu_fir[rc], cpu_fir[ra]);
+} else {
/* CPYS */
gen_fcpys(ra, rb, rc);
+}
}
break;
case 0x021:
[Qemu-devel] [PATCH 09/13] alpha: Expand msk*h inline.
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-alpha/helper.h
index 8db73b0..a545c5c 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -19,11 +19,8 @@ DEF_HELPER_1(cttz, i64, i64)
DEF_HELPER_2(zap, i64, i64, i64)
DEF_HELPER_2(zapnot, i64, i64, i64)
-DEF_HELPER_2(mskwh, i64, i64, i64)
DEF_HELPER_2(inswh, i64, i64, i64)
-DEF_HELPER_2(msklh, i64, i64, i64)
DEF_HELPER_2(inslh, i64, i64, i64)
-DEF_HELPER_2(mskqh, i64, i64, i64)
DEF_HELPER_2(insqh, i64, i64, i64)
DEF_HELPER_2(cmpbge, i64, i64, i64)
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index 591adbd..b6ec0e8 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -185,33 +185,18 @@ uint64_t helper_zapnot(uint64_t val, uint64_t mask)
return byte_zap(val, ~mask);
}
-uint64_t helper_mskwh(uint64_t val, uint64_t mask)
-{
-return byte_zap(val, (0x03 << (mask & 7)) >> 8);
-}
-
uint64_t helper_inswh(uint64_t val, uint64_t mask)
{
val >>= 64 - ((mask & 7) * 8);
return byte_zap(val, ~((0x03 << (mask & 7)) >> 8));
}
-uint64_t helper_msklh(uint64_t val, uint64_t mask)
-{
-return byte_zap(val, (0x0F << (mask & 7)) >> 8);
-}
-
uint64_t helper_inslh(uint64_t val, uint64_t mask)
{
val >>= 64 - ((mask & 7) * 8);
return byte_zap(val, ~((0x0F << (mask & 7)) >> 8));
}
-uint64_t helper_mskqh(uint64_t val, uint64_t mask)
-{
-return byte_zap(val, (0xFF << (mask & 7)) >> 8);
-}
-
uint64_t helper_insqh(uint64_t val, uint64_t mask)
{
val >>= 64 - ((mask & 7) * 8);
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 3e50d27..92d001d 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -579,8 +579,8 @@ static inline void gen_zap(int ra, int rb, int rc, int islit, uint8_t lit)
/* EXTWH, EXTLH, EXTQH */
-static inline void gen_ext_h(int ra, int rb, int rc, int islit,
- uint8_t lit, uint8_t byte_mask)
+static void gen_ext_h(int ra, int rb, int rc, int islit,
+ uint8_t lit, uint8_t byte_mask)
{
if (unlikely(rc == 31))
return;
@@ -604,8 +604,8 @@ static inline void gen_ext_h(int ra, int rb, int rc, int islit,
}
/* EXTBL, EXTWL, EXTLL, EXTQL */
-static inline void gen_ext_l(int ra, int rb, int rc, int islit,
- uint8_t lit, uint8_t byte_mask)
+static void gen_ext_l(int ra, int rb, int rc, int islit,
+ uint8_t lit, uint8_t byte_mask)
{
if (unlikely(rc == 31))
return;
@@ -626,8 +626,8 @@ static inline void gen_ext_l(int ra, int rb, int rc, int islit,
}
/* INSBL, INSWL, INSLL, INSQL */
-static inline void gen_ins_l(int ra, int rb, int rc, int islit,
- uint8_t lit, uint8_t byte_mask)
+static void gen_ins_l(int ra, int rb, int rc, int islit,
+ uint8_t lit, uint8_t byte_mask)
{
if (unlikely(rc == 31))
return;
@@ -655,9 +655,47 @@ static inline void gen_ins_l(int ra, int rb, int rc, int islit,
}
}
+/* MSKWH, MSKLH, MSKQH */
+static void gen_msk_h(int ra, int rb, int rc, int islit,
+ uint8_t lit, uint8_t byte_mask)
+{
+if (unlikely(rc == 31))
+return;
+else if (unlikely(ra == 31))
+tcg_gen_movi_i64(cpu_ir[rc], 0);
+else if (islit) {
+gen_zapnoti (cpu_ir[rc], cpu_ir[ra], ~((byte_mask << (lit & 7)) >> 8));
+} else {
+TCGv shift = tcg_temp_new();
+TCGv mask = tcg_temp_new();
+
+/* The instruction description is as above, where the byte_mask
+ is shifted left, and then we extract bits <15:8>. This can be
+ emulated with a right-shift on the expanded byte mask. This
+ requires extra care because for an input <2:0> == 0 we need a
+ shift of 64 bits in order to generate a zero. This is done by
+ splitting the shift into two parts, the variable shift - 1
+ followed by a constant 1 shift. The code we expand below is
+ equivalent to ~((B & 7) * 8) & 63. */
+
+tcg_gen_andi_i64(shift, cpu_ir[rb], 7);
+tcg_gen_shli_i64(shift, shift, 3);
+tcg_gen_not_i64(shift, shift);
+tcg_gen_andi_i64(shift, shift, 0x3f);
+tcg_gen_movi_i64(mask, zapnot_mask (byte_mask));
+tcg_gen_shr_i64(mask, mask, shift);
+tcg_gen_shri_i64(mask, mask, 1);
+
+tcg_gen_andc_i64(cpu_ir[rc], cpu_ir[ra], mask);
+
+tcg_temp_free(mask);
+tcg_temp_free(shift);
+}
+}
+
/* MSKBL, MSKWL, MSKLL, MSKQL */
-static inline void gen_msk_l(int ra, int rb, int rc, int islit,
- uint8_t lit, uint8_t byte_mask)
+static void gen_msk_l(int ra, int rb, int rc, int islit,
+
[Qemu-devel] [PATCH 00/13] Alpha emulation improvements, round two
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 instructions inline instead of via helpers. Worst case these expand to about 6 tcg ops. I was hoping without looking that tcg would do some simple CSE operations within the block. Of course, cse isn't implemented yet, but there's no reason that couldn't happen in the future. A good test case for the cse might be gcc.c-torture/execute/20040709-2.c, function retmeE: 120001964: 0f 00 50 2c ldq_u t1,15(a0) 120001968: 00 00 30 2c ldq_u t0,0(a0) 12000196c: e4 0e 50 4a insqh a2,a0,t3 120001970: 72 07 50 4a insql a2,a0,a2 120001974: e3 0e 30 4a insqh a1,a0,t2 120001978: 71 07 30 4a insql a1,a0,a1 12000197c: 03 04 72 44 or t2,a2,t2 120001980: 42 0e 50 48 mskqh t1,a0,t1 120001984: 41 06 30 48 mskql t0,a0,t0 120001988: 02 04 44 44 or t1,t3,t1 12000198c: 01 04 31 44 or t0,a1,t0 120001990: 0f 00 50 3c stq_u t1,15(a0) 120001994: 08 00 70 3c stq_u t2,8(a0) 120001998: 00 00 30 3c stq_u t0,0(a0) Here we've got 6 byte manipulation insns using A0 as an input, all of which compute at least (A0 & 7) * 8; there's even more that could be shared in this block. (3) There are three FP correctness fixes. Not surprisingly from the last, there are now fewer gcc testsuite failures. I suspect that I'll have to tackle the missing rounding mode bits before the rest of the testsuite will work. r~ Richard Henderson (13): alpha: Implement missing MVI instructions. alpha: Fix -d in_asm alpha: Expand zap/zapnot with immediate inline. alpha: Rewrite gen_ext_[hl] in terms of zapnot. alpha: Fix fbcond branch offset. alpha: Implement RD/WRUNIQUE in the translator alpha: Expand ins*l inline. alpha: Expand msk*l inline. alpha: Expand msk*h inline. alpha: Expand ins*h inline. alpha: Fix FMOV. alpha: Fix double log_cpu_state. alpha: Implement fp branch/cmov inline. hw/alpha_palcode.c | 11 +- target-alpha/helper.h| 35 +-- target-alpha/op_helper.c | 228 ++-- target-alpha/translate.c | 645 +++--- 4 files changed, 600 insertions(+), 319 deletions(-)
[Qemu-devel] [PATCH 03/13] alpha: Expand zap/zapnot with immediate inline.
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 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 4f923bb..bd193da 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -507,6 +507,65 @@ FCMOV(cmpfge)
FCMOV(cmpfle)
FCMOV(cmpfgt)
+/* Implement zapnot with an immediate operand, which expands to some
+ form of immediate AND. This is a basic building block in the
+ definition of many of the other byte manipulation instructions. */
+static inline void gen_zapnoti(int ra, int rc, uint8_t lit)
+{
+uint64_t mask;
+int i;
+
+switch (lit) {
+case 0x00:
+tcg_gen_movi_i64(cpu_ir[rc], 0);
+break;
+case 0x01:
+tcg_gen_ext8u_i64(cpu_ir[rc], cpu_ir[ra]);
+break;
+case 0x03:
+tcg_gen_ext16u_i64(cpu_ir[rc], cpu_ir[ra]);
+break;
+case 0x0f:
+tcg_gen_ext32u_i64(cpu_ir[rc], cpu_ir[ra]);
+break;
+case 0xff:
+tcg_gen_mov_i64(cpu_ir[rc], cpu_ir[ra]);
+break;
+default:
+for (mask = i = 0; i < 8; ++i) {
+if ((lit >> i) & 1)
+mask |= 0xffull << (i * 8);
+}
+tcg_gen_andi_i64 (cpu_ir[rc], cpu_ir[ra], mask);
+break;
+}
+}
+
+static inline void gen_zapnot(int ra, int rb, int rc, int islit, uint8_t lit)
+{
+if (unlikely(rc == 31))
+return;
+else if (unlikely(ra == 31))
+tcg_gen_movi_i64(cpu_ir[rc], 0);
+else if (islit)
+gen_zapnoti(ra, rc, lit);
+else
+gen_helper_zapnot (cpu_ir[rc], cpu_ir[ra], cpu_ir[rb]);
+}
+
+static inline void gen_zap(int ra, int rb, int rc, int islit, uint8_t lit)
+{
+if (unlikely(rc == 31))
+return;
+else if (unlikely(ra == 31))
+tcg_gen_movi_i64(cpu_ir[rc], 0);
+else if (islit)
+gen_zapnoti(ra, rc, ~lit);
+else
+gen_helper_zap (cpu_ir[rc], cpu_ir[ra], cpu_ir[rb]);
+}
+
+
/* EXTWH, EXTWH, EXTLH, EXTQH */
static inline void gen_ext_h(void(*tcg_gen_ext_i64)(TCGv t0, TCGv t1),
int ra, int rb, int rc, int islit, uint8_t lit)
@@ -598,8 +657,6 @@ ARITH3(mskwl)
ARITH3(inswl)
ARITH3(mskll)
ARITH3(insll)
-ARITH3(zap)
-ARITH3(zapnot)
ARITH3(mskql)
ARITH3(insql)
ARITH3(mskwh)
[Qemu-devel] [PATCH 01/13] alpha: Implement missing MVI instructions.
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.h b/target-alpha/helper.h
index 9c60be1..850ba0d 100644
--- a/target-alpha/helper.h
+++ b/target-alpha/helper.h
@@ -36,6 +36,20 @@ DEF_HELPER_2(insqh, i64, i64, i64)
DEF_HELPER_2(cmpbge, i64, i64, i64)
+DEF_HELPER_2(minub8, i64, i64, i64)
+DEF_HELPER_2(minsb8, i64, i64, i64)
+DEF_HELPER_2(minuw4, i64, i64, i64)
+DEF_HELPER_2(minsw4, i64, i64, i64)
+DEF_HELPER_2(maxub8, i64, i64, i64)
+DEF_HELPER_2(maxsb8, i64, i64, i64)
+DEF_HELPER_2(maxuw4, i64, i64, i64)
+DEF_HELPER_2(maxsw4, i64, i64, i64)
+DEF_HELPER_2(perr, i64, i64, i64)
+DEF_HELPER_1(pklb, i64, i64)
+DEF_HELPER_1(pkwb, i64, i64)
+DEF_HELPER_1(unpkbl, i64, i64)
+DEF_HELPER_1(unpkbw, i64, i64)
+
DEF_HELPER_0(load_fpcr, i64)
DEF_HELPER_1(store_fpcr, void, i64)
diff --git a/target-alpha/op_helper.c b/target-alpha/op_helper.c
index 999a8ab..08d5924 100644
--- a/target-alpha/op_helper.c
+++ b/target-alpha/op_helper.c
@@ -277,6 +277,174 @@ uint64_t helper_cmpbge (uint64_t op1, uint64_t op2)
return res;
}
+uint64_t helper_minub8 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+uint8_t opa, opb, opr;
+int i;
+
+for (i = 0; i < 8; ++i) {
+opa = op1 >> (i * 8);
+opb = op2 >> (i * 8);
+opr = opa < opb ? opa : opb;
+res |= (uint64_t)opr << (i * 8);
+}
+return res;
+}
+
+uint64_t helper_minsb8 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+int8_t opa, opb;
+uint8_t opr;
+int i;
+
+for (i = 0; i < 8; ++i) {
+opa = op1 >> (i * 8);
+opb = op2 >> (i * 8);
+opr = opa < opb ? opa : opb;
+res |= (uint64_t)opr << (i * 8);
+}
+return res;
+}
+
+uint64_t helper_minuw4 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+uint16_t opa, opb, opr;
+int i;
+
+for (i = 0; i < 4; ++i) {
+opa = op1 >> (i * 16);
+opb = op2 >> (i * 16);
+opr = opa < opb ? opa : opb;
+res |= (uint64_t)opr << (i * 16);
+}
+return res;
+}
+
+uint64_t helper_minsw4 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+int16_t opa, opb;
+uint16_t opr;
+int i;
+
+for (i = 0; i < 4; ++i) {
+opa = op1 >> (i * 16);
+opb = op2 >> (i * 16);
+opr = opa < opb ? opa : opb;
+res |= (uint64_t)opr << (i * 16);
+}
+return res;
+}
+
+uint64_t helper_maxub8 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+uint8_t opa, opb, opr;
+int i;
+
+for (i = 0; i < 8; ++i) {
+opa = op1 >> (i * 8);
+opb = op2 >> (i * 8);
+opr = opa > opb ? opa : opb;
+res |= (uint64_t)opr << (i * 8);
+}
+return res;
+}
+
+uint64_t helper_maxsb8 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+int8_t opa, opb;
+uint8_t opr;
+int i;
+
+for (i = 0; i < 8; ++i) {
+opa = op1 >> (i * 8);
+opb = op2 >> (i * 8);
+opr = opa > opb ? opa : opb;
+res |= (uint64_t)opr << (i * 8);
+}
+return res;
+}
+
+uint64_t helper_maxuw4 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+uint16_t opa, opb, opr;
+int i;
+
+for (i = 0; i < 4; ++i) {
+opa = op1 >> (i * 16);
+opb = op2 >> (i * 16);
+opr = opa > opb ? opa : opb;
+res |= (uint64_t)opr << (i * 16);
+}
+return res;
+}
+
+uint64_t helper_maxsw4 (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+int16_t opa, opb;
+uint16_t opr;
+int i;
+
+for (i = 0; i < 4; ++i) {
+opa = op1 >> (i * 16);
+opb = op2 >> (i * 16);
+opr = opa > opb ? opa : opb;
+res |= (uint64_t)opr << (i * 16);
+}
+return res;
+}
+
+uint64_t helper_perr (uint64_t op1, uint64_t op2)
+{
+uint64_t res = 0;
+uint8_t opa, opb, opr;
+int i;
+
+for (i = 0; i < 8; ++i) {
+opa = op1 >> (i * 8);
+opb = op2 >> (i * 8);
+if (opa >= opb)
+opr = opa - opb;
+else
+opr = opb - opa;
+res += opr;
+}
+return res;
+}
+
+uint64_t helper_pklb (uint64_t op1)
+{
+return (op1 & 0xff) | ((op1 >> 24) & 0xff00);
+}
+
+uint64_t helper_pkwb (uint64_t op1)
+{
+return ((op1 & 0xff)
+| ((op1 >> 8) & 0xff00)
+| ((op1 >> 16) & 0xff)
+| ((op1 >> 24) & 0xff00));
+}
+
+uint64_t helper_unpkbl (uint64_t op1)
+{
+return (op1 & 0xff) | ((op1 & 0xff00) << 24);
+}
+
+uint64_t helper_unpkbw (uint64_t op1)
+{
+return ((op1 & 0xff)
+| ((op1 & 0xff00) << 8)
+| ((op1 & 0xff) << 16)
+| ((op1 & 0xff00) << 24));
+}
+
/* Floating point helpers */
/* F floating (VAX) */
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
in
[Qemu-devel] [PATCH 02/13] alpha: Fix -d in_asm
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 | 19 ---
1 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 851eb50..4f923bb 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -35,7 +35,7 @@
#undef ALPHA_DEBUG_DISAS
#ifdef ALPHA_DEBUG_DISAS
-# define LOG_DISAS(...) qemu_log(__VA_ARGS__)
+# define LOG_DISAS(...) qemu_log_mask(CPU_LOG_TB_IN_ASM, ## __VA_ARGS__)
#else
# define LOG_DISAS(...) do { } while (0)
#endif
@@ -696,8 +696,9 @@ static inline int translate_one(DisasContext *ctx, uint32_t insn)
fn7 = (insn >> 5) & 0x007F;
fn2 = (insn >> 5) & 0x0003;
ret = 0;
-LOG_DISAS("opc %02x ra %d rb %d rc %d disp16 %04x\n",
+LOG_DISAS("opc %02x ra %2d rb %2d rc %2d disp16 %6d\n",
opc, ra, rb, rc, disp16);
+
switch (opc) {
case 0x00:
/* CALL_PAL */
@@ -2353,9 +2354,6 @@ static inline void gen_intermediate_code_internal(CPUState *env,
TranslationBlock *tb,
int search_pc)
{
-#if defined ALPHA_DEBUG_DISAS
-static int insn_count;
-#endif
DisasContext ctx, *ctxp = &ctx;
target_ulong pc_start;
uint32_t insn;
@@ -2405,16 +2403,7 @@ static inline void gen_intermediate_code_internal(CPUState *env,
}
if (num_insns + 1 == max_insns && (tb->cflags & CF_LAST_IO))
gen_io_start();
-#if defined ALPHA_DEBUG_DISAS
-insn_count++;
-LOG_DISAS("pc " TARGET_FMT_lx " mem_idx %d\n",
- ctx.pc, ctx.mem_idx);
-#endif
insn = ldl_code(ctx.pc);
-#if defined ALPHA_DEBUG_DISAS
-insn_count++;
-LOG_DISAS("opcode %08x %d\n", insn, insn_count);
-#endif
num_insns++;
ctx.pc += 4;
ret = translate_one(ctxp, insn);
@@ -2459,7 +2448,7 @@ static inline void gen_intermediate_code_internal(CPUState *env,
tb->size = ctx.pc - pc_start;
tb->icount = num_insns;
}
-#if defined ALPHA_DEBUG_DISAS
+#ifdef DEBUG_DISAS
log_cpu_state_mask(CPU_LOG_TB_CPU, env, 0);
if (qemu_loglevel_mask(CPU_LOG_TB_IN_ASM)) {
qemu_log("IN: %s\n", lookup_symbol(pc_start));
Re: [Qemu-devel] Adding support for Mac OS X ppc64 host
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 other ppc[64] platforms yet. how exactly did you test that (so that i can try to debug it here) $ /Users/andreas/QEMU/latest64/bin/qemu-system-sparc64 -boot d -cdrom /Users/andreas/QEMU/sol-10-u3-ga-sparc-dvd.iso $ /Users/andreas/QEMU/latest64/bin/qemu-system-sparc64 -boot d -cdrom /Users/andreas/QEMU/debian-40r3-sparc-CD-1.iso All these (also MilaX, in case you don't have Solaris 10 around) are expected to enter OpenBIOS and result in OpenBIOS errors but not in QEMU crashes or hangs. On Linux add -nographic. I was only able to find debian-40r3-sparc-netinst.iso here on ppc/ linux it boots (i think): boot: expert Allocated 8 Megs of memory at 0x4000 for kernel Loaded kernel version 2.6.18 Loading initial ramdisk (3882238 bytes at 0xC0 phys, 0x40C0 virt)... - Remapping the kernel... done. Booting Linux... And it sits there while i'm losing patience.. Can you retry with netinst, if it behaves like CD-1 in your case the problem is most likely confined to OSX, otherwise i would have to search for CD-1 better. I tried with 4.0r8 businesscard: Such a hang I could reproduce on Linux/ppc and Linux/ppc64 and OSX/ppc64 and Linux/amd64 only when running with qemu-system-sparc64, but not with qemu-system-sparc. Also, on Linux/ppc64, qemu and qemu-system-x86_64 render Haiku nightly image r34558 x86gcc2 unusable (desktop garbled, no cursor), while on Linux/ppc and OSX/ppc64 (r34514) and Linux/amd64 it works okay. Andreas
Re: [Qemu-devel] Spice project is now open
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 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 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 then figuring out if there's a vnc analog. If there are compellingly unique features to Spice that can't be duplicated in vnc, then it's a no brainer. If you can do most things in vnc but it would be hackish whereas Spice makes it all elegant, then provided we can merge Spice without a huge amount of pain, then it's a net win. However, if we need to make a few changes to vnc in order to get the same performance as Spice, then it's not quite as clear that it's what we should be using. We're talking about a major change here. There is a ton of management software that assumes vnc today. Even though there are Spice clients out there, there are embedded vnc clients in certain tools today along with java applets. That's not to say we shouldn't embrace Spice, we just have to make sure we have a good reason to. >>> >>> Ok, I understand your concerns. >>> >>> But even though that spice and vnc achive in the end of the day >>> the same thing - they both allow remote rendering, they have >>> fendumental diffrent architacture. >>> >>> Spice server work with a ring to the guest, it was build from >>> day one to work like that, In addition it was built from day >>> one so that the server will render only what it must to render >>> (to allow much higher virtualization denticity). >> >> The ring is from qemu <-> guest, right? I mean, qemu <-> client >> would be a TCP transport anyways, so the ring argument is void. > > > Beside the fact that we dont have the network overhead... Eh - when you connect to the VM remotely you still get the network overhead, because you're connecting to it via the network :-). >>> >>> Yes but you send the data from the HOST networking, not from the >>> virtualized guest networking (That will later send it from the Host >>> networking)... >> >> Exactly. So you'd get the same as with virtio-fb and VNC :-). > > Yes, virtio-fb and spice have the same overhead for the ring part, > but this not what i understood when you said: > "The ring is from qemu <-> guest, right? I mean, qemu <-> client > would be a TCP transport anyways, so the ring argument is void." Oh one of your arguments about the superiority of SPICE was that it uses a ring buffer. I just wanted to make sure you're talking about the guest <-> hypervisor interface there, thus not stressing anything in the SPICE protocol :-). > > But leave it :). > >> >>> >>> > >> >>> Just to make clear how much spice is diffrence from VNC is by >>> the fact that only the library itself (not including the >>> drivers) have 128,277 lines of code inside it. (In my old qemu >>> repo i see almost 600,000 lines for qemu) so this should give >>> better prespective on how much spice is diffrent from vnc. >>> >>> So ofcurse in theory you can take all this 128,000 lines and >>> push them into qemu-vnc.c ?, but you got to remember that spice >>> is not just specific qemu thing, Spice should be used to work >>> on physical machines too, just cutting all this lines of code >>> from spice and throw it into qemu-vnc.c will be meaning a fork >>> of spice inside qemu >> >> I definitely understand your point of having a single protocol. >> The good news is that your physical machine stuff isn't released >> yet (AFAIK), so luckily there's still time to change parts of the >> protocol :-). >> >>> It isnt just the rings and the rendering style that make spice >>> diffrence, it is the channels it have for each compoment, it is >>> the multiple drawing surfaces, and so on... >> >> These should be fairly easy to implement in VNC too. In fact, I >> remember a project implementing off-screen drawing in VNC using a >> larger region of the screen than what was visible and then >> copyrect them in. >
[Qemu-devel] Re: Spice project is now open
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 1 too!...) 3) they would create stability issues in qemu because the plugin quality cannot be controlled. How is this different from 3rd party modules in the kernel? Paolo
[Qemu-devel] Re: Spice project is now open
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. Firefox uses that extensively, for example to render tiled backgrounds (though probably GTK user interface elements can do so less successfully). Paolo
Re: [Qemu-devel] Spice project is now open
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 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 > >>> 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 then figuring out if there's a > >> vnc analog. > >> > >> If there are compellingly unique features to Spice that can't > >> be duplicated in vnc, then it's a no brainer. If you can do > >> most things in vnc but it would be hackish whereas Spice makes > >> it all elegant, then provided we can merge Spice without a > >> huge amount of pain, then it's a net win. > >> > >> However, if we need to make a few changes to vnc in order to > >> get the same performance as Spice, then it's not quite as > >> clear that it's what we should be using. > >> > >> We're talking about a major change here. There is a ton of > >> management software that assumes vnc today. Even though there > >> are Spice clients out there, there are embedded vnc clients in > >> certain tools today along with java applets. > >> > >> That's not to say we shouldn't embrace Spice, we just have to > >> make sure we have a good reason to. > > > > Ok, I understand your concerns. > > > > But even though that spice and vnc achive in the end of the day > > the same thing - they both allow remote rendering, they have > > fendumental diffrent architacture. > > > > Spice server work with a ring to the guest, it was build from > > day one to work like that, In addition it was built from day > > one so that the server will render only what it must to render > > (to allow much higher virtualization denticity). > > The ring is from qemu <-> guest, right? I mean, qemu <-> client > would be a TCP transport anyways, so the ring argument is void. > >>> > >>> > >>> Beside the fact that we dont have the network overhead... > >> > >> Eh - when you connect to the VM remotely you still get the network > >> overhead, because you're connecting to it via the network :-). > > > > Yes but you send the data from the HOST networking, not from the > > virtualized guest networking (That will later send it from the Host > > networking)... > > Exactly. So you'd get the same as with virtio-fb and VNC :-). Yes, virtio-fb and spice have the same overhead for the ring part, but this not what i understood when you said: "The ring is from qemu <-> guest, right? I mean, qemu <-> client would be a TCP transport anyways, so the ring argument is void." But leave it :). > > > > > > >> > >>> > > > Just to make clear how much spice is diffrence from VNC is by > > the fact that only the library itself (not including the > > drivers) have 128,277 lines of code inside it. (In my old qemu > > repo i see almost 600,000 lines for qemu) so this should give > > better prespective on how much spice is diffrent from vnc. > > > > So ofcurse in theory you can take all this 128,000 lines and > > push them into qemu-vnc.c ?, but you got to remember that spice > > is not just specific qemu thing, Spice should be used to work > > on physical machines too, just cutting all this lines of code > > from spice and throw it into qemu-vnc.c will be meaning a fork > > of spice inside qemu > > I definitely understand your point of having a single protocol. > The good news is that your physical machine stuff isn't released > yet (AFAIK), so luckily there's still time to change parts of the > protocol :-). > > > It isnt just the rings and the rendering style that make spice > > diffrence, it is the channels it have for each compoment, it is > > the multiple drawing surfaces, and so on... > > These should be fairly easy to implement in VNC too. In fact, I > remember a project implementing off-screen drawing in VNC using a > larger region of the screen than what was visible and then > copyrect them in. > >>> > >>> In theory you can even change the whole of VNC into SPICE or the > >>> whole of VI into EMACS, so???, I personaly think changing code > >>> isnt the problem, the problem is always the desgien, and SPICE > >>> have fandumental diffrent desgien than VNC, (Here you can say: OK > >>> I can make my VNC
Re: [Qemu-devel] [Patch] remove unused params in some TCG functions
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() and
>> tcg_out_ld(). Probably this remains from dyngen time?
>
> Thoses parameters are used, simply not on an i386 host. Just look at
> tcg/*/tcg-target.c, especially 64-bit hosts.
Forward-looking (if that makes any sense for TCG) the parameters
can also be used for FP temps.
Laurent
>>
>> diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
>> index 972b102..484f476 100644
>> --- a/tcg/i386/tcg-target.c
>> +++ b/tcg/i386/tcg-target.c
>> @@ -262,14 +262,14 @@ static inline void tcg_out_movi(TCGContext *s,
>> TCGType type,
>> }
>> }
>>
>> -static inline void tcg_out_ld(TCGContext *s, TCGType type, int ret,
>> +static inline void tcg_out_ld(TCGContext *s, int ret,
>> int arg1, tcg_target_long arg2)
>> {
>> /* movl */
>> tcg_out_modrm_offset(s, 0x8b, ret, arg1, arg2);
>> }
>>
>> -static inline void tcg_out_st(TCGContext *s, TCGType type, int arg,
>> +static inline void tcg_out_st(TCGContext *s, int arg,
>> int arg1, tcg_target_long arg2)
>> {
>> /* movl */
>> diff --git a/tcg/tcg.c b/tcg/tcg.c
>> index 3c0e296..abed1c3 100644
>> --- a/tcg/tcg.c
>> +++ b/tcg/tcg.c
>> @@ -1333,7 +1333,7 @@ static void tcg_reg_free(TCGContext *s, int reg)
>> if (!ts->mem_coherent) {
>> if (!ts->mem_allocated)
>> temp_allocate_frame(s, temp);
>> - tcg_out_st(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
>> + tcg_out_st(s, reg, ts->mem_reg, ts->mem_offset);
>> }
>> ts->val_type = TEMP_VAL_MEM;
>> s->reg_to_temp[reg] = -1;
>> @@ -1389,7 +1389,7 @@ static void temp_save(TCGContext *s, int temp,
>> TCGRegSet allocated_regs)
>> if (!ts->mem_allocated)
>> temp_allocate_frame(s, temp);
>> tcg_out_movi(s, ts->type, reg, ts->val);
>> - tcg_out_st(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
>> + tcg_out_st(s, reg, ts->mem_reg, ts->mem_offset);
>> ts->val_type = TEMP_VAL_MEM;
>> break;
>> case TEMP_VAL_MEM:
>> @@ -1494,7 +1494,7 @@ static void tcg_reg_alloc_mov(TCGContext *s,
>> const TCGOpDef *def,
>> } else {
>> reg = tcg_reg_alloc(s, arg_ct->u.regs, s->reserved_regs);
>> }
>> - tcg_out_ld(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
>> + tcg_out_ld(s, reg, ts->mem_reg, ts->mem_offset);
>> } else if (ts->val_type == TEMP_VAL_CONST) {
>> if (ots->fixed_reg) {
>> reg = ots->reg;
>> @@ -1546,7 +1546,7 @@ static void tcg_reg_alloc_op(TCGContext *s,
>> ts = &s->temps[arg];
>> if (ts->val_type == TEMP_VAL_MEM) {
>> reg = tcg_reg_alloc(s, arg_ct->u.regs, allocated_regs);
>> - tcg_out_ld(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
>> + tcg_out_ld(s, reg, ts->mem_reg, ts->mem_offset);
>> ts->val_type = TEMP_VAL_REG;
>> ts->reg = reg;
>> ts->mem_coherent = 1;
>> @@ -1726,19 +1726,19 @@ static int tcg_reg_alloc_call(TCGContext *s,
>> const TCGOpDef *def,
>> if (arg != TCG_CALL_DUMMY_ARG) {
>> ts = &s->temps[arg];
>> if (ts->val_type == TEMP_VAL_REG) {
>> - tcg_out_st(s, ts->type, ts->reg, TCG_REG_CALL_STACK,
>> stack_offset);
>> + tcg_out_st(s, ts->reg, TCG_REG_CALL_STACK, stack_offset);
>> } else if (ts->val_type == TEMP_VAL_MEM) {
>> reg = tcg_reg_alloc(s, tcg_target_available_regs[ts->type],
>> s->reserved_regs);
>> /* XXX: not correct if reading values from the stack */
>> - tcg_out_ld(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
>> - tcg_out_st(s, ts->type, reg, TCG_REG_CALL_STACK,
>> stack_offset);
>> + tcg_out_ld(s, reg, ts->mem_reg, ts->mem_offset);
>> + tcg_out_st(s, reg, TCG_REG_CALL_STACK, stack_offset);
>> } else if (ts->val_type == TEMP_VAL_CONST) {
>> reg = tcg_reg_alloc(s, tcg_target_available_regs[ts->type],
>> s->reserved_regs);
>> /* XXX: sign extend may be needed on some targets */
>> tcg_out_movi(s, ts->type, reg, ts->val);
>> - tcg_out_st(s, ts->type, reg, TCG_REG_CALL_STACK,
>> stack_offset);
>> + tcg_out_st(s, reg, TCG_REG_CALL_STACK, stack_offset);
>> } else {
>> tcg_abort();
>> }
>> @@ -1761,7 +1761,7 @@ static int tcg_reg_alloc_call(TCGContext *s,
>> const TCGOpDef *def,
>> t
Re: [Qemu-devel] Re: X support for QXL and SPICE
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 support merged, I dont think it fair > to compare it into other stuff that do X, the opengl 3d rendering > should take much of spice advantages and work on spice better (at > least this my opinion) Oh Xrdp has 2 modes. 1) frame buffer mode 2) X passthrough I was talking about the first one. Alex
Re: [Qemu-devel] Re: X support for QXL and SPICE
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 stuff that do X, the opengl 3d rendering should take much of spice advantages and work on spice better (at least this my opinion) And beside Linux you got Windows that in that area Spice is much more advanced... > > Don't get me wrong - I'm not trying to talk anyone into what's best > for anyone. I'm trying to understand what speed we can expect from > which solution and what actually speeds up what :-). We dont get you wrong :). > > Alex >
Re: [Qemu-devel] Spice project is now open
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 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 couldn't possibly do with vnc. That means understanding each >> feature and then figuring out if there's a vnc analog. >> >> If there are compellingly unique features to Spice that can't be >> duplicated in vnc, then it's a no brainer. If you can do most >> things in vnc but it would be hackish whereas Spice makes it all >> elegant, then provided we can merge Spice without a huge amount >> of pain, then it's a net win. >> >> However, if we need to make a few changes to vnc in order to get >> the same performance as Spice, then it's not quite as clear that >> it's what we should be using. >> >> We're talking about a major change here. There is a ton of >> management software that assumes vnc today. Even though there >> are Spice clients out there, there are embedded vnc clients in >> certain tools today along with java applets. >> >> That's not to say we shouldn't embrace Spice, we just have to >> make sure we have a good reason to. > > Ok, I understand your concerns. > > But even though that spice and vnc achive in the end of the day > the same thing - they both allow remote rendering, they have > fendumental diffrent architacture. > > Spice server work with a ring to the guest, it was build from day > one to work like that, In addition it was built from day one so > that the server will render only what it must to render (to allow > much higher virtualization denticity). The ring is from qemu <-> guest, right? I mean, qemu <-> client would be a TCP transport anyways, so the ring argument is void. >>> >>> >>> Beside the fact that we dont have the network overhead... >> >> Eh - when you connect to the VM remotely you still get the network >> overhead, because you're connecting to it via the network :-). > > Yes but you send the data from the HOST networking, not from the > virtualized guest networking (That will later send it from the Host > networking)... Exactly. So you'd get the same as with virtio-fb and VNC :-). > > >> >>> > Just to make clear how much spice is diffrence from VNC is by the > fact that only the library itself (not including the drivers) have > 128,277 lines of code inside it. (In my old qemu repo i see almost > 600,000 lines for qemu) so this should give better prespective on > how much spice is diffrent from vnc. > > So ofcurse in theory you can take all this 128,000 lines and push > them into qemu-vnc.c ?, but you got to remember that spice is not > just specific qemu thing, Spice should be used to work on physical > machines too, just cutting all this lines of code from spice and > throw it into qemu-vnc.c will be meaning a fork of spice inside > qemu I definitely understand your point of having a single protocol. The good news is that your physical machine stuff isn't released yet (AFAIK), so luckily there's still time to change parts of the protocol :-). > It isnt just the rings and the rendering style that make spice > diffrence, it is the channels it have for each compoment, it is > the multiple drawing surfaces, and so on... These should be fairly easy to implement in VNC too. In fact, I remember a project implementing off-screen drawing in VNC using a larger region of the screen than what was visible and then copyrect them in. >>> >>> In theory you can even change the whole of VNC into SPICE or the >>> whole of VI into EMACS, so???, I personaly think changing code isnt >>> the problem, the problem is always the desgien, and SPICE have >>> fandumental diffrent desgien than VNC, (Here you can say: OK I can >>> make my VNC desgien like SPICE, or you can say I think SPICE dsgien >>> is bad, or you can just use SPICE...) >> >> Oh I'm not trying to talk you or anyone into anything. I was merely >> trying to stress that SPICE isn't really its own protocol but >> extensions to the RDP protocol (IIUC). You could do similar >> extensions to VNC if you liked. Thus I'd love to see a generic >> mid-layer and implementations of RDP and VNC on top of that actually. > > One of the decisions we have made in SPICE, was to provide a full > functional remote system, not realy
Re: [Qemu-devel] Spice project is now open
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 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 couldn't possibly do with vnc. That means understanding each > feature and then figuring out if there's a vnc analog. > > If there are compellingly unique features to Spice that can't be > duplicated in vnc, then it's a no brainer. If you can do most > things in vnc but it would be hackish whereas Spice makes it all > elegant, then provided we can merge Spice without a huge amount > of pain, then it's a net win. > > However, if we need to make a few changes to vnc in order to get > the same performance as Spice, then it's not quite as clear that > it's what we should be using. > > We're talking about a major change here. There is a ton of > management software that assumes vnc today. Even though there > are Spice clients out there, there are embedded vnc clients in > certain tools today along with java applets. > > That's not to say we shouldn't embrace Spice, we just have to > make sure we have a good reason to. > >>> > >>> Ok, I understand your concerns. > >>> > >>> But even though that spice and vnc achive in the end of the day > >>> the same thing - they both allow remote rendering, they have > >>> fendumental diffrent architacture. > >>> > >>> Spice server work with a ring to the guest, it was build from day > >>> one to work like that, In addition it was built from day one so > >>> that the server will render only what it must to render (to allow > >>> much higher virtualization denticity). > >> > >> The ring is from qemu <-> guest, right? I mean, qemu <-> client > >> would be a TCP transport anyways, so the ring argument is void. > > > > > > Beside the fact that we dont have the network overhead... > > Eh - when you connect to the VM remotely you still get the network > overhead, because you're connecting to it via the network :-). Yes but you send the data from the HOST networking, not from the virtualized guest networking (That will later send it from the Host networking)... > > > > >> > >>> Just to make clear how much spice is diffrence from VNC is by the > >>> fact that only the library itself (not including the drivers) have > >>> 128,277 lines of code inside it. (In my old qemu repo i see almost > >>> 600,000 lines for qemu) so this should give better prespective on > >>> how much spice is diffrent from vnc. > >>> > >>> So ofcurse in theory you can take all this 128,000 lines and push > >>> them into qemu-vnc.c ?, but you got to remember that spice is not > >>> just specific qemu thing, Spice should be used to work on physical > >>> machines too, just cutting all this lines of code from spice and > >>> throw it into qemu-vnc.c will be meaning a fork of spice inside > >>> qemu > >> > >> I definitely understand your point of having a single protocol. The > >> good news is that your physical machine stuff isn't released yet > >> (AFAIK), so luckily there's still time to change parts of the > >> protocol :-). > >> > >>> It isnt just the rings and the rendering style that make spice > >>> diffrence, it is the channels it have for each compoment, it is > >>> the multiple drawing surfaces, and so on... > >> > >> These should be fairly easy to implement in VNC too. In fact, I > >> remember a project implementing off-screen drawing in VNC using a > >> larger region of the screen than what was visible and then copyrect > >> them in. > > > > In theory you can even change the whole of VNC into SPICE or the > > whole of VI into EMACS, so???, I personaly think changing code isnt > > the problem, the problem is always the desgien, and SPICE have > > fandumental diffrent desgien than VNC, (Here you can say: OK I can > > make my VNC desgien like SPICE, or you can say I think SPICE dsgien > > is bad, or you can just use SPICE...) > > Oh I'm not trying to talk you or anyone into anything. I was merely > trying to stress that SPICE isn't really its own protocol but > extensions to the RDP protocol (IIUC). You could do similar > extensions to VNC if you liked. Thus I'd love to see a generic > mid-layer and implementations of RDP and VNC on top of that actually. One of the decisions we have made in SPICE, was to provide a full functional remote system, not realying on other system, We already have far more features than VNC have, so what is the logical in making spice extention of VNC? it more logical to
[Qemu-devel] Re: X support for QXL and SPICE
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 yet support for offscreen pixmaps in SPICE, so at the > moment, solid fill and CopyArea are the two main things that actually > make a difference. I Have patch that already add this support, we delayed it integration in order that we will make sure that the new surfaces/offscreens architacture would work well for all the users (windows and X), we should see it in very soon. Thanks. > > > Soren
[Qemu-devel] Re: X support for QXL and SPICE
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 >- Trapezoids > > - Bits of the core protocol: >- Solid fills >- CopyArea > > The X driver for the QXL device is not yet very sophisticated. What it > does is basically this: > >- It keeps a separate memory framebuffer uptodate using > software Very good :-). >- Solid fills and CopyArea requests are turned into SPICE > commands. The Tight VNC extension implements commands for this. We only implement CopyArea in Qemu though. >- The cursor is drawn using cursor commands VNC (the protocol) implements this. >- For other things, bitmaps are sent across the wire >- It uses the hashing feature of SPICE to only send > hashcodes for those bitmaps if it can get away with > it. I think VNC doesn't have a notion of this yet. It should be fairly easy to add though. > Even this simple support provides a better user experience than VNC > because scrolling is accelerated and doesn't result in a huge bitmap > getting sent across the wire. (I don't know if VNC has support for > bltblt, but even if it does, a screenscraping VNC server can't easily > make use of it). What really surprises me is that this is pretty much what Xvnc does. Except for the bitmap cache of course. Do you get better performance with SPICE on Linux guests than you get with direct Xvnc forwarding and -encodings 'tight copyrect'? What does performance look like in comparison to Xrdp? That one does implement bitmap caches. It should be really really close, right? Don't get me wrong - I'm not trying to talk anyone into what's best for anyone. I'm trying to understand what speed we can expect from which solution and what actually speeds up what :-). Alex
[Qemu-devel] X support for QXL and SPICE
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 - CopyArea The X driver for the QXL device is not yet very sophisticated. What it does is basically this: - It keeps a separate memory framebuffer uptodate using software - Solid fills and CopyArea requests are turned into SPICE commands. - The cursor is drawn using cursor commands - For other things, bitmaps are sent across the wire - It uses the hashing feature of SPICE to only send hashcodes for those bitmaps if it can get away with it. Even this simple support provides a better user experience than VNC because scrolling is accelerated and doesn't result in a huge bitmap getting sent across the wire. (I don't know if VNC has support for bltblt, but even if it does, a screenscraping VNC server can't easily make use of it). I believe some parts of XRender can be supported within the existing SPICE protocol, and that it would be fairly straightforward to add the other parts. 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 yet support for offscreen pixmaps in SPICE, so at the moment, solid fill and CopyArea are the two main things that actually make a difference. Soren
Re: [Qemu-devel] Spice project is now open
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 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 then figuring out if there's a vnc analog. If there are compellingly unique features to Spice that can't be duplicated in vnc, then it's a no brainer. If you can do most things in vnc but it would be hackish whereas Spice makes it all elegant, then provided we can merge Spice without a huge amount of pain, then it's a net win. However, if we need to make a few changes to vnc in order to get the same performance as Spice, then it's not quite as clear that it's what we should be using. We're talking about a major change here. There is a ton of management software that assumes vnc today. Even though there are Spice clients out there, there are embedded vnc clients in certain tools today along with java applets. That's not to say we shouldn't embrace Spice, we just have to make sure we have a good reason to. >>> >>> Ok, I understand your concerns. >>> >>> But even though that spice and vnc achive in the end of the day the >>> same thing - they both allow remote rendering, they have fendumental >>> diffrent architacture. >>> >>> Spice server work with a ring to the guest, it was build from day >>> one to work like that, In addition it was built from day one so >>> that the server will render only what it must to render (to allow >>> much higher virtualization denticity). >> >> The ring is from qemu <-> guest, right? I mean, qemu <-> client would >> be a TCP transport anyways, so the ring argument is void. > > > Beside the fact that we dont have the network overhead... Eh - when you connect to the VM remotely you still get the network overhead, because you're connecting to it via the network :-). > >> >>> Just to make clear how much spice is diffrence from VNC is by the >>> fact that only the library itself (not including the drivers) have >>> 128,277 lines of code inside it. (In my old qemu repo i see almost >>> 600,000 lines for qemu) so this should give better prespective on >>> how much spice is diffrent from vnc. >>> >>> So ofcurse in theory you can take all this 128,000 lines and push >>> them into qemu-vnc.c ?, but you got to remember that spice is not >>> just specific qemu thing, Spice should be used to work on physical >>> machines too, just cutting all this lines of code from spice and >>> throw it into qemu-vnc.c will be meaning a fork of spice inside >>> qemu >> >> I definitely understand your point of having a single protocol. The >> good news is that your physical machine stuff isn't released yet >> (AFAIK), so luckily there's still time to change parts of the >> protocol :-). >> >>> It isnt just the rings and the rendering style that make spice >>> diffrence, it is the channels it have for each compoment, it is the >>> multiple drawing surfaces, and so on... >> >> These should be fairly easy to implement in VNC too. In fact, I >> remember a project implementing off-screen drawing in VNC using a >> larger region of the screen than what was visible and then copyrect >> them in. > > In theory you can even change the whole of VNC into SPICE or the whole > of VI into EMACS, so???, I personaly think changing code isnt the > problem, the problem is always the desgien, and SPICE have fandumental > diffrent desgien than VNC, (Here you can say: OK I can make my VNC > desgien like SPICE, or you can say I think SPICE dsgien is bad, or you > can just use SPICE...) Oh I'm not trying to talk you or anyone into anything. I was merely trying to stress that SPICE isn't really its own protocol but extensions to the RDP protocol (IIUC). You could do similar extensions to VNC if you liked. Thus I'd love to see a generic mid-layer and implementations of RDP and VNC on top of that actually. > >> >>> This why the VDI interfaces were made, it was made so who ever used >>> VNC, can still use it, whoever want to use SPICE can still use >>> spice, >>> >>> By merging SPICE you just merge VDI interfaces, not the library >>> itself, it is so self contained thanks to the VDI interfaces, that >>> it almost dont touch anything inside qemu, I belive this was one of >>> the best aurgoments when Avi pushed kvm into the kernel - the fact >>> that it was a module that can be easyly removed if ppl dont want to >>> use it. >>> >>> > We acctuly want to kick away that video streaming, and move into > the DirectX and X video extentions vid
Re: [Qemu-devel] [PATCH 0/7] Improve alpha-linux userspace emulation
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 in qemu. At the moment I'm most interested in being able to test gcc, so user-level is enough. However, being able to boot a real kernel would be a Really Cool Thing. BTW, who takes care of reviewing and committing patches to non-mainstream cpus like this? r~
Re: [Qemu-devel] Spice project is now open
* 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 say the >> keyboard >> >> Is it really diffrence from any other function callbacks that used for >> such purpuse? >> > > Plugin interfaces have been discussed a few times in the past. The > concerns have been 1) they will be abused with the introduction of > proprietary plugins 2) we would have tremendous difficulty maintaining a > stable plugin abi 3) they would create stability issues in qemu because > the plugin quality cannot be controlled. I think you're talking about dlopen() vs. direct linkage of .so? Here's some code to ground things a bit. ifdef CONFIG_SPICE CFLAGS+=$(SPICE_CFLAGS) LIBS+=$(SPICE_LIBS) endif And specifically, there's a notion of the VDI interface added to core qemu, which can be extended by simply registering callbacks to that interface: vl.c::main() ... #ifdef CONFIG_SPICE ... spice_init(&core_interface);. #endif thanks, -chris
Re: [Qemu-devel] Spice project is now open
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 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 then figuring out if there's a vnc analog. > >> > >> If there are compellingly unique features to Spice that can't be > >> duplicated in vnc, then it's a no brainer. If you can do most > >> things in vnc but it would be hackish whereas Spice makes it all > >> elegant, then provided we can merge Spice without a huge amount of > >> pain, then it's a net win. > >> > >> However, if we need to make a few changes to vnc in order to get > >> the same performance as Spice, then it's not quite as clear that > >> it's what we should be using. > >> > >> We're talking about a major change here. There is a ton of > >> management software that assumes vnc today. Even though there are > >> Spice clients out there, there are embedded vnc clients in certain > >> tools today along with java applets. > >> > >> That's not to say we shouldn't embrace Spice, we just have to make > >> sure we have a good reason to. > > > > Ok, I understand your concerns. > > > > But even though that spice and vnc achive in the end of the day the > > same thing - they both allow remote rendering, they have fendumental > > diffrent architacture. > > > > Spice server work with a ring to the guest, it was build from day > > one to work like that, In addition it was built from day one so > > that the server will render only what it must to render (to allow > > much higher virtualization denticity). > > The ring is from qemu <-> guest, right? I mean, qemu <-> client would > be a TCP transport anyways, so the ring argument is void. Beside the fact that we dont have the network overhead... > > > Just to make clear how much spice is diffrence from VNC is by the > > fact that only the library itself (not including the drivers) have > > 128,277 lines of code inside it. (In my old qemu repo i see almost > > 600,000 lines for qemu) so this should give better prespective on > > how much spice is diffrent from vnc. > > > > So ofcurse in theory you can take all this 128,000 lines and push > > them into qemu-vnc.c ?, but you got to remember that spice is not > > just specific qemu thing, Spice should be used to work on physical > > machines too, just cutting all this lines of code from spice and > > throw it into qemu-vnc.c will be meaning a fork of spice inside > > qemu > > I definitely understand your point of having a single protocol. The > good news is that your physical machine stuff isn't released yet > (AFAIK), so luckily there's still time to change parts of the > protocol :-). > > > It isnt just the rings and the rendering style that make spice > > diffrence, it is the channels it have for each compoment, it is the > > multiple drawing surfaces, and so on... > > These should be fairly easy to implement in VNC too. In fact, I > remember a project implementing off-screen drawing in VNC using a > larger region of the screen than what was visible and then copyrect > them in. In theory you can even change the whole of VNC into SPICE or the whole of VI into EMACS, so???, I personaly think changing code isnt the problem, the problem is always the desgien, and SPICE have fandumental diffrent desgien than VNC, (Here you can say: OK I can make my VNC desgien like SPICE, or you can say I think SPICE dsgien is bad, or you can just use SPICE...) > > > This why the VDI interfaces were made, it was made so who ever used > > VNC, can still use it, whoever want to use SPICE can still use > > spice, > > > > By merging SPICE you just merge VDI interfaces, not the library > > itself, it is so self contained thanks to the VDI interfaces, that > > it almost dont touch anything inside qemu, I belive this was one of > > the best aurgoments when Avi pushed kvm into the kernel - the fact > > that it was a module that can be easyly removed if ppl dont want to > > use it. > > > > > >> > >>> We acctuly want to kick away that video streaming, and move into > >>> the DirectX and X video extentions video support (that will be > >>> made using the qxl driver) - will give much better performence. > >>> > >> > >> Okay, I suspect we're in agreement here then. > > > > Thanks God ! ;-) > > > > > >> > 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 applciation that draw Rectangle, > >>> and just anoth
[Qemu-devel] [PATCH] usb: increase buffer for USB control requests
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 safe choice.
Signed-off-by: Christian Krause
---
usb-linux.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 285ac22..d205bd3 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -113,7 +113,7 @@ struct ctrl_struct {
uint16_t offset;
uint8_t state;
struct usb_ctrlrequest req;
-uint8_t buffer[2048];
+uint8_t buffer[8192];
};
struct USBAutoFilter {
--
1.6.2.5
Re: [Qemu-devel] Spice project is now open
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 > render another window on top of it. > > > >>> I dont understand, if you have applciation that draw Rectangle, > >>> and just another Rectanlge on top of it, wont it hide it?, doesnt > >>> we want just to send the newest Rectangle? > >>> > >>> > >> If you're using something like gdk, the toolkit double buffers > >> windows by default and does a single flip on expose. So this sort > >> of thing never makes it way to the X server. But the other point > >> is, if you draw a rectangle with gdk, all the X server ever sees > >> is the drawing of an image. > >> > > > > Spice work on the driver primitives it doesnt know what is GDK, if > > the X driver will draw rectangle and then another rectangle, VNC > > will have to draw it twice, spice not. > > > > 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] > > These things exist at higher levels (like GTK and QT). > > [1] there actually are but modern applications don't use them. While X can use just the Fill and Copy commands for spice, no one block driver writer to add the GTK / QT levels you are talking about and send this commands into spice (Xrender???), In addition to the Fill and Copy commands spice can help improve performence with offscreen surfaces support that allowing sending the pixmaps in the background while the network is idle. We are currently at the moment just implmented the X driver and we are working to add better support for spice in this area (probably it will be improvments regerding to xrender), so this parts have still big potential to improve in spice. In addition when we will merge the 3d support, driver would be able to translate opengl commands into spice 3d commands. > > > Ohh, The performence is much better user interactive and higher > > density the user interactive come from the paravirtual device and > > the fact that we dont send commands that were "hide" into the > > client. > > > > The higher density come from the fact that the server that run the > > VM (qemu) almost never have to render the stuff > > > > With the Linux guest driver? If you can quantify that, it would be > very useful. The X driver is still very new, we have still a way to go to add all what X need to achive the performence spice can offer. > > >> Are there plans to integrate Spice support in gdk (or cairo)? I > >> think that would be required to get performance parity with > >> Windows. > > > > Can you expline more what you mean? > > Spice work on the driver primitives, so I am not sure I understand > > here what you suggest... > > > > I think the point I'm trying to get across, is that Windows has a > centralized architecture of drawing primitives and interfaces that is > relatively easy for drivers to hook into. > > Linux doesn't have this. Different things are handled in different > places and some layers (like GDK) aren't really made for hooking into. > > What I'm trying to understand is whether it will be possible to > implement a lot of the Spice accelerations for Linux guests. Xrender, and Opengl would be possible to be implment in spice I think Xrender is what Cairo use for hardware accelration and this much of what you need no? > > Regards, > > Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 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 then figuring out if there's a vnc analog. If there are compellingly unique features to Spice that can't be duplicated in vnc, then it's a no brainer. If you can do most things in vnc but it would be hackish whereas Spice makes it all elegant, then provided we can merge Spice without a huge amount of pain, then it's a net win. However, if we need to make a few changes to vnc in order to get the same performance as Spice, then it's not quite as clear that it's what we should be using. We're talking about a major change here. There is a ton of management software that assumes vnc today. Even though there are Spice clients out there, there are embedded vnc clients in certain tools today along with java applets. That's not to say we shouldn't embrace Spice, we just have to make sure we have a good reason to. Ok, I understand your concerns. But even though that spice and vnc achive in the end of the day the same thing - they both allow remote rendering, they have fendumental diffrent architacture. Spice server work with a ring to the guest, it was build from day one to work like that, In addition it was built from day one so that the server will render only what it must to render (to allow much higher virtualization denticity). The ring is from qemu<-> guest, right? I mean, qemu<-> client would be a TCP transport anyways, so the ring argument is void. Right, the ring is like any pv device. The descriptor is passed from the ring through the 'graphic VDI interface' to the spice server that is linked together with qemu. Izik or the code can give better answer. In fact, the code + lots of documentation exist. Indeed, this is just an early bird and it will change into qemu/kvm git repo for easier access. Once spice features are better understood, a merge plan should be decided and bits should start their journey into qemu. Just to make clear how much spice is diffrence from VNC is by the fact that only the library itself (not including the drivers) have 128,277 lines of code inside it. (In my old qemu repo i see almost 600,000 lines for qemu) so this should give better prespective on how much spice is diffrent from vnc. So ofcurse in theory you can take all this 128,000 lines and push them into qemu-vnc.c ?, but you got to remember that spice is not just specific qemu thing, Spice should be used to work on physical machines too, just cutting all this lines of code from spice and throw it into qemu-vnc.c will be meaning a fork of spice inside qemu I definitely understand your point of having a single protocol. The good news is that your physical machine stuff isn't released yet (AFAIK), so luckily there's still time to change parts of the protocol :-). It isnt just the rings and the rendering style that make spice diffrence, it is the channels it have for each compoment, it is the multiple drawing surfaces, and so on... These should be fairly easy to implement in VNC too. In fact, I remember a project implementing off-screen drawing in VNC using a larger region of the screen than what was visible and then copyrect them in. This why the VDI interfaces were made, it was made so who ever used VNC, can still use it, whoever want to use SPICE can still use spice, By merging SPICE you just merge VDI interfaces, not the library itself, it is so self contained thanks to the VDI interfaces, that it almost dont touch anything inside qemu, I belive this was one of the best aurgoments when Avi pushed kvm into the kernel - the fact that it was a module that can be easyly removed if ppl dont want to use it. We acctuly want to kick away that video streaming, and move into the DirectX and X video extentions video support (that will be made using the qxl driver) - will give much better performence. Okay, I suspect we're in agreement here then. Thanks God ! ;-) 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 applciation that draw Rectangle, and just another Rectanlge on top of it, wont it hide it?, doesnt we want just to send the newest Rectangle? If you're using something like gdk, the toolkit double buffers windows by default and does a single flip on expose. So this sort of thing never makes it way to the X server. But the other point is, if you draw a rectangle with gdk, all the X server ever sees is the drawing of an im
Re: [Qemu-devel] Spice project is now open
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 understand is, what can we do with Spice that we >> couldn't possibly do with vnc. That means understanding each feature >> and then figuring out if there's a vnc analog. >> >> If there are compellingly unique features to Spice that can't be >> duplicated in vnc, then it's a no brainer. If you can do most things >> in vnc but it would be hackish whereas Spice makes it all elegant, >> then provided we can merge Spice without a huge amount of pain, then >> it's a net win. >> >> However, if we need to make a few changes to vnc in order to get the >> same performance as Spice, then it's not quite as clear that it's >> what we should be using. >> >> We're talking about a major change here. There is a ton of >> management software that assumes vnc today. Even though there are >> Spice clients out there, there are embedded vnc clients in certain >> tools today along with java applets. >> >> That's not to say we shouldn't embrace Spice, we just have to make >> sure we have a good reason to. > > Ok, I understand your concerns. > > But even though that spice and vnc achive in the end of the day the > same thing - they both allow remote rendering, they have fendumental > diffrent architacture. > > Spice server work with a ring to the guest, it was build from day one > to work like that, In addition it was built from day one so that the > server will render only what it must to render (to allow much higher > virtualization denticity). The ring is from qemu <-> guest, right? I mean, qemu <-> client would be a TCP transport anyways, so the ring argument is void. > Just to make clear how much spice is diffrence from VNC is by the fact > that only the library itself (not including the drivers) have 128,277 > lines of code inside it. (In my old qemu repo i see almost 600,000 > lines for qemu) so this should give better prespective on how much > spice is diffrent from vnc. > > So ofcurse in theory you can take all this 128,000 lines and push them > into qemu-vnc.c ?, but you got to remember that spice is not just > specific qemu thing, Spice should be used to work on physical machines > too, just cutting all this lines of code from spice and throw it into > qemu-vnc.c will be meaning a fork of spice inside qemu I definitely understand your point of having a single protocol. The good news is that your physical machine stuff isn't released yet (AFAIK), so luckily there's still time to change parts of the protocol :-). > It isnt just the rings and the rendering style that make spice > diffrence, it is the channels it have for each compoment, it is the > multiple drawing surfaces, and so on... These should be fairly easy to implement in VNC too. In fact, I remember a project implementing off-screen drawing in VNC using a larger region of the screen than what was visible and then copyrect them in. > This why the VDI interfaces were made, it was made so who ever used > VNC, can still use it, whoever want to use SPICE can still use spice, > > By merging SPICE you just merge VDI interfaces, not the library > itself, it is so self contained thanks to the VDI interfaces, that it > almost dont touch anything inside qemu, I belive this was one of the > best aurgoments when Avi pushed kvm into the kernel - the fact that it > was a module that can be easyly removed if ppl dont want to use it. > > >> >>> We acctuly want to kick away that video streaming, and move into the >>> DirectX and X video extentions video support (that will be made >>> using the qxl driver) - will give much better performence. >>> >> >> Okay, I suspect we're in agreement here then. > > Thanks God ! ;-) > > >> 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 applciation that draw Rectangle, and >>> just another Rectanlge on top of it, wont it hide it?, doesnt we >>> want just to send the newest Rectangle? >>> >> >> If you're using something like gdk, the toolkit double buffers >> windows by default and does a single flip on expose. So this sort of >> thing never makes it way to the X server. But the other point is, if >> you draw a rectangle with gdk, all the X server ever sees is the >> drawing of an image. > > Spice work on the driver primitives it doesnt know what is GDK, if the > X driver will draw rectangle and then another rectangle, VNC will have > to draw it twice, spice not. Well, in fact VNC would wait for the refresh timer of the VGA framebuffer dirty thing and only send a sin
Re: [Qemu-devel] Spice project is now open
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 function callbacks that used for such purpuse? Plugin interfaces have been discussed a few times in the past. The concerns have been 1) they will be abused with the introduction of proprietary plugins 2) we would have tremendous difficulty maintaining a stable plugin abi 3) they would create stability issues in qemu because the plugin quality cannot be controlled. For 3, it's a matter of getting a bug report of a crash in qemu with a random plugin module enabled. How do we know whether the crash is really a qemu bug or whether it was an issue in the plugin? This isn't so bad in dynamic languages like Python but it's a real pain in C. Regards, Anthony Liguori Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 applciation that draw Rectangle, and just another Rectanlge on top of it, wont it hide it?, doesnt we want just to send the newest Rectangle? If you're using something like gdk, the toolkit double buffers windows by default and does a single flip on expose. So this sort of thing never makes it way to the X server. But the other point is, if you draw a rectangle with gdk, all the X server ever sees is the drawing of an image. Spice work on the driver primitives it doesnt know what is GDK, if the X driver will draw rectangle and then another rectangle, VNC will have to draw it twice, spice not. 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] These things exist at higher levels (like GTK and QT). [1] there actually are but modern applications don't use them. Ohh, The performence is much better user interactive and higher density the user interactive come from the paravirtual device and the fact that we dont send commands that were "hide" into the client. The higher density come from the fact that the server that run the VM (qemu) almost never have to render the stuff With the Linux guest driver? If you can quantify that, it would be very useful. Are there plans to integrate Spice support in gdk (or cairo)? I think that would be required to get performance parity with Windows. Can you expline more what you mean? Spice work on the driver primitives, so I am not sure I understand here what you suggest... I think the point I'm trying to get across, is that Windows has a centralized architecture of drawing primitives and interfaces that is relatively easy for drivers to hook into. Linux doesn't have this. Different things are handled in different places and some layers (like GDK) aren't really made for hooking into. What I'm trying to understand is whether it will be possible to implement a lot of the Spice accelerations for Linux guests. Regards, Anthony Liguori
Re: [Qemu-devel] Current state of qemu-system-mips
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/qemu-devel/2009-11/msg01892.html I assume...) /Palle
Re: [Qemu-devel] Current state of qemu-system-mips
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 reference here is the output from 'uname -a' SunOS opensolaris 5.11 snv_111b sun4u sparc SUNW,Ultra-5_10 Solaris /Palle
Re: [Qemu-devel] Adding support for Mac OS X ppc64 host
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" option fine. amd64 qemu-system-ppc does not exhibit this crash. amd64 qemu-system-ppc64 boots okay, too. Andreas
Re: [Qemu-devel] Spice project is now open
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 > >> not crash :-) I would not want a user to replace glibc with a > >> different libc. > > > > I think it problomatic to say "I dont want to use this library" > > beacuse "Librarys can crush", do you have any reason to say it on > > spice? did you look on the code and saw huge ugly bugs? > > > > Libraries are fine. But libraries are not plugins. > > It's the difference between qemu writing directly to libspice verses > having a libspice-vdi that implements the VDI plugin interface and > then a mechanism in qemu to load arbitrary libraries that implement > the VDI interface. > > If I understand correctly, VDI is a plugin interface. 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 function callbacks that used for such purpuse? > > Regards, > > Anthony Liguori > >
Re: [Qemu-devel] RFC: exit on incoming exec migrate failure
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 is to try launching with -incoming exec:/bin/false.
> This is obviously useless, but illustrates the issue handily.
I've hit this in real life too, with restore from a file containing
the saved state which had got corrupted/truncated. I only discovered
the failure when I wondered by QEMU was chewing 100% cpu
> One solution might be to retry the command on migrate failure, but that
> won't really help in all circumstances (for instance, if the migration
> command is broken!), so it seems equally appropriate to just die if an
> incoming exec migration fails. The patch is trivial, and follows - does
> this look sensible? (I'm new to qemu development, but trying to pick it up.)
It looks like a reasonable approach to me. If we carried on running, it would
be hard for apps to determine whether migration succeeded & thus QEMU is
running, or whether it failed and is just idling. By exiting we give the
management app/user the optional to retry simply by relaunching
> diff --git a/migration-exec.c b/migration-exec.c
> index c830669..0292c19 100644
> --- a/migration-exec.c
> +++ b/migration-exec.c
> @@ -114,7 +114,7 @@ static void exec_accept_incoming_migration(void *opaque)
> ret = qemu_loadvm_state(f);
> if (ret < 0) {
> fprintf(stderr, "load of migration failed\n");
> -goto err;
> +exit(0);
> }
> qemu_announce_self();
> dprintf("successfully loaded vm state\n");
> @@ -123,7 +123,6 @@ static void exec_accept_incoming_migration(void *opaque)
> if (autostart)
> vm_start();
>
> -err:
> qemu_fclose(f);
> }
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] Spice project is now open
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 > couldn't possibly do with vnc. That means understanding each feature > and then figuring out if there's a vnc analog. > > If there are compellingly unique features to Spice that can't be > duplicated in vnc, then it's a no brainer. If you can do most things > in vnc but it would be hackish whereas Spice makes it all elegant, > then provided we can merge Spice without a huge amount of pain, then > it's a net win. > > However, if we need to make a few changes to vnc in order to get the > same performance as Spice, then it's not quite as clear that it's > what we should be using. > > We're talking about a major change here. There is a ton of > management software that assumes vnc today. Even though there are > Spice clients out there, there are embedded vnc clients in certain > tools today along with java applets. > > That's not to say we shouldn't embrace Spice, we just have to make > sure we have a good reason to. Ok, I understand your concerns. But even though that spice and vnc achive in the end of the day the same thing - they both allow remote rendering, they have fendumental diffrent architacture. Spice server work with a ring to the guest, it was build from day one to work like that, In addition it was built from day one so that the server will render only what it must to render (to allow much higher virtualization denticity). Just to make clear how much spice is diffrence from VNC is by the fact that only the library itself (not including the drivers) have 128,277 lines of code inside it. (In my old qemu repo i see almost 600,000 lines for qemu) so this should give better prespective on how much spice is diffrent from vnc. So ofcurse in theory you can take all this 128,000 lines and push them into qemu-vnc.c ?, but you got to remember that spice is not just specific qemu thing, Spice should be used to work on physical machines too, just cutting all this lines of code from spice and throw it into qemu-vnc.c will be meaning a fork of spice inside qemu It isnt just the rings and the rendering style that make spice diffrence, it is the channels it have for each compoment, it is the multiple drawing surfaces, and so on... This why the VDI interfaces were made, it was made so who ever used VNC, can still use it, whoever want to use SPICE can still use spice, By merging SPICE you just merge VDI interfaces, not the library itself, it is so self contained thanks to the VDI interfaces, that it almost dont touch anything inside qemu, I belive this was one of the best aurgoments when Avi pushed kvm into the kernel - the fact that it was a module that can be easyly removed if ppl dont want to use it. > > > We acctuly want to kick away that video streaming, and move into the > > DirectX and X video extentions video support (that will be made > > using the qxl driver) - will give much better performence. > > > > Okay, I suspect we're in agreement here then. Thanks God ! ;-) > > >> 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 applciation that draw Rectangle, and > > just another Rectanlge on top of it, wont it hide it?, doesnt we > > want just to send the newest Rectangle? > > > > If you're using something like gdk, the toolkit double buffers > windows by default and does a single flip on expose. So this sort of > thing never makes it way to the X server. But the other point is, if > you draw a rectangle with gdk, all the X server ever sees is the > drawing of an image. Spice work on the driver primitives it doesnt know what is GDK, if the X driver will draw rectangle and then another rectangle, VNC will have to draw it twice, spice not. > > > Well any driver can use what ever spice commands it want, the X > > driver doesnt have to use all the spice commands, what is so bad > > about that? > > What I'm asking is what's the performance of the X driver vs. say, > VNC? Do these high level operations really make sense for a Linux > guest if we cannot ever implement them in an X driver? Ohh, The performence is much better user interactive and higher density the user interactive come from the paravirtual device and the fact that we dont send commands that were "hide" into the client. The higher density come from the fact that the server that run the VM (qemu) almost never have to render the stuff > > I can see where this is a win with Windows because you can hook into > GDI, but I'm not sure that this could ever do better than say, N
[Qemu-devel] [PATCH] Avoid permanently disabled QEMU monitor when UNIX migration fails
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. Berrange
---
migration-unix.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/migration-unix.c b/migration-unix.c
index 783228b..a141dbb 100644
--- a/migration-unix.c
+++ b/migration-unix.c
@@ -112,10 +112,6 @@ MigrationState *unix_start_outgoing_migration(Monitor *mon,
socket_set_nonblock(s->fd);
-if (!detach) {
-migrate_fd_monitor_suspend(s, mon);
-}
-
do {
ret = connect(s->fd, (struct sockaddr *)&addr, sizeof(addr));
if (ret == -1)
@@ -128,7 +124,13 @@ MigrationState *unix_start_outgoing_migration(Monitor *mon,
if (ret < 0 && ret != -EINPROGRESS && ret != -EWOULDBLOCK) {
dprintf("connect failed\n");
goto err_after_open;
-} else if (ret >= 0)
+}
+
+if (!detach) {
+migrate_fd_monitor_suspend(s, mon);
+}
+
+if (ret >= 0)
migrate_fd_connect(s);
return &s->mig_state;
--
1.6.5.2
[Qemu-devel] Re: [PATCH] Avoid permanently disabled QEMU monitor when UNIX migration fails
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_monitor_suspend() once > connected to the UNIX socket. Sorry, forgot to include the signed-off tag with this patch, so will resend. FYI, the test case here is simply (qemu) migrate unix:/tmp/doesnotexist migration failed ...now hung, no prompt returns.. There is also similar kind of problem with exec migration, but I have not been able to figure out where the problem lies for that one. I suspect something is not dealing with errors properly in the buffered file code. If someone fancies investigating the exec: issue, the test case is simply to run exec with a command that fails, eg give invalid syntax for one of its args. I discovered the problem when i did a simple typo with dd (qemu) migrate "exec:dd bs-1m of=/tmp/file" dd: unrecognized operand `bs-1m' Try `dd --help' for more information. ...now hung, no prompt returns.. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
[Qemu-devel] [PATCH] Avoid permanently disabled QEMU monitor when UNIX migration fails
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 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/migration-unix.c b/migration-unix.c
index 783228b..a141dbb 100644
--- a/migration-unix.c
+++ b/migration-unix.c
@@ -112,10 +112,6 @@ MigrationState *unix_start_outgoing_migration(Monitor *mon,
socket_set_nonblock(s->fd);
-if (!detach) {
-migrate_fd_monitor_suspend(s, mon);
-}
-
do {
ret = connect(s->fd, (struct sockaddr *)&addr, sizeof(addr));
if (ret == -1)
@@ -128,7 +124,13 @@ MigrationState *unix_start_outgoing_migration(Monitor *mon,
if (ret < 0 && ret != -EINPROGRESS && ret != -EWOULDBLOCK) {
dprintf("connect failed\n");
goto err_after_open;
-} else if (ret >= 0)
+}
+
+if (!detach) {
+migrate_fd_monitor_suspend(s, mon);
+}
+
+if (ret >= 0)
migrate_fd_connect(s);
return &s->mig_state;
--
1.6.5.2
Re: [Qemu-devel] Spice project is now open
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. I think it problomatic to say "I dont want to use this library" beacuse "Librarys can crush", do you have any reason to say it on spice? did you look on the code and saw huge ugly bugs? Libraries are fine. But libraries are not plugins. It's the difference between qemu writing directly to libspice verses having a libspice-vdi that implements the VDI plugin interface and then a mechanism in qemu to load arbitrary libraries that implement the VDI interface. If I understand correctly, VDI is a plugin interface. Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 then figuring out if there's a vnc analog. If there are compellingly unique features to Spice that can't be duplicated in vnc, then it's a no brainer. If you can do most things in vnc but it would be hackish whereas Spice makes it all elegant, then provided we can merge Spice without a huge amount of pain, then it's a net win. However, if we need to make a few changes to vnc in order to get the same performance as Spice, then it's not quite as clear that it's what we should be using. We're talking about a major change here. There is a ton of management software that assumes vnc today. Even though there are Spice clients out there, there are embedded vnc clients in certain tools today along with java applets. That's not to say we shouldn't embrace Spice, we just have to make sure we have a good reason to. We acctuly want to kick away that video streaming, and move into the DirectX and X video extentions video support (that will be made using the qxl driver) - will give much better performence. Okay, I suspect we're in agreement here then. 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 applciation that draw Rectangle, and just another Rectanlge on top of it, wont it hide it?, doesnt we want just to send the newest Rectangle? If you're using something like gdk, the toolkit double buffers windows by default and does a single flip on expose. So this sort of thing never makes it way to the X server. But the other point is, if you draw a rectangle with gdk, all the X server ever sees is the drawing of an image. Well any driver can use what ever spice commands it want, the X driver doesnt have to use all the spice commands, what is so bad about that? What I'm asking is what's the performance of the X driver vs. say, VNC? Do these high level operations really make sense for a Linux guest if we cannot ever implement them in an X driver? I can see where this is a win with Windows because you can hook into GDI, but I'm not sure that this could ever do better than say, NX without something really clever or really deep integration with toolkits. Spice is not protocol for just windows or X or whatever, it id display protocol that implment common display commands that can be used over every display system. Are there plans to integrate Spice support in gdk (or cairo)? I think that would be required to get performance parity with Windows. Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 problomatic to say "I dont want to use this library" beacuse "Librarys can crush", do you have any reason to say it on spice? did you look on the code and saw huge ugly bugs? > > Regards, > > Anthony Liguori > >
Re: [Qemu-devel] Spice project is now open
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, Izik Eidus wrote: > > > > > > > > > > > On Fri, 11 Dec 2009 09:57:48 -0600 > > > > > > Anthony Liguori wrote: > > > > > > > > > > > [..snip..] > > > > > > > > > > > > > > > > > [..snip..] > > > > > > > > > > > > > Any particular reason for implementing audio as a driver > > > > > instead of a capture? > > > > > > > > > > > > Spice doesnt have paravirtual audio driver, it use the AC97 > > > > device. > > > > > > Yes it has - interface_audio_driver in audio/vd_interface_audio.c > > > > > > > I think the file name here is missleading you... > > I think you just don't understand what i'm asking. Let me try to > expand: one way to implement audio interception is by having a special > audio_driver (wavaudio.c vd_interface_audio.c) the other is by using > a capture interface atop of existing driver (wavcapture.c vnc.c) > > I was curious as to why the former was chosen. > I see what you mean, I didnt write this part, so i will have to ask who wrote it and will come back to you with an answer why he did it like that. Thanks.
Re: [Qemu-devel] Spice project is now open
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 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 guest try > >>> to read its video memory, we have video streaming, and we have > >>> cache based by the guest driver. > >>> We have private channels for stuff like keyboard, display and so > >>> on... > >>> > >> The video streaming is an encoding heuristic though, right? > >> > >> The lack of guest visible rendering is interesting. > >> > > > > The video streaming now is motiation jpeg due to patents problems. > > > > The approach taken by THINC was to support just a YUV overlay. That > gets you half way there in terms of compressing a video stream. > Since most hardware provides YUV->RGB acceleration, it fits very well > into existing driver architectures. For instance, VMware VGA > supports YUV overlays because X has the Xv interface for this. > > The other important bit is tiling. That's easy enough to support in > something like VNC since it's rectangle based. The one real missing > bit is tile motion. I would think you wouldn't get that with mjpeg > anyway. > > The other equally important piece is hardware scaling. Obviously, if > you have a normal desktop resolution and are full screening an NTSC > dvd, you can save a huge amount of bandwidth by supporting a scaled > overlay. > > I think adding both of these things to VNC would be pretty easy. I > think the result would probably be better than a heuristic based > mjpeg (simply because of the accelerated scaling). > > Any thoughts on that? Am I misunderstanding how the mjpeg works with > Spice and QXL? 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? We acctuly want to kick away that video streaming, and move into the DirectX and X video extentions video support (that will be made using the qxl driver) - will give much better performence. > > > What you mean lack of guest visible rendering?, I might didnt > > understand you > > > > Sorry, I meant what Spice does with video memory (that it doesn't > render a bitmap until the guest tries to read video memory). If I > understood that correctly, it sounds very interesting. Again, I'd > love to see the perf details around that. > I'm not familiar with what a "depth viewing tree". Can you > elaborate? > > >>> In it simplest way of working, we will take the simplest case of > >>> what it is doing: > >>> If you have application that rendered a window, and then it > >>> renendered another window on top of it, you dont want to send the > >>> commands that rendered the old window, beacuse the new commands > >>> hide the older one... > >>> > >> Ah, this is unique to a windowing protocol. A framebuffer protocol > >> does not have to worry about this because the OS does it for you. > >> > > > > Not true. > > This is optimization for remote rendering, in physical machines we > > can rendner what ever we want, it take more cpu to try to use trees > > in order to render the right things > > But with remote machines, we dont want to stress the network, so we > > want to transfer just what we really need. > > > > If the z-order of the window is such that one window is not > displayed, then it's contents will not be rendered. In Windows, > individual windows only receive a WM_PAINT message with the visible > region. Not all apps clip accordingly of course. > > For X, only windows that are visible receive expose events and again, > they're given a clipping region with what is actually displayed. > > 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 applciation that draw Rectangle, and just another Rectanlge on top of it, wont it hide it?, doesnt we want just to send the newest Rectangle? > > >> How well does this work with a Linux guest? To get a lot of this > >> level of information, you have to hook in at the X protocol level > >> (which is what NX does). Can you really do much at the X driver > >> level? > >> > > > > Well we have X driver, why would there be any problems with X? > > > > A lot of the things in Spice (from a quick glance at the spec) are > too high level for just an X driver. For instance, there are glyph > based operations presumably for text rendering. There are also brush > primitives. While X has some
[Qemu-devel] Bug in Sparc64/IDE Code
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 recent issue indicates that the IDE code for the Sparc64 emulator is reading from and writing to the wrong memory locations. The end result is the following output when trying to boot off an ISO image in Qemu: 0 > boot cdrom [sparc64] Booting file 'cdrom' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 7084 bytes entry point is 0x4000 Evaluating FCode... qemu: unsupported keyboard cmd=0x57 sSegmentation fault This is using the "-nographic" option - the results reported with graphics tend to be more interesting, with lots of garbage being written to the VGA device. Turning on IDE debugging in Qemu and then trying to boot yields a lot of output - the last few lines look like this: ide: write control addr=0x682 val=02 IDE: write addr=0x601 val=0x00 IDE: write addr=0x602 val=0x00 IDE: write addr=0x603 val=0x00 IDE: write addr=0x604 val=0x08 IDE: write addr=0x605 val=0x00 IDE: write addr=0x606 val=0x00 IDE: write addr=0x607 val=0xa0 ide: CMD=a0 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read addr=0x607 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read status addr=0x682 val=58 ide: read addr=0x607 val=58 ide: read addr=0x602 val=02 ide: read addr=0x604 val=08 ide: read addr=0x605 val=00 ide: read status addr=0x682 val=50 ide: read status addr=0x682 val=50 ide: read status addr=0x682 val=50 ide: read status addr=0x682 val=50 ide: read status addr=0x682 val=50 ide: read status addr=0x682 val=50 ide: read status addr=0x682 val=50 ide: read status addr=0x682 val=50 ide: read addr=0x607 val=50 ide: read status addsIDE: write addr=0x502 val=0x9a IDE: write addr=0x503 val=0xa9 IDE: write addr=0x504 val=0x06 IDE: write addr=0x505 val=0xed IDE: write addr=0x506 val=0x14 IDE: write addr=0x507 val=0xcd ide: CMD=cd ide: write control addr=0x582 val=97 IDE: write addr=0x602 val=0xba IDE: write addr=0x603 val=0xae IDE: write addr=0x604 val=0xce IDE: write addr=0x605 val=0xb6 IDE: write addr=0x606 val=0x58 IDE: write addr=0x607 val=0x57 ide: CMD=57 ide: write control addr=0x682 val=70 bmdma_cmd_writeb: 0x0054 bmdma: writeb 0x701 : 0xd7 bmdma: writeb 0x702 : 0x79 bmdma: writeb 0x703 : 0xfe bmdma_addr_writew: 0xddef bmdma_addr_writew: 0xb12b bmdma_cmd_writeb: 0x00da bmdma: writeb 0x709 : 0x95 Segmentation fault On the OpenBIOS list it was pointed out that the addresses for the IDE control seem to be in the 0x6nn range (0x602 to 0x607 with the register at 0x682), but then toward the end the addresses switch over to the 0x5nn range, with the IDE code trying to write to locations 0x502 through 0x507 and the register at 0x582. This seems to be what causes the segmentation fault and the garbage written to the screen, including the error about an invalid keyboard command. Any help in tracking down the error would be greatly appreciated, and I'm happy to do any debugging/testing necessary! Thanks! -Nick This e-mail may contain confidential and privileged material for the sole use of the intended recipient. If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information. In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way. If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox. Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
Re: [Qemu-devel] Spice project is now open
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 Dec 2009 09:57:48 -0600 > > > > > Anthony Liguori wrote: > > > > > > > > > [..snip..] > > > > > > > > > > > > > [..snip..] > > > > > > > > > > Any particular reason for implementing audio as a driver instead > > > > of a capture? > > > > > > > > > Spice doesnt have paravirtual audio driver, it use the AC97 device. > > > > Yes it has - interface_audio_driver in audio/vd_interface_audio.c > > > > I think the file name here is missleading you... I think you just don't understand what i'm asking. Let me try to expand: one way to implement audio interception is by having a special audio_driver (wavaudio.c vd_interface_audio.c) the other is by using a capture interface atop of existing driver (wavcapture.c vnc.c) I was curious as to why the former was chosen. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] Spice project is now open
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 thing if Spice does require a new protocol. The underlying goal is getting lost in the "Spice can't be a VNC extension" discussion :-) Fair point. Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 surfaces, that are depended on each other. We Dont renender untill the very moment that the guest try to read its video memory, we have video streaming, and we have cache based by the guest driver. We have private channels for stuff like keyboard, display and so on... The video streaming is an encoding heuristic though, right? The lack of guest visible rendering is interesting. The video streaming now is motiation jpeg due to patents problems. The approach taken by THINC was to support just a YUV overlay. That gets you half way there in terms of compressing a video stream. Since most hardware provides YUV->RGB acceleration, it fits very well into existing driver architectures. For instance, VMware VGA supports YUV overlays because X has the Xv interface for this. The other important bit is tiling. That's easy enough to support in something like VNC since it's rectangle based. The one real missing bit is tile motion. I would think you wouldn't get that with mjpeg anyway. The other equally important piece is hardware scaling. Obviously, if you have a normal desktop resolution and are full screening an NTSC dvd, you can save a huge amount of bandwidth by supporting a scaled overlay. I think adding both of these things to VNC would be pretty easy. I think the result would probably be better than a heuristic based mjpeg (simply because of the accelerated scaling). Any thoughts on that? Am I misunderstanding how the mjpeg works with Spice and QXL? What you mean lack of guest visible rendering?, I might didnt understand you Sorry, I meant what Spice does with video memory (that it doesn't render a bitmap until the guest tries to read video memory). If I understood that correctly, it sounds very interesting. Again, I'd love to see the perf details around that. I'm not familiar with what a "depth viewing tree". Can you elaborate? In it simplest way of working, we will take the simplest case of what it is doing: If you have application that rendered a window, and then it renendered another window on top of it, you dont want to send the commands that rendered the old window, beacuse the new commands hide the older one... Ah, this is unique to a windowing protocol. A framebuffer protocol does not have to worry about this because the OS does it for you. Not true. This is optimization for remote rendering, in physical machines we can rendner what ever we want, it take more cpu to try to use trees in order to render the right things But with remote machines, we dont want to stress the network, so we want to transfer just what we really need. If the z-order of the window is such that one window is not displayed, then it's contents will not be rendered. In Windows, individual windows only receive a WM_PAINT message with the visible region. Not all apps clip accordingly of course. For X, only windows that are visible receive expose events and again, they're given a clipping region with what is actually displayed. 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. How well does this work with a Linux guest? To get a lot of this level of information, you have to hook in at the X protocol level (which is what NX does). Can you really do much at the X driver level? Well we have X driver, why would there be any problems with X? A lot of the things in Spice (from a quick glance at the spec) are too high level for just an X driver. For instance, there are glyph based operations presumably for text rendering. There are also brush primitives. While X has some support for these things, it's so old and broken that in modern applications, most toolkits just render to a local buffer, and then do a draw the image to the window. That means the X server has no visibility into the fact that you're actually rendering text which means an X driver cannot take advantage of that information. Spice driver to X (I mean from the X prespective on things) is just another display driver. What's the performance compared to the Windows driver? Think about qemu give infastracture to multiple librarys to use it? For example one user can use qemu with VNC, one with SPICE, and one can use qemu with diffrent private local rendering soultion (for highly fast local 3d rendering...) As I said, I don't have a problem with externalizing things. I think there's some discussion about how best to do that. For instance, I think we want to avoid sha
Re: [Qemu-devel] [PATCH 10/19] monitor: Convert do_info_name() to QObject
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 going to provide a > >supported > >JSON monitor it needs to have all the commands converted, otherwise we'll > >have to stick with using the text based monitor. > > > > I would suggest that for 0.12, libvirt not use QMP. It should wait > until 0.13 to convert over to QMP since we should have a full conversion > by then. I agree, given the time lines involved its not practical for us to switch to QMP in 0.12, so we'll wait until 0.13. On the plus side we've got all the QMP code in libvirt GIT now, so we can make sure that 0.13 is very well tested when time comes for its release :-) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] Spice project is now open
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 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 their management tool is aware or not. It should Just Work. > >> > > > > That's a good goal. > > > > If we add a new protocol, we could achieve the same thing by allowing > > qemu support both VNC and Spice at runtime. Then you just need a client > > like virt-viewer that can handle both protocols, and old VNC clients > > will continue to be able to connect to newer qemu. > > > > Supporting them at the same time could be potentially challenging. You > would need to render Spice locally in qemu in order to expose it via vnc. > > Another nasty bit is that two protocols mean two different sets of > authentication mechanisms. Does Spice support SASL based > authentication? Could it make sense to essentially tunnel Spice through > vnc in order to reuse the existing authentication infrastructure? 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 thing if Spice does require a new protocol. The underlying goal is getting lost in the "Spice can't be a VNC extension" discussion :-) Cheers, Mark.
Re: [Qemu-devel] Spice project is now open
* 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 shouldn't have to contemplate the trade-offs of whether their > > management tool is aware or not. It should Just Work. > > > >> I would happy to answer more questions if anyone have > >> > > > > Thanks. > > Just to make a point clear: > > AFAIU, there are two parts of qemu spice support. The protocol (vnc-like), and > the guest device (vga-like). I am right? There's also some qemu glue to deliver "desktop" to spice protocol. Sometimes called the remoting API, or VDI. thanks, -chris
Re: [Qemu-devel] Spice project is now open
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, that are depended on each other. > > We Dont renender untill the very moment that the guest try to read > > its video memory, we have video streaming, and we have cache based > > by the guest driver. > > We have private channels for stuff like keyboard, display and so > > on... > > The video streaming is an encoding heuristic though, right? > > The lack of guest visible rendering is interesting. The video streaming now is motiation jpeg due to patents problems. What you mean lack of guest visible rendering?, I might didnt understand you > > > > >> I'm not familiar with what a "depth viewing tree". Can you > >> elaborate? > > > > In it simplest way of working, we will take the simplest case of > > what it is doing: > > If you have application that rendered a window, and then it > > renendered another window on top of it, you dont want to send the > > commands that rendered the old window, beacuse the new commands > > hide the older one... > > Ah, this is unique to a windowing protocol. A framebuffer protocol > does not have to worry about this because the OS does it for you. Not true. This is optimization for remote rendering, in physical machines we can rendner what ever we want, it take more cpu to try to use trees in order to render the right things But with remote machines, we dont want to stress the network, so we want to transfer just what we really need. > > How well does this work with a Linux guest? To get a lot of this > level of information, you have to hook in at the X protocol level > (which is what NX does). Can you really do much at the X driver > level? Well we have X driver, why would there be any problems with X? Spice driver to X (I mean from the X prespective on things) is just another display driver. > > Of course, a lot of interesting stuff (like drawing ops and text > rendering) doesn't even happen in the X server these days. > > >>> 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. > >>> > >>> > >> What would be ideal, is if there was a mechanism whereas a client > >> could connect to the VNC server, and get VNC traffic if it's a > >> normal VNC client, but if it was a smarter client, got a more > >> sophisticated stream. If that was something that was Spice or > >> Spice-like, that would be perfect. > >> > >> 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 their management tool is aware or not. It > >> should Just Work. > >> > > > > > > This why we suggest the VDI interface, to solve all this choicses we > > made for the users, > > > > Okay, but it's hard to evaluate that suggestion without seeing the > VDI interface :-) No problems! http://www.spice-space.org/docs/vd_interfaces.pdf > > > Think about qemu give infastracture to multiple librarys to use it? > > For example one user can use qemu with VNC, one with SPICE, and one > > can use qemu with diffrent private local rendering soultion (for > > highly fast local 3d rendering...) > > > > As I said, I don't have a problem with externalizing things. I think > there's some discussion about how best to do that. For instance, I > think we want to avoid shared library plugins as it introduces a good > deal of instability into our address space. Well why libc is diffrent then? > > Regards, > > Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 about Spice or VNC. They shouldn't have to contemplate the trade-offs of whether their management tool is aware or not. It should Just Work. That's a good goal. If we add a new protocol, we could achieve the same thing by allowing qemu support both VNC and Spice at runtime. Then you just need a client like virt-viewer that can handle both protocols, and old VNC clients will continue to be able to connect to newer qemu. Supporting them at the same time could be potentially challenging. You would need to render Spice locally in qemu in order to expose it via vnc. Another nasty bit is that two protocols mean two different sets of authentication mechanisms. Does Spice support SASL based authentication? Could it make sense to essentially tunnel Spice through vnc in order to reuse the existing authentication infrastructure? Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 >> > >> > 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 maintains guest visible >> state. There are a lot of advantages to keeping qemu as the sole >> maintainer of guest visible state as it simplifies things like live >> migration. More importantly, it allows us to do things like Avi's >> suggested security sandboxing using seccomp(). For that to work, we >> need to make sure that we can isolate any code that interacts >> directly with the guest. > > Spice guest visible state inside qemu is just its PCI QXL device. > This part is qemu specificed. > But this part can work together with vnc with no problems, right? If this is so, why don't we just start by merging it, while trying to make the case for the rendering protocol in parallel ? -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."
Re: [Qemu-devel] Spice project is now open
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: > > > > > > > [..snip..] > > > > > > > > > [..snip..] > > > > > > > Any particular reason for implementing audio as a driver instead > > > of a capture? > > > > > > Spice doesnt have paravirtual audio driver, it use the AC97 device. > > Yes it has - interface_audio_driver in audio/vd_interface_audio.c > I think the file name here is missleading you...
Re: [Qemu-devel] Spice project is now open
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 guest try to read its video memory, we have video streaming, and we have cache based by the guest driver. We have private channels for stuff like keyboard, display and so on... The video streaming is an encoding heuristic though, right? The lack of guest visible rendering is interesting. I'm not familiar with what a "depth viewing tree". Can you elaborate? In it simplest way of working, we will take the simplest case of what it is doing: If you have application that rendered a window, and then it renendered another window on top of it, you dont want to send the commands that rendered the old window, beacuse the new commands hide the older one... Ah, this is unique to a windowing protocol. A framebuffer protocol does not have to worry about this because the OS does it for you. How well does this work with a Linux guest? To get a lot of this level of information, you have to hook in at the X protocol level (which is what NX does). Can you really do much at the X driver level? Of course, a lot of interesting stuff (like drawing ops and text rendering) doesn't even happen in the X server these days. 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. What would be ideal, is if there was a mechanism whereas a client could connect to the VNC server, and get VNC traffic if it's a normal VNC client, but if it was a smarter client, got a more sophisticated stream. If that was something that was Spice or Spice-like, that would be perfect. 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 their management tool is aware or not. It should Just Work. This why we suggest the VDI interface, to solve all this choicses we made for the users, Okay, but it's hard to evaluate that suggestion without seeing the VDI interface :-) Think about qemu give infastracture to multiple librarys to use it? For example one user can use qemu with VNC, one with SPICE, and one can use qemu with diffrent private local rendering soultion (for highly fast local 3d rendering...) As I said, I don't have a problem with externalizing things. I think there's some discussion about how best to do that. For instance, I think we want to avoid shared library plugins as it introduces a good deal of instability into our address space. Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 VNC. They shouldn't have to contemplate the > > trade-offs of whether their management tool is aware or not. It > > should Just Work. > > > >> I would happy to answer more questions if anyone have > >> > > > > Thanks. > > Just to make a point clear: > > AFAIU, there are two parts of qemu spice support. The protocol > (vnc-like), and the guest device (vga-like). I am right? > > qemu spice support is built by just 2 parts qxl pci device - para virtual display device, vdi interfaces - what allow to qemu to connect into the spice library.
Re: [Qemu-devel] Spice project is now open
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. They shouldn't have to contemplate the trade-offs > of whether their management tool is aware or not. It should Just Work. That's a good goal. If we add a new protocol, we could achieve the same thing by allowing qemu support both VNC and Spice at runtime. Then you just need a client like virt-viewer that can handle both protocols, and old VNC clients will continue to be able to connect to newer qemu. Cheers, Mark.
Re: [Qemu-devel] Spice project is now open
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 for implementing audio as a driver instead of > > a capture? > > > Spice doesnt have paravirtual audio driver, it use the AC97 device. Yes it has - interface_audio_driver in audio/vd_interface_audio.c -- mailto:av1...@comtv.ru
Re: [Qemu-devel] Spice project is now open
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 printers) > >> and so on... > >> > > > > 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? > > > I don't fully understand spice yet, but what's the difficulty here? > libraries changes every single day to try to acomodate for the needs > of specific users, be it through generalizations, shims, or whatever. > > This is just another day in the OSS world. > > We are working on spice for physical machines, the library contain all what need for remote displays.
Re: [Qemu-devel] Spice project is now open
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 library is not necessarily a problem. > > What would be a probably is if the library maintains guest visible > state. There are a lot of advantages to keeping qemu as the sole > maintainer of guest visible state as it simplifies things like live > migration. More importantly, it allows us to do things like Avi's > suggested security sandboxing using seccomp(). For that to work, we > need to make sure that we can isolate any code that interacts > directly with the guest. Spice guest visible state inside qemu is just its PCI QXL device. This part is qemu specificed. > > Regards, > > Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 about spice is that it isnt just a framebuffer > > drawing and not a bitmaps protocol. > > > > Spice protocl support multiple graphics commands, > > VNC actually does have high level 2d commands like CopyRect. The > higher end encodings (like Tight and ZRLE) provide for mechanisms to > do operations like fill even with different types of patterns. > > Do you have any performance data that demonstrates where SPICE does > well compared to something like VNC? 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 guest try to read its video memory, we have video streaming, and we have cache based by the guest driver. We have private channels for stuff like keyboard, display and so on... > > > multiple surfaces > > drawings, > > VNC does not have a notion of off-screen pixmaps but it would be > pretty easy to add. I think the simpliest approach would be to > introduce the notion of a Viewport which clips the visible screen to > a smaller size. That way, you could resize the screen to 2x or 3x the > viewable screen. You could us things like CopyRect to blt from an > off-screen surface to the on-screen surface. I think the real > question though is how much of a win is off-screen drawing? > > We've always been very limited by the VGA devices we emulate so we've > never really tried to make the most out of VNC. > > > Spice is desgined to render as less as it can on the server > > and instead to render on the client side much of the work, > > To achive this spice use all kind of techniques such as depth > > viewing tree. > > > > I'm not familiar with what a "depth viewing tree". Can you elaborate? In it simplest way of working, we will take the simplest case of what it is doing: If you have application that rendered a window, and then it renendered another window on top of it, you dont want to send the commands that rendered the old window, beacuse the new commands hide the older one... When the guest will try to read the video memory, you wont want the server to render the old commands. But you will want to rendner the old commands in case the new commands are depended on the older commands... > > > The patchs that we wanted to push into qemu were what is called VDI > > interfaces, it allow to qemu work with what ever interface it want, > > what so bad about that? > > > > Those patches never made it to the list. It will take some time, it is in our todo, we never expected qemu to merge spice without this patches! > > > 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. > > > > What would be ideal, is if there was a mechanism whereas a client > could connect to the VNC server, and get VNC traffic if it's a normal > VNC client, but if it was a smarter client, got a more sophisticated > stream. If that was something that was Spice or Spice-like, that > would be perfect. > > 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 their management tool is aware or not. It > should Just Work. This why we suggest the VDI interface, to solve all this choicses we made for the users, Think about qemu give infastracture to multiple librarys to use it? For example one user can use qemu with VNC, one with SPICE, and one can use qemu with diffrent private local rendering soultion (for highly fast local 3d rendering...) > > > I would happy to answer more questions if anyone have > > > > Thanks. > > Regards, > > Anthony Liguori
Re: [Qemu-devel] [PATCH 4/7] linux-user: add core dump support for PPC
On Fri, 11 Dec 2009, Nathan Froyd wrote: > > Signed-off-by: Nathan Froyd Works here. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] Spice project is now open
> > 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 their > management tool is aware or not. It should Just Work. > >> I would happy to answer more questions if anyone have >> > > Thanks. Just to make a point clear: AFAIU, there are two parts of qemu spice support. The protocol (vnc-like), and the guest device (vga-like). I am right? -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."
Re: [Qemu-devel] Spice project is now open
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 framebuffer > > drawing and not a bitmaps protocol. > > > > Spice protocl support multiple graphics commands, multiple surfaces > > drawings, Spice is desgined to render as less as it can on the > > server and instead to render on the client side much of the work, > > To achive this spice use all kind of techniques such as depth > > viewing tree. > > > > We already have patchs that support offscreen surfaces -> the > > architacture for high end 3d, this make things even more > > complicated. > > > > 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... > > > > The patchs that we wanted to push into qemu were what is called VDI > > interfaces, it allow to qemu work with what ever interface it want, > > what so bad about that? > > > > 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 > > Any particular reason for implementing audio as a driver instead of > a capture? Spice doesnt have paravirtual audio driver, it use the AC97 device. >
Re: [Qemu-devel] Spice project is now open
>> 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 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 current set of patches against GIT head. > > Anything else is just a waste of time. The paths both projects are > at are too far apart. > More important than forward porting, is respecting the design decisions a huge community has agreed upon. Of course, when you become part of that community, you can try to shift these designs towards your goals, but trying to force them is just ridiculous. That said, I do believe spice can play a essential role in making us go forward, but the attitude towards it has to change quite a bit. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."
Re: [Qemu-devel] Spice project is now open
>> >> 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 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? > I don't fully understand spice yet, but what's the difficulty here? libraries changes every single day to try to acomodate for the needs of specific users, be it through generalizations, shims, or whatever. This is just another day in the OSS world. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."
Re: [Qemu-devel] Spice project is now open
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 maintains guest visible state. There are a lot of advantages to keeping qemu as the sole maintainer of guest visible state as it simplifies things like live migration. More importantly, it allows us to do things like Avi's suggested security sandboxing using seccomp(). For that to work, we need to make sure that we can isolate any code that interacts directly with the guest. Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 current set of patches against GIT > head. This was never the issue. We have planes to send the vdi interfaces to qemu, we just open sourced spice, it take time. I think you guys totaly didnt understand us. We will send patchs to qemu-devel adding the vdi interfaces. But again spice itself is library and it have more than one user other than qemu, so the way the protocol work is spice specific and not qemu specific. And this why we are adding the VDI interfaces, it allow qemu to work with whatever library the users will want to use. What so bad about that? > > Anything else is just a waste of time. The paths both projects are > at are too far apart.
Re: [Qemu-devel] Spice project is now open
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 support multiple graphics commands, VNC actually does have high level 2d commands like CopyRect. The higher end encodings (like Tight and ZRLE) provide for mechanisms to do operations like fill even with different types of patterns. Do you have any performance data that demonstrates where SPICE does well compared to something like VNC? multiple surfaces drawings, VNC does not have a notion of off-screen pixmaps but it would be pretty easy to add. I think the simpliest approach would be to introduce the notion of a Viewport which clips the visible screen to a smaller size. That way, you could resize the screen to 2x or 3x the viewable screen. You could us things like CopyRect to blt from an off-screen surface to the on-screen surface. I think the real question though is how much of a win is off-screen drawing? We've always been very limited by the VGA devices we emulate so we've never really tried to make the most out of VNC. Spice is desgined to render as less as it can on the server and instead to render on the client side much of the work, To achive this spice use all kind of techniques such as depth viewing tree. I'm not familiar with what a "depth viewing tree". Can you elaborate? The patchs that we wanted to push into qemu were what is called VDI interfaces, it allow to qemu work with what ever interface it want, what so bad about that? Those patches never made it to the list. 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. What would be ideal, is if there was a mechanism whereas a client could connect to the VNC server, and get VNC traffic if it's a normal VNC client, but if it was a smarter client, got a more sophisticated stream. If that was something that was Spice or Spice-like, that would be perfect. 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 their management tool is aware or not. It should Just Work. I would happy to answer more questions if anyone have Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] Spice project is now open
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 multiple graphics commands, multiple surfaces > drawings, Spice is desgined to render as less as it can on the server > and instead to render on the client side much of the work, > To achive this spice use all kind of techniques such as depth viewing > tree. > > We already have patchs that support offscreen surfaces -> the > architacture for high end 3d, this make things even more complicated. > > 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... > > The patchs that we wanted to push into qemu were what is called VDI > interfaces, it allow to qemu work with what ever interface it want, > what so bad about that? > > 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 Any particular reason for implementing audio as a driver instead of a capture? -- mailto:av1...@comtv.ru
Re: [Qemu-devel] qemu architecture
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 consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Re: [Qemu-devel] Spice project is now open
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 down during this weekend. > > > > > > Spice ship patched QEMU based on fairly old KVM snapshot as a > > > reference implementation. The Spice team plane to push all the > > > relevant bits into QEMU upstream. > > > > > > > Historically, we have not supported multiple display mechanisms > > favoring making one mechanism as good as it can be. > > > > Supporting both Spice and VNC would go against this policy. It's > > not outside the realm of possibility, but there has to be a good > > justification for it. > > > > We need to separate the advantages of having a paravirtual display > > driver from the advantages of a remote display protocol. For > > instance, VNC is capable of doing ARGB cursor offloading to the > > client. We do not support it in QEMU because the VGA drivers we > > emulate do not support this functionality. Likewise, VNC can > > support sound tunneling and QEMU does implement this (although > > virt-manager does not yet). > > > > 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 support multiple graphics commands, multiple surfaces > drawings, Spice is desgined to render as less as it can on the server > and instead to render on the client side much of the work, > To achive this spice use all kind of techniques such as depth viewing > tree. > > We already have patchs that support offscreen surfaces -> the > architacture for high end 3d, this make things even more complicated. > > 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 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?
Re: [Qemu-devel] Spice project is now open
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 during this weekend. >> > >> > Spice ship patched QEMU based on fairly old KVM snapshot as a >> > reference implementation. The Spice team plane to push all the >> > relevant bits into QEMU upstream. >> > >> >> Historically, we have not supported multiple display mechanisms >> favoring making one mechanism as good as it can be. >> >> Supporting both Spice and VNC would go against this policy. It's not >> outside the realm of possibility, but there has to be a good >> justification for it. >> >> We need to separate the advantages of having a paravirtual display >> driver from the advantages of a remote display protocol. For >> instance, VNC is capable of doing ARGB cursor offloading to the >> client. We do not support it in QEMU because the VGA drivers we >> emulate do not support this functionality. Likewise, VNC can support >> sound tunneling and QEMU does implement this (although virt-manager >> does not yet). >> >> 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 support multiple graphics commands, multiple surfaces > drawings, Spice is desgined to render as less as it can on the server > and instead to render on the client side much of the work, > To achive this spice use all kind of techniques such as depth viewing > tree. > > We already have patchs that support offscreen surfaces -> the > architacture for high end 3d, this make things even more complicated. > > 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... > > The patchs that we wanted to push into qemu were what is called VDI > interfaces, it allow to qemu work with what ever interface it want, > what so bad about that? > > 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 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 current set of patches against GIT head. Anything else is just a waste of time. The paths both projects are at are too far apart.
Re: [Qemu-devel] Spice project is now open
>> 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 agenda here than making qemu as best as it can get. If he is evil, I'm the devil myself. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act."
Re: [Qemu-devel] Spice project is now open
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 fairly old KVM snapshot as a > > reference implementation. The Spice team plane to push all the > > relevant bits into QEMU upstream. > > > > Historically, we have not supported multiple display mechanisms > favoring making one mechanism as good as it can be. > > Supporting both Spice and VNC would go against this policy. It's not > outside the realm of possibility, but there has to be a good > justification for it. > > We need to separate the advantages of having a paravirtual display > driver from the advantages of a remote display protocol. For > instance, VNC is capable of doing ARGB cursor offloading to the > client. We do not support it in QEMU because the VGA drivers we > emulate do not support this functionality. Likewise, VNC can support > sound tunneling and QEMU does implement this (although virt-manager > does not yet). > > 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 support multiple graphics commands, multiple surfaces drawings, Spice is desgined to render as less as it can on the server and instead to render on the client side much of the work, To achive this spice use all kind of techniques such as depth viewing tree. We already have patchs that support offscreen surfaces -> the architacture for high end 3d, this make things even more complicated. 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... The patchs that we wanted to push into qemu were what is called VDI interfaces, it allow to qemu work with what ever interface it want, what so bad about that? 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 Thanks. > > Obviously, the disadvantages are that for all practical purposes, > it's a closed protocol. While there is now a specification, there is > not a clear mechanism for extending it by third parties. VNC has a > published protocol and there's a documented process for extending by > third parties. There are a large number of existing VNC clients so > from an interoperability perspective, VNC clearly wins. > > Since VNC is extensible (and we've extended it many times for QEMU), > if Spice possesses unique encoding mechanisms that are advantageous, > why wouldn't we just add those mechanisms to VNC as an extension? > > Regards, > > Anthony Liguori > >
Re: [Qemu-devel] [Patch] remove unused params in some TCG functions
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?
Thoses parameters are used, simply not on an i386 host. Just look at
tcg/*/tcg-target.c, especially 64-bit hosts.
>
> diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
> index 972b102..484f476 100644
> --- a/tcg/i386/tcg-target.c
> +++ b/tcg/i386/tcg-target.c
> @@ -262,14 +262,14 @@ static inline void tcg_out_movi(TCGContext *s,
> TCGType type,
> }
> }
>
> -static inline void tcg_out_ld(TCGContext *s, TCGType type, int ret,
> +static inline void tcg_out_ld(TCGContext *s, int ret,
>int arg1, tcg_target_long arg2)
> {
> /* movl */
> tcg_out_modrm_offset(s, 0x8b, ret, arg1, arg2);
> }
>
> -static inline void tcg_out_st(TCGContext *s, TCGType type, int arg,
> +static inline void tcg_out_st(TCGContext *s, int arg,
>int arg1, tcg_target_long arg2)
> {
> /* movl */
> diff --git a/tcg/tcg.c b/tcg/tcg.c
> index 3c0e296..abed1c3 100644
> --- a/tcg/tcg.c
> +++ b/tcg/tcg.c
> @@ -1333,7 +1333,7 @@ static void tcg_reg_free(TCGContext *s, int reg)
> if (!ts->mem_coherent) {
> if (!ts->mem_allocated)
> temp_allocate_frame(s, temp);
> -tcg_out_st(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
> +tcg_out_st(s, reg, ts->mem_reg, ts->mem_offset);
> }
> ts->val_type = TEMP_VAL_MEM;
> s->reg_to_temp[reg] = -1;
> @@ -1389,7 +1389,7 @@ static void temp_save(TCGContext *s, int temp,
> TCGRegSet allocated_regs)
> if (!ts->mem_allocated)
> temp_allocate_frame(s, temp);
> tcg_out_movi(s, ts->type, reg, ts->val);
> -tcg_out_st(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
> +tcg_out_st(s, reg, ts->mem_reg, ts->mem_offset);
> ts->val_type = TEMP_VAL_MEM;
> break;
> case TEMP_VAL_MEM:
> @@ -1494,7 +1494,7 @@ static void tcg_reg_alloc_mov(TCGContext *s,
> const TCGOpDef *def,
> } else {
> reg = tcg_reg_alloc(s, arg_ct->u.regs, s->reserved_regs);
> }
> -tcg_out_ld(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
> +tcg_out_ld(s, reg, ts->mem_reg, ts->mem_offset);
> } else if (ts->val_type == TEMP_VAL_CONST) {
> if (ots->fixed_reg) {
> reg = ots->reg;
> @@ -1546,7 +1546,7 @@ static void tcg_reg_alloc_op(TCGContext *s,
> ts = &s->temps[arg];
> if (ts->val_type == TEMP_VAL_MEM) {
> reg = tcg_reg_alloc(s, arg_ct->u.regs, allocated_regs);
> -tcg_out_ld(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
> +tcg_out_ld(s, reg, ts->mem_reg, ts->mem_offset);
> ts->val_type = TEMP_VAL_REG;
> ts->reg = reg;
> ts->mem_coherent = 1;
> @@ -1726,19 +1726,19 @@ static int tcg_reg_alloc_call(TCGContext *s,
> const TCGOpDef *def,
> if (arg != TCG_CALL_DUMMY_ARG) {
> ts = &s->temps[arg];
> if (ts->val_type == TEMP_VAL_REG) {
> -tcg_out_st(s, ts->type, ts->reg, TCG_REG_CALL_STACK,
> stack_offset);
> +tcg_out_st(s, ts->reg, TCG_REG_CALL_STACK, stack_offset);
> } else if (ts->val_type == TEMP_VAL_MEM) {
> reg = tcg_reg_alloc(s, tcg_target_available_regs[ts->type],
> s->reserved_regs);
> /* XXX: not correct if reading values from the stack */
> -tcg_out_ld(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
> -tcg_out_st(s, ts->type, reg, TCG_REG_CALL_STACK,
> stack_offset);
> +tcg_out_ld(s, reg, ts->mem_reg, ts->mem_offset);
> +tcg_out_st(s, reg, TCG_REG_CALL_STACK, stack_offset);
> } else if (ts->val_type == TEMP_VAL_CONST) {
> reg = tcg_reg_alloc(s, tcg_target_available_regs[ts->type],
> s->reserved_regs);
> /* XXX: sign extend may be needed on some targets */
> tcg_out_movi(s, ts->type, reg, ts->val);
> -tcg_out_st(s, ts->type, reg, TCG_REG_CALL_STACK,
> stack_offset);
> +tcg_out_st(s, reg, TCG_REG_CALL_STACK, stack_offset);
> } else {
> tcg_abort();
> }
> @@ -1761,7 +1761,7 @@ static int tcg_reg_alloc_call(TCGContext *s,
> const TCGOpDef *def,
> tcg_out_mov(s, reg, ts->reg);
> }
> } else if (ts->val_type == TEMP_VAL_MEM) {
> -tcg_out_ld(s, ts->type, reg, ts->mem_reg, ts->mem_offset);
> +tcg_out_ld(s, reg, ts->mem_reg, ts->mem_offset);
>
Re: [Qemu-devel] Current state of qemu-system-mips
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 > > qemu: hardware error: Unknown device 'smbus-eeprom' for bus 'I2C' > > CPU #0: > pc=0xbfc0 HI=0x LO=0x ds 0010 0 > GPR00: r0 at v0 v1 > GPR04: a0 a1 a2 a3 > GPR08: t0 t1 t2 t3 > GPR12: t4 t5 t6 t7 > GPR16: s0 s1 s2 s3 > GPR20: s4 s5 s6 s7 > GPR24: t8 t9 k0 k1 > GPR28: gp sp s8 ra > CP0 Status 0x0044 Cause 0x EPC0x > Config0 0x80008482 Config1 0x9e190c8b LLAddr 0x > Abort (core dumped) > > Which version are you using? Both stable-0.12 and trunk are working fine here, at least on a Linux host. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] [PATCH 4/7] linux-user: add core dump support for PPC
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,32 @@ static inline void init_thread(struct target_pt_regs
*_regs, struct image_info *
_regs->gpr[5] = pos;
}
+/* See linux kernel: arch/powerpc/include/asm/elf.h. */
+#define ELF_NREG 48
+typedef target_elf_greg_t target_elf_gregset_t[ELF_NREG];
+
+static void elf_core_copy_regs(target_elf_gregset_t *regs, const CPUState *env)
+{
+int i;
+target_ulong ccr = 0;
+
+for (i = 0; i < ARRAY_SIZE(env->gpr); i++) {
+(*regs)[i] = tswapl(env->gpr[i]);
+}
+
+(*regs)[32] = tswapl(env->nip);
+(*regs)[33] = tswapl(env->msr);
+(*regs)[35] = tswapl(env->ctr);
+(*regs)[36] = tswapl(env->lr);
+(*regs)[37] = tswapl(env->xer);
+
+for (i = 0; i < ARRAY_SIZE(env->crf); i++) {
+ccr |= env->crf[i] << (32 - ((i + 1) * 4));
+}
+(*regs)[38] = tswapl(ccr);
+}
+
+#define USE_ELF_CORE_DUMP
#define ELF_EXEC_PAGESIZE 4096
#endif
--
1.6.3.2
Re: [Qemu-devel] Spice project is now open
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. > > > > There's nothing to reject. You haven't posted patches. > > When you do post patches, if you can't/won't offer an explanation as to why > it's better than what we already have, then they will be rejected. It is nice to see the cozy and nice welcome. For the record, I have nothing to do with SPICE, other than reading Slashdot to find out that SPICE was Open Sourced. And for another record, nothing can be as instable as VNC support in QEmu has turned out to be, so I would not be so negative about something that was tried and tested for a long time, certainly not when I was relying on a proprietary and not-at-all documented VNC extension that does not even have an appropriate name. Ciao, Dscho
Re: [Qemu-devel] Spice project is now open
* 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 don't > carry their own version strings like 0.4. That's true. It's not unusual to see things like this when a project has done all of its work out-of-tree. The classic difficulty of maintaining a large set of changes out-of-tree. thanks, -chris
[Qemu-devel] [PATCH 2/7] linux-user: commonify definitions of target typedefs
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 deletions(-)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 76eb031..024dcc2 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -97,6 +97,16 @@ enum {
#define ELIBBAD 80
#endif
+typedef target_ulong target_elf_greg_t;
+#ifdef USE_UID16
+typedef uint16_t target_uid_t;
+typedef uint16_t target_gid_t;
+#else
+typedef uint32_t target_uid_t;
+typedef uint32_t target_gid_t;
+#endif
+typedef int32_ttarget_pid_t;
+
#ifdef TARGET_I386
#define ELF_PLATFORM get_elf_platform()
@@ -134,11 +144,6 @@ static inline void init_thread(struct target_pt_regs
*regs, struct image_info *i
regs->rip = infop->entry;
}
-typedef target_ulongtarget_elf_greg_t;
-typedef uint32_ttarget_uid_t;
-typedef uint32_ttarget_gid_t;
-typedef int32_t target_pid_t;
-
#define ELF_NREG27
typedef target_elf_greg_t target_elf_gregset_t[ELF_NREG];
@@ -211,11 +216,6 @@ static inline void init_thread(struct target_pt_regs
*regs, struct image_info *i
regs->edx = 0;
}
-typedef target_ulongtarget_elf_greg_t;
-typedef uint16_ttarget_uid_t;
-typedef uint16_ttarget_gid_t;
-typedef int32_t target_pid_t;
-
#define ELF_NREG17
typedef target_elf_greg_t target_elf_gregset_t[ELF_NREG];
@@ -286,11 +286,6 @@ static inline void init_thread(struct target_pt_regs
*regs, struct image_info *i
regs->ARM_r10 = infop->start_data;
}
-typedef uint32_t target_elf_greg_t;
-typedef uint16_t target_uid_t;
-typedef uint16_t target_gid_t;
-typedef int32_t target_pid_t;
-
#define ELF_NREG18
typedef target_elf_greg_t target_elf_gregset_t[ELF_NREG];
@@ -1779,13 +1774,6 @@ int load_elf_binary(struct linux_binprm * bprm, struct
target_pt_regs * regs,
* #define ELF_NREG
* typedef taret_elf_greg_t target_elf_gregset_t[ELF_NREG];
*
- * Then define following types to match target types. Actual types can
- * be found from linux kernel (arch//include/asm/posix_types.h):
- *
- * typedef target_uid_t;
- * typedef target_gid_t;
- * typedef target_pid_t;
- *
* Last step is to implement target specific function that copies registers
* from given cpu into just specified register set. Prototype is:
*
--
1.6.3.2
[Qemu-devel] [PATCH] target-mips: fix user-mode emulation startup
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_HFLAG_UM.
The same end can be achieved by swapping the ordering of fpu_init and
cpu_reset in cpu_mips_init, but it seemed better to consolidate the
CONFIG_USER_ONLY code into a single location.
Signed-off-by: Nathan Froyd
---
target-mips/translate.c |8
target-mips/translate_init.c |8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 9d62b64..f756ab9 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -8652,6 +8652,14 @@ void cpu_reset (CPUMIPSState *env)
env->hflags = MIPS_HFLAG_UM;
/* Enable access to the SYNCI_Step register. */
env->CP0_HWREna |= (1 << 1);
+if (env->CP0_Config1 & (1 << CP0C1_FP)) {
+env->hflags |= MIPS_HFLAG_FPU;
+}
+#ifdef TARGET_MIPS64
+if (env->active_fpu.fcr0 & (1 << FCR0_F64)) {
+env->hflags |= MIPS_HFLAG_F64;
+}
+#endif
#else
if (env->hflags & MIPS_HFLAG_BMASK) {
/* If the exception was raised from a delay slot,
diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
index c950eab..3978908 100644
--- a/target-mips/translate_init.c
+++ b/target-mips/translate_init.c
@@ -524,14 +524,6 @@ static void fpu_init (CPUMIPSState *env, const mips_def_t
*def)
env->fpus[i].fcr0 = def->CP1_fcr0;
memcpy(&env->active_fpu, &env->fpus[0], sizeof(env->active_fpu));
-#if defined(CONFIG_USER_ONLY)
-if (env->CP0_Config1 & (1 << CP0C1_FP))
-env->hflags |= MIPS_HFLAG_FPU;
-#ifdef TARGET_MIPS64
-if (env->active_fpu.fcr0 & (1 << FCR0_F64))
-env->hflags |= MIPS_HFLAG_F64;
-#endif
-#endif
}
static void mvp_init (CPUMIPSState *env, const mips_def_t *def)
--
1.6.3.2
