[Qemu-devel] [PATCH v3 01/12] Revert "vnc: set the right prefered encoding"

[Corentin Chary]

This patch was wrong, because the loop was already reversed,
so the first encoding was correctly set at the end of the loopp.

This reverts commit 14eb8b6829ad9dee7035de729e083844a425f274.

Signed-off-by: Corentin Chary 
---
 vnc.c |   14 --
 1 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/vnc.c b/vnc.c
index 1f7ad73..b1a3fdb 100644
--- a/vnc.c
+++ b/vnc.c
@@ -1594,7 +1594,7 @@ static void set_encodings(VncState *vs, int32_t 
*encodings, size_t n_encodings)
 
 vnc_zlib_init(vs);
 vs->features = 0;
-vs->vnc_encoding = -1;
+vs->vnc_encoding = 0;
 vs->tight_compression = 9;
 vs->tight_quality = 9;
 vs->absolute = -1;
@@ -1603,24 +1603,18 @@ static void set_encodings(VncState *vs, int32_t 
*encodings, size_t n_encodings)
 enc = encodings[i];
 switch (enc) {
 case VNC_ENCODING_RAW:
-if (vs->vnc_encoding != -1) {
-vs->vnc_encoding = enc;
-}
+vs->vnc_encoding = enc;
 break;
 case VNC_ENCODING_COPYRECT:
 vs->features |= VNC_FEATURE_COPYRECT_MASK;
 break;
 case VNC_ENCODING_HEXTILE:
 vs->features |= VNC_FEATURE_HEXTILE_MASK;
-if (vs->vnc_encoding != -1) {
-vs->vnc_encoding = enc;
-}
+vs->vnc_encoding = enc;
 break;
 case VNC_ENCODING_ZLIB:
 vs->features |= VNC_FEATURE_ZLIB_MASK;
-if (vs->vnc_encoding != -1) {
-vs->vnc_encoding = enc;
-}
+vs->vnc_encoding = enc;
 break;
 case VNC_ENCODING_DESKTOPRESIZE:
 vs->features |= VNC_FEATURE_RESIZE_MASK;
-- 
1.7.0.2

[Qemu-devel] [PATCH v3 00/12] *** SUBJECT HERE ***

[Corentin Chary]

Since v2:
* Fixed coding style.
* Splitted some patchs
* Added missing copyrights
* Reverted set_encoding patch

Since v1: added commit descriptions for all patchs

Hi,
I this series you'll find zlib fixes and a new encoding: tight.
Tight implementation is inspired (stolen ?) from libvncserver/tightvnc/tigervnc,
but rewritten to match QEMU VNC implementation and coding style.
Tight encoding still lacks gradient and jpeg, but some results [1] [2] show
that it already performs better than zlib and hextile.

Thanks,

[1] 
http://xf.iksaif.net/blog/index.php?post/2010/05/11/GsoC-2010-QEMU%3A-First-%28dumb%29-tight-benchmarks
[2] 
http://xf.iksaif.net/blog/index.php?post/2010/05/18/QEMU%3A-some-charts-on-tight-zlib-and-hextile

Corentin Chary (12):
  Revert "vnc: set the right prefered encoding"
  vnc: explain why set_encodings loop is reversed
  vnc: really call zlib if we want zlib
  vnc: only use a single zlib stream
  vnc: adjust compression zstream level
  vnc: don't clear zlib stream on set_encoding
  vnc: add buffer_free()
  vnc: remove a memory leak in zlib
  vnc: return the number of rectangles
  vnc: add basic tight support
  vnc: add support for tight fill encoding
  vnc: tight: add palette encoding

 Makefile   |2 +
 Makefile.objs  |1 +
 vnc-encoding-hextile.c |5 +-
 vnc-encoding-tight.c   |  961 
 vnc-encoding-tight.h   |  176 +
 vnc-encoding-zlib.c|   40 ++-
 vnc.c  |   73 +++--
 vnc.h  |   24 +-
 8 files changed, 1232 insertions(+), 50 deletions(-)
 create mode 100644 vnc-encoding-tight.c
 create mode 100644 vnc-encoding-tight.h

[Qemu-devel] [PATCH v3 04/12] vnc: only use a single zlib stream

[Corentin Chary]

According to http://tigervnc.org/cgi-bin/rfbproto#zlib-encoding
zlib encoding only uses a single stream. Current implementation defines
4 streams but only uses the first one. Remove them and only use a single
stream.

Signed-off-by: Corentin Chary 
---
 vnc-encoding-zlib.c |   12 +---
 vnc.h   |2 +-
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/vnc-encoding-zlib.c b/vnc-encoding-zlib.c
index 4a495ad..6a16a79 100644
--- a/vnc-encoding-zlib.c
+++ b/vnc-encoding-zlib.c
@@ -54,9 +54,9 @@ static void vnc_zlib_start(VncState *vs)
 vs->output = vs->zlib;
 }
 
-static int vnc_zlib_stop(VncState *vs, int stream_id)
+static int vnc_zlib_stop(VncState *vs)
 {
-z_streamp zstream = &vs->zlib_stream[stream_id];
+z_streamp zstream = &vs->zlib_stream;
 int previous_out;
 
 // switch back to normal output/zlib buffers
@@ -70,7 +70,7 @@ static int vnc_zlib_stop(VncState *vs, int stream_id)
 if (zstream->opaque != vs) {
 int err;
 
-VNC_DEBUG("VNC: initializing zlib stream %d\n", stream_id);
+VNC_DEBUG("VNC: initializing zlib stream\n");
 VNC_DEBUG("VNC: opaque = %p | vs = %p\n", zstream->opaque, vs);
 zstream->zalloc = zalloc;
 zstream->zfree = zfree;
@@ -122,7 +122,7 @@ void vnc_zlib_send_framebuffer_update(VncState *vs, int x, 
int y, int w, int h)
 // compress the stream
 vnc_zlib_start(vs);
 vnc_raw_send_framebuffer_update(vs, x, y, w, h);
-bytes_written = vnc_zlib_stop(vs, 0);
+bytes_written = vnc_zlib_stop(vs);
 
 if (bytes_written == -1)
 return;
@@ -136,7 +136,5 @@ void vnc_zlib_send_framebuffer_update(VncState *vs, int x, 
int y, int w, int h)
 
 void vnc_zlib_init(VncState *vs)
 {
-int i;
-for (i=0; i<(sizeof(vs->zlib_stream) / sizeof(z_stream)); i++)
-vs->zlib_stream[i].opaque = NULL;
+vs->zlib_stream.opaque = NULL;
 }
diff --git a/vnc.h b/vnc.h
index 1aa71b0..dfdb240 100644
--- a/vnc.h
+++ b/vnc.h
@@ -173,7 +173,7 @@ struct VncState
 /* Zlib */
 Buffer zlib;
 Buffer zlib_tmp;
-z_stream zlib_stream[4];
+z_stream zlib_stream;
 
 Notifier mouse_mode_notifier;
 
-- 
1.7.0.2

[Qemu-devel] [PATCH v3 03/12] vnc: really call zlib if we want zlib

[Corentin Chary]

send_framebuffer_update() was calling hextile instead of zlib
since commit 70a4568fe0c5a64adaa3da5030b7109e5199e692.

Signed-off-by: Corentin Chary 
---
 vnc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vnc.c b/vnc.c
index d0402b9..e81a2a5 100644
--- a/vnc.c
+++ b/vnc.c
@@ -655,7 +655,7 @@ static void send_framebuffer_update(VncState *vs, int x, 
int y, int w, int h)
 {
 switch(vs->vnc_encoding) {
 case VNC_ENCODING_ZLIB:
-vnc_hextile_send_framebuffer_update(vs, x, y, w, h);
+vnc_zlib_send_framebuffer_update(vs, x, y, w, h);
 break;
 case VNC_ENCODING_HEXTILE:
 vnc_framebuffer_update(vs, x, y, w, h, VNC_ENCODING_HEXTILE);
-- 
1.7.0.2

[Qemu-devel] [PATCH v3 05/12] vnc: adjust compression zstream level

[Corentin Chary]

Adjust zlib compression level if needed by calling deflateParams.

Signed-off-by: Corentin Chary 
---
 vnc-encoding-zlib.c |9 -
 vnc.h   |1 +
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/vnc-encoding-zlib.c b/vnc-encoding-zlib.c
index 6a16a79..29dd1b7 100644
--- a/vnc-encoding-zlib.c
+++ b/vnc-encoding-zlib.c
@@ -83,10 +83,17 @@ static int vnc_zlib_stop(VncState *vs)
 return -1;
 }
 
+vs->zlib_level = vs->tight_compression;
 zstream->opaque = vs;
 }
 
-// XXX what to do if tight_compression changed in between?
+if (vs->tight_compression != vs->zlib_level) {
+if (deflateParams(zstream, vs->tight_compression,
+  Z_DEFAULT_STRATEGY) != Z_OK) {
+return -1;
+}
+vs->zlib_level = vs->tight_compression;
+}
 
 // reserve memory in output buffer
 buffer_reserve(&vs->output, vs->zlib.offset + 64);
diff --git a/vnc.h b/vnc.h
index dfdb240..96f3fe7 100644
--- a/vnc.h
+++ b/vnc.h
@@ -174,6 +174,7 @@ struct VncState
 Buffer zlib;
 Buffer zlib_tmp;
 z_stream zlib_stream;
+int zlib_level;
 
 Notifier mouse_mode_notifier;
 
-- 
1.7.0.2

[Qemu-devel] [PATCH v3 02/12] vnc: explain why set_encodings loop is reversed

[Corentin Chary]

Add a small comment to explain why we need to start from
the end of the array to set the right prefered encoding.

Signed-off-by: Corentin Chary 
---
 vnc.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/vnc.c b/vnc.c
index b1a3fdb..d0402b9 100644
--- a/vnc.c
+++ b/vnc.c
@@ -1599,6 +1599,11 @@ static void set_encodings(VncState *vs, int32_t 
*encodings, size_t n_encodings)
 vs->tight_quality = 9;
 vs->absolute = -1;
 
+/*
+ * Start from the end because the encodings are sent in order of 
preference.
+ * This way the prefered encoding (first encoding defined in the array)
+ * will be set at the end of the loop.
+ */
 for (i = n_encodings - 1; i >= 0; i--) {
 enc = encodings[i];
 switch (enc) {
-- 
1.7.0.2

[Qemu-devel] [PATCH v3 12/12] vnc: tight: add palette encoding

[Corentin Chary]

Add palette tight encoding. Palette encoding will try to count the number
of colors for a given rectangle, and if this number is low enough
(< 256) it will send the palette + the rectangle with indexed colors.

Signed-off-by: Corentin Chary 
---
 vnc-encoding-tight.c |  437 --
 1 files changed, 425 insertions(+), 12 deletions(-)

diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index 2c9dab6..50be44e 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -28,6 +28,8 @@
 
 #include 
 
+#include "qdict.h"
+#include "qint.h"
 #include "vnc.h"
 #include "vnc-encoding-tight.h"
 
@@ -56,6 +58,285 @@ static const struct {
 };
 
 /*
+ * Code to determine how many different colors used in rectangle.
+ */
+
+static void tight_palette_rgb2buf(uint32_t rgb, int bpp, uint8_t buf[6])
+{
+memset(buf, 0, 6);
+
+if (bpp == 32) {
+buf[0] = ((rgb >> 24) & 0xFF);
+buf[1] = ((rgb >> 16) & 0xFF);
+buf[2] = ((rgb >>  8) & 0xFF);
+buf[3] = ((rgb >>  0) & 0xFF);
+buf[4] = ((buf[0] & 1) == 0) << 3 | ((buf[1] & 1) == 0) << 2;
+buf[4]|= ((buf[2] & 1) == 0) << 1 | ((buf[3] & 1) == 0) << 0;
+buf[0] |= 1;
+buf[1] |= 1;
+buf[2] |= 1;
+buf[3] |= 1;
+}
+if (bpp == 16) {
+buf[0] = ((rgb >> 8) & 0xFF);
+buf[1] = ((rgb >> 0) & 0xFF);
+buf[2] = ((buf[0] & 1) == 0) << 1 | ((buf[1] & 1) == 0) << 0;
+buf[0] |= 1;
+buf[1] |= 1;
+}
+}
+
+static uint32_t tight_palette_buf2rgb(int bpp, const uint8_t *buf)
+{
+uint32_t rgb = 0;
+
+if (bpp == 32) {
+rgb |= ((buf[0] & ~1) | !((buf[4] >> 3) & 1)) << 24;
+rgb |= ((buf[1] & ~1) | !((buf[4] >> 2) & 1)) << 16;
+rgb |= ((buf[2] & ~1) | !((buf[4] >> 1) & 1)) <<  8;
+rgb |= ((buf[3] & ~1) | !((buf[4] >> 0) & 1)) <<  0;
+}
+if (bpp == 16) {
+rgb |= ((buf[0] & ~1) | !((buf[2] >> 1) & 1)) << 8;
+rgb |= ((buf[1] & ~1) | !((buf[2] >> 0) & 1)) << 0;
+}
+return rgb;
+}
+
+
+static int tight_palette_insert(QDict *palette, uint32_t rgb, int bpp, int max)
+{
+uint8_t key[6];
+int idx = qdict_size(palette);
+bool present;
+
+tight_palette_rgb2buf(rgb, bpp, key);
+present = qdict_haskey(palette, (char *)key);
+if (idx >= max && !present) {
+return 0;
+}
+if (!present) {
+qdict_put(palette, (char *)key, qint_from_int(idx));
+}
+return qdict_size(palette);
+}
+
+#define DEFINE_FILL_PALETTE_FUNCTION(bpp)   \
+\
+static int  \
+tight_fill_palette##bpp(VncState *vs, int x, int y, \
+int max, size_t count,  \
+uint32_t *bg, uint32_t *fg, \
+struct QDict **palette) {   \
+uint##bpp##_t *data;\
+uint##bpp##_t c0, c1, ci;   \
+int i, n0, n1;  \
+\
+data = (uint##bpp##_t *)vs->tight.buffer;   \
+\
+c0 = data[0];   \
+i = 1;  \
+while (i < count && data[i] == c0)  \
+i++;\
+if (i >= count) {   \
+*bg = *fg = c0; \
+return 1;   \
+}   \
+\
+if (max < 2) {  \
+return 0;   \
+}   \
+\
+n0 = i; \
+c1 = data[i];   \
+n1 = 0; \
+for (i++; i < count; i++) { \
+ci = data[i];   \
+if (ci == c0) { \
+n0++;   \
+ 

[Qemu-devel] Re: qemu-kvm hangs if multipath device is queing

[Christoph Hellwig]

On Tue, May 18, 2010 at 03:22:36PM +0200, Kevin Wolf wrote:
> I think it's stuck here in an endless loop:
> 
> while (laiocb->ret == -EINPROGRESS)
> qemu_laio_completion_cb(laiocb->ctx);
> 
> Can you verify this by single-stepping one or two loop iterations? ret
> and errno after the read call could be interesting, too.

Maybe the compiler is just too smart.  Without some form of barrier
it could just optimize the loop away as laiocb->ret couldn't change
in a normal single-threaded environment.

[Qemu-devel] [PATCH v3 08/12] vnc: remove a memory leak in zlib

[Corentin Chary]

Makes sure we free all ressources used in zlib encoding (zlib stream
and buffer).

Signed-off-by: Corentin Chary 
---
 vnc-encoding-zlib.c |8 
 vnc.c   |2 ++
 vnc.h   |1 +
 3 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/vnc-encoding-zlib.c b/vnc-encoding-zlib.c
index 52b18aa..1d4dd1a 100644
--- a/vnc-encoding-zlib.c
+++ b/vnc-encoding-zlib.c
@@ -140,3 +140,11 @@ void vnc_zlib_send_framebuffer_update(VncState *vs, int x, 
int y, int w, int h)
 vnc_write_u32(vs, bytes_written);
 vs->output.offset = new_offset;
 }
+
+void vnc_zlib_clear(VncState *vs)
+{
+if (vs->zlib_stream.opaque) {
+deflateEnd(&vs->zlib_stream);
+}
+buffer_free(&vs->zlib);
+}
diff --git a/vnc.c b/vnc.c
index 8f256b3..d622a5a 100644
--- a/vnc.c
+++ b/vnc.c
@@ -924,6 +924,8 @@ static void vnc_disconnect_finish(VncState *vs)
 
 qobject_decref(vs->info);
 
+vnc_zlib_clear(vs);
+
 #ifdef CONFIG_VNC_TLS
 vnc_tls_client_cleanup(vs);
 #endif /* CONFIG_VNC_TLS */
diff --git a/vnc.h b/vnc.h
index abd9f27..ffcbc52 100644
--- a/vnc.h
+++ b/vnc.h
@@ -399,5 +399,6 @@ void vnc_hextile_send_framebuffer_update(VncState *vs, int 
x,
 void vnc_hextile_set_pixel_conversion(VncState *vs, int generic);
 
 void vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int 
h);
+void vnc_zlib_clear(VncState *vs);
 
 #endif /* __QEMU_VNC_H */
-- 
1.7.0.2

[Qemu-devel] [PATCH v3 09/12] vnc: return the number of rectangles

[Corentin Chary]

Some encodings like tight supports tiling (spliting in
multiple sub-rectangles). So we needed a way to tell
vnc_update_client() how much rectangles are in the buffer.

zlib, raw and hextile always send a full rectangle.

Signed-off-by: Corentin Chary 
---
 vnc-encoding-hextile.c |5 +++--
 vnc-encoding-zlib.c|6 --
 vnc.c  |   25 -
 vnc.h  |6 +++---
 4 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/vnc-encoding-hextile.c b/vnc-encoding-hextile.c
index a01c5e2..728f25e 100644
--- a/vnc-encoding-hextile.c
+++ b/vnc-encoding-hextile.c
@@ -62,8 +62,8 @@ static void hextile_enc_cord(uint8_t *ptr, int x, int y, int 
w, int h)
 #undef BPP
 #undef GENERIC
 
-void vnc_hextile_send_framebuffer_update(VncState *vs, int x,
- int y, int w, int h)
+int vnc_hextile_send_framebuffer_update(VncState *vs, int x,
+int y, int w, int h)
 {
 int i, j;
 int has_fg, has_bg;
@@ -83,6 +83,7 @@ void vnc_hextile_send_framebuffer_update(VncState *vs, int x,
 free(last_fg);
 free(last_bg);
 
+return 1;
 }
 
 void vnc_hextile_set_pixel_conversion(VncState *vs, int generic)
diff --git a/vnc-encoding-zlib.c b/vnc-encoding-zlib.c
index 1d4dd1a..88ac863 100644
--- a/vnc-encoding-zlib.c
+++ b/vnc-encoding-zlib.c
@@ -116,7 +116,7 @@ static int vnc_zlib_stop(VncState *vs)
 return zstream->total_out - previous_out;
 }
 
-void vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h)
+int vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h)
 {
 int old_offset, new_offset, bytes_written;
 
@@ -132,13 +132,15 @@ void vnc_zlib_send_framebuffer_update(VncState *vs, int 
x, int y, int w, int h)
 bytes_written = vnc_zlib_stop(vs);
 
 if (bytes_written == -1)
-return;
+return 0;
 
 // hack in the size
 new_offset = vs->output.offset;
 vs->output.offset = old_offset;
 vnc_write_u32(vs, bytes_written);
 vs->output.offset = new_offset;
+
+return 1;
 }
 
 void vnc_zlib_clear(VncState *vs)
diff --git a/vnc.c b/vnc.c
index d622a5a..34da9a2 100644
--- a/vnc.c
+++ b/vnc.c
@@ -646,7 +646,7 @@ static void vnc_write_pixels_generic(VncState *vs, void 
*pixels1, int size)
 }
 }
 
-void vnc_raw_send_framebuffer_update(VncState *vs, int x, int y, int w, int h)
+int vnc_raw_send_framebuffer_update(VncState *vs, int x, int y, int w, int h)
 {
 int i;
 uint8_t *row;
@@ -657,23 +657,27 @@ void vnc_raw_send_framebuffer_update(VncState *vs, int x, 
int y, int w, int h)
 vs->write_pixels(vs, row, w * ds_get_bytes_per_pixel(vs->ds));
 row += ds_get_linesize(vs->ds);
 }
+return 1;
 }
 
-static void send_framebuffer_update(VncState *vs, int x, int y, int w, int h)
+static int send_framebuffer_update(VncState *vs, int x, int y, int w, int h)
 {
+int n = 0;
+
 switch(vs->vnc_encoding) {
 case VNC_ENCODING_ZLIB:
-vnc_zlib_send_framebuffer_update(vs, x, y, w, h);
+n = vnc_zlib_send_framebuffer_update(vs, x, y, w, h);
 break;
 case VNC_ENCODING_HEXTILE:
 vnc_framebuffer_update(vs, x, y, w, h, VNC_ENCODING_HEXTILE);
-vnc_hextile_send_framebuffer_update(vs, x, y, w, h);
+n = vnc_hextile_send_framebuffer_update(vs, x, y, w, h);
 break;
 default:
 vnc_framebuffer_update(vs, x, y, w, h, VNC_ENCODING_RAW);
-vnc_raw_send_framebuffer_update(vs, x, y, w, h);
+n = vnc_raw_send_framebuffer_update(vs, x, y, w, h);
 break;
 }
+return n;
 }
 
 static void vnc_copy(VncState *vs, int src_x, int src_y, int dst_x, int dst_y, 
int w, int h)
@@ -784,6 +788,7 @@ static int vnc_update_client(VncState *vs, int has_dirty)
 int y;
 int n_rectangles;
 int saved_offset;
+int n;
 
 if (vs->output.offset && !vs->audio_cap && !vs->force_update)
 /* kernel send buffers are full -> drop frames to throttle */
@@ -816,16 +821,18 @@ static int vnc_update_client(VncState *vs, int has_dirty)
 } else {
 if (last_x != -1) {
 int h = find_and_clear_dirty_height(vs, y, last_x, x);
-send_framebuffer_update(vs, last_x * 16, y, (x - 
last_x) * 16, h);
-n_rectangles++;
+n = send_framebuffer_update(vs, last_x * 16, y,
+(x - last_x) * 16, h);
+n_rectangles += n;
 }
 last_x = -1;
 }
 }
 if (last_x != -1) {
 int h = find_and_clear_dirty_height(vs, y, last_x, x);
-send_framebuffer_update(vs, last_x * 16, y, (x - last_x) * 16, 
h);
-n_rectangles++;
+n 

[Qemu-devel] [PATCH v3 11/12] vnc: add support for tight fill encoding

[Corentin Chary]

Fill encoding detects rectangles using only one color and send only
one pixel value.

Signed-off-by: Corentin Chary 
---
 vnc-encoding-tight.c |  257 +-
 1 files changed, 255 insertions(+), 2 deletions(-)

diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index ce9cc49..2c9dab6 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -55,6 +55,139 @@ static const struct {
 { 65536, 2048,  32,  8192, 9, 9, 9, 6, 200, 500,  96, 80,   200,   500 }
 };
 
+/*
+ * Check if a rectangle is all of the same color. If needSameColor is
+ * set to non-zero, then also check that its color equals to the
+ * *colorPtr value. The result is 1 if the test is successfull, and in
+ * that case new color will be stored in *colorPtr.
+ */
+
+#define DEFINE_CHECK_SOLID_FUNCTION(bpp)\
+\
+static bool \
+check_solid_tile##bpp(VncState *vs, int x, int y, int w, int h, \
+  uint32_t* color, bool samecolor)  \
+{   \
+VncDisplay *vd = vs->vd;\
+uint##bpp##_t *fbptr;   \
+uint##bpp##_t c;\
+int dx, dy; \
+\
+fbptr = (uint##bpp##_t *)   \
+(vd->server->data + y * ds_get_linesize(vs->ds) +   \
+ x * ds_get_bytes_per_pixel(vs->ds));   \
+\
+c = *fbptr; \
+if (samecolor && (uint32_t)c != *color) {   \
+return false;   \
+}   \
+\
+for (dy = 0; dy < h; dy++) {\
+for (dx = 0; dx < w; dx++) {\
+if (c != fbptr[dx]) {   \
+return false;   \
+}   \
+}   \
+fbptr = (uint##bpp##_t *)   \
+((uint8_t *)fbptr + ds_get_linesize(vs->ds));   \
+}   \
+\
+*color = (uint32_t)c;   \
+return true;\
+}
+
+DEFINE_CHECK_SOLID_FUNCTION(32)
+DEFINE_CHECK_SOLID_FUNCTION(16)
+DEFINE_CHECK_SOLID_FUNCTION(8)
+
+static bool check_solid_tile(VncState *vs, int x, int y, int w, int h,
+ uint32_t* color, bool samecolor)
+{
+VncDisplay *vd = vs->vd;
+
+switch(vd->server->pf.bytes_per_pixel) {
+case 4:
+return check_solid_tile32(vs, x, y, w, h, color, samecolor);
+case 2:
+return check_solid_tile16(vs, x, y, w, h, color, samecolor);
+default:
+return check_solid_tile8(vs, x, y, w, h, color, samecolor);
+}
+}
+
+static void find_best_solid_area(VncState *vs, int x, int y, int w, int h,
+ uint32_t color, int *w_ptr, int *h_ptr)
+{
+int dx, dy, dw, dh;
+int w_prev;
+int w_best = 0, h_best = 0;
+
+w_prev = w;
+
+for (dy = y; dy < y + h; dy += VNC_TIGHT_MAX_SPLIT_TILE_SIZE) {
+
+dh = MIN(VNC_TIGHT_MAX_SPLIT_TILE_SIZE, y + h - dy);
+dw = MIN(VNC_TIGHT_MAX_SPLIT_TILE_SIZE, w_prev);
+
+if (!check_solid_tile(vs, x, dy, dw, dh, &color, true)) {
+break;
+}
+
+for (dx = x + dw; dx < x + w_prev;) {
+dw = MIN(VNC_TIGHT_MAX_SPLIT_TILE_SIZE, x + w_prev - dx);
+
+if (!check_solid_tile(vs, dx, dy, dw, dh, &color, true)) {
+break;
+}
+dx += dw;
+}
+
+w_prev = dx - x;
+if (w_prev * (dy + dh - y) > w_best * h_best) {
+w_best = w_prev;
+h_best = dy + dh - y;
+}
+}
+
+*w_ptr = w_best;
+*h_ptr = h_best;
+}
+
+static void extend_solid_area(VncState *vs, int x, int y, int w, int h,
+  uint32_t color, int *x_ptr, int *y_ptr,
+  int *w_ptr, int *h

[Qemu-devel] [PATCH v3 07/12] vnc: add buffer_free()

[Corentin Chary]

Add a buffer_free() helper to free vnc buffers and
remove some duplicated code in vnc_disconnect_finish().

Signed-off-by: Corentin Chary 
---
 vnc.c |   18 ++
 vnc.h |1 +
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/vnc.c b/vnc.c
index a5a0456..8f256b3 100644
--- a/vnc.c
+++ b/vnc.c
@@ -506,6 +506,14 @@ void buffer_reset(Buffer *buffer)
 buffer->offset = 0;
 }
 
+void buffer_free(Buffer *buffer)
+{
+qemu_free(buffer->buffer);
+buffer->offset = 0;
+buffer->capacity = 0;
+buffer->buffer = NULL;
+}
+
 void buffer_append(Buffer *buffer, const void *data, size_t len)
 {
 memcpy(buffer->buffer + buffer->offset, data, len);
@@ -911,14 +919,8 @@ static void vnc_disconnect_finish(VncState *vs)
 {
 vnc_qmp_event(vs, QEVENT_VNC_DISCONNECTED);
 
-if (vs->input.buffer) {
-qemu_free(vs->input.buffer);
-vs->input.buffer = NULL;
-}
-if (vs->output.buffer) {
-qemu_free(vs->output.buffer);
-vs->output.buffer = NULL;
-}
+buffer_free(&vs->input);
+buffer_free(&vs->output);
 
 qobject_decref(vs->info);
 
diff --git a/vnc.h b/vnc.h
index b2d8738..abd9f27 100644
--- a/vnc.h
+++ b/vnc.h
@@ -376,6 +376,7 @@ void buffer_reserve(Buffer *buffer, size_t len);
 int buffer_empty(Buffer *buffer);
 uint8_t *buffer_end(Buffer *buffer);
 void buffer_reset(Buffer *buffer);
+void buffer_free(Buffer *buffer);
 void buffer_append(Buffer *buffer, const void *data, size_t len);
 
 
-- 
1.7.0.2

[Qemu-devel] [PATCH v3 06/12] vnc: don't clear zlib stream on set_encoding

[Corentin Chary]

On init, values are already NULL, but we shouldn't try
to reset them each time a client send a set encoding
command because this break everything. For example,
libvncclient re-send a set encoding command if the
framebuffer is resized.

This fix framebuffer resizing for zlib encoding.

Signed-off-by: Corentin Chary 
---
 vnc-encoding-zlib.c |5 -
 vnc.c   |1 -
 vnc.h   |1 -
 3 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/vnc-encoding-zlib.c b/vnc-encoding-zlib.c
index 29dd1b7..52b18aa 100644
--- a/vnc-encoding-zlib.c
+++ b/vnc-encoding-zlib.c
@@ -140,8 +140,3 @@ void vnc_zlib_send_framebuffer_update(VncState *vs, int x, 
int y, int w, int h)
 vnc_write_u32(vs, bytes_written);
 vs->output.offset = new_offset;
 }
-
-void vnc_zlib_init(VncState *vs)
-{
-vs->zlib_stream.opaque = NULL;
-}
diff --git a/vnc.c b/vnc.c
index e81a2a5..a5a0456 100644
--- a/vnc.c
+++ b/vnc.c
@@ -1592,7 +1592,6 @@ static void set_encodings(VncState *vs, int32_t 
*encodings, size_t n_encodings)
 int i;
 unsigned int enc = 0;
 
-vnc_zlib_init(vs);
 vs->features = 0;
 vs->vnc_encoding = 0;
 vs->tight_compression = 9;
diff --git a/vnc.h b/vnc.h
index 96f3fe7..b2d8738 100644
--- a/vnc.h
+++ b/vnc.h
@@ -397,7 +397,6 @@ void vnc_hextile_send_framebuffer_update(VncState *vs, int 
x,
  int y, int w, int h);
 void vnc_hextile_set_pixel_conversion(VncState *vs, int generic);
 
-void vnc_zlib_init(VncState *vs);
 void vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int 
h);
 
 #endif /* __QEMU_VNC_H */
-- 
1.7.0.2

[Qemu-devel] [PATCH v3 10/12] vnc: add basic tight support

[Corentin Chary]

Add support for tight encoding [1]. This patch only add support
for "basic" tight compression without any filter.

[1] http://tigervnc.org/cgi-bin/rfbproto#tight-encoding.

Signed-off-by: Corentin Chary 
---
 Makefile |2 +
 Makefile.objs|1 +
 vnc-encoding-tight.c |  295 ++
 vnc-encoding-tight.h |  176 ++
 vnc-encoding-zlib.c  |8 +-
 vnc.c|8 ++
 vnc.h|   12 ++
 7 files changed, 498 insertions(+), 4 deletions(-)
 create mode 100644 vnc-encoding-tight.c
 create mode 100644 vnc-encoding-tight.h

diff --git a/Makefile b/Makefile
index 306a1a4..8e1f9d6 100644
--- a/Makefile
+++ b/Makefile
@@ -124,6 +124,8 @@ vnc-encoding-zlib.o: vnc.h
 
 vnc-encoding-hextile.o: vnc.h
 
+vnc-encoding-tight.o: vnc.h vnc-encoding-tight.h
+
 curses.o: curses.c keymaps.h curses_keys.h
 
 bt-host.o: QEMU_CFLAGS += $(BLUEZ_CFLAGS)
diff --git a/Makefile.objs b/Makefile.objs
index acbaf22..070ee09 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -104,6 +104,7 @@ common-obj-$(CONFIG_SDL) += sdl.o sdl_zoom.o x_keymap.o
 common-obj-$(CONFIG_CURSES) += curses.o
 common-obj-y += vnc.o acl.o d3des.o
 common-obj-y += vnc-encoding-zlib.o vnc-encoding-hextile.o
+common-obj-y += vnc-encoding-tight.o
 common-obj-y += iov.o
 common-obj-$(CONFIG_VNC_TLS) += vnc-tls.o vnc-auth-vencrypt.o
 common-obj-$(CONFIG_VNC_SASL) += vnc-auth-sasl.o
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
new file mode 100644
index 000..ce9cc49
--- /dev/null
+++ b/vnc-encoding-tight.c
@@ -0,0 +1,295 @@
+/*
+ * QEMU VNC display driver: tight encoding
+ *
+ * From libvncserver/libvncserver/tight.c
+ * Copyright (C) 2000, 2001 Const Kaplinsky.  All Rights Reserved.
+ * Copyright (C) 1999 AT&T Laboratories Cambridge.  All Rights Reserved.
+ *
+ * Copyright (C) 2010 Corentin Chary 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include 
+
+#include "vnc.h"
+#include "vnc-encoding-tight.h"
+
+/* Compression level stuff. The following array contains various
+   encoder parameters for each of 10 compression levels (0..9).
+   Last three parameters correspond to JPEG quality levels (0..9). */
+
+static const struct {
+int max_rect_size, max_rect_width;
+int mono_min_rect_size, gradient_min_rect_size;
+int idx_zlib_level, mono_zlib_level, raw_zlib_level, gradient_zlib_level;
+int gradient_threshold, gradient_threshold24;
+int idx_max_colors_divisor;
+int jpeg_quality, jpeg_threshold, jpeg_threshold24;
+} tight_conf[] = {
+{   512,   32,   6, 65536, 0, 0, 0, 0,   0,   0,   4,  5, 1, 23000 },
+{  2048,  128,   6, 65536, 1, 1, 1, 0,   0,   0,   8, 10,  8000, 18000 },
+{  6144,  256,   8, 65536, 3, 3, 2, 0,   0,   0,  24, 15,  6500, 15000 },
+{ 10240, 1024,  12, 65536, 5, 5, 3, 0,   0,   0,  32, 25,  5000, 12000 },
+{ 16384, 2048,  12, 65536, 6, 6, 4, 0,   0,   0,  32, 37,  4000, 1 },
+{ 32768, 2048,  12,  4096, 7, 7, 5, 4, 150, 380,  32, 50,  3000,  8000 },
+{ 65536, 2048,  16,  4096, 7, 7, 6, 4, 170, 420,  48, 60,  2000,  5000 },
+{ 65536, 2048,  16,  4096, 8, 8, 7, 5, 180, 450,  64, 70,  1000,  2500 },
+{ 65536, 2048,  32,  8192, 9, 9, 8, 6, 190, 475,  64, 75,   500,  1200 },
+{ 65536, 2048,  32,  8192, 9, 9, 9, 6, 200, 500,  96, 80,   200,   500 }
+};
+
+static int tight_init_stream(VncState *vs, int stream_id,
+ int level, int strategy)
+{
+z_streamp zstream = &vs->tight_stream[stream_id];
+
+if (zstream->opaque == NULL) {
+int err;
+
+VNC_DEBUG("VNC: TIGHT: initializing zlib stream %d\n", stream_id);
+VNC_DEBUG("VNC: TIGHT: opaque = %p | vs = %p\n", zstream->opaque, vs);
+zstream->zalloc = vnc_zlib_zalloc;
+zstream->zfree = vnc_zlib_zfree;
+
+err = deflateInit2(zstream, level, Z_DEFLATED, MAX_WBITS,
+   MAX_MEM_L

Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself

[Avi Kivity]

On 05/19/2010 10:39 AM, Rusty Russell wrote:


I think we're talking about the last 2 entries of the avail ring.  That means
the worst case is 1 false bounce every time around the ring.


It's low, but why introduce an inefficiency when you can avoid doing it 
for the same effort?



I think that's
why we're debating it instead of measuring it :)
   


Measure before optimize is good for code but not for protocols.  
Protocols have to be robust against future changes.  Virtio is warty 
enough already, we can't keep doing local optimizations.



Note that this is a exclusive->shared->exclusive bounce only, too.
   


A bounce is a bounce.

Virtio is already way too bouncy due to the indirection between the 
avail/used rings and the descriptor pool.  A device with out of order 
completion (like virtio-blk) will quickly randomize the unused 
descriptor indexes, so every descriptor fetch will require a bounce.


In contrast, if the rings hold the descriptors themselves instead of 
pointers, we bounce (sizeof(descriptor)/cache_line_size) cache lines for 
every descriptor, amortized.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] Re: [PATCH +stable] block: don't attempt to merge overlapping requests

[Avi Kivity]

On 05/18/2010 10:22 PM, Stefan Hajnoczi wrote:

On Tue, May 18, 2010 at 6:18 PM, Avi Kivity  wrote:
   

The block multiwrite code pretends to be able to merge overlapping requests,
but doesn't do so in fact.  This leads to I/O errors (for example on mkfs
of a large virtio disk).
 

Are overlapping write requests correct guest behavior?  I thought the
ordering semantics require a flush between overlapping writes to
ensure A is written before B.

What cache= mode are you running?
   


writeback.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

Re: [Qemu-devel] [PATCH 1/8] qdev: Allow device addressing via 'driver.instance'

[Avi Kivity]

On 05/18/2010 03:31 PM, Gerd Hoffmann wrote:

On 05/18/10 14:15, Markus Armbruster wrote:

Jan Kiszka  writes:

Extend qbus_find_dev to allow addressing of devices without an 
unique id

via an optional instance number. The new formats are 'driver.instance'
and 'alias.instance'.

Signed-off-by: Jan Kiszka


How's the instance number defined?  Should be documented.


savevm instance id, used to identify multiple instances of some device 
on loadvm.  By default is just incrementing (0,1,2,...) for each new 
device instance I think.


That's an implementation detail that's being exposed in an external 
interface.  Granted, users shouldn't expect this to remain stable across 
invocations, yet it makes me uncomfortable.


Why not always use topology to locate devices?


  Drivers can also specify one.  Most don't do that.  IIRC some ISA 
drivers use the base ioport as instance id, which sort-of makes sense 
as it makes sure the id identifies the correct device no matter what 
the initialization order is.


It probably makes sense to replace the instance id with the device 
path once all devices are converted over to qdev+vmstate, so we avoid 
the nasty ordering issues altogether.


Oh, that's what you're suggesting.  So we agree.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] [PATCH] qemu-kvm: Enable xsave related CPUID

[Sheng Yang]

Signed-off-by: Sheng Yang 
---
 target-i386/cpuid.c |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index eebf038..21e94f3 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -1067,6 +1067,38 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
uint32_t count,
 *ecx = 0;
 *edx = 0;
 break;
+case 0xD:
+/* Processor Extended State */
+if (!(env->cpuid_ext_features & CPUID_EXT_XSAVE)) {
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+break;
+}
+if (count == 0) {
+*eax = 0x7;
+*ebx = 0x340;
+*ecx = 0x340;
+*edx = 0;
+} else if (count == 1) {
+/* eax = 1, so we can continue with others */
+*eax = 1;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+} else if (count == 2) {
+*eax = 0x100;
+*ebx = 0x240;
+*ecx = 0;
+*edx = 0;
+} else {
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+}
+break;
 case 0x8000:
 *eax = env->cpuid_xlevel;
 *ebx = env->cpuid_vendor1;
-- 
1.7.0.1

[Qemu-devel] [PATCH v2] KVM: VMX: Enable XSAVE/XRSTORE for guest

[Sheng Yang]

From: Dexuan Cui 

Enable XSAVE/XRSTORE for guest.

Change from V1:

1. Use FPU API.
2. Fix CPUID issue.
3. Save/restore all possible guest xstate fields when switching. Because we
don't know which fields guest has already touched.

Signed-off-by: Dexuan Cui 
Signed-off-by: Sheng Yang 
---
 arch/x86/include/asm/kvm_host.h |1 +
 arch/x86/include/asm/vmx.h  |1 +
 arch/x86/kvm/vmx.c  |   28 +
 arch/x86/kvm/x86.c  |   85 +++---
 4 files changed, 108 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index d08bb4a..78d7b06 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -302,6 +302,7 @@ struct kvm_vcpu_arch {
} update_pte;
 
struct fpu guest_fpu;
+   uint64_t xcr0, host_xcr0;
 
gva_t mmio_fault_cr2;
struct kvm_pio_request pio;
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 9e6779f..346ea66 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -266,6 +266,7 @@ enum vmcs_field {
 #define EXIT_REASON_EPT_VIOLATION   48
 #define EXIT_REASON_EPT_MISCONFIG   49
 #define EXIT_REASON_WBINVD 54
+#define EXIT_REASON_XSETBV 55
 
 /*
  * Interruption-information format
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 99ae513..2ee8ff6 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -36,6 +36,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "trace.h"
 
@@ -2616,6 +2618,8 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
vmx->vcpu.arch.cr4_guest_owned_bits = KVM_CR4_GUEST_OWNED_BITS;
if (enable_ept)
vmx->vcpu.arch.cr4_guest_owned_bits |= X86_CR4_PGE;
+   if (cpu_has_xsave)
+   vmx->vcpu.arch.cr4_guest_owned_bits |= X86_CR4_OSXSAVE;
vmcs_writel(CR4_GUEST_HOST_MASK, ~vmx->vcpu.arch.cr4_guest_owned_bits);
 
tsc_base = vmx->vcpu.kvm->arch.vm_init_tsc;
@@ -3354,6 +3358,29 @@ static int handle_wbinvd(struct kvm_vcpu *vcpu)
return 1;
 }
 
+static int handle_xsetbv(struct kvm_vcpu *vcpu)
+{
+   u64 new_bv = ((u64)(kvm_register_read(vcpu, VCPU_REGS_RDX) << 32)) |
+   kvm_register_read(vcpu, VCPU_REGS_RAX);
+
+   if (kvm_register_read(vcpu, VCPU_REGS_RCX) != 0)
+   goto err;
+   if (vmx_get_cpl(vcpu) != 0)
+   goto err;
+   if (!(new_bv & XSTATE_FP) ||
+(new_bv & ~vcpu->arch.host_xcr0))
+   goto err;
+   if ((new_bv & XSTATE_YMM) && !(new_bv & XSTATE_SSE))
+   goto err;
+   vcpu->arch.xcr0 = new_bv;
+   xsetbv(XCR_XFEATURE_ENABLED_MASK, vcpu->arch.xcr0);
+   skip_emulated_instruction(vcpu);
+   return 1;
+err:
+   kvm_inject_gp(vcpu, 0);
+   return 1;
+}
+
 static int handle_apic_access(struct kvm_vcpu *vcpu)
 {
return emulate_instruction(vcpu, 0, 0, 0) == EMULATE_DONE;
@@ -3632,6 +3659,7 @@ static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu 
*vcpu) = {
[EXIT_REASON_TPR_BELOW_THRESHOLD] = handle_tpr_below_threshold,
[EXIT_REASON_APIC_ACCESS] = handle_apic_access,
[EXIT_REASON_WBINVD]  = handle_wbinvd,
+   [EXIT_REASON_XSETBV]  = handle_xsetbv,
[EXIT_REASON_TASK_SWITCH] = handle_task_switch,
[EXIT_REASON_MCE_DURING_VMENTRY]  = handle_machine_check,
[EXIT_REASON_EPT_VIOLATION]   = handle_ept_violation,
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 7be1d36..5e20f37 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -64,6 +64,7 @@
(~(unsigned long)(X86_CR4_VME | X86_CR4_PVI | X86_CR4_TSD | X86_CR4_DE\
  | X86_CR4_PSE | X86_CR4_PAE | X86_CR4_MCE \
  | X86_CR4_PGE | X86_CR4_PCE | X86_CR4_OSFXSR  \
+ | X86_CR4_OSXSAVE \
  | X86_CR4_OSXMMEXCPT | X86_CR4_VMXE))
 
 #define CR8_RESERVED_BITS (~(unsigned long)X86_CR8_TPR)
@@ -149,6 +150,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
{ NULL }
 };
 
+static inline u32 bit(int bitno)
+{
+   return 1 << (bitno & 31);
+}
+
 static void kvm_on_user_return(struct user_return_notifier *urn)
 {
unsigned slot;
@@ -473,6 +479,17 @@ void kvm_lmsw(struct kvm_vcpu *vcpu, unsigned long msw)
 }
 EXPORT_SYMBOL_GPL(kvm_lmsw);
 
+static bool guest_cpuid_has_xsave(struct kvm_vcpu *vcpu)
+{
+   struct kvm_cpuid_entry2 *best;
+
+   best = kvm_find_cpuid_entry(vcpu, 1, 0);
+   if (best->ecx & bit(X86_FEATURE_XSAVE))
+   return true;
+
+   return false;
+}
+
 int __kvm_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
 {
unsigned long old_cr4 = kvm_read_cr4(vcpu);
@@ -481,6 +498,9 @@ int __kvm_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
if (cr4 & CR4_RESERVED_BIT

[Qemu-devel] Re: qemu-kvm hangs if multipath device is queing

[Kevin Wolf]

Am 19.05.2010 09:29, schrieb Christoph Hellwig:
> On Tue, May 18, 2010 at 03:22:36PM +0200, Kevin Wolf wrote:
>> I think it's stuck here in an endless loop:
>>
>> while (laiocb->ret == -EINPROGRESS)
>> qemu_laio_completion_cb(laiocb->ctx);
>>
>> Can you verify this by single-stepping one or two loop iterations? ret
>> and errno after the read call could be interesting, too.
> 
> Maybe the compiler is just too smart.  Without some form of barrier
> it could just optimize the loop away as laiocb->ret couldn't change
> in a normal single-threaded environment.

It probably could in theory, but in practice we're in a read() inside
qemu_laio_completion, so it didn't do it here.

Kevin

[Qemu-devel] Re: [PATCH +stable] block: don't attempt to merge overlapping requests

[Stefan Hajnoczi]

On Wed, May 19, 2010 at 9:09 AM, Avi Kivity  wrote:
> On 05/18/2010 10:22 PM, Stefan Hajnoczi wrote:
>> What cache= mode are you running?
>
> writeback.

In the cache=writeback case the virtio-blk guest driver does:

blk_queue_ordered(q, QUEUE_ORDERED_DRAIN_FLUSH, ...)

Stefan

[Qemu-devel] Re: [PATCH +stable] block: don't attempt to merge overlapping requests

[Avi Kivity]

On 05/19/2010 12:01 PM, Stefan Hajnoczi wrote:

On Wed, May 19, 2010 at 9:09 AM, Avi Kivity  wrote:
   

On 05/18/2010 10:22 PM, Stefan Hajnoczi wrote:
 

What cache= mode are you running?
   

writeback.
 

In the cache=writeback case the virtio-blk guest driver does:

blk_queue_ordered(q, QUEUE_ORDERED_DRAIN_FLUSH, ...)
   


I don't follow.  What's the implication?

btw I really dislike how the cache attribute (which I see as a pure host 
choice) is exposed to the guest.  It means we can't change caching mode 
on the fly (for example after live migration), or that changing caching 
mode during a restart may expose a previously hidden guest bug.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] Re: [PATCH 2/3] QMP: Introduce commands documentation

[Jan Kiszka]

Luiz Capitulino wrote:
> From: Jan Kiszka 
> 
> One of the most important missing feature in QMP today is its
> supported commands documentation.
> 
> The plan is to make it part of self-description support, however
> self-description is a big task we have been postponing for a
> long time now and still don't know when it's going to be done.
> 
> In order not to compromise QMP adoption and make users' life easier,
> this commit adds a simple text documentation which fully describes
> all QMP supported commands.
> 
> This is not ideal for a number of reasons (harder to maintain,
> text-only, etc) but does improve the current situation. To avoid at
> least divering from the user monitor help and texi snippets, QMP bits
> are also maintained inside qemu-monitor.hx, and hxtool is extended to
> generate a single text file from them.
> 
> Signed-off-by: Jan Kiszka 
> Signed-off-by: Luiz Capitulino 
> ---
>  Makefile|5 +-
>  QMP/README  |5 +-
>  configure   |4 +
>  hxtool  |   44 ++-
>  qemu-monitor.hx | 1314 
> ++-
>  5 files changed, 1367 insertions(+), 5 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 306a1a4..110698e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -29,7 +29,7 @@ $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
>  LIBS+=-lz $(LIBS_TOOLS)
> 
>  ifdef BUILD_DOCS
> -DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8
> +DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 
> QMP/qmp-commands.txt
>  else
>  DOCS=
>  endif
> @@ -259,6 +259,9 @@ qemu-options.texi: $(SRC_PATH)/qemu-options.hx
>  qemu-monitor.texi: $(SRC_PATH)/qemu-monitor.hx
> $(call quiet-command,sh $(SRC_PATH)/hxtool -t < $< > $@,"  GEN   $@")
> 
> +QMP/qmp-commands.txt: $(SRC_PATH)/qemu-monitor.hx
> +   $(call quiet-command,sh $(SRC_PATH)/hxtool -q < $< > $@,"  GEN   $@")
> +
>  qemu-img-cmds.texi: $(SRC_PATH)/qemu-img-cmds.hx
> $(call quiet-command,sh $(SRC_PATH)/hxtool -t < $< > $@,"  GEN   $@")
> 
> diff --git a/QMP/README b/QMP/README
> index 9334c25..35a80c7 100644
> --- a/QMP/README
> +++ b/QMP/README
> @@ -15,8 +15,9 @@ QMP is JSON[1] based and has the following features:
> 
>  For more information, please, refer to the following files:
> 
> -o qmp-spec.txtQEMU Monitor Protocol current specification
> -o qmp-events.txt  List of available asynchronous events
> +o qmp-spec.txt  QEMU Monitor Protocol current specification
> +o qmp-commands.txt  QMP supported commands
> +o qmp-events.txtList of available asynchronous events
> 
>  There are also two simple Python scripts available:
> 
> diff --git a/configure b/configure
> index 36d028f..6738e0b 100755
> --- a/configure
> +++ b/configure
> @@ -2807,3 +2807,7 @@ ln -s $source_path/Makefile.user $d/Makefile
>  if test "$static" = "no" -a "$user_pie" = "yes" ; then
>echo "QEMU_CFLAGS+=-fpie" > $d/config.mak
>  fi
> +
> +if test "$docs" = "yes" ; then
> +  mkdir -p QMP
> +fi
> diff --git a/hxtool b/hxtool
> index 8f65532..d499dc0 100644
> --- a/hxtool
> +++ b/hxtool
> @@ -7,7 +7,7 @@ hxtoh()
>  case $str in
>  HXCOMM*)
>  ;;
> -STEXI*|ETEXI*) flag=$(($flag^1))
> +STEXI*|ETEXI*|SQMP*|EQMP*) flag=$(($flag^1))
>  ;;
>  *)
>  test $flag -eq 1 && printf "%s\n" "$str"
> @@ -38,6 +38,12 @@ hxtotexi()
>  fi
>  flag=0
>  ;;
> +SQMP*|EQMP*)
> +if test $flag -eq 1 ; then
> +echo "line $line: syntax error: expected ETEXI, found $str" 
> >&2
> +exit 1
> +fi
> +;;
>  DEFHEADING*)
>  echo "$(expr "$str" : "DEFHEADING(\(.*\))")"
>  ;;
> @@ -49,9 +55,45 @@ hxtotexi()
>  done
>  }
> 
> +hxtoqmp()
> +{
> +IFS=
> +flag=0
> +while read -r str; do
> +case "$str" in
> +HXCOMM*)
> +;;
> +SQMP*)
> +if test $flag -eq 1 ; then
> +echo "line $line: syntax error: expected EQMP, found $str" 
> >&2
> +exit 1
> +fi
> +flag=1
> +;;
> +EQMP*)
> +if test $flag -ne 1 ; then
> +echo "line $line: syntax error: expected SQMP, found $str" 
> >&2
> +exit 1
> +fi
> +flag=0
> +;;
> +STEXI*|ETEXI*)
> +if test $flag -eq 1 ; then
> +echo "line $line: syntax error: expected EQMP, found $str" 
> >&2
> +exit 1
> +fi
> +;;
> +*)
> +test $flag -eq 1 && echo "$str"
> +;;
> +esac
> +done
> +}
> +
>  case "$1" in
>  "-h") hxtoh ;;
>  "-t") hxtotexi ;;
> +"-q") hxtoqmp ;;
>  *) exit 1 ;;
>  esac
> 

Unfortunately, it looks like you mismerged my hxtool changes (the syntax
checking bits and the ext

[Qemu-devel] Re: qemu-kvm hangs if multipath device is queing

[Peter Lieven]

Kevin Wolf wrote:

Am 19.05.2010 09:29, schrieb Christoph Hellwig:
  

On Tue, May 18, 2010 at 03:22:36PM +0200, Kevin Wolf wrote:


I think it's stuck here in an endless loop:

while (laiocb->ret == -EINPROGRESS)
qemu_laio_completion_cb(laiocb->ctx);

Can you verify this by single-stepping one or two loop iterations? ret
and errno after the read call could be interesting, too.
  

Maybe the compiler is just too smart.  Without some form of barrier
it could just optimize the loop away as laiocb->ret couldn't change
in a normal single-threaded environment.



It probably could in theory, but in practice we're in a read() inside
qemu_laio_completion, so it didn't do it here.
  

if you supply a patch that will add some usleeps at the point in
question i'm willing to test if it solves the 100% cpu problem.

Kevin

  

[Qemu-devel] Re: [PATCH +stable] block: don't attempt to merge overlapping requests

[Stefan Hajnoczi]

On Wed, May 19, 2010 at 10:06 AM, Avi Kivity  wrote:
>> In the cache=writeback case the virtio-blk guest driver does:
>>
>> blk_queue_ordered(q, QUEUE_ORDERED_DRAIN_FLUSH, ...)
>>
>
> I don't follow.  What's the implication?

I was wondering whether the queue is incorrectly set to a mode where
overlapping write requests aren't being ordered.  Anyway, Christoph
says overlapping write requests can be issued so my theory is broken.

> btw I really dislike how the cache attribute (which I see as a pure host
> choice) is exposed to the guest.  It means we can't change caching mode on
> the fly (for example after live migration), or that changing caching mode
> during a restart may expose a previously hidden guest bug.

Christoph has mentioned wanting to make the write cache switchable
from inside the guest.

Stefan

[Qemu-devel] [PATCH] virtio-serial-bus: fix ports_map allocation on init

[Amit Shah]

From: Alon Levy 

Fix for too small allocation to ports_map

Signed-off-by: Alon Levy 
Signed-off-by: Amit Shah 
---
 hw/virtio-serial-bus.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 3ce95e8..7f9d28f 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -774,7 +774,8 @@ VirtIODevice *virtio_serial_init(DeviceState *dev, uint32_t 
max_nr_ports)
 }
 
 vser->config.max_nr_ports = max_nr_ports;
-vser->ports_map = qemu_mallocz((max_nr_ports + 31) / 32);
+vser->ports_map = qemu_mallocz(((max_nr_ports + 31) / 32)
+* sizeof(vser->ports_map[0]));
 /*
  * Reserve location 0 for a console port for backward compat
  * (old kernel, new qemu)
-- 
1.7.0.1

[Qemu-devel] Re: [PATCH +stable] block: don't attempt to merge overlapping requests

[Christoph Hellwig]

On Wed, May 19, 2010 at 10:23:44AM +0100, Stefan Hajnoczi wrote:
> On Wed, May 19, 2010 at 10:06 AM, Avi Kivity  wrote:
> >> In the cache=writeback case the virtio-blk guest driver does:
> >>
> >> blk_queue_ordered(q, QUEUE_ORDERED_DRAIN_FLUSH, ...)
> >>
> >
> > I don't follow. ?What's the implication?
> 
> I was wondering whether the queue is incorrectly set to a mode where
> overlapping write requests aren't being ordered.  Anyway, Christoph
> says overlapping write requests can be issued so my theory is broken.

They can happen, but won't during usual pagecache based writeback.  So
this should not happen for the pagecache based mke2fs workload.  It
could happen for a workload with mkfs that uses O_DIRECT.  And we
need to handle it either way.

And btw, our barrier handling for devices using multiwrite (aka virtio)
is utterly busted right now, patch will follow ASAP.

[Qemu-devel] [PATCH 2/2] all vga: fail graicefully when vga ports are taken

[Gerd Hoffmann]

Try to pci hotplug a vga card, watch qemu die with hw_error().
This patch fixes it.

[v2: code style fixes]

Signed-off-by: Gerd Hoffmann 
---
 hw/cirrus_vga.c |4 
 hw/vga-pci.c|4 
 hw/vmware_vga.c |4 
 3 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 9f61a01..977abd2 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -3189,6 +3189,10 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
  uint8_t *pci_conf = d->dev.config;
  int device_id = CIRRUS_ID_CLGD5446;
 
+ if (is_ioport_assigned(0x3c0)) {
+ return -1;
+ }
+
  /* setup VGA */
  vga_common_init(&s->vga, VGA_RAM_SIZE);
  cirrus_init_common(s, device_id, 1);
diff --git a/hw/vga-pci.c b/hw/vga-pci.c
index c8d260c..9fa0bfb 100644
--- a/hw/vga-pci.c
+++ b/hw/vga-pci.c
@@ -79,6 +79,10 @@ static int pci_vga_initfn(PCIDevice *dev)
  VGACommonState *s = &d->vga;
  uint8_t *pci_conf = d->dev.config;
 
+ if (is_ioport_assigned(0x3c0)) {
+ return -1;
+ }
+
  // vga + console init
  vga_common_init(s, VGA_RAM_SIZE);
  vga_init(s);
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index 4e7a75d..7a8cec0 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -1232,6 +1232,10 @@ static int pci_vmsvga_initfn(PCIDevice *dev)
 struct pci_vmsvga_state_s *s =
 DO_UPCAST(struct pci_vmsvga_state_s, card, dev);
 
+if (is_ioport_assigned(0x3c0)) {
+return -1;
+}
+
 pci_config_set_vendor_id(s->card.config, PCI_VENDOR_ID_VMWARE);
 pci_config_set_device_id(s->card.config, SVGA_PCI_DEVICE_ID);
 s->card.config[PCI_COMMAND]= PCI_COMMAND_IO |
-- 
1.6.6.1

[Qemu-devel] [PATCH 1/2] ioport: add function to check whenever a port is assigned or not

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 ioport.c |5 +
 ioport.h |1 +
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/ioport.c b/ioport.c
index 53dd87a..b718047 100644
--- a/ioport.c
+++ b/ioport.c
@@ -190,6 +190,11 @@ void isa_unassign_ioport(pio_addr_t start, int length)
 }
 }
 
+int is_ioport_assigned(pio_addr_t addr)
+{
+return ioport_opaque[addr] != NULL;
+}
+
 /***/
 
 void cpu_outb(pio_addr_t addr, uint8_t val)
diff --git a/ioport.h b/ioport.h
index 3d3c8a3..46fbfa8 100644
--- a/ioport.h
+++ b/ioport.h
@@ -41,6 +41,7 @@ int register_ioport_read(pio_addr_t start, int length, int 
size,
 int register_ioport_write(pio_addr_t start, int length, int size,
   IOPortWriteFunc *func, void *opaque);
 void isa_unassign_ioport(pio_addr_t start, int length);
+int is_ioport_assigned(pio_addr_t addr);
 
 
 void cpu_outb(pio_addr_t addr, uint8_t val);
-- 
1.6.6.1

[Qemu-devel] Re: KVM call agenda for May 18

[Christoph Hellwig]

On Tue, May 18, 2010 at 08:52:36AM -0500, Anthony Liguori wrote:
> This should be filed in launchpad as a qemu bug and it should be tested  
> against the latest git.  This bug sounds like we're using an int to  
> represent sector offset somewhere but there's not enough info in the bug  
> report to figure out for sure.  I just audited the virtio-blk -> raw ->  
> aio=threads path and I don't see an obvious place that we're getting it  
> wrong.

FYI: I'm going to ignore everything that's in launchpad - even more than
in the stupid SF bugtracker.  While the SF one is almost unsuable
launchpad is entirely unsuable.  If you don't have an account with the
evil spacement empire you can't even check the email addresses of the
reporters, so any communication with them is entirely impossible.

It's time we get a proper bugzilla.qemu.org for both qemu and qemu-kvm
that can be used sanely.  If you ask nicely you might even get a virtual
instance of bugzilla.kernel.org which works quite nicely.

[Qemu-devel] Re: [PATCH 1/3] cursor: add cursor functions.

[Gerd Hoffmann]

Then there would be no need of parsing.


  You would need _two_ bitmaps (e.g. mask and cursor, so that mask=1 gives
transparent, mask=0 cursor=0 gives black and mask=0 cursor=1 gives white).


Yes, but it's still packed more efficiently.


Well.  You can't have both.  We can have a efficiently packed format 
(i.e. two bitmaps).  Or we can do it in a way which doesn't need 
parsing, but that wouldn't be the most compact format ...



There's yet another way:
#define _ 0,
#define X 0xff00,
#define o 0x,
{
  _ _ _ X o X _ _ _
}
#undef _
#undef X
#undef o


Neat idea ;)

cheers,
  Gerd

Re: [Qemu-devel] Qemu-KVM 0.12.4 Guest entered Paused State

[Peter Lieven]

Anthony Liguori wrote:

On 05/17/2010 10:16 AM, Peter Lieven wrote:

Hi,

i have a VM where I just did a dist-upgrade in Ubuntu and the VM entered
paused state without any obvious reason.

Is there a way to debug why this happened? I have not touched the VM by
now to leave the opportunity to debug.
   


You have run out of disk space on the host.
i oversaw the following output from qemu-kvm at the moment the vm went 
to status paused:


KVM internal error. Suberror: 1
rax 0100 rbx 880017585bc0 rcx 7f84c6d5b000 rdx 
0001
rsi  rdi 88001d322dec rsp 88001e133e88 rbp 
88001e133e88
r8  01f25bc2 r9  0007 r10 7f84c6b4d97b r11 
0206
r12 88001d322dec r13 88001d322de8 r14 0001 r15 


rip 81039719 rflags 00010092
cs 0010 (/ p 1 dpl 0 db 0 s 1 type b l 1 g 1 avl 0)
ds  (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
es  (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
ss 0018 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
fs  (7f84c6d53700/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
gs  (880001d0/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
tr 0040 (880001d13780/2087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
ldt  (/ p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
gdt 880001d04000/7f
idt 8195e000/fff
cr0 80050033 cr2 7f84c6b38ec8 cr3 1db7d000 cr4 6e0 cr8 0 efer 501
emulation failure, check dmesg for details

Unfortunately, I found nothing in syslog or dmesg

any ideas?


Regards,

Anthony Liguori


Peter


   







--
Mit freundlichen Grüßen/Kind Regards

Peter Lieven

..

  KAMP Netzwerkdienste GmbH
  Vestische Str. 89-91 | 46117 Oberhausen
  Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40
  mailto:p...@kamp.de | http://www.kamp.de

  Geschäftsführer: Heiner Lante | Michael Lante
  Amtsgericht Duisburg | HRB Nr. 12154
  USt-Id-Nr.: DE 120607556

. 

Re: [Qemu-devel] [PATCH v3 00/12] *** SUBJECT HERE ***

[Corentin Chary]

Arg ... I did it *again* ... sorry for the stupid title ..

-- 
Corentin Chary
http://xf.iksaif.net

[Qemu-devel] [PATCH] virtio-blk: fix barrier support

[Christoph Hellwig]

Before issuing the barrier to the block driver we need to flush our oustanding
queue of write requests, as the flush is supposed to be issued after them.

Signed-off-by: Christoph Hellwig 

Index: qemu/hw/virtio-blk.c
===
--- qemu.orig/hw/virtio-blk.c   2010-05-19 11:05:23.259005741 +0200
+++ qemu/hw/virtio-blk.c2010-05-19 11:08:09.797255846 +0200
@@ -238,10 +238,20 @@ static void do_multiwrite(BlockDriverSta
 }
 }
 
-static void virtio_blk_handle_flush(VirtIOBlockReq *req)
+static void virtio_blk_handle_flush(BlockRequest *blkreq, int *num_writes,
+VirtIOBlockReq *req, BlockDriverState **old_bs)
 {
 BlockDriverAIOCB *acb;
 
+/*
+ * Make sure all outstanding writes are posted to the backing device.
+ */
+if (*old_bs != NULL) {
+do_multiwrite(*old_bs, blkreq, *num_writes);
+}
+*num_writes = 0;
+*old_bs = req->dev->bs;
+
 acb = bdrv_aio_flush(req->dev->bs, virtio_blk_flush_complete, req);
 if (!acb) {
 virtio_blk_req_complete(req, VIRTIO_BLK_S_IOERR);
@@ -314,7 +324,8 @@ static void virtio_blk_handle_request(Vi
 req->in = (void *)req->elem.in_sg[req->elem.in_num - 1].iov_base;
 
 if (req->out->type & VIRTIO_BLK_T_FLUSH) {
-virtio_blk_handle_flush(req);
+virtio_blk_handle_flush(mrb->blkreq, &mrb->num_writes,
+req, &mrb->old_bs);
 } else if (req->out->type & VIRTIO_BLK_T_SCSI_CMD) {
 virtio_blk_handle_scsi(req);
 } else if (req->out->type & VIRTIO_BLK_T_OUT) {

Re: [Qemu-devel] [PATCH 2/2] migration: Fix calculation of bytes_transferred

[Pierre Riteau]

Anyone interested by this diff?

On 12 mai 2010, at 15:12, Pierre Riteau wrote:

> When a page with all identical bytes is transferred, it is counted
> as a full page (TARGET_PAGE_SIZE) although only one byte is actually
> sent. Fix this by changing ram_save_block() to return the number of
> bytes sent instead of a boolean value. This makes bandwidth
> estimation, and consequently downtime estimation, more precise.
> 
> Signed-off-by: Pierre Riteau 
> ---
> arch_init.c |   21 -
> 1 files changed, 12 insertions(+), 9 deletions(-)
> 
> diff --git a/arch_init.c b/arch_init.c
> index cf6b7b0..76317af 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -108,7 +108,7 @@ static int ram_save_block(QEMUFile *f)
> static ram_addr_t current_addr = 0;
> ram_addr_t saved_addr = current_addr;
> ram_addr_t addr = 0;
> -int found = 0;
> +int bytes_sent = 0;
> 
> while (addr < last_ram_offset) {
> if (cpu_physical_memory_get_dirty(current_addr, 
> MIGRATION_DIRTY_FLAG)) {
> @@ -123,19 +123,20 @@ static int ram_save_block(QEMUFile *f)
> if (is_dup_page(p, *p)) {
> qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_COMPRESS);
> qemu_put_byte(f, *p);
> +bytes_sent = 1;
> } else {
> qemu_put_be64(f, current_addr | RAM_SAVE_FLAG_PAGE);
> qemu_put_buffer(f, p, TARGET_PAGE_SIZE);
> +bytes_sent = TARGET_PAGE_SIZE;
> }
> 
> -found = 1;
> break;
> }
> addr += TARGET_PAGE_SIZE;
> current_addr = (saved_addr + addr) % last_ram_offset;
> }
> 
> -return found;
> +return bytes_sent;
> }
> 
> static uint64_t bytes_transferred;
> @@ -206,11 +207,11 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
> void *opaque)
> bwidth = qemu_get_clock_ns(rt_clock);
> 
> while (!qemu_file_rate_limit(f)) {
> -int ret;
> +int bytes_sent;
> 
> -ret = ram_save_block(f);
> -bytes_transferred += ret * TARGET_PAGE_SIZE;
> -if (ret == 0) { /* no more blocks */
> +bytes_sent = ram_save_block(f);
> +bytes_transferred += bytes_sent;
> +if (bytes_sent == 0) { /* no more blocks */
> break;
> }
> }
> @@ -226,9 +227,11 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
> void *opaque)
> 
> /* try transferring iterative blocks of memory */
> if (stage == 3) {
> +int bytes_sent;
> +
> /* flush all remaining blocks regardless of rate limiting */
> -while (ram_save_block(f) != 0) {
> -bytes_transferred += TARGET_PAGE_SIZE;
> +while ((bytes_sent = ram_save_block(f)) != 0) {
> +bytes_transferred += bytes_sent;
> }
> cpu_physical_memory_set_dirty_tracking(0);
> }
> -- 
> 1.7.1
> 
> 

-- 
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/

Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself

[Rusty Russell]

On Wed, 12 May 2010 04:57:22 am Avi Kivity wrote:
> On 05/07/2010 06:23 AM, Rusty Russell wrote:
> > On Thu, 6 May 2010 07:30:00 pm Avi Kivity wrote:
> >
> >> On 05/05/2010 11:58 PM, Michael S. Tsirkin wrote:
> >>  
> >>> + /* We publish the last-seen used index at the end of the available ring.
> >>> +  * It is at the end for backwards compatibility. */
> >>> + vr->last_used_idx =&(vr)->avail->ring[num];
> >>> + /* Verify that last used index does not spill over the used ring. */
> >>> + BUG_ON((void *)vr->last_used_idx +
> >>> +sizeof *vr->last_used_idx>   (void *)vr->used);
> >>>}
> >>>
> >>>
> >> Shouldn't this be on its own cache line?
> >>  
> > It's next to the available ring; because that's where the guest publishes
> > its data.  That whole page is guest-write, host-read.
> >
> > Putting it on a cacheline by itself would be a slight pessimization; the 
> > host
> > cpu would have to get the last_used_idx cacheline and the avail descriptor
> > cacheline every time.  This way, they are sometimes the same cacheline.
> 
> If one peer writes the tail of the available ring, while the other reads 
> last_used_idx, it's a false bounce, no?

I think we're talking about the last 2 entries of the avail ring.  That means
the worst case is 1 false bounce every time around the ring.  I think that's
why we're debating it instead of measuring it :)

Note that this is a exclusive->shared->exclusive bounce only, too.

Cheers,
Rusty.

Re: [Qemu-devel] opensuse 11.2 guest hangs after live migration with clocksource=kvm-clock

[Peter Lieven]

Peter Lieven wrote:

Hi all,

i would like to debug a problem that I encountered some time ago with 
opensuse 11.2 and also

with Ubuntu (karmic/lucid).

If I run an opensuse guest 64-bit and do not touch the clocksource 
settings the guest almost

everytime hangs after live migration at:

(gdb) thread apply all bt

Thread 2 (Thread 0x7f846782a950 (LWP 27356)):
#0  0x7f8467d24cd7 in ioctl () from /lib/libc.so.6
#1  0x0042b945 in kvm_run (env=0x2468170)
   at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:921
#2  0x0042cea2 in kvm_cpu_exec (env=0x2468170)
   at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1651
#3  0x0042d62c in kvm_main_loop_cpu (env=0x2468170)
   at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1893
#4  0x0042d76d in ap_main_loop (_env=0x2468170)
   at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943
#5  0x7f8468caa3ba in start_thread () from /lib/libpthread.so.0
#6  0x7f8467d2cfcd in clone () from /lib/libc.so.6
#7  0x in ?? ()

Thread 1 (Thread 0x7f84692d96f0 (LWP 27353)):
#0  0x7f8467d25742 in select () from /lib/libc.so.6
#1  0x0040c25a in main_loop_wait (timeout=1000)
   at /usr/src/qemu-kvm-0.12.4/vl.c:3994
#2  0x0042dcf1 in kvm_main_loop ()
   at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126
#3  0x0040c98c in main_loop () at 
/usr/src/qemu-kvm-0.12.4/vl.c:4212

#4  0x0041054b in main (argc=31, argv=0x7fffa91351c8,
   envp=0x7fffa91352c8) at /usr/src/qemu-kvm-0.12.4/vl.c:6252

If I run the same guest with kernel parameter clocksource=acpi_pm, the 
migration succeeds reliably.


The hosts runs:
/kernel: /2.6.33.3, /bin: /qemu-kvm-0.12.4, /mod: /2.6.33.3

I invoke qemu-kvm with:
/usr/bin/qemu-kvm-0.12.4  -net none  -drive 
file=/dev/sdb,if=ide,boot=on,cache=none,aio=native  -m 1024 -cpu 
qemu64,model_id='Intel(R) Xeon(R) CPU   E5430  @ 2.66GHz'  
-monitor tcp:0:4001,server,nowait -vnc :1 -name 'test'  -boot 
order=dc,menu=on  -k de  -pidfile /var/run/qemu/vm-149.pid  -mem-path 
/hugepages -mem-prealloc  -rtc base=utc,clock=vm -usb -usbdevice tablet


The Guest is:
OpenSuse 11.2 64-bit with Kernel 2.6.31.5-0.1-desktop #1 SMP PREEMPT 
2009-10-26 15:49:03 +0100 x86_64

The clocksource automatically choosen is kvm-clock.

Feedback appreciated. I have observed the same problem with 0.12.2 and 
also with old binaries provided by Ubuntu Karmic (kvm-88).


BR,
Peter



The same problem exists with 32-bit guest OS. Sometimes the guest kernel 
reports a Soft Lockup after some time with a really high value for the 
stuck time (in the order of billion seconds).

Is there maybe an overflow or a clock going backwards?

Re: [Qemu-devel] [PATCH] virtio-blk: fix barrier support

[Kevin Wolf]

Am 19.05.2010 12:40, schrieb Christoph Hellwig:
> Before issuing the barrier to the block driver we need to flush our oustanding
> queue of write requests, as the flush is supposed to be issued after them.
> 
> Signed-off-by: Christoph Hellwig 

Thanks, applied to the block branch.

I'm going to send a pull request today to get this in ASAP. It would be
helpful to know by then why Avi's patch helps and if it should be
pushed, too. It looks merely like a workaround, so I'd love to see it
replaced by a real fix.

Kevin

[Qemu-devel] Latest git does not compile target_to_host_rlim()

[Riccardo Magliocchetti]

Hello,

latest git does not compile on debian sid 32 bit (kernel 64 bit), gcc 
4.4.4:


 CCalpha-linux-user/syscall.o
cc1: warnings being treated as errors
/home/rm/src/qemu/linux-user/syscall.c: In function ‘target_to_host_rlim’:
/home/rm/src/qemu/linux-user/syscall.c:836: error: integer constant is 
too large for ‘unsigned long’ type

/home/rm/src/qemu/linux-user/syscall.c: In function ‘host_to_target_rlim’:
/home/rm/src/qemu/linux-user/syscall.c:845: error: integer constant is 
too large for ‘unsigned long’ type


thanks,
Riccardo Magliocchetti

Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

[Stefano Stabellini]

On Tue, 18 May 2010, Gerd Hoffmann wrote:
> On 05/13/10 17:53, Julian Pidancet wrote:
> > This patch implements a DirectFB driver for QEMU. It allows Qemu to
> > draw a VM graphic output directly in the framebuffer of the host,
> > without having to rely on X11.
> 
> Managed to build it after hacking configure to use pkgconfig.  Patch 
> attached for reference.
> 
> Same bug as SDL on framebuffer:  No sane console switching.  Boot a 
> guest, switch to another (host) virtual terminal, watch qemu continue 
> drawing on your screen.
> 
> Guys, this is simply not acceptable.  You are not alone on the machine. 
>   If I switch away to another virtual terminal I want to see that other 
> terminals content and nothing else.
> 
> NACK.


I completely agree with you.

I think the only way to fix this is to handle VT acquire and release
events ourselves.
At this point I am not sure if it is worth doing it in the DirectFB
frontend or in the SDL frontend directly (making sure we are not
running on X11 first).

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Miguel Di Ciurcio Filho]

On Wed, May 19, 2010 at 2:04 AM, Aurelien Jarno  wrote:
>
> The idea is nice, but would it be possible to hold this on a week-end,
> I personally won't be able to attend such thing on a day week.
>
> Or maybe holding that on two days: friday and saturday so that people
> can participate at least one of the two days, depending if they do that
> from work or from home.
>

I second that. How about June 4th and 5th?

Miguel

[Qemu-devel] Re: [PATCH 2/3] QMP: Introduce commands documentation

[Luiz Capitulino]

On Wed, 19 May 2010 11:15:16 +0200
Jan Kiszka  wrote:

> Luiz Capitulino wrote:
> > From: Jan Kiszka 
> > 
> > One of the most important missing feature in QMP today is its
> > supported commands documentation.
> > 
> > The plan is to make it part of self-description support, however
> > self-description is a big task we have been postponing for a
> > long time now and still don't know when it's going to be done.
> > 
> > In order not to compromise QMP adoption and make users' life easier,
> > this commit adds a simple text documentation which fully describes
> > all QMP supported commands.
> > 
> > This is not ideal for a number of reasons (harder to maintain,
> > text-only, etc) but does improve the current situation. To avoid at
> > least divering from the user monitor help and texi snippets, QMP bits
> > are also maintained inside qemu-monitor.hx, and hxtool is extended to
> > generate a single text file from them.
> > 
> > Signed-off-by: Jan Kiszka 
> > Signed-off-by: Luiz Capitulino 
> > ---
> >  Makefile|5 +-
> >  QMP/README  |5 +-
> >  configure   |4 +
> >  hxtool  |   44 ++-
> >  qemu-monitor.hx | 1314 
> > ++-
> >  5 files changed, 1367 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Makefile b/Makefile
> > index 306a1a4..110698e 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -29,7 +29,7 @@ $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
> >  LIBS+=-lz $(LIBS_TOOLS)
> > 
> >  ifdef BUILD_DOCS
> > -DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8
> > +DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 
> > QMP/qmp-commands.txt
> >  else
> >  DOCS=
> >  endif
> > @@ -259,6 +259,9 @@ qemu-options.texi: $(SRC_PATH)/qemu-options.hx
> >  qemu-monitor.texi: $(SRC_PATH)/qemu-monitor.hx
> > $(call quiet-command,sh $(SRC_PATH)/hxtool -t < $< > $@,"  GEN   
> > $@")
> > 
> > +QMP/qmp-commands.txt: $(SRC_PATH)/qemu-monitor.hx
> > +   $(call quiet-command,sh $(SRC_PATH)/hxtool -q < $< > $@,"  GEN   
> > $@")
> > +
> >  qemu-img-cmds.texi: $(SRC_PATH)/qemu-img-cmds.hx
> > $(call quiet-command,sh $(SRC_PATH)/hxtool -t < $< > $@,"  GEN   
> > $@")
> > 
> > diff --git a/QMP/README b/QMP/README
> > index 9334c25..35a80c7 100644
> > --- a/QMP/README
> > +++ b/QMP/README
> > @@ -15,8 +15,9 @@ QMP is JSON[1] based and has the following features:
> > 
> >  For more information, please, refer to the following files:
> > 
> > -o qmp-spec.txtQEMU Monitor Protocol current specification
> > -o qmp-events.txt  List of available asynchronous events
> > +o qmp-spec.txt  QEMU Monitor Protocol current specification
> > +o qmp-commands.txt  QMP supported commands
> > +o qmp-events.txtList of available asynchronous events
> > 
> >  There are also two simple Python scripts available:
> > 
> > diff --git a/configure b/configure
> > index 36d028f..6738e0b 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2807,3 +2807,7 @@ ln -s $source_path/Makefile.user $d/Makefile
> >  if test "$static" = "no" -a "$user_pie" = "yes" ; then
> >echo "QEMU_CFLAGS+=-fpie" > $d/config.mak
> >  fi
> > +
> > +if test "$docs" = "yes" ; then
> > +  mkdir -p QMP
> > +fi
> > diff --git a/hxtool b/hxtool
> > index 8f65532..d499dc0 100644
> > --- a/hxtool
> > +++ b/hxtool
> > @@ -7,7 +7,7 @@ hxtoh()
> >  case $str in
> >  HXCOMM*)
> >  ;;
> > -STEXI*|ETEXI*) flag=$(($flag^1))
> > +STEXI*|ETEXI*|SQMP*|EQMP*) flag=$(($flag^1))
> >  ;;
> >  *)
> >  test $flag -eq 1 && printf "%s\n" "$str"
> > @@ -38,6 +38,12 @@ hxtotexi()
> >  fi
> >  flag=0
> >  ;;
> > +SQMP*|EQMP*)
> > +if test $flag -eq 1 ; then
> > +echo "line $line: syntax error: expected ETEXI, found 
> > $str" >&2
> > +exit 1
> > +fi
> > +;;
> >  DEFHEADING*)
> >  echo "$(expr "$str" : "DEFHEADING(\(.*\))")"
> >  ;;
> > @@ -49,9 +55,45 @@ hxtotexi()
> >  done
> >  }
> > 
> > +hxtoqmp()
> > +{
> > +IFS=
> > +flag=0
> > +while read -r str; do
> > +case "$str" in
> > +HXCOMM*)
> > +;;
> > +SQMP*)
> > +if test $flag -eq 1 ; then
> > +echo "line $line: syntax error: expected EQMP, found $str" 
> > >&2
> > +exit 1
> > +fi
> > +flag=1
> > +;;
> > +EQMP*)
> > +if test $flag -ne 1 ; then
> > +echo "line $line: syntax error: expected SQMP, found $str" 
> > >&2
> > +exit 1
> > +fi
> > +flag=0
> > +;;
> > +STEXI*|ETEXI*)
> > +if test $flag -eq 1 ; then
> > +echo "line $line: syntax error: expected EQMP, found $str" 
> > >&2
> > +exit 1
>

[Qemu-devel] latest git target-sparc/translate.c does not compile with --disable-kvm --enable-debug

[Riccardo Magliocchetti]

Hello,

latest git does not compile on a mixed debian sid 32 bit / kernel 64 bit 
on x86-64, gcc is 4.4.4.


$ ./configure --disable-kvm --enable-debug

  CCsparc64-softmmu/translate.o
/home/rm/src/qemu/target-sparc/translate.c: In function ‘gen_op_addxi_cc’:
/home/rm/src/qemu/target-sparc/translate.c:337: error: incompatible type 
for argument 1 of ‘gen_helper_compute_C_icc’
/home/rm/src/qemu/target-sparc/helper.h:161: note: expected ‘TCGv_i32’ 
but argument is of type ‘TCGv_i64’

/home/rm/src/qemu/target-sparc/translate.c: In function ‘gen_op_addx_cc’:
/home/rm/src/qemu/target-sparc/translate.c:347: error: incompatible type 
for argument 1 of ‘gen_helper_compute_C_icc’
/home/rm/src/qemu/target-sparc/helper.h:161: note: expected ‘TCGv_i32’ 
but argument is of type ‘TCGv_i64’

/home/rm/src/qemu/target-sparc/translate.c: In function ‘gen_op_subxi_cc’:
/home/rm/src/qemu/target-sparc/translate.c:420: error: incompatible type 
for argument 1 of ‘gen_helper_compute_C_icc’
/home/rm/src/qemu/target-sparc/helper.h:161: note: expected ‘TCGv_i32’ 
but argument is of type ‘TCGv_i64’

/home/rm/src/qemu/target-sparc/translate.c: In function ‘gen_op_subx_cc’:
/home/rm/src/qemu/target-sparc/translate.c:430: error: incompatible type 
for argument 1 of ‘gen_helper_compute_C_icc’
/home/rm/src/qemu/target-sparc/helper.h:161: note: expected ‘TCGv_i32’ 
but argument is of type ‘TCGv_i64’

/home/rm/src/qemu/target-sparc/translate.c: In function ‘disas_sparc_insn’:
/home/rm/src/qemu/target-sparc/translate.c:2960: error: incompatible 
type for argument 1 of ‘gen_helper_compute_C_icc’
/home/rm/src/qemu/target-sparc/helper.h:161: note: expected ‘TCGv_i32’ 
but argument is of type ‘TCGv_i64’
/home/rm/src/qemu/target-sparc/translate.c:2970: error: incompatible 
type for argument 1 of ‘gen_helper_compute_C_icc’
/home/rm/src/qemu/target-sparc/helper.h:161: note: expected ‘TCGv_i32’ 
but argument is of type ‘TCGv_i64’
/home/rm/src/qemu/target-sparc/translate.c:3012: error: incompatible 
type for argument 1 of ‘gen_helper_compute_C_icc’
/home/rm/src/qemu/target-sparc/helper.h:161: note: expected ‘TCGv_i32’ 
but argument is of type ‘TCGv_i64’
/home/rm/src/qemu/target-sparc/translate.c:3022: error: incompatible 
type for argument 1 of ‘gen_helper_compute_C_icc’
/home/rm/src/qemu/target-sparc/helper.h:161: note: expected ‘TCGv_i32’ 
but argument is of type ‘TCGv_i64’

make[1]: *** [translate.o] Error 1
make: *** [subdir-sparc64-softmmu] Error 2

thanks,
Riccardo Magliocchetti

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Anthony Liguori]

On 05/18/2010 08:45 PM, Jamie Lokier wrote:

Natalia Portillo wrote:
   

Hi,

 

- We'll try to migrate as many confirmable bugs from the Source Forge tracker 
to Launchpad.
   

I think that part of the bug day should also include retesting OSes that appear 
in OS Support List as having bug and confirming if the bug is still present and 
if it's in Launchpad or not.


We don't have a supported OS list.  Everything is best effort.  The OS 
Support List Natalia is referring to is a reflection of what's been 
reported to work, not what we expect should work.



There have been reports of several legacy OSes being unable to install
or boot in the newer qemu while working in the older one.  They're
probably not in the "OS Support List" though.  Are they effectively
uninteresting for the purpose of the 0.13 release?
 


For the Bug Day, anything is interesting IMHO.  My main interest is to 
get as many people involved in testing and bug fixing as possible.  If 
folks are interested in testing specific things like unusual or older 
OSes, I'm happy to see it!


Regards,

Anthony Liguori


Unfortunately I doubt I will have time to participate in the Bug Day.

Thanks,
-- Jamie

 

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Michael Tokarev]

Anthony Liguori wrote:
[]
> For the Bug Day, anything is interesting IMHO.  My main interest is to
> get as many people involved in testing and bug fixing as possible.  If
> folks are interested in testing specific things like unusual or older
> OSes, I'm happy to see it!

Well, interesting or not, but I for one don't know what to do with the
results.  There were a thread on kvm@ about sigsegv in cirrus code when
running winNT. The issue has been identified and appears to be fixed,
as in, kvm process does not SIGSEGV anymore, but it does not work anyway,
now printing:

 BUG: kvm_dirty_pages_log_enable_slot: invalid parameters

with garbled guest display.  Thanks goes to Stefano Stabellini for
finding the SIGSEGV case, but unfortunately his hard work isn't quite
useful since the behavour isn't very much different from the previous
version... ;)

Also, thanks to Andre Przywara, whole winNT thing works but it requires
-cpu qemu64,level=1 (or level=2 or =3), -- _not_ with default CPU.  This
is also testing, but it's not obvious what to do witht the result...

Thanks!

/mjt

[Qemu-devel] Re: [PATCH 2/3] QMP: Introduce commands documentation

[Jan Kiszka]

Luiz Capitulino wrote:
> On Wed, 19 May 2010 11:15:16 +0200
> Jan Kiszka  wrote:
> 
>> Luiz Capitulino wrote:
>>> From: Jan Kiszka 
>>>
>>> One of the most important missing feature in QMP today is its
>>> supported commands documentation.
>>>
>>> The plan is to make it part of self-description support, however
>>> self-description is a big task we have been postponing for a
>>> long time now and still don't know when it's going to be done.
>>>
>>> In order not to compromise QMP adoption and make users' life easier,
>>> this commit adds a simple text documentation which fully describes
>>> all QMP supported commands.
>>>
>>> This is not ideal for a number of reasons (harder to maintain,
>>> text-only, etc) but does improve the current situation. To avoid at
>>> least divering from the user monitor help and texi snippets, QMP bits
>>> are also maintained inside qemu-monitor.hx, and hxtool is extended to
>>> generate a single text file from them.
>>>
>>> Signed-off-by: Jan Kiszka 
>>> Signed-off-by: Luiz Capitulino 
>>> ---
>>>  Makefile|5 +-
>>>  QMP/README  |5 +-
>>>  configure   |4 +
>>>  hxtool  |   44 ++-
>>>  qemu-monitor.hx | 1314 
>>> ++-
>>>  5 files changed, 1367 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 306a1a4..110698e 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -29,7 +29,7 @@ $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
>>>  LIBS+=-lz $(LIBS_TOOLS)
>>>
>>>  ifdef BUILD_DOCS
>>> -DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8
>>> +DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 
>>> QMP/qmp-commands.txt
>>>  else
>>>  DOCS=
>>>  endif
>>> @@ -259,6 +259,9 @@ qemu-options.texi: $(SRC_PATH)/qemu-options.hx
>>>  qemu-monitor.texi: $(SRC_PATH)/qemu-monitor.hx
>>> $(call quiet-command,sh $(SRC_PATH)/hxtool -t < $< > $@,"  GEN   
>>> $@")
>>>
>>> +QMP/qmp-commands.txt: $(SRC_PATH)/qemu-monitor.hx
>>> +   $(call quiet-command,sh $(SRC_PATH)/hxtool -q < $< > $@,"  GEN   
>>> $@")
>>> +
>>>  qemu-img-cmds.texi: $(SRC_PATH)/qemu-img-cmds.hx
>>> $(call quiet-command,sh $(SRC_PATH)/hxtool -t < $< > $@,"  GEN   
>>> $@")
>>>
>>> diff --git a/QMP/README b/QMP/README
>>> index 9334c25..35a80c7 100644
>>> --- a/QMP/README
>>> +++ b/QMP/README
>>> @@ -15,8 +15,9 @@ QMP is JSON[1] based and has the following features:
>>>
>>>  For more information, please, refer to the following files:
>>>
>>> -o qmp-spec.txtQEMU Monitor Protocol current specification
>>> -o qmp-events.txt  List of available asynchronous events
>>> +o qmp-spec.txt  QEMU Monitor Protocol current specification
>>> +o qmp-commands.txt  QMP supported commands
>>> +o qmp-events.txtList of available asynchronous events
>>>
>>>  There are also two simple Python scripts available:
>>>
>>> diff --git a/configure b/configure
>>> index 36d028f..6738e0b 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -2807,3 +2807,7 @@ ln -s $source_path/Makefile.user $d/Makefile
>>>  if test "$static" = "no" -a "$user_pie" = "yes" ; then
>>>echo "QEMU_CFLAGS+=-fpie" > $d/config.mak
>>>  fi
>>> +
>>> +if test "$docs" = "yes" ; then
>>> +  mkdir -p QMP
>>> +fi
>>> diff --git a/hxtool b/hxtool
>>> index 8f65532..d499dc0 100644
>>> --- a/hxtool
>>> +++ b/hxtool
>>> @@ -7,7 +7,7 @@ hxtoh()
>>>  case $str in
>>>  HXCOMM*)
>>>  ;;
>>> -STEXI*|ETEXI*) flag=$(($flag^1))
>>> +STEXI*|ETEXI*|SQMP*|EQMP*) flag=$(($flag^1))
>>>  ;;
>>>  *)
>>>  test $flag -eq 1 && printf "%s\n" "$str"
>>> @@ -38,6 +38,12 @@ hxtotexi()
>>>  fi
>>>  flag=0
>>>  ;;
>>> +SQMP*|EQMP*)
>>> +if test $flag -eq 1 ; then
>>> +echo "line $line: syntax error: expected ETEXI, found 
>>> $str" >&2
>>> +exit 1
>>> +fi
>>> +;;
>>>  DEFHEADING*)
>>>  echo "$(expr "$str" : "DEFHEADING(\(.*\))")"
>>>  ;;
>>> @@ -49,9 +55,45 @@ hxtotexi()
>>>  done
>>>  }
>>>
>>> +hxtoqmp()
>>> +{
>>> +IFS=
>>> +flag=0
>>> +while read -r str; do
>>> +case "$str" in
>>> +HXCOMM*)
>>> +;;
>>> +SQMP*)
>>> +if test $flag -eq 1 ; then
>>> +echo "line $line: syntax error: expected EQMP, found $str" 
>>> >&2
>>> +exit 1
>>> +fi
>>> +flag=1
>>> +;;
>>> +EQMP*)
>>> +if test $flag -ne 1 ; then
>>> +echo "line $line: syntax error: expected SQMP, found $str" 
>>> >&2
>>> +exit 1
>>> +fi
>>> +flag=0
>>> +;;
>>> +STEXI*|ETEXI*)
>>> +if test $flag -eq 1 ; then
>>> +echo "line $line: syntax error: expected EQMP, found $str" 
>>> >&2
>>> +

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Anthony Liguori]

On 05/19/2010 08:19 AM, Michael Tokarev wrote:

Anthony Liguori wrote:
[]
   

For the Bug Day, anything is interesting IMHO.  My main interest is to
get as many people involved in testing and bug fixing as possible.  If
folks are interested in testing specific things like unusual or older
OSes, I'm happy to see it!
 

Well, interesting or not, but I for one don't know what to do with the
results.  There were a thread on kvm@ about sigsegv in cirrus code when
running winNT. The issue has been identified and appears to be fixed,
as in, kvm process does not SIGSEGV anymore, but it does not work anyway,
now printing:

  BUG: kvm_dirty_pages_log_enable_slot: invalid parameters

with garbled guest display.  Thanks goes to Stefano Stabellini for
finding the SIGSEGV case, but unfortunately his hard work isn't quite
useful since the behavour isn't very much different from the previous
version... ;)
   


File a bug in Launchpad.  Even if it isn't fixed immediately, at least 
that way it will not be lost.  Things are too easily lost on the mailing 
list.


Regards,

Anthony Liguori


Also, thanks to Andre Przywara, whole winNT thing works but it requires
-cpu qemu64,level=1 (or level=2 or =3), -- _not_ with default CPU.  This
is also testing, but it's not obvious what to do witht the result...

Thanks!

/mjt

   

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Anthony Liguori]

On 05/19/2010 12:04 AM, Aurelien Jarno wrote:

On Tue, May 18, 2010 at 05:38:27PM -0500, Anthony Liguori wrote:
   

Hi,

In an effort to improve the 0.13 release quality, I'd like to host a
Bug Day on June 1st, 2010.  I've setup a quick wiki page with some
more info (http://wiki.qemu.org/BugDay/June2010).

Here's my basic thinking:

  - Anyone who can should try to spend some time either triaging
bugs, updating bug status, or actually fixing bugs.
  - We'll have a special IRC channel (#qemu-bugday) on OFTC.  As many
QEMU and KVM developers as possible should join this channel for
that day to help assist people working on bugs.
  - We'll try to migrate as many confirmable bugs from the Source
Forge tracker to Launchpad.

If this is successful, we'll try to have regular bug days.  Any
suggestions on how to make the experience as fun and productive as
possible are certainly appreciated!
 

The idea is nice, but would it be possible to hold this on a week-end,
I personally won't be able to attend such thing on a day week.

Or maybe holding that on two days: friday and saturday so that people
can participate at least one of the two days, depending if they do that
from work or from home.
   


The work week in Israel is Sunday - Thursday.

It would have to be Sunday and Monday but honestly, I think both days 
tend to be bad for this sort of thing.


I'd much rather do more frequent bug days and alternate between a 
weekday and a Saturday.


Regards,

Anthony Liguori

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Anthony Liguori]

On 05/18/2010 08:48 PM, Natalia Portillo wrote:


El 19/05/2010, a las 02:45, Jamie Lokier escribió:


Natalia Portillo wrote:

Hi,

- We'll try to migrate as many confirmable bugs from the Source 
Forge tracker to Launchpad.
I think that part of the bug day should also include retesting OSes 
that appear in OS Support List as having bug and confirming if the 
bug is still present and if it's in Launchpad or not.


There have been reports of several legacy OSes being unable to install
or boot in the newer qemu while working in the older one.  They're
probably not in the "OS Support List" though.  Are they effectively
uninteresting for the purpose of the 0.13 release?

There are a couple of.

The majority of them are because SeaBIOS not behaving like real 
hardware should and must do.


If you know any OS that's not in the OS Support List and is broken 
please commit.


If something is broken, please file a bug against it.  The OS Support 
List is a very useful resource but we still need bugs to actually work 
on fixing the problems.


Regards,

Anthony Liguori




Unfortunately I doubt I will have time to participate in the Bug Day.

Thanks,
-- Jamie

Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

[Gerd Hoffmann]

  Hi,


I think the only way to fix this is to handle VT acquire and release
events ourselves.


Hmm.  I suspect sdl and directfb wanna do this too, so I'm not sure this 
will actually work out.



At this point I am not sure if it is worth doing it in the DirectFB
frontend or in the SDL frontend directly (making sure we are not
running on X11 first).


I didn't investigate who is at fault here.  SDL docs doesn't mention 
console switching at all it seems (grep -i console in 
/usr/share/doc/SDL-devel-1.2.13/html doesn't find me anything).  Which 
makes me assume no special actions by the app using SDL are required for 
it.  Which in turn makes me think SDL is broken.


Which makes me think we should just go the direct route.  No SDL.  No 
directfb.  No other funky library which provides us with nothing but 
bugs.  Programming fbdev isn't that hard after all.  Especially if you 
skip all the (IMHO pointless) video mode switching bits.


cheers,
  Gerd

[Qemu-devel] Re: [PATCH 2/3] QMP: Introduce commands documentation

[Luiz Capitulino]

On Wed, 19 May 2010 15:30:43 +0200
Jan Kiszka  wrote:

> Luiz Capitulino wrote:

[...]

> >  I didn't submit the syntax checking bits on purpose, there's something
> > failing there and I didn't want to check it now.
> 
> You already did for QMP, just skipped the STEXI/ETEXI balancing checks.
> And if that reports an error for TEXI, better have a closer look. It
> worked fine with my tree, so something may have regressed.

 Here you go:

"""
GEN   qemu-img-cmds.texi
line 10: syntax error: expected ETEXI, found STEXI
make: *** [qemu-img-cmds.texi] Error 1
make: *** Deleting file `qemu-img-cmds.texi'
"""

 Indeed, looks like a bug in qemu-img-cmds.hx:

"""
STEXI
@table @option
STEXI
"""

Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

[Stefano Stabellini]

On Wed, 19 May 2010, Gerd Hoffmann wrote:
>Hi,
> 
> > I think the only way to fix this is to handle VT acquire and release
> > events ourselves.
> 
> Hmm.  I suspect sdl and directfb wanna do this too, so I'm not sure this 
> will actually work out.
> 
> > At this point I am not sure if it is worth doing it in the DirectFB
> > frontend or in the SDL frontend directly (making sure we are not
> > running on X11 first).
> 
> I didn't investigate who is at fault here.  SDL docs doesn't mention 
> console switching at all it seems (grep -i console in 
> /usr/share/doc/SDL-devel-1.2.13/html doesn't find me anything).  Which 
> makes me assume no special actions by the app using SDL are required for 
> it.  Which in turn makes me think SDL is broken.
> 
> Which makes me think we should just go the direct route.  No SDL.  No 
> directfb.  No other funky library which provides us with nothing but 
> bugs.  Programming fbdev isn't that hard after all.  Especially if you 
> skip all the (IMHO pointless) video mode switching bits.
 
Agreed, actually I was thinking the same thing.
The only reason for using a library is to have the color/pixel conversion
functions, that could be useful. However we have many of them already
implemented in qemu so it shouldn't be difficult to roll our own.

Julian, what do you think?

[Qemu-devel] Re: [PATCH 2/3] QMP: Introduce commands documentation

[Jan Kiszka]

Luiz Capitulino wrote:
> On Wed, 19 May 2010 15:30:43 +0200
> Jan Kiszka  wrote:
> 
>> Luiz Capitulino wrote:
> 
> [...]
> 
>>>  I didn't submit the syntax checking bits on purpose, there's something
>>> failing there and I didn't want to check it now.
>> You already did for QMP, just skipped the STEXI/ETEXI balancing checks.
>> And if that reports an error for TEXI, better have a closer look. It
>> worked fine with my tree, so something may have regressed.
> 
>  Here you go:
> 
> """
> GEN   qemu-img-cmds.texi
> line 10: syntax error: expected ETEXI, found STEXI
> make: *** [qemu-img-cmds.texi] Error 1
> make: *** Deleting file `qemu-img-cmds.texi'
> """
> 
>  Indeed, looks like a bug in qemu-img-cmds.hx:
> 
> """
> STEXI
> @table @option
> STEXI
> """

Oh, then I also did no "make clean all" run with my patch applied that
night... :] Still, good to know that it works. I can handle this if you
don't want to.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

[Qemu-devel] Re: [PATCH 2/3] QMP: Introduce commands documentation

[Luiz Capitulino]

On Wed, 19 May 2010 15:50:56 +0200
Jan Kiszka  wrote:

> Luiz Capitulino wrote:
> > On Wed, 19 May 2010 15:30:43 +0200
> > Jan Kiszka  wrote:
> > 
> >> Luiz Capitulino wrote:
> > 
> > [...]
> > 
> >>>  I didn't submit the syntax checking bits on purpose, there's something
> >>> failing there and I didn't want to check it now.
> >> You already did for QMP, just skipped the STEXI/ETEXI balancing checks.
> >> And if that reports an error for TEXI, better have a closer look. It
> >> worked fine with my tree, so something may have regressed.
> > 
> >  Here you go:
> > 
> > """
> > GEN   qemu-img-cmds.texi
> > line 10: syntax error: expected ETEXI, found STEXI
> > make: *** [qemu-img-cmds.texi] Error 1
> > make: *** Deleting file `qemu-img-cmds.texi'
> > """
> > 
> >  Indeed, looks like a bug in qemu-img-cmds.hx:
> > 
> > """
> > STEXI
> > @table @option
> > STEXI
> > """
> 
> Oh, then I also did no "make clean all" run with my patch applied that
> night... :] Still, good to know that it works. I can handle this if you
> don't want to.

 Please do, you could send both patches in the same series (ie. fix and
feature), so that we don't break the build.

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Natalia Portillo]

Hi,

>>> There have been reports of several legacy OSes being unable to install
>>> or boot in the newer qemu while working in the older one.  They're
>>> probably not in the "OS Support List" though.  Are they effectively
>>> uninteresting for the purpose of the 0.13 release?
>>> 
> 
> For the Bug Day, anything is interesting IMHO.  My main interest is to get as 
> many people involved in testing and bug fixing as possible.  If folks are 
> interested in testing specific things like unusual or older OSes, I'm happy 
> to see it!

Well the idea is not only about unusual or older OSes.
That list detected bugs and regressions appearing in usual and new OSes (for 
example the infamous SeaBIOS problem with Windows 9x and mouse also affects 
freshly and new OpenSuSE Linux 11.2).

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Natalia Portillo]

Hi,

>> There are a couple of.
>> 
>> The majority of them are because SeaBIOS not behaving like real hardware 
>> should and must do.
>> 
>> If you know any OS that's not in the OS Support List and is broken please 
>> commit.
> 
> If something is broken, please file a bug against it.  The OS Support List is 
> a very useful resource but we still need bugs to actually work on fixing the 
> problems.
The OS Support List clearly specifies that in case of a fail, bug, or non 
working case, a bug should be filled, so I think, using the OS Support List 
includes bugs in Launchpad, however the reverse is not true.

[Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Riccardo Magliocchetti]

Hello,

i have quite a few free time in these days so i've anticipated the bug 
day and started looking for some low hanging fruit. I've found a couple 
of sf.net bugs that are obsoleted / fixed:


- Compilation fails when configure with -DDEBUG #1945129 : code has been 
updated and the issue is not valid anymore, compiles fine with -DDEBUG


- KVM doesn't compiles due to bug in "configure" script #1830975 : fixed 
in ac62922e7295acd0cdc2824472ae91c31917359b


thanks,
riccardo

[Qemu-devel] [PATCH v2 0/6] MIPS: Initial support for fulong (Loongson-2E based) mini pc

[chen huacai]

Change from v1:
1, fulong support is limited to mips64el only (doesn't affect mips,
mips64 and mipsel)
2, qdev model is used for Bonito north bridge
3, code style and other errors have been fixed

This series of patches are for qemu master branch. They make qemu
initially support fulong (Loongson-2E based) mini pc, a new type of
MIPS machine.
Usage:
 1, Load PMON as bios, and then load OS in PMON shell
   qemu-system-mips64el -M fulong2e -bios pmon_fulong2e.bin -hda /root/hda.img
 2, Load OS directly with -kernel parameter
   qemu-system-mips64el -M fulong2e -kernel vmlinux -append
"root=/dev/hda1 console=ttyS0" -hda /root/hda.img

Patches include:
[PATCH 1/6] MIPS: Initial support of bonito north bridge used by fulong mini pc
[PATCH 2/6] MIPS: Initial support of vt82686b south bridge used by
fulong mini pc
[PATCH 3/6] MIPS: Initial support of VIA IDE controller used by fulong mini pc
[PATCH 4/6] MIPS: Initial support of VIA USB controller used by fulong mini pc
[PATCH 5/6] MIPS: Initial support of fulong mini pc (CPU definition,
machine construction, etc.)
[PATCH 6/6] MIPS: add PMON (binary file) used by fulong mini pc

Signed-off-by: Huacai Chen 

[Qemu-devel] [PATCH v2 1/6] MIPS: Initial support of bonito north bridge used by fulong mini pc

[Huacai Chen]

Signed-off-by: Huacai Chen 
---
 Makefile.target  |1 +
 default-configs/mips64el-softmmu.mak |1 +
 hw/bonito.c  |  950 ++
 hw/mips.h|3 +
 4 files changed, 955 insertions(+), 0 deletions(-)
 create mode 100644 hw/bonito.c

diff --git a/Makefile.target b/Makefile.target
index a22484e..247a2eb 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -221,6 +221,7 @@ obj-mips-y += dma.o vga.o i8259.o
 obj-mips-y += g364fb.o jazz_led.o
 obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
 obj-mips-y += piix4.o cirrus_vga.o
+obj-mips-$(CONFIG_FULONG) += bonito.o
 
 obj-microblaze-y = petalogix_s3adsp1800_mmu.o
 
diff --git a/default-configs/mips64el-softmmu.mak 
b/default-configs/mips64el-softmmu.mak
index 6fa54a3..b731c74 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -27,3 +27,4 @@ CONFIG_DP8393X=y
 CONFIG_DS1225Y=y
 CONFIG_MIPSNET=y
 CONFIG_PFLASH_CFI01=y
+CONFIG_FULONG=y
diff --git a/hw/bonito.c b/hw/bonito.c
new file mode 100644
index 000..246c12a
--- /dev/null
+++ b/hw/bonito.c
@@ -0,0 +1,950 @@
+/*
+ * bonito north bridge support
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ *
+ * This code is licensed under the GNU GPL v2.
+ */
+
+/*
+ * fulong 2e mini pc has a bonito north bridge.
+ */
+
+/* what is the meaning of devfn in qemu and IDSEL in bonito northbridge?
+ *
+ * devfn   pci_slot<<3  + funno
+ * one pci bus can have 32 devices and each device can have 8 functions.
+ *
+ * In bonito north bridge, pci slot = IDSEL bit - 12.
+ * For example, PCI_IDSEL_VIA686B = 17,
+ * pci slot = 17-12=5
+ *
+ * so
+ * VT686B_FUN0's devfn = (5<<3)+0
+ * VT686B_FUN1's devfn = (5<<3)+1
+ *
+ * qemu also uses pci address for north bridge to access pci config register.
+ * bus_no   [23:16]
+ * dev_no   [15:11]
+ * fun_no   [10:8]
+ * reg_no   [7:2]
+ *
+ * so function bonito_sbridge_pciaddr for the translation from
+ * north bridge address to pci address.
+ */
+
+#include 
+
+#include "hw.h"
+#include "pci.h"
+#include "pc.h"
+#include "mips.h"
+
+typedef target_phys_addr_t pci_addr_t;
+#include "pci_host.h"
+
+//#define DEBUG_BONITO
+
+#ifdef DEBUG_BONITO
+#define DPRINTF(fmt, ...) fprintf(stderr, "%s: " fmt, __FUNCTION__, 
##__VA_ARGS__)
+#else
+#define DPRINTF(fmt, ...)
+#endif
+
+/* from linux soure code. include/asm-mips/mips-boards/bonito64.h*/
+#define BONITO_BOOT_BASE0x1fc0
+#define BONITO_BOOT_SIZE0x0010
+#define BONITO_BOOT_TOP (BONITO_BOOT_BASE+BONITO_BOOT_SIZE-1)
+#define BONITO_FLASH_BASE   0x1c00
+#define BONITO_FLASH_SIZE   0x0300
+#define BONITO_FLASH_TOP(BONITO_FLASH_BASE+BONITO_FLASH_SIZE-1)
+#define BONITO_SOCKET_BASE  0x1f80
+#define BONITO_SOCKET_SIZE  0x0040
+#define BONITO_SOCKET_TOP   (BONITO_SOCKET_BASE+BONITO_SOCKET_SIZE-1)
+#define BONITO_REG_BASE 0x1fe0
+#define BONITO_REG_SIZE 0x0004
+#define BONITO_REG_TOP  (BONITO_REG_BASE+BONITO_REG_SIZE-1)
+#define BONITO_DEV_BASE 0x1ff0
+#define BONITO_DEV_SIZE 0x0010
+#define BONITO_DEV_TOP  (BONITO_DEV_BASE+BONITO_DEV_SIZE-1)
+#define BONITO_PCILO_BASE   0x1000
+#define BONITO_PCILO_BASE_VA0xb000
+#define BONITO_PCILO_SIZE   0x0c00
+#define BONITO_PCILO_TOP(BONITO_PCILO_BASE+BONITO_PCILO_SIZE-1)
+#define BONITO_PCILO0_BASE  0x1000
+#define BONITO_PCILO1_BASE  0x1400
+#define BONITO_PCILO2_BASE  0x1800
+#define BONITO_PCIHI_BASE   0x2000
+#define BONITO_PCIHI_SIZE   0x2000
+#define BONITO_PCIHI_TOP(BONITO_PCIHI_BASE+BONITO_PCIHI_SIZE-1)
+#define BONITO_PCIIO_BASE   0x1fd0
+#define BONITO_PCIIO_BASE_VA0xbfd0
+#define BONITO_PCIIO_SIZE   0x0001
+#define BONITO_PCIIO_TOP(BONITO_PCIIO_BASE+BONITO_PCIIO_SIZE-1)
+#define BONITO_PCICFG_BASE  0x1fe8
+#define BONITO_PCICFG_SIZE  0x0008
+#define BONITO_PCICFG_TOP   (BONITO_PCICFG_BASE+BONITO_PCICFG_SIZE-1)
+
+
+#define BONITO_PCICONFIGBASE0x00
+#define BONITO_REGBASE  0x100
+
+#define BONITO_PCICONFIG_BASE   (BONITO_PCICONFIGBASE+BONITO_REG_BASE)
+#define BONITO_PCICONFIG_SIZE   (0x100)
+
+#define BONITO_INTERNAL_REG_BASE  (BONITO_REGBASE+BONITO_REG_BASE)
+#define BONITO_INTERNAL_REG_SIZE  (0x70)
+
+#define BONITO_SPCICONFIG_BASE  (BONITO_PCICFG_BASE)
+#define BONITO_SPCICONFIG_SIZE  (BONITO_PCICFG_SIZE)
+
+
+
+/* 1. Bonito h/w Configuration */
+/* Power on register */
+
+#define BONITO_BONPONCFG(0x00 >> 2)  /* 0x100 */
+#define BONITO_BONGENCFG_OFFSET 0x4
+#define BONITO_BONGENCFG(BONITO_BONGENCFG_OFFSET>>2)   /*0x104 */
+
+/* 2. IO & IDE configuration */
+#define BONITO_IODEVCFG (0x08 >> 2)  /* 0x108 */
+
+/* 3. IO & IDE configuration */
+#define BONITO_SDCFG(0x0c 

[Qemu-devel] [PATCH v2 2/6] MIPS: Initial support of vt82686b south bridge used by fulong mini pc

[Huacai Chen]

Signed-off-by: Huacai Chen 
---
 Makefile.target |2 +-
 hw/pc.h |7 +
 hw/pci_ids.h|8 +
 hw/vt82c686.c   |  786 +++
 4 files changed, 802 insertions(+), 1 deletions(-)
 create mode 100644 hw/vt82c686.c

diff --git a/Makefile.target b/Makefile.target
index 247a2eb..9ed4a8d 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -221,7 +221,7 @@ obj-mips-y += dma.o vga.o i8259.o
 obj-mips-y += g364fb.o jazz_led.o
 obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
 obj-mips-y += piix4.o cirrus_vga.o
-obj-mips-$(CONFIG_FULONG) += bonito.o
+obj-mips-$(CONFIG_FULONG) += bonito.o vt82c686.o
 
 obj-microblaze-y = petalogix_s3adsp1800_mmu.o
 
diff --git a/hw/pc.h b/hw/pc.h
index 654b7b3..7f0730b 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -143,6 +143,13 @@ void i440fx_init_memory_mappings(PCII440FXState *d);
 extern PCIDevice *piix4_dev;
 int piix4_init(PCIBus *bus, int devfn);
 
+/* vt82c686.c */
+int vt82c686b_init(PCIBus * bus, int devfn);
+void vt82c686b_ac97_init(PCIBus *bus, int devfn);
+void vt82c686b_mc97_init(PCIBus *bus, int devfn);
+i2c_bus *vt82c686b_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
+qemu_irq sci_irq);
+
 /* vga.c */
 enum vga_retrace_method {
 VGA_RETRACE_DUMB,
diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index fe7a121..39e9f1d 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -78,6 +78,14 @@
 
 #define PCI_VENDOR_ID_XILINX 0x10ee
 
+#define PCI_VENDOR_ID_VIA0x1106
+#define PCI_DEVICE_ID_VIA_ISA_BRIDGE 0x0686
+#define PCI_DEVICE_ID_VIA_IDE0x0571
+#define PCI_DEVICE_ID_VIA_UHCI   0x3038
+#define PCI_DEVICE_ID_VIA_ACPI   0x3057
+#define PCI_DEVICE_ID_VIA_AC97   0x3058
+#define PCI_DEVICE_ID_VIA_MC97   0x3068
+
 #define PCI_VENDOR_ID_MARVELL0x11ab
 
 #define PCI_VENDOR_ID_ENSONIQ0x1274
diff --git a/hw/vt82c686.c b/hw/vt82c686.c
new file mode 100644
index 000..1045467
--- /dev/null
+++ b/hw/vt82c686.c
@@ -0,0 +1,786 @@
+/*
+ * VT82C686B south bridge support
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2009 chenming (chenm...@rdc.faw.com.cn)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ * This code is licensed under the GNU GPL v2.
+ */
+
+#include "hw.h"
+#include "pc.h"
+#include "i2c.h"
+#include "smbus.h"
+#include "pci.h"
+#include "isa.h"
+#include "sysbus.h"
+#include "mips.h"
+
+typedef uint32_t pci_addr_t;
+#include "pci_host.h"
+//#define DEBUG_VT82C686B
+
+#ifdef DEBUG_VT82C686B
+#define DPRINTF(fmt, ...) fprintf(stderr, "%s: " fmt, __FUNCTION__, 
##__VA_ARGS__)
+#else
+#define DPRINTF(fmt, ...)
+#endif
+
+typedef struct SuperIOConfig
+{
+uint8_t config[0xff];
+uint8_t index;
+uint8_t data;
+} SuperIOConfig;
+
+typedef struct VT82C686BState {
+PCIDevice dev;
+SuperIOConfig *superio_conf;
+} VT82C686BState;
+
+uint32_t smb_data[16];
+static void superio_ioport_writeb(void *opaque, uint32_t addr, uint32_t data)
+{
+int can_write;
+SuperIOConfig *superio_conf = (SuperIOConfig *)opaque;
+
+DPRINTF("superio_ioport_writeb  address 0x%x  val 0x%x  \n", addr, data);
+if (addr == 0x3f0) {
+superio_conf->index = data & 0xff;
+} else {
+/* 0x3f1 */
+switch (superio_conf->index) {
+case 0x00 ... 0xdf:
+case 0xe4:
+case 0xe5:
+case 0xe9 ... 0xed:
+case 0xf3:
+case 0xf5:
+case 0xf7:
+case 0xf9 ... 0xfb:
+case 0xfd ... 0xff:
+can_write = 0;
+break;
+default:
+can_write = 1;
+
+if (can_write) {
+switch (superio_conf->index) {
+case 0xe7:
+if ((data & 0xff) != 0xfe) {
+DPRINTF("chage uart 1 base. unsupported yet \n");
+}
+break;
+case 0xe8:
+if ((data & 0xff) != 0xbe) {
+DPRINTF("chage uart 2 base. unsupported yet \n");
+}
+break;
+
+default:
+superio_conf->config[superio_conf->index] = data & 0xff;
+}
+}
+}
+superio_conf->config[superio_conf->index] = data & 0xff;
+}
+}
+
+static uint32_t superio_ioport_readb(void *opaque, uint32_t addr)
+{
+SuperIOConfig *superio_conf = (SuperIOConfig *)opaque;
+
+DPRINTF("superio_ioport_readb  address 0x%x   \n", addr);
+return (superio_conf->config[superio_conf->index]);
+}
+
+static void vt82c686b_reset(void * opaque)
+{
+PCIDevice *d = opaque;
+uint8_t *pci_conf = d->config;
+VT82C686BState *vt82c = DO_UPCAST(VT82C686BState, dev, d);
+
+pci_set_long(pci_conf + PCI_CAPABILITY_LIST, 0x00c0);
+
+pci_conf[0x04] = 0x87; /* master, memory, I/O and special */
+pci_conf[0x05] = 0x00;
+pci_conf[0x06] = 0x00;
+pci_con

[Qemu-devel] [PATCH v2 3/6] MIPS: Initial support of VIA IDE controller used by fulong mini pc

[Huacai Chen]

Signed-off-by: Huacai Chen 
---
 Makefile.objs|1 +
 default-configs/mips64el-softmmu.mak |1 +
 hw/ide.h |1 +
 hw/ide/via.c |  185 ++
 4 files changed, 188 insertions(+), 0 deletions(-)
 create mode 100644 hw/ide/via.c

diff --git a/Makefile.objs b/Makefile.objs
index acbaf22..3291e3a 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -196,6 +196,7 @@ hw-obj-$(CONFIG_IDE_ISA) += ide/isa.o
 hw-obj-$(CONFIG_IDE_PIIX) += ide/piix.o
 hw-obj-$(CONFIG_IDE_CMD646) += ide/cmd646.o
 hw-obj-$(CONFIG_IDE_MACIO) += ide/macio.o
+hw-obj-$(CONFIG_IDE_VIA) += ide/via.o
 
 # SCSI layer
 hw-obj-y += lsi53c895a.o
diff --git a/default-configs/mips64el-softmmu.mak 
b/default-configs/mips64el-softmmu.mak
index b731c74..bf19577 100644
--- a/default-configs/mips64el-softmmu.mak
+++ b/default-configs/mips64el-softmmu.mak
@@ -19,6 +19,7 @@ CONFIG_IDE_QDEV=y
 CONFIG_IDE_PCI=y
 CONFIG_IDE_ISA=y
 CONFIG_IDE_PIIX=y
+CONFIG_IDE_VIA=y
 CONFIG_NE2000_ISA=y
 CONFIG_SOUND=y
 CONFIG_VIRTIO_PCI=y
diff --git a/hw/ide.h b/hw/ide.h
index 0e7d540..bb635b6 100644
--- a/hw/ide.h
+++ b/hw/ide.h
@@ -12,6 +12,7 @@ void pci_cmd646_ide_init(PCIBus *bus, DriveInfo **hd_table,
  int secondary_ide_enabled);
 void pci_piix3_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn);
 void pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn);
+void vt82c686b_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn);
 
 /* ide-macio.c */
 int pmac_ide_init (DriveInfo **hd_table, qemu_irq irq,
diff --git a/hw/ide/via.c b/hw/ide/via.c
new file mode 100644
index 000..33a0b90
--- /dev/null
+++ b/hw/ide/via.c
@@ -0,0 +1,185 @@
+/*
+ * QEMU IDE Emulation: PCI VIA82C686B support.
+ *
+ * Copyright (c) 2003 Fabrice Bellard
+ * Copyright (c) 2006 Openedhand Ltd.
+ * Copyright (c) 2010 Huacai Chen 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include "block.h"
+#include "block_int.h"
+#include "sysemu.h"
+#include "dma.h"
+
+#include 
+
+static uint32_t bmdma_readb(void *opaque, uint32_t addr)
+{
+BMDMAState *bm = opaque;
+uint32_t val;
+
+switch (addr & 3) {
+case 0:
+val = bm->cmd;
+break;
+case 2:
+val = bm->status;
+break;
+default:
+val = 0xff;
+break;
+}
+#ifdef DEBUG_IDE
+printf("bmdma: readb 0x%02x : 0x%02x\n", addr, val);
+#endif
+return val;
+}
+
+static void bmdma_writeb(void *opaque, uint32_t addr, uint32_t val)
+{
+BMDMAState *bm = opaque;
+#ifdef DEBUG_IDE
+printf("bmdma: writeb 0x%02x : 0x%02x\n", addr, val);
+#endif
+switch (addr & 3) {
+case 2:
+bm->status = (val & 0x60) | (bm->status & 1) | (bm->status & ~val & 
0x06);
+break;
+default:;
+}
+}
+
+static void bmdma_map(PCIDevice *pci_dev, int region_num,
+pcibus_t addr, pcibus_t size, int type)
+{
+PCIIDEState *d = DO_UPCAST(PCIIDEState, dev, pci_dev);
+int i;
+
+for(i = 0;i < 2; i++) {
+BMDMAState *bm = &d->bmdma[i];
+d->bus[i].bmdma = bm;
+bm->bus = d->bus+i;
+qemu_add_vm_change_state_handler(ide_dma_restart_cb, bm);
+
+register_ioport_write(addr, 1, 1, bmdma_cmd_writeb, bm);
+
+register_ioport_write(addr + 1, 3, 1, bmdma_writeb, bm);
+register_ioport_read(addr, 4, 1, bmdma_readb, bm);
+
+register_ioport_write(addr + 4, 4, 1, bmdma_addr_writeb, bm);
+register_ioport_read(addr + 4, 4, 1, bmdma_addr_readb, bm);
+register_ioport_write(addr + 4, 4, 2, bmdma_addr_writew, bm);
+register_ioport_read(addr + 4, 4, 2, bmdma_addr_readw, bm);
+register_ioport_write(addr + 4, 4, 4, bmdma_addr_writel, bm);
+register_ioport_read(addr + 4, 4, 4, bmdma_addr_readl, bm);
+addr += 8;
+}
+}
+
+static void via_reset(void *opaqu

[Qemu-devel] [PATCH v2 4/6] MIPS: Initial support of VIA USB controller used by fulong mini pc

[Huacai Chen]

Signed-off-by: Huacai Chen 
---
 hw/usb-uhci.c |   30 ++
 hw/usb-uhci.h |1 +
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 624d55b..5fd5388 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -1152,6 +1152,26 @@ static int usb_uhci_piix4_initfn(PCIDevice *dev)
 return usb_uhci_common_initfn(s);
 }
 
+static int usb_uhci_vt82c686b_initfn(PCIDevice *dev)
+{
+UHCIState *s = DO_UPCAST(UHCIState, dev, dev);
+uint8_t *pci_conf = s->dev.config;
+
+pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_VIA);
+pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_VIA_UHCI);
+
+pci_set_long(pci_conf + 0x0c,0x1600);
+pci_set_long(pci_conf + 0x20,0x0301);
+pci_set_long(pci_conf + 0x34,0x1080);
+pci_set_long(pci_conf + 0x3c,0x0004);
+pci_set_long(pci_conf + 0x40,0x1000);
+pci_set_long(pci_conf + 0x60,0x0010);
+pci_set_long(pci_conf + 0x80,0x00020001);
+pci_set_long(pci_conf + 0xc0,0x2000);
+
+return usb_uhci_common_initfn(s);
+}
+
 static PCIDeviceInfo uhci_info[] = {
 {
 .qdev.name= "piix3-usb-uhci",
@@ -1164,6 +1184,11 @@ static PCIDeviceInfo uhci_info[] = {
 .qdev.vmsd= &vmstate_uhci,
 .init = usb_uhci_piix4_initfn,
 },{
+.qdev.name= "vt82c686b-usb-uhci",
+.qdev.size= sizeof(UHCIState),
+.qdev.vmsd= &vmstate_uhci,
+.init = usb_uhci_vt82c686b_initfn,
+},{
 /* end of list */
 }
 };
@@ -1183,3 +1208,8 @@ void usb_uhci_piix4_init(PCIBus *bus, int devfn)
 {
 pci_create_simple(bus, devfn, "piix4-usb-uhci");
 }
+
+void usb_uhci_vt82c686b_init(PCIBus *bus, int devfn)
+{
+pci_create_simple(bus, devfn, "vt82c686b-usb-uhci");
+}
diff --git a/hw/usb-uhci.h b/hw/usb-uhci.h
index 911948e..3e4d377 100644
--- a/hw/usb-uhci.h
+++ b/hw/usb-uhci.h
@@ -5,5 +5,6 @@
 
 void usb_uhci_piix3_init(PCIBus *bus, int devfn);
 void usb_uhci_piix4_init(PCIBus *bus, int devfn);
+void usb_uhci_vt82c686b_init(PCIBus *bus, int devfn);
 
 #endif
-- 
1.7.0.4

[Qemu-devel] [PATCH v2 5/6] MIPS: Initial support of fulong mini pc (CPU definition, machine construction, etc.)

[Huacai Chen]

Signed-off-by: Huacai Chen 
---
 Makefile.target  |2 +-
 hw/mips_fulong2e.c   |  421 ++
 target-mips/translate_init.c |   35 
 3 files changed, 457 insertions(+), 1 deletions(-)
 create mode 100644 hw/mips_fulong2e.c

diff --git a/Makefile.target b/Makefile.target
index 9ed4a8d..db4badd 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -221,7 +221,7 @@ obj-mips-y += dma.o vga.o i8259.o
 obj-mips-y += g364fb.o jazz_led.o
 obj-mips-y += gt64xxx.o pckbd.o mc146818rtc.o
 obj-mips-y += piix4.o cirrus_vga.o
-obj-mips-$(CONFIG_FULONG) += bonito.o vt82c686.o
+obj-mips-$(CONFIG_FULONG) += bonito.o vt82c686.o mips_fulong2e.o
 
 obj-microblaze-y = petalogix_s3adsp1800_mmu.o
 
diff --git a/hw/mips_fulong2e.c b/hw/mips_fulong2e.c
new file mode 100644
index 000..3e6ed7e
--- /dev/null
+++ b/hw/mips_fulong2e.c
@@ -0,0 +1,421 @@
+/*
+ * QEMU fulong 2e mini pc support
+ *
+ * Copyright (c) 2008 yajin (ya...@vm-kernel.org)
+ * Copyright (c) 2009 chenming (chenm...@rdc.faw.com.cn)
+ * Copyright (c) 2010 Huacai Chen (zltjiang...@gmail.com)
+ * This code is licensed under the GNU GPL v2.
+ */
+
+/*
+ * Fulong 2e mini pc is based on ICT/ST Loongson 2e CPU (MIPS III like, 800MHz)
+ * http://www.linux-mips.org/wiki/Fulong
+ *
+ * Loongson 2e user manual:
+ * http://www.loongsondeveloper.com/doc/Loongson2EUserGuide.pdf
+ */
+
+#include "hw.h"
+#include "pc.h"
+#include "fdc.h"
+#include "net.h"
+#include "boards.h"
+#include "smbus.h"
+#include "block.h"
+#include "flash.h"
+#include "mips.h"
+#include "mips_cpudevs.h"
+#include "pci.h"
+#include "usb-uhci.h"
+#include "qemu-char.h"
+#include "sysemu.h"
+#include "audio/audio.h"
+#include "qemu-log.h"
+#include "loader.h"
+#include "mips-bios.h"
+#include "ide.h"
+#include "elf.h"
+#include "mc146818rtc.h"
+
+#define DEBUG_FULONG2E_INIT
+
+#define ENVP_ADDR   0x80002000l
+#define ENVP_NB_ENTRIES16
+#define ENVP_ENTRY_SIZE256
+
+#define MAX_IDE_BUS 2
+
+/* PCI SLOT in fulong 2e */
+#define FULONG2E_VIA_SLOT5
+#define FULONG2E_ATI_SLOT6
+#define FULONG2E_RTL8139_SLOT7
+
+static PITState *pit;
+
+static struct _loaderparams {
+int ram_size;
+const char *kernel_filename;
+const char *kernel_cmdline;
+const char *initrd_filename;
+} loaderparams;
+
+static void mips_qemu_writel (void *opaque, target_phys_addr_t addr,
+ uint32_t val)
+{
+if ((addr & 0x) == 0 && val == 42)
+qemu_system_reset_request ();
+else if ((addr & 0x) == 4 && val == 42)
+qemu_system_shutdown_request ();
+}
+
+static uint32_t mips_qemu_readl (void *opaque, target_phys_addr_t addr)
+{
+return 0;
+}
+
+static CPUWriteMemoryFunc *mips_qemu_write[] = {
+mips_qemu_writel,
+mips_qemu_writel,
+mips_qemu_writel,
+};
+
+static CPUReadMemoryFunc *mips_qemu_read[] = {
+mips_qemu_readl,
+mips_qemu_readl,
+mips_qemu_readl,
+};
+static int mips_qemu_iomemtype = 0;
+
+static void prom_set(uint32_t* prom_buf, int index, const char *string, ...)
+{
+va_list ap;
+int32_t table_addr;
+
+if (index >= ENVP_NB_ENTRIES)
+return;
+
+if (string == NULL) {
+prom_buf[index] = 0;
+return;
+}
+
+table_addr = sizeof(int32_t) * ENVP_NB_ENTRIES + index * ENVP_ENTRY_SIZE;
+prom_buf[index] = tswap32(ENVP_ADDR + table_addr);
+
+va_start(ap, string);
+vsnprintf((char *)prom_buf + table_addr, ENVP_ENTRY_SIZE, string, ap);
+va_end(ap);
+}
+
+static int64_t load_kernel (CPUState *env)
+{
+int64_t kernel_entry, kernel_low, kernel_high;
+int index = 0;
+long initrd_size;
+ram_addr_t initrd_offset;
+uint32_t *prom_buf;
+long prom_size;
+
+if (load_elf(loaderparams.kernel_filename, cpu_mips_kseg0_to_phys, NULL,
+ (uint64_t *)&kernel_entry, (uint64_t *)&kernel_low,
+ (uint64_t *)&kernel_high, 0, ELF_MACHINE, 1) < 0) {
+fprintf(stderr, "qemu: could not load kernel '%s'\n",
+loaderparams.kernel_filename);
+exit(1);
+}
+
+/* load initrd */
+initrd_size = 0;
+initrd_offset = 0;
+if (loaderparams.initrd_filename) {
+initrd_size = get_image_size (loaderparams.initrd_filename);
+if (initrd_size > 0) {
+initrd_offset = (kernel_high + ~TARGET_PAGE_MASK) & 
TARGET_PAGE_MASK;
+if (initrd_offset + initrd_size > ram_size) {
+fprintf(stderr,
+"qemu: memory too small for initial ram disk '%s'\n",
+loaderparams.initrd_filename);
+exit(1);
+}
+initrd_size = load_image_targphys(loaderparams.initrd_filename,
+ initrd_offset, ram_size - initrd_offset);
+}
+if (initrd_size == (target_ulong) -1) {
+fprintf(stderr, "qemu: could not load initial ram disk '%s'\n",
+  

[Qemu-devel] Re: [PATCH 0/3] Fix ADDX compilation plus improvements, v2

[Richard Henderson]

http://lists.nongnu.org/archive/html/qemu-devel/2010-05/msg00922.html

I would appreciate it if you would at least apply the first patch
from this series.  The sparc target has been broken for a week.

  CCsparc64-softmmu/translate.o
/home/rth/qemu/qemu/target-sparc/translate.c: In function 'gen_op_addxi_cc':
/home/rth/qemu/qemu/target-sparc/translate.c:337: error: incompatible type for 
argument 1 of 'gen_helper_compute_C_icc'
/home/rth/qemu/qemu/target-sparc/translate.c: In function 'gen_op_addx_cc':
/home/rth/qemu/qemu/target-sparc/translate.c:347: error: incompatible type for 
argument 1 of 'gen_helper_compute_C_icc'
/home/rth/qemu/qemu/target-sparc/translate.c: In function 'gen_op_subxi_cc':
/home/rth/qemu/qemu/target-sparc/translate.c:420: error: incompatible type for 
argument 1 of 'gen_helper_compute_C_icc'
/home/rth/qemu/qemu/target-sparc/translate.c: In function 'gen_op_subx_cc':
/home/rth/qemu/qemu/target-sparc/translate.c:430: error: incompatible type for 
argument 1 of 'gen_helper_compute_C_icc'
/home/rth/qemu/qemu/target-sparc/translate.c: In function 'disas_sparc_insn':
/home/rth/qemu/qemu/target-sparc/translate.c:2960: error: incompatible type for 
argument 1 of 'gen_helper_compute_C_icc'
/home/rth/qemu/qemu/target-sparc/translate.c:2970: error: incompatible type for 
argument 1 of 'gen_helper_compute_C_icc'
/home/rth/qemu/qemu/target-sparc/translate.c:3012: error: incompatible type for 
argument 1 of 'gen_helper_compute_C_icc'
/home/rth/qemu/qemu/target-sparc/translate.c:3022: error: incompatible type for 
argument 1 of 'gen_helper_compute_C_icc'
make[1]: *** [translate.o] Error 1



r~

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Luiz Capitulino]

On Tue, 18 May 2010 17:38:27 -0500
Anthony Liguori  wrote:

> Hi,
> 
> In an effort to improve the 0.13 release quality, I'd like to host a Bug 
> Day on June 1st, 2010.  I've setup a quick wiki page with some more info 
> (http://wiki.qemu.org/BugDay/June2010).

 Tuesday is our call conf day and other people have reported that they have
more confs during that day. Suggest Jun 2.

> Here's my basic thinking:
> 
>   - Anyone who can should try to spend some time either triaging bugs, 
> updating bug status, or actually fixing bugs.

 And testing, Fedora has a number of test cases already written, but
I guess that just a few are qemu specific:

https://fedoraproject.org/wiki/Test_Day:2010-04-08_Virtualization

 We could link those and write our own, or at least list the major
features to be tested..

 Of course we could have a different day for testing too, but I think
this is a way to get everyone busy.

>   - We'll have a special IRC channel (#qemu-bugday) on OFTC.  As many 
> QEMU and KVM developers as possible should join this channel for that 
> day to help assist people working on bugs.
>   - We'll try to migrate as many confirmable bugs from the Source Forge 
> tracker to Launchpad.

 Can't this be automated?

> If this is successful, we'll try to have regular bug days.  Any 
> suggestions on how to make the experience as fun and productive as 
> possible are certainly appreciated!

 Lots of foods and a Monty Python session in the evening.

[Qemu-devel] Reporting unknown keycodes...

[Seth Goldberg]

Hi,

 With qemu 0.12.4 (and earier revisions), I see:
unknown keycodes `sun(type6_usb)_aliases(qwerty)', please report to 
qemu-devel@nongnu.org

  Let me know if you need anything further.

 Thanks,
 --S

[Qemu-devel] Re: [PATCH 10/12] kvm: enable smp > 1

[Udo Lembke]

Jan Kiszka schrieb:

...
--enable-io-thread?

If you had it disabled, it would also answer my question if -smp works
without problems without that feature.

Jan

  

Hi,
i have a dumb question: what is the "--enable-io-thread"? Is this a 
kvm-switch?
My kvm 0.12.4 don't accept this switch. I'm know only "threads=n" as 
smp-parameter and "aio=threads" as drive-parameter.


Because i look for a solution for a better io-performance of 
windows-guest with more than one cpu...


best regards

Udo



smime.p7s
Description: S/MIME Cryptographic Signature

[Qemu-devel] Update the http configuration on git.qemu.org

[Bernhard Kohl]

Hi,

could you please run "git update-server-info" on the server
and enable the hooks? At least seabios.git and vgabios.git
cannot be accessed via http://.

And the cgit does not show any tags for all repositories on
http://git.qemu.org/

Thanks,
Bernhard

Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

[Gerd Hoffmann]

  Hi,


Which makes me think we should just go the direct route.  No SDL.  No
directfb.  No other funky library which provides us with nothing but
bugs.  Programming fbdev isn't that hard after all.  Especially if you
skip all the (IMHO pointless) video mode switching bits.


Agreed, actually I was thinking the same thing.
The only reason for using a library is to have the color/pixel conversion
functions, that could be useful. However we have many of them already
implemented in qemu so it shouldn't be difficult to roll our own.


Everybody implements its own conversion functions though.  It probably 
makes sense to consolidate that stuff into a small conversion library, 
probably best based on PixelFormat, and make everybody use that.


cheers,
  Gerd

Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

[Stefano Stabellini]

On Wed, 19 May 2010, Gerd Hoffmann wrote:
>Hi,
> 
> >> Which makes me think we should just go the direct route.  No SDL.  No
> >> directfb.  No other funky library which provides us with nothing but
> >> bugs.  Programming fbdev isn't that hard after all.  Especially if you
> >> skip all the (IMHO pointless) video mode switching bits.
> >
> > Agreed, actually I was thinking the same thing.
> > The only reason for using a library is to have the color/pixel conversion
> > functions, that could be useful. However we have many of them already
> > implemented in qemu so it shouldn't be difficult to roll our own.
> 
> Everybody implements its own conversion functions though.  It probably 
> makes sense to consolidate that stuff into a small conversion library, 
> probably best based on PixelFormat, and make everybody use that.
> 
 
Yeah definitely

Re: [Qemu-devel] Update the http configuration on git.qemu.org

[Stefan Hajnoczi]

It's the post-update hook that needs chmod +x, I believe.

Stefan

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Jamie Lokier]

Michael Tokarev wrote:
> Anthony Liguori wrote:
> []
> > For the Bug Day, anything is interesting IMHO.  My main interest is to
> > get as many people involved in testing and bug fixing as possible.  If
> > folks are interested in testing specific things like unusual or older
> > OSes, I'm happy to see it!
> 
> Well, interesting or not, but I for one don't know what to do with the
> results.  There were a thread on kvm@ about sigsegv in cirrus code when
> running winNT. The issue has been identified and appears to be fixed,
> as in, kvm process does not SIGSEGV anymore, but it does not work anyway,
> now printing:
> 
>  BUG: kvm_dirty_pages_log_enable_slot: invalid parameters
> 
> with garbled guest display.  Thanks goes to Stefano Stabellini for
> finding the SIGSEGV case, but unfortunately his hard work isn't quite
> useful since the behavour isn't very much different from the previous
> version... ;)

A "BUG:" is good to see in a bug report: It gives you something
specific to analyse.  Good luck ;-)

Imho, it'd be quite handy to keep a timeline of working/non-working
guests in a table somewhere, and which qemu versions and options they
were observed to work or break with.

> Also, thanks to Andre Przywara, whole winNT thing works but it requires
> -cpu qemu64,level=1 (or level=2 or =3), -- _not_ with default CPU.  This
> is also testing, but it's not obvious what to do witht the result...

Doesn't WinNT work with qemu32 or kvm32?
It's a 32-bit OS after all.

- Jamie

[Qemu-devel] [PATCH 3/7] Revert "monitor: Convert do_pci_device_hot_remove() to QObject"

[Luiz Capitulino]

From: Markus Armbruster 

We don't want pci_del in QMP.  Use device_del instead.

This reverts commit 6848d827162fea039f2658414a4adb6164a4f9b0.

Conflicts:

hw/pci-hotplug.c
sysemu.h

Signed-off-by: Markus Armbruster 
---
 hw/pci-hotplug.c |5 ++---
 qemu-monitor.hx  |3 +--
 sysemu.h |3 +--
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index 22a7ce4..37ac015 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -277,8 +277,7 @@ int pci_device_hot_remove(Monitor *mon, const char 
*pci_addr)
 return qdev_unplug(&d->qdev);
 }
 
-int do_pci_device_hot_remove(Monitor *mon, const QDict *qdict,
- QObject **ret_data)
+void do_pci_device_hot_remove(Monitor *mon, const QDict *qdict)
 {
-return pci_device_hot_remove(mon, qdict_get_str(qdict, "pci_addr"));
+pci_device_hot_remove(mon, qdict_get_str(qdict, "pci_addr"));
 }
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index fba4c3f..b6e3467 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -874,8 +874,7 @@ ETEXI
 .args_type  = "pci_addr:s",
 .params = "[[:]:]",
 .help   = "hot remove PCI device",
-.user_print = monitor_user_noop,
-.mhandler.cmd_new = do_pci_device_hot_remove,
+.mhandler.cmd = do_pci_device_hot_remove,
 },
 #endif
 
diff --git a/sysemu.h b/sysemu.h
index 47975b5..643c0c6 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -204,8 +204,7 @@ DriveInfo *add_init_drive(const char *opts);
 void pci_device_hot_add(Monitor *mon, const QDict *qdict);
 void drive_hot_add(Monitor *mon, const QDict *qdict);
 int pci_device_hot_remove(Monitor *mon, const char *pci_addr);
-int do_pci_device_hot_remove(Monitor *mon, const QDict *qdict,
- QObject **ret_data);
+void do_pci_device_hot_remove(Monitor *mon, const QDict *qdict);
 
 /* serial ports */
 
-- 
1.7.1.86.g0e460

[Qemu-devel] [PATCH 2/7] Revert "PCI: Convert pci_device_hot_add() to QObject"

[Luiz Capitulino]

From: Markus Armbruster 

Short story: We don't want pci_add in QMP.  Long story follows.

pci_add can do two things:

* Hot plug a PCI NIC.  device_add is more general.

* Hot plug a PCI disk controller, and a drive connected to it.

  The controller is either virtio-blk-pci (if=virtio) or lsi53c895a
  (if=scsi).  With the latter, the drive is optional.  Use drive_add to
  hotplug additional SCSI drives.  Except drive_add is not available in
  QMP.

  device_add is more general for controllers and the guest part of
  drives.  I'm working on a more general alternative for the host part
  of drives.

Why am I proposing to remove pci_add from QMP before its replacement is
ready?  I want it out sooner rather than later, because it isn't fully
functional (errors and drive_add are missing), and we do not plan to
complete the job.  In other words, it's not really usable over QMP now,
and it's not what we want for QMP anyway.  Since we don't want it to be
used over QMP, we should take it out, not leave it around as a trap for
the uninitiated.

Dan Berrange confirmed that libvirt has no need for pci_add & friends
over QMP.

This reverts commit 7a344f7ac7bb651d0556a933ed8060d3a9e5d949.

Conflicts:

hw/pci-hotplug.c
sysemu.h

Signed-off-by: Markus Armbruster 
---
 hw/pci-hotplug.c |   46 +-
 qemu-monitor.hx  |3 +--
 sysemu.h |3 +--
 3 files changed, 7 insertions(+), 45 deletions(-)

diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c
index cc45c50..22a7ce4 100644
--- a/hw/pci-hotplug.c
+++ b/hw/pci-hotplug.c
@@ -33,7 +33,6 @@
 #include "scsi.h"
 #include "virtio-blk.h"
 #include "qemu-config.h"
-#include "qemu-objects.h"
 
 #if defined(TARGET_I386)
 static PCIDevice *qemu_pci_hot_add_nic(Monitor *mon,
@@ -224,36 +223,7 @@ static PCIDevice *qemu_pci_hot_add_storage(Monitor *mon,
 return dev;
 }
 
-void pci_device_hot_add_print(Monitor *mon, const QObject *data)
-{
-QDict *qdict;
-
-assert(qobject_type(data) == QTYPE_QDICT);
-qdict = qobject_to_qdict(data);
-
-monitor_printf(mon, "OK domain %d, bus %d, slot %d, function %d\n",
-   (int) qdict_get_int(qdict, "domain"),
-   (int) qdict_get_int(qdict, "bus"),
-   (int) qdict_get_int(qdict, "slot"),
-   (int) qdict_get_int(qdict, "function"));
-
-}
-
-/**
- * pci_device_hot_add(): Hot add a PCI device
- *
- * Return a QDict with the following device information:
- *
- * - "domain": domain number
- * - "bus": bus number
- * - "slot": slot number
- * - "function": function number
- *
- * Example:
- *
- * { "domain": 0, "bus": 0, "slot": 5, "function": 0 }
- */
-int pci_device_hot_add(Monitor *mon, const QDict *qdict, QObject **ret_data)
+void pci_device_hot_add(Monitor *mon, const QDict *qdict)
 {
 PCIDevice *dev = NULL;
 const char *pci_addr = qdict_get_str(qdict, "pci_addr");
@@ -278,20 +248,14 @@ int pci_device_hot_add(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
 dev = qemu_pci_hot_add_storage(mon, pci_addr, opts);
 } else {
 monitor_printf(mon, "invalid type: %s\n", type);
-return -1;
 }
 
 if (dev) {
-*ret_data =
-qobject_from_jsonf("{ 'domain': 0, 'bus': %d, 'slot': %d, "
-   "'function': %d }", pci_bus_num(dev->bus),
-   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
-} else {
+monitor_printf(mon, "OK domain %d, bus %d, slot %d, function %d\n",
+   0, pci_bus_num(dev->bus), PCI_SLOT(dev->devfn),
+   PCI_FUNC(dev->devfn));
+} else
 monitor_printf(mon, "failed to add %s\n", opts);
-return -1;
-}
-
-return 0;
 }
 #endif
 
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index a8f194c..fba4c3f 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -858,8 +858,7 @@ ETEXI
 .args_type  = "pci_addr:s,type:s,opts:s?",
 .params = "auto|[[:]:] nic|storage 
[[vlan=n][,macaddr=addr][,model=type]] [file=file][,if=type][,bus=nr]...",
 .help   = "hot-add PCI device",
-.user_print = pci_device_hot_add_print,
-.mhandler.cmd_new = pci_device_hot_add,
+.mhandler.cmd = pci_device_hot_add,
 },
 #endif
 
diff --git a/sysemu.h b/sysemu.h
index fa921df..47975b5 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -201,8 +201,7 @@ extern DriveInfo *drive_init(QemuOpts *arg, void *machine, 
int *fatal_error);
 DriveInfo *add_init_drive(const char *opts);
 
 /* pci-hotplug */
-void pci_device_hot_add_print(Monitor *mon, const QObject *data);
-int pci_device_hot_add(Monitor *mon, const QDict *qdict, QObject **ret_data);
+void pci_device_hot_add(Monitor *mon, const QDict *qdict);
 void drive_hot_add(Monitor *mon, const QDict *qdict);
 int pci_device_hot_remove(Monitor *mon, const char *pci_addr);
 int do_pci_device_hot_remove(Monitor *mon, const QDict *qdict,
-- 
1.7.1.86.g0e460

[Qemu-devel] [PATCH 1/7] QMP: Add "Downstream extension of QMP" to spec

[Luiz Capitulino]

From: Markus Armbruster 

Signed-off-by: Markus Armbruster 
---
 QMP/qmp-spec.txt |   55 ++
 1 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/QMP/qmp-spec.txt b/QMP/qmp-spec.txt
index f3c0327..9d30a8c 100644
--- a/QMP/qmp-spec.txt
+++ b/QMP/qmp-spec.txt
@@ -215,3 +215,58 @@ Additionally, Clients must not assume any particular:
 - Order of json-object members or json-array elements
 - Amount of errors generated by a command, that is, new errors can be added
   to any existing command in newer versions of the Server
+
+6. Downstream extension of QMP
+--
+
+We recommend that downstream consumers of QEMU do *not* modify QMP.
+Management tools should be able to support both upstream and downstream
+versions of QMP without special logic, and downstream extensions are
+inherently at odds with that.
+
+However, we recognize that it is sometimes impossible for downstreams to
+avoid modifying QMP.  Both upstream and downstream need to take care to
+preserve long-term compatibility and interoperability.
+
+To help with that, QMP reserves JSON object member names beginning with
+'__' (double underscore) for downstream use ("downstream names").  This
+means upstream will never use any downstream names for its commands,
+arguments, errors, asynchronous events, and so forth.
+
+Any new names downstream wishes to add must begin with '__'.  To
+ensure compatibility with other downstreams, it is strongly
+recommended that you prefix your downstram names with '__RFQDN_' where
+RFQDN is a valid, reverse fully qualified domain name which you
+control.  For example, a qemu-kvm specific monitor command would be:
+
+(qemu) __org.linux-kvm_enable_irqchip
+
+Downstream must not change the server greeting (section 2.2) other than
+to offer additional capabilities.  But see below for why even that is
+discouraged.
+
+Section '5 Compatibility Considerations' applies to downstream as well
+as to upstream, obviously.  It follows that downstream must behave
+exactly like upstream for any input not containing members with
+downstream names ("downstream members"), except it may add members
+with downstream names to its output.
+
+Thus, a client should not be able to distinguish downstream from
+upstream as long as it doesn't send input with downstream members, and
+properly ignores any downstream members in the output it receives.
+
+Advice on downstream modifications:
+
+1. Introducing new commands is okay.  If you want to extend an existing
+   command, consider introducing a new one with the new behaviour
+   instead.
+
+2. Introducing new asynchronous messages is okay.  If you want to extend
+   an existing message, consider adding a new one instead.
+
+3. Introducing new errors for use in new commands is okay.  Adding new
+   errors to existing commands counts as extension, so 1. applies.
+
+4. New capabilities are strongly discouraged.  Capabilities are for
+   evolving the basic protocol, and multiple diverging basic protocol
+   dialects are most undesirable.
-- 
1.7.1.86.g0e460

[Qemu-devel] [PATCH 7/7] Fix qtypes' licenses

[Luiz Capitulino]

- Change from GPL to LGPL
- Add license text when missing
- Minor cosmetic changes to make all headers look the same

Signed-off-by: Luiz Capitulino 
---
 check-qdict.c   |3 +++
 check-qfloat.c  |5 -
 check-qint.c|3 +++
 check-qlist.c   |4 ++--
 check-qstring.c |3 +++
 qbool.c |8 
 qdict.c |6 +++---
 qdict.h |   12 
 qemu-objects.h  |5 +++--
 qerror.c|2 +-
 qerror.h|2 +-
 qfloat.c|8 
 qint.c  |7 ---
 qint.h  |   12 
 qlist.c |7 ---
 qlist.h |7 ---
 qobject.h   |4 ++--
 qstring.c   |7 ---
 qstring.h   |   12 
 19 files changed, 73 insertions(+), 44 deletions(-)

diff --git a/check-qdict.c b/check-qdict.c
index f2b4826..2c3089f 100644
--- a/check-qdict.c
+++ b/check-qdict.c
@@ -5,6 +5,9 @@
  *
  * Authors:
  *  Luiz Capitulino 
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
  */
 #include 
 
diff --git a/check-qfloat.c b/check-qfloat.c
index 3758700..b71d983 100644
--- a/check-qfloat.c
+++ b/check-qfloat.c
@@ -1,11 +1,6 @@
 /*
  * QFloat unit-tests.
  *
- * Copyright (C) 2009 Red Hat Inc.
- *
- * Authors:
- *  Luiz Capitulino 
- *
  * Copyright IBM, Corp. 2009
  *
  * Authors:
diff --git a/check-qint.c b/check-qint.c
index 49887bb..f3b0316 100644
--- a/check-qint.c
+++ b/check-qint.c
@@ -5,6 +5,9 @@
  *
  * Authors:
  *  Luiz Capitulino 
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
  */
 #include 
 
diff --git a/check-qlist.c b/check-qlist.c
index 0117ef3..58984cb 100644
--- a/check-qlist.c
+++ b/check-qlist.c
@@ -6,8 +6,8 @@
  * Authors:
  *  Luiz Capitulino 
  *
- * This work is licensed under the terms of the GNU GPL, version 2. See
- * the COPYING file in the top-level directory.
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
  */
 #include 
 
diff --git a/check-qstring.c b/check-qstring.c
index c308a63..c9bafc2 100644
--- a/check-qstring.c
+++ b/check-qstring.c
@@ -5,6 +5,9 @@
  *
  * Authors:
  *  Luiz Capitulino 
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
  */
 #include 
 
diff --git a/qbool.c b/qbool.c
index 5ab734c..ad4873f 100644
--- a/qbool.c
+++ b/qbool.c
@@ -1,14 +1,6 @@
 /*
  * QBool Module
  *
- * Copyright (C) 2009 Red Hat Inc.
- *
- * Authors:
- *  Luiz Capitulino 
- *
- * This work is licensed under the terms of the GNU GPL, version 2.  See
- * the COPYING file in the top-level directory.
- *
  * Copyright IBM, Corp. 2009
  *
  * Authors:
diff --git a/qdict.c b/qdict.c
index aae57bf..175bc17 100644
--- a/qdict.c
+++ b/qdict.c
@@ -1,13 +1,13 @@
 /*
- * QDict data type.
+ * QDict Module
  *
  * Copyright (C) 2009 Red Hat Inc.
  *
  * Authors:
  *  Luiz Capitulino 
  *
- * This work is licensed under the terms of the GNU GPL, version 2.  See
- * the COPYING file in the top-level directory.
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
  */
 
 #include "qint.h"
diff --git a/qdict.h b/qdict.h
index 579dcdd..5e5902c 100644
--- a/qdict.h
+++ b/qdict.h
@@ -1,3 +1,15 @@
+/*
+ * QDict Module
+ *
+ * Copyright (C) 2009 Red Hat Inc.
+ *
+ * Authors:
+ *  Luiz Capitulino 
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ */
+
 #ifndef QDICT_H
 #define QDICT_H
 
diff --git a/qemu-objects.h b/qemu-objects.h
index e1d1e0c..c53fbaa 100644
--- a/qemu-objects.h
+++ b/qemu-objects.h
@@ -6,9 +6,10 @@
  * Authors:
  *  Luiz Capitulino 
  *
- * This work is licensed under the terms of the GNU GPL, version 2.  See
- * the COPYING file in the top-level directory.
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
  */
+
 #ifndef QEMU_OBJECTS_H
 #define QEMU_OBJECTS_H
 
diff --git a/qerror.c b/qerror.c
index 034c7de..44d0bf8 100644
--- a/qerror.c
+++ b/qerror.c
@@ -1,5 +1,5 @@
 /*
- * QError: QEMU Error data-type.
+ * QError Module
  *
  * Copyright (C) 2009 Red Hat Inc.
  *
diff --git a/qerror.h b/qerror.h
index c98c61a..77ae574 100644
--- a/qerror.h
+++ b/qerror.h
@@ -1,5 +1,5 @@
 /*
- * QError header file.
+ * QError Module
  *
  * Copyright (C) 2009 Red Hat Inc.
  *
diff --git a/qfloat.c b/qfloat.c
index 05215f5..f8c8a2e 100644
--- a/qfloat.c
+++ b/qfloat.c
@@ -1,14 +1,6 @@
 /*
  * QFloat Module
  *
- * Copyright (C) 2009 Red Hat Inc.
- *
- * Authors:
- *  Luiz Capitulino 
- *
- * This work is licensed under the terms of the GNU GPL, version 

[Qemu-devel] [PATCH 4/7] Revert "Monitor: Return before exiting with 'quit'"

[Luiz Capitulino]

This reverts commit 0e8d2b5575938b8876a3c4bb66ee13c5d306fb6d.

Next commits will do the same thing in a better way.

Signed-off-by: Luiz Capitulino 
---
 monitor.c |3 +--
 sysemu.h  |2 --
 vl.c  |   18 --
 3 files changed, 1 insertions(+), 22 deletions(-)

diff --git a/monitor.c b/monitor.c
index a1ebc5d..2e202ff 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1020,8 +1020,7 @@ static void do_info_cpu_stats(Monitor *mon)
  */
 static int do_quit(Monitor *mon, const QDict *qdict, QObject **ret_data)
 {
-monitor_suspend(mon);
-qemu_system_exit_request();
+exit(0);
 return 0;
 }
 
diff --git a/sysemu.h b/sysemu.h
index 643c0c6..48ee66c 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -45,11 +45,9 @@ void cpu_disable_ticks(void);
 void qemu_system_reset_request(void);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
-void qemu_system_exit_request(void);
 int qemu_shutdown_requested(void);
 int qemu_reset_requested(void);
 int qemu_powerdown_requested(void);
-int qemu_exit_requested(void);
 extern qemu_irq qemu_system_powerdown;
 void qemu_system_reset(void);
 
diff --git a/vl.c b/vl.c
index d77b47c..8c818f0 100644
--- a/vl.c
+++ b/vl.c
@@ -1708,7 +1708,6 @@ static int shutdown_requested;
 static int powerdown_requested;
 int debug_requested;
 int vmstop_requested;
-static int exit_requested;
 
 int qemu_shutdown_requested(void)
 {
@@ -1731,12 +1730,6 @@ int qemu_powerdown_requested(void)
 return r;
 }
 
-int qemu_exit_requested(void)
-{
-/* just return it, we'll exit() anyway */
-return exit_requested;
-}
-
 static int qemu_debug_requested(void)
 {
 int r = debug_requested;
@@ -1807,12 +1800,6 @@ void qemu_system_powerdown_request(void)
 qemu_notify_event();
 }
 
-void qemu_system_exit_request(void)
-{
-exit_requested = 1;
-qemu_notify_event();
-}
-
 #ifdef _WIN32
 static void host_main_loop_wait(int *timeout)
 {
@@ -1949,8 +1936,6 @@ static int vm_can_run(void)
 return 0;
 if (debug_requested)
 return 0;
-if (exit_requested)
-return 0;
 return 1;
 }
 
@@ -2003,9 +1988,6 @@ static void main_loop(void)
 if ((r = qemu_vmstop_requested())) {
 vm_stop(r);
 }
-if (qemu_exit_requested()) {
-exit(0);
-}
 }
 pause_all_vcpus();
 }
-- 
1.7.1.86.g0e460

Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

[Julian Pidancet]

On 05/19/2010 02:52 PM, Stefano Stabellini wrote:
> On Wed, 19 May 2010, Gerd Hoffmann wrote:
>>Hi,
>>
>>> I think the only way to fix this is to handle VT acquire and release
>>> events ourselves.
>>
>> Hmm.  I suspect sdl and directfb wanna do this too, so I'm not sure this 
>> will actually work out.
>>
>>> At this point I am not sure if it is worth doing it in the DirectFB
>>> frontend or in the SDL frontend directly (making sure we are not
>>> running on X11 first).
>>
>> I didn't investigate who is at fault here.  SDL docs doesn't mention 
>> console switching at all it seems (grep -i console in 
>> /usr/share/doc/SDL-devel-1.2.13/html doesn't find me anything).  Which 
>> makes me assume no special actions by the app using SDL are required for 
>> it.  Which in turn makes me think SDL is broken.
>>
>> Which makes me think we should just go the direct route.  No SDL.  No 
>> directfb.  No other funky library which provides us with nothing but 
>> bugs.  Programming fbdev isn't that hard after all.  Especially if you 
>> skip all the (IMHO pointless) video mode switching bits.
>  
> Agreed, actually I was thinking the same thing.
> The only reason for using a library is to have the color/pixel conversion
> functions, that could be useful. However we have many of them already
> implemented in qemu so it shouldn't be difficult to roll our own.
> 
> Julian, what do you think?
> 

It also appears to me to be the good way to do this thing.

Gerd, it is true that the DirectFB suffers the same problem as the SDL driver 
regarding the VT switching. Actually I investigated the issue yesterday, and I 
found out that:
 1) even though there is some VT handling in DirectFB, it is incomplete (I 
found "to be finished" mentions in the TODO file).
 2) When we switch to another VT, Qemu continues to draw on the screen using 
the pointer acquired from DirectFB. There's no hooks we can set in DirectFB's 
VT code for Qemu to be notified when we change VT, in order to stop drawing.

So, even though DirectFB claims to handle multiple VTs, I agree that it 
currently sucks.

So after all, why not implementing our own VT switching and using directly the 
fbdev interface. I just checked the linux fbdev code to find out if it provides 
with a blitting method that could perform the pixel color conversion 
automatically for Qemu. 

Unfortunately, from what I have read from the drivers/video/cfbimgblt.c file in 
the linux tree, there's no such thing, and it also means that we cannot take 
advantage of any kind of hardware pixel format conversion.

But anyway, I don't think software color conversion would be a problem, because 
it already exists in several places in Qemu.

-- 
Julian

[Qemu-devel] [PATCH 0/7][PULL]: QMP/Monitor queue

[Luiz Capitulino]

 Hi Anthony,

 The following QMP/Monitor patches have been sent to the list and look good
to me. I have also tested most of them.

 Please, note that I didn't add the QMP doc patches, since they are still under
discussion.

 The changes (since 0d5d46993840c1e6a04c1db38a554aad4ee83835) are available in
the following repository:

git://repo.or.cz/qemu/qmp-unstable.git for-anthony

Luiz Capitulino (4):
  Revert "Monitor: Return before exiting with 'quit'"
  sysemu: Export 'no_shutdown'
  Monitor: Return before exiting with 'quit'
  Fix qtypes' licenses

Markus Armbruster (3):
  QMP: Add "Downstream extension of QMP" to spec
  Revert "PCI: Convert pci_device_hot_add() to QObject"
  Revert "monitor: Convert do_pci_device_hot_remove() to QObject"

 QMP/qmp-spec.txt |   55 ++
 check-qdict.c|3 ++
 check-qfloat.c   |5 
 check-qint.c |3 ++
 check-qlist.c|4 +-
 check-qstring.c  |3 ++
 hw/pci-hotplug.c |   51 ++---
 monitor.c|4 ++-
 qbool.c  |8 ---
 qdict.c  |6 ++--
 qdict.h  |   12 +++
 qemu-monitor.hx  |6 +---
 qemu-objects.h   |5 ++-
 qerror.c |2 +-
 qerror.h |2 +-
 qfloat.c |8 ---
 qint.c   |7 +++--
 qint.h   |   12 +++
 qlist.c  |7 +++--
 qlist.h  |7 +++--
 qobject.h|4 +-
 qstring.c|7 +++--
 qstring.h|   12 +++
 sysemu.h |9 ++-
 vl.c |   18 -
 25 files changed, 143 insertions(+), 117 deletions(-)

[Qemu-devel] [PATCH 5/7] sysemu: Export 'no_shutdown'

[Luiz Capitulino]

It's a global variable already, do_quit() will use it.

Signed-off-by: Luiz Capitulino 
---
 sysemu.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/sysemu.h b/sysemu.h
index 48ee66c..879446a 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -128,6 +128,7 @@ extern int max_cpus;
 extern int cursor_hide;
 extern int graphic_rotate;
 extern int no_quit;
+extern int no_shutdown;
 extern int semihosting_enabled;
 extern int old_param;
 extern int boot_menu;
-- 
1.7.1.86.g0e460

[Qemu-devel] Re: [PATCH 10/12] kvm: enable smp > 1

[Avi Kivity]

On 05/19/2010 12:57 PM, Udo Lembke wrote:

Jan Kiszka schrieb:

...
--enable-io-thread?

If you had it disabled, it would also answer my question if -smp works
without problems without that feature.

Jan


Hi,
i have a dumb question: what is the "--enable-io-thread"? Is this a 
kvm-switch?


It's a ./configure switch for upstream qemu (don't use with qemu-kvm yet).

My kvm 0.12.4 don't accept this switch. I'm know only "threads=n" as 
smp-parameter and "aio=threads" as drive-parameter.


Because i look for a solution for a better io-performance of 
windows-guest with more than one cpu...


Unrelated, what are your smp issues?

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] [PATCH 6/7] Monitor: Return before exiting with 'quit'

[Luiz Capitulino]

This is a new version of the (now reverted) following commit:

0e8d2b5575938b8876a3c4bb66ee13c5d306fb6d

The 'quit' Monitor command (implemented by do_quit()) calls
exit() directly, this is problematic under QMP because QEMU
exits before having a chance to send the ok response.

Clients don't know if QEMU exited because of a problem or
because the 'quit' command has been executed.

This commit fixes that by making do_quit() use
qemu_system_shutdown_request(), so that we exit gracefully.

Thanks to Paolo Bonzini  for suggesting
this solution.

Signed-off-by: Luiz Capitulino 
---
 monitor.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/monitor.c b/monitor.c
index 2e202ff..ad50f12 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1020,7 +1020,10 @@ static void do_info_cpu_stats(Monitor *mon)
  */
 static int do_quit(Monitor *mon, const QDict *qdict, QObject **ret_data)
 {
-exit(0);
+monitor_suspend(mon);
+no_shutdown = 0;
+qemu_system_shutdown_request();
+
 return 0;
 }
 
-- 
1.7.1.86.g0e460

Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

[Jamie Lokier]

Julian Pidancet wrote:
> So after all, why not implementing our own VT switching and using
> directly the fbdev interface.

It's a good idea.  VT switching isn't hard to track reliably.

Being able to tell qemu, through the monitor, to attach/detach from a
particular VT might be a nice easy bonus too.

> I just checked the linux fbdev code to
> find out if it provides with a blitting method that could perform
> the pixel color conversion automatically for Qemu.
> 
> Unfortunately, from what I have read from the
> drivers/video/cfbimgblt.c file in the linux tree, there's no such
> thing, and it also means that we cannot take advantage of any kind
> of hardware pixel format conversion.

I'm not sure if DirectFB provides that particular operation, but I
have the impression it's the sort of thing DirectFB is intended for: A
framebuffer, plus a variety of 2d acceleration methods (and other
things like multi-buffering, video and alpha channel overlay).

-- Jamie

Re: [Qemu-devel] Latest git does not compile target_to_host_rlim()

[Aurelien Jarno]

On Wed, May 19, 2010 at 01:51:35PM +0200, Riccardo Magliocchetti wrote:
> Hello,
> 
> latest git does not compile on debian sid 32 bit (kernel 64 bit),
> gcc 4.4.4:
> 
>  CCalpha-linux-user/syscall.o
> cc1: warnings being treated as errors
> /home/rm/src/qemu/linux-user/syscall.c: In function ‘target_to_host_rlim’:
> /home/rm/src/qemu/linux-user/syscall.c:836: error: integer constant
> is too large for ‘unsigned long’ type
> /home/rm/src/qemu/linux-user/syscall.c: In function ‘host_to_target_rlim’:
> /home/rm/src/qemu/linux-user/syscall.c:845: error: integer constant
> is too large for ‘unsigned long’ type
> 

I have just committed a patch to fix the problem.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] Update the http configuration on git.qemu.org

[Anthony Liguori]

On 05/19/2010 10:15 AM, Bernhard Kohl wrote:

Hi,

could you please run "git update-server-info" on the server
and enable the hooks? At least seabios.git and vgabios.git
cannot be accessed via http://.


Sure.  I'd prefer people didn't use http because it's pretty inefficient 
but I understand it's the only option for people being proxies.



And the cgit does not show any tags for all repositories on
http://git.qemu.org/


I've updated tags for seabios and vgabios.  For mirrored repositories 
like qemu.git, I've updated the script to mirror tags so once the cron 
job runs, it should be updated.


Regards,

Anthony Liguori


Thanks,
Bernhard

[Qemu-devel] [PATCH 3/3] Fix hw/gt64xxx.c compilation with DEBUG defined

[Riccardo Magliocchetti]

Use TARGET_FMT_plx as format placeholder for target_phys_addr_t

Signed-off-by: Riccardo Magliocchetti 
---
 hw/gt64xxx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/hw/gt64xxx.c b/hw/gt64xxx.c
index 55971b9..7691e1d 100644
--- a/hw/gt64xxx.c
+++ b/hw/gt64xxx.c
@@ -276,7 +276,7 @@ static void gt64120_isd_mapping(GT64120State *s)
 check_reserved_space(&start, &length);
 length = 0x1000;
 /* Map new address */
-DPRINTF("ISD: %...@%x -> %...@%x, %x\n", s->ISD_length, s->ISD_start,
+DPRINTF("ISD: "TARGET_FMT_plx"@"TARGET_FMT_plx" -> 
"TARGET_FMT_plx"@"TARGET_FMT_plx", %x\n", s->ISD_length, s->ISD_start,
 length, start, s->ISD_handle);
 s->ISD_start = start;
 s->ISD_length = length;
-- 
1.7.1

[Qemu-devel] [PATCH 2/3] Fix __VA__ARGS__ typo in cris mmu.c

[Riccardo Magliocchetti]

Fix compilation with DEBUG defined

Signed-off-by: Riccardo Magliocchetti 
---
 target-cris/mmu.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/target-cris/mmu.c b/target-cris/mmu.c
index 2a5ded8..d09e921 100644
--- a/target-cris/mmu.c
+++ b/target-cris/mmu.c
@@ -31,7 +31,7 @@
 
 #ifdef DEBUG
 #define D(x) x
-#define D_LOG(...) qemu_log(__VA__ARGS__)
+#define D_LOG(...) qemu_log(__VA_ARGS__)
 #else
 #define D(x)
 #define D_LOG(...) do { } while (0)
-- 
1.7.1

Re: [Qemu-devel] Update the http configuration on git.qemu.org

[Pierre Riteau]

On 19 mai 2010, at 18:28, Anthony Liguori wrote:

> On 05/19/2010 10:15 AM, Bernhard Kohl wrote:
>> Hi,
>> 
>> could you please run "git update-server-info" on the server
>> and enable the hooks? At least seabios.git and vgabios.git
>> cannot be accessed via http://.
> 
> Sure.  I'd prefer people didn't use http because it's pretty inefficient but 
> I understand it's the only option for people being proxies.

In recent versions Git as a so-called "Smart HTTP" protocol which is much more 
efficient. However it requires both the new server and new clients.

-- 
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/

[Qemu-devel] Re: [PATCH v2] KVM: VMX: Enable XSAVE/XRSTORE for guest

[Avi Kivity]

On 05/19/2010 11:34 AM, Sheng Yang wrote:

From: Dexuan Cui

Enable XSAVE/XRSTORE for guest.

Change from V1:

1. Use FPU API.
2. Fix CPUID issue.
3. Save/restore all possible guest xstate fields when switching. Because we
don't know which fields guest has already touched.

Signed-off-by: Dexuan Cui
Signed-off-by: Sheng Yang
---
  arch/x86/include/asm/kvm_host.h |1 +
  arch/x86/include/asm/vmx.h  |1 +
  arch/x86/kvm/vmx.c  |   28 +
  arch/x86/kvm/x86.c  |   85 +++---
  4 files changed, 108 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index d08bb4a..78d7b06 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -302,6 +302,7 @@ struct kvm_vcpu_arch {
} update_pte;

struct fpu guest_fpu;
+   uint64_t xcr0, host_xcr0;
   


host_xcr0 can be a global.


  /*
   * Interruption-information format
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 99ae513..2ee8ff6 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -36,6 +36,8 @@
  #include
  #include
  #include
+#include
+#include

  #include "trace.h"

@@ -2616,6 +2618,8 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
vmx->vcpu.arch.cr4_guest_owned_bits = KVM_CR4_GUEST_OWNED_BITS;
if (enable_ept)
vmx->vcpu.arch.cr4_guest_owned_bits |= X86_CR4_PGE;
+   if (cpu_has_xsave)
+   vmx->vcpu.arch.cr4_guest_owned_bits |= X86_CR4_OSXSAVE;
   


First, we should only allow the guest to play with cr4.osxsave if 
guest_has_xsave in cpuid; otherwise we need to #GP if the guest sets 
it.  Second, it may be better to trap when the guest sets it (should be 
rare); this way, we only need to save/restore xcr0 if the guest has 
enabled cr4.osxsave.



vmcs_writel(CR4_GUEST_HOST_MASK, ~vmx->vcpu.arch.cr4_guest_owned_bits);

tsc_base = vmx->vcpu.kvm->arch.vm_init_tsc;
@@ -3354,6 +3358,29 @@ static int handle_wbinvd(struct kvm_vcpu *vcpu)
return 1;
  }

+static int handle_xsetbv(struct kvm_vcpu *vcpu)
+{
+   u64 new_bv = ((u64)(kvm_register_read(vcpu, VCPU_REGS_RDX)<<  32)) |
+   kvm_register_read(vcpu, VCPU_REGS_RAX);
   


I think you need to trim the upper 32 bits of rax.

Please introduce helpers for reading edx:eax into a u64 and vice versa.  
We can then use the helpers here and in the msr code.



+
+   if (kvm_register_read(vcpu, VCPU_REGS_RCX) != 0)
+   goto err;
+   if (vmx_get_cpl(vcpu) != 0)
+   goto err;
+   if (!(new_bv&  XSTATE_FP) ||
+(new_bv&  ~vcpu->arch.host_xcr0))
+   goto err;
+   if ((new_bv&  XSTATE_YMM)&&  !(new_bv&  XSTATE_SSE))
+   goto err;
   


This is a little worrying.  What if a new bit is introduced later that 
depends on other bits?  We'll need to add a dependency between ZMM and 
YMM or whatever, and old versions will be broken.


So I think we need to check xcr0 not against host_xcr0 but instead 
against a whitelist of xcr0 bits that we know how to handle (currently 
fpu, see, and ymm).



+   vcpu->arch.xcr0 = new_bv;
+   xsetbv(XCR_XFEATURE_ENABLED_MASK, vcpu->arch.xcr0);
+   skip_emulated_instruction(vcpu);
+   return 1;
+err:
+   kvm_inject_gp(vcpu, 0);
+   return 1;
+}
+
   



@@ -149,6 +150,11 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
{ NULL }
  };

+static inline u32 bit(int bitno)
+{
+   return 1<<  (bitno&  31);
+}
+
  static void kvm_on_user_return(struct user_return_notifier *urn)
  {
unsigned slot;
@@ -473,6 +479,17 @@ void kvm_lmsw(struct kvm_vcpu *vcpu, unsigned long msw)
  }
  EXPORT_SYMBOL_GPL(kvm_lmsw);

+static bool guest_cpuid_has_xsave(struct kvm_vcpu *vcpu)
+{
+   struct kvm_cpuid_entry2 *best;
+
+   best = kvm_find_cpuid_entry(vcpu, 1, 0);
+   if (best->ecx&  bit(X86_FEATURE_XSAVE))
   


Sanity:  if (best && ...)


+   return true;
+
+   return false;
   


Can avoid the if (): return best && (best->ecx & ...);


+}
+
  int __kvm_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
  {
unsigned long old_cr4 = kvm_read_cr4(vcpu);
@@ -481,6 +498,9 @@ int __kvm_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
if (cr4&  CR4_RESERVED_BITS)
return 1;

+   if (!guest_cpuid_has_xsave(vcpu)&&  X86_CR4_OSXSAVE)
   


s/&&.*//


+   return 1;
+
if (is_long_mode(vcpu)) {
if (!(cr4&  X86_CR4_PAE))
   



return 1;

@@ -1887,6 +1902,7 @@ static void do_cpuid_ent(struct kvm_cpuid_entry2 *entry, 
u32 function,
unsigned f_lm = 0;
  #endif
unsigned f_rdtscp = kvm_x86_ops->rdtscp_supported() ? F(RDTSCP) : 0;
+   unsigned f_xsave = cpu_has_xsave ? F(XSAVE) : 0;

/* cpuid 1.edx */
const u32 kvm_supported_word0_x86_features =
@@ -1916,7 +1932,7 @@ static void do_

[Qemu-devel] [PATCH 1/3] Fix typo in balloon help

[Riccardo Magliocchetti]

Fix launchpad #563883

Signed-off-by: Riccardo Magliocchetti 
---
 qemu-monitor.hx |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index a8f194c..ed7def9 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -979,7 +979,7 @@ ETEXI
 .name   = "balloon",
 .args_type  = "value:M",
 .params = "target",
-.help   = "request VM to change it's memory allocation (in MB)",
+.help   = "request VM to change its memory allocation (in MB)",
 .user_print = monitor_user_noop,
 .mhandler.cmd_async = do_balloon,
 .async  = 1,
-- 
1.7.1

[Qemu-devel] Re: [PATCH] qemu-kvm: Enable xsave related CPUID

[Avi Kivity]

On 05/19/2010 11:34 AM, Sheng Yang wrote:

Signed-off-by: Sheng Yang
---
  target-i386/cpuid.c |   32 
   


Can send to Anthony directly, while tcg doesn't support xsave/ymm, all 
the code here is generic.



  1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index eebf038..21e94f3 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -1067,6 +1067,38 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, 
uint32_t count,
  *ecx = 0;
  *edx = 0;
  break;
+case 0xD:
+/* Processor Extended State */
+if (!(env->cpuid_ext_features&  CPUID_EXT_XSAVE)) {
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+break;
+}
+if (count == 0) {
+*eax = 0x7;
+*ebx = 0x340;
+*ecx = 0x340;
+*edx = 0;
+} else if (count == 1) {
+/* eax = 1, so we can continue with others */
+*eax = 1;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+} else if (count == 2) {
+*eax = 0x100;
+*ebx = 0x240;
+*ecx = 0;
+*edx = 0;
+} else {
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+}
+break;
   


Lots of magic numbers.  Symbolic constants or explanatory comments.

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010

[Anthony Liguori]

On 05/19/2010 09:52 AM, Luiz Capitulino wrote:

On Tue, 18 May 2010 17:38:27 -0500
Anthony Liguori  wrote:

   

Hi,

In an effort to improve the 0.13 release quality, I'd like to host a Bug
Day on June 1st, 2010.  I've setup a quick wiki page with some more info
(http://wiki.qemu.org/BugDay/June2010).
 

  Tuesday is our call conf day and other people have reported that they have
more confs during that day. Suggest Jun 2.
   


I don't have a problem with the 2nd.


Here's my basic thinking:

   - Anyone who can should try to spend some time either triaging bugs,
updating bug status, or actually fixing bugs.
 

  And testing, Fedora has a number of test cases already written, but
I guess that just a few are qemu specific:

https://fedoraproject.org/wiki/Test_Day:2010-04-08_Virtualization

  We could link those and write our own, or at least list the major
features to be tested..

  Of course we could have a different day for testing too, but I think
this is a way to get everyone busy.
   


Yup, I think it's a good suggestion.  Please update the wiki if there's 
anything you'd like to add.



   - We'll have a special IRC channel (#qemu-bugday) on OFTC.  As many
QEMU and KVM developers as possible should join this channel for that
day to help assist people working on bugs.
   - We'll try to migrate as many confirmable bugs from the Source Forge
tracker to Launchpad.
 

  Can't this be automated?
   


It could, but I think doing it manually could be helpful in culling bad 
bug reports.



If this is successful, we'll try to have regular bug days.  Any
suggestions on how to make the experience as fun and productive as
possible are certainly appreciated!
 

  Lots of foods and a Monty Python session in the evening.
   


Of course :-)

Regards,

Anthony Liguori

[Qemu-devel] Re: KVM call minutes for May 18

[Avi Kivity]

On 05/18/2010 05:29 PM, Chris Wright wrote:


sourceforge bug tracker...
- sucks
- unclear if there's active triage
- anthony prefers the launchpad instance
   


Kernel bugs can go to bugzilla.kernel.org.  Of course it isn't always 
clear if a bug is a kernel or qemu bug.  Recommend we ask users to post 
to the list first, get some guidance, then the bug is either resolved or 
we ask them to file a bug report.  Should improve the experience for 
users and developers.



- alex likes the sf email to list, wuld be good to keep that feature
   


Pretty critical IMO.  The little attention the tracker gets is entirely 
due to the email.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

[Qemu-devel] Re: kvm: network problem with Solaris 10u8 guest

[Avi Kivity]

On 05/19/2010 04:46 PM, Harald Dunkel wrote:

Hi folks,

   


Please post kvm issues to the kvm mailing list.


I am trying to run Solaris 10u8 as a guest in kvm (kernel
2.6.33.2). Problem: The virtual network devices don't work
with this Solaris version.

e1000 and pcnet work just by chance, as it seems. I can ping
the guest (even though some packets are lost). I cannot use
ssh to login.

rtl8139 and ne2k_pci are not even listed by "ifconfig -a" on
the guest.

Solaris 10u6 worked fine (using the e1000 emulation). Same for
the Linux guests.

Can anybody reproduce this problem?


Any helpful comment would be highly appreciated. Of course
I would be glad to help to track this down.
   


Does opensolaris exhibit the the same problems?  If so, you can probably 
bisect the driver to find the change that broke the device.  With that 
we can probably deduce if it is the device or driver that is broken, and 
what the issue is.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

Re: [Qemu-devel] Latest git does not compile target_to_host_rlim()

[Riccardo Magliocchetti]

Il 19/05/2010 18:38, Aurelien Jarno ha scritto:

On Wed, May 19, 2010 at 01:51:35PM +0200, Riccardo Magliocchetti wrote:

Hello,

latest git does not compile on debian sid 32 bit (kernel 64 bit),
gcc 4.4.4:

  CCalpha-linux-user/syscall.o
cc1: warnings being treated as errors
/home/rm/src/qemu/linux-user/syscall.c: In function ‘target_to_host_rlim’:
/home/rm/src/qemu/linux-user/syscall.c:836: error: integer constant
is too large for ‘unsigned long’ type
/home/rm/src/qemu/linux-user/syscall.c: In function ‘host_to_target_rlim’:
/home/rm/src/qemu/linux-user/syscall.c:845: error: integer constant
is too large for ‘unsigned long’ type



I have just committed a patch to fix the problem.



thanks for the prompt reply, have you pushed it? can't see it on 
git.qemu.org.


thanks,
riccardo

Re: [Qemu-devel] Latest git does not compile target_to_host_rlim()

[Aurelien Jarno]

On Wed, May 19, 2010 at 07:09:55PM +0200, Riccardo Magliocchetti wrote:
> Il 19/05/2010 18:38, Aurelien Jarno ha scritto:
>> On Wed, May 19, 2010 at 01:51:35PM +0200, Riccardo Magliocchetti wrote:
>>> Hello,
>>>
>>> latest git does not compile on debian sid 32 bit (kernel 64 bit),
>>> gcc 4.4.4:
>>>
>>>   CCalpha-linux-user/syscall.o
>>> cc1: warnings being treated as errors
>>> /home/rm/src/qemu/linux-user/syscall.c: In function ‘target_to_host_rlim’:
>>> /home/rm/src/qemu/linux-user/syscall.c:836: error: integer constant
>>> is too large for ‘unsigned long’ type
>>> /home/rm/src/qemu/linux-user/syscall.c: In function ‘host_to_target_rlim’:
>>> /home/rm/src/qemu/linux-user/syscall.c:845: error: integer constant
>>> is too large for ‘unsigned long’ type
>>>
>>
>> I have just committed a patch to fix the problem.
>>
>
> thanks for the prompt reply, have you pushed it? can't see it on  
> git.qemu.org.
>

Yes.

git.qemu.org is only a mirror, so a propagation time is needed.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

[Qemu-devel] [PATCH] Name the default PCI bus "pci.0" on all architectures

[Daniel P. Berrange]

The system emulators for each arch are using inconsistent
naming for the default PCI bus "pci" vs "pci.0". Since it
is conceivable we'll have multiple PCI buses in the future
standardize on "pci.0" for all architectures. This ensures
mgmt apps can rely on a name when assigning PCI devices an
address on the bus using eg '-device e1000,bus=pci.0,addr=3'

Signed-off-by: Daniel P. Berrange 
---
 hw/grackle_pci.c   |2 +-
 hw/gt64xxx.c   |2 +-
 hw/ppc4xx_pci.c|2 +-
 hw/ppce500_pci.c   |2 +-
 hw/prep_pci.c  |2 +-
 hw/sh_pci.c|2 +-
 hw/unin_pci.c  |4 ++--
 hw/versatile_pci.c |2 +-
 8 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/hw/grackle_pci.c b/hw/grackle_pci.c
index aa0c51b..8444a35 100644
--- a/hw/grackle_pci.c
+++ b/hw/grackle_pci.c
@@ -88,7 +88,7 @@ PCIBus *pci_grackle_init(uint32_t base, qemu_irq *pic)
 qdev_init_nofail(dev);
 s = sysbus_from_qdev(dev);
 d = FROM_SYSBUS(GrackleState, s);
-d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci",
+d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci.0",
  pci_grackle_set_irq,
  pci_grackle_map_irq,
  pic, 0, 4);
diff --git a/hw/gt64xxx.c b/hw/gt64xxx.c
index 55971b9..756e1bf 100644
--- a/hw/gt64xxx.c
+++ b/hw/gt64xxx.c
@@ -1113,7 +1113,7 @@ PCIBus *pci_gt64120_init(qemu_irq *pic)
 s = qemu_mallocz(sizeof(GT64120State));
 s->pci = qemu_mallocz(sizeof(GT64120PCIState));
 
-s->pci->bus = pci_register_bus(NULL, "pci",
+s->pci->bus = pci_register_bus(NULL, "pci.0",
pci_gt64120_set_irq, pci_gt64120_map_irq,
pic, 144, 4);
 s->ISD_handle = cpu_register_io_memory(gt64120_read, gt64120_write, s);
diff --git a/hw/ppc4xx_pci.c b/hw/ppc4xx_pci.c
index c9e3279..dc1d2f8 100644
--- a/hw/ppc4xx_pci.c
+++ b/hw/ppc4xx_pci.c
@@ -357,7 +357,7 @@ PCIBus *ppc4xx_pci_init(CPUState *env, qemu_irq pci_irqs[4],
 
 controller = qemu_mallocz(sizeof(PPC4xxPCIState));
 
-controller->pci_state.bus = pci_register_bus(NULL, "pci",
+controller->pci_state.bus = pci_register_bus(NULL, "pci.0",
  ppc4xx_pci_set_irq,
  ppc4xx_pci_map_irq,
  pci_irqs, 0, 4);
diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
index 336d284..fa4387a 100644
--- a/hw/ppce500_pci.c
+++ b/hw/ppce500_pci.c
@@ -276,7 +276,7 @@ PCIBus *ppce500_pci_init(qemu_irq pci_irqs[4], 
target_phys_addr_t registers)
 
 controller = qemu_mallocz(sizeof(PPCE500PCIState));
 
-controller->pci_state.bus = pci_register_bus(NULL, "pci",
+controller->pci_state.bus = pci_register_bus(NULL, "pci.0",
  mpc85xx_pci_set_irq,
  mpc85xx_pci_map_irq,
  pci_irqs, 0x88, 4);
diff --git a/hw/prep_pci.c b/hw/prep_pci.c
index 144fde0..7ea7ca5 100644
--- a/hw/prep_pci.c
+++ b/hw/prep_pci.c
@@ -117,7 +117,7 @@ PCIBus *pci_prep_init(qemu_irq *pic)
 int PPC_io_memory;
 
 s = qemu_mallocz(sizeof(PREPPCIState));
-s->bus = pci_register_bus(NULL, "pci",
+s->bus = pci_register_bus(NULL, "pci.0",
   prep_set_irq, prep_map_irq, pic, 0, 4);
 
 pci_host_conf_register_ioport(0xcf8, s);
diff --git a/hw/sh_pci.c b/hw/sh_pci.c
index cc2f190..0e138ed 100644
--- a/hw/sh_pci.c
+++ b/hw/sh_pci.c
@@ -98,7 +98,7 @@ PCIBus *sh_pci_register_bus(pci_set_irq_fn set_irq, 
pci_map_irq_fn map_irq,
 int reg;
 
 p = qemu_mallocz(sizeof(SHPCIC));
-p->bus = pci_register_bus(NULL, "pci",
+p->bus = pci_register_bus(NULL, "pci.0",
   set_irq, map_irq, opaque, devfn_min, nirq);
 
 p->dev = pci_register_device(p->bus, "SH PCIC", sizeof(PCIDevice),
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index f0a773d..57c56e0 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -226,7 +226,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic)
 qdev_init_nofail(dev);
 s = sysbus_from_qdev(dev);
 d = FROM_SYSBUS(UNINState, s);
-d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci",
+d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci.0",
  pci_unin_set_irq, pci_unin_map_irq,
  pic, 11 << 3, 4);
 
@@ -278,7 +278,7 @@ PCIBus *pci_pmac_u3_init(qemu_irq *pic)
 s = sysbus_from_qdev(dev);
 d = FROM_SYSBUS(UNINState, s);
 
-d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci",
+d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci.0",
  pci_unin_set_irq, pci_unin_map_irq,
  pic, 11 << 3, 4);
 
diff --git a/hw/

Re: [Qemu-devel] [PATCH 02/22] tcg-i386: Tidy initialization of tcg_target_call_clobber_regs.

[Aurelien Jarno]

On Tue, Apr 13, 2010 at 03:26:17PM -0700, Richard Henderson wrote:
> Setting the registers one by one is easier to read, and gets
> optimized by the compiler just the same.
> 
> Signed-off-by: Richard Henderson 
> ---
>  tcg/i386/tcg-target.c |   11 ++-
>  1 files changed, 6 insertions(+), 5 deletions(-)

Thanks, applied.

> diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
> index f5c24f7..359f81b 100644
> --- a/tcg/i386/tcg-target.c
> +++ b/tcg/i386/tcg-target.c
> @@ -1365,11 +1365,12 @@ void tcg_target_init(TCGContext *s)
>  #endif
>  
>  tcg_regset_set32(tcg_target_available_regs[TCG_TYPE_I32], 0, 0xff);
> -tcg_regset_set32(tcg_target_call_clobber_regs, 0,
> - (1 << TCG_REG_EAX) | 
> - (1 << TCG_REG_EDX) | 
> - (1 << TCG_REG_ECX));
> -
> +
> +tcg_regset_clear(tcg_target_call_clobber_regs);
> +tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_EAX);
> +tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_EDX);
> +tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_ECX);
> +
>  tcg_regset_clear(s->reserved_regs);
>  tcg_regset_set_reg(s->reserved_regs, TCG_REG_ESP);
>  
> -- 
> 1.6.6.1
> 
> 
> 
> 

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH 03/22] tcg-i386: Tidy ext8u and ext16u operations.

[Aurelien Jarno]

Hi,

On Tue, Apr 13, 2010 at 03:59:20PM -0700, Richard Henderson wrote:
> Define OPC_MOVZBL and OPC_MOVZWL.  Factor opcode emission to
> separate functions.  Don't restrict the input register to the
> low 4 "q" registers; emit an AND instead if needed.

I am fine about the cleaning part, but I don't know what to think about
the constraints change.

The reg allocator is able to issue move if needed, so the only
improvement this patch is for doing a ext8u on both "q" registers.

OTOH the reg allocator knows this situation and will try to avoid this
situation during the allocation. Cheating on the reg allocator might
have some wrong effects, especially after your patch "Allocate
call-saved registers first". I am thinking of the scenario where the
value is in memory (which is likely to be the case given the limited 
number of registers), it will be likely loaded in a "r" register (they
are now at the top priority), and then ext8u will be called, which will 
issue "mov" + "and" instructions instead of a "movzbl" instruction.

If there are still cases to optimize I think it should be done in the
reg allocator instead, so it could benefit all ops and all targets. I
have started to play on that with Laurent Desnogues, I have a few more
ideas how to improve it, but unfortunately I don't have time to code
them.

All of that is purely theoretical. Do you know how does it behave in 
practice?

> Signed-off-by: Richard Henderson 
> ---
>  tcg/i386/tcg-target.c |   68 ++--
>  1 files changed, 42 insertions(+), 26 deletions(-)
> 
> diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
> index 359f81b..2cc1191 100644
> --- a/tcg/i386/tcg-target.c
> +++ b/tcg/i386/tcg-target.c
> @@ -161,6 +161,11 @@ static inline int tcg_target_const_match(tcg_target_long 
> val,
>  return 0;
>  }
>  
> +#define P_EXT   0x100 /* 0x0f opcode prefix */
> +
> +#define OPC_MOVZBL   (0xb6 | P_EXT)
> +#define OPC_MOVZWL   (0xb7 | P_EXT)
> +
>  #define ARITH_ADD 0
>  #define ARITH_OR  1
>  #define ARITH_ADC 2
> @@ -194,8 +199,6 @@ static inline int tcg_target_const_match(tcg_target_long 
> val,
>  #define JCC_JLE 0xe
>  #define JCC_JG  0xf
>  
> -#define P_EXT   0x100 /* 0x0f opcode prefix */
> -
>  static const uint8_t tcg_cond_to_jcc[10] = {
>  [TCG_COND_EQ] = JCC_JE,
>  [TCG_COND_NE] = JCC_JNE,
> @@ -288,6 +291,27 @@ static inline void tcg_out_st(TCGContext *s, TCGType 
> type, int arg,
>  tcg_out_modrm_offset(s, 0x89, arg, arg1, arg2);
>  }
>  
> +static void tcg_out_ext8u(TCGContext *s, int dest, int src)
> +{
> +if (src >= 4) {
> +tcg_out_mov(s, dest, src);
> +if (dest >= 4) {
> +tcg_out_modrm(s, 0x81, ARITH_AND, dest);
> +tcg_out32(s, 0xff);
> +return;
> +}
> +src = dest;
> +}
> +/* movzbl */
> +tcg_out_modrm(s, OPC_MOVZBL, dest, src);
> +}
> +
> +static inline void tcg_out_ext16u(TCGContext *s, int dest, int src)
> +{
> +/* movzwl */
> +tcg_out_modrm(s, OPC_MOVZWL, dest, src);
> +}
> +
>  static inline void tgen_arithi(TCGContext *s, int c, int r0, int32_t val, 
> int cf)
>  {
>  if (!cf && ((c == ARITH_ADD && val == 1) || (c == ARITH_SUB && val == 
> -1))) {
> @@ -300,11 +324,9 @@ static inline void tgen_arithi(TCGContext *s, int c, int 
> r0, int32_t val, int cf
>  tcg_out_modrm(s, 0x83, c, r0);
>  tcg_out8(s, val);
>  } else if (c == ARITH_AND && val == 0xffu && r0 < 4) {
> -/* movzbl */
> -tcg_out_modrm(s, 0xb6 | P_EXT, r0, r0);
> +tcg_out_ext8u(s, r0, r0);
>  } else if (c == ARITH_AND && val == 0xu) {
> -/* movzwl */
> -tcg_out_modrm(s, 0xb7 | P_EXT, r0, r0);
> +tcg_out_ext16u(s, r0, r0);
>  } else {
>  tcg_out_modrm(s, 0x81, c, r0);
>  tcg_out32(s, val);
> @@ -645,12 +667,10 @@ static void tcg_out_qemu_ld(TCGContext *s, const TCGArg 
> *args,
>  tcg_out_modrm(s, 0xbf | P_EXT, data_reg, TCG_REG_EAX);
>  break;
>  case 0:
> -/* movzbl */
> -tcg_out_modrm(s, 0xb6 | P_EXT, data_reg, TCG_REG_EAX);
> +tcg_out_ext8u(s, data_reg, TCG_REG_EAX);
>  break;
>  case 1:
> -/* movzwl */
> -tcg_out_modrm(s, 0xb7 | P_EXT, data_reg, TCG_REG_EAX);
> +tcg_out_ext16u(s, data_reg, TCG_REG_EAX);
>  break;
>  case 2:
>  default:
> @@ -690,7 +710,7 @@ static void tcg_out_qemu_ld(TCGContext *s, const TCGArg 
> *args,
>  switch(opc) {
>  case 0:
>  /* movzbl */
> -tcg_out_modrm_offset(s, 0xb6 | P_EXT, data_reg, r0, GUEST_BASE);
> +tcg_out_modrm_offset(s, OPC_MOVZBL, data_reg, r0, GUEST_BASE);
>  break;
>  case 0 | 4:
>  /* movsbl */
> @@ -698,7 +718,7 @@ static void tcg_out_qemu_ld(TCGContext *s, const TCGArg 
> *args,
>  break;
>  case 1:
>  /* movzwl */
> -tcg_out_modrm_offset(s, 0xb7 | P_EXT, data_reg, r0, GUEST_BASE);
> + 

Re: [Qemu-devel] [PATCH 01/22] tcg-i386: Allocate call-saved registers first.

[Aurelien Jarno]

On Tue, Apr 13, 2010 at 03:23:53PM -0700, Richard Henderson wrote:
> Signed-off-by: Richard Henderson 
> ---
>  tcg/i386/tcg-target.c |   13 +
>  1 files changed, 9 insertions(+), 4 deletions(-)

Thanks, applied.

> diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
> index e684b33..f5c24f7 100644
> --- a/tcg/i386/tcg-target.c
> +++ b/tcg/i386/tcg-target.c
> @@ -36,16 +36,21 @@ static const char * const 
> tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
>  #endif
>  
>  static const int tcg_target_reg_alloc_order[] = {
> -TCG_REG_EAX,
> -TCG_REG_EDX,
> -TCG_REG_ECX,
>  TCG_REG_EBX,
>  TCG_REG_ESI,
>  TCG_REG_EDI,
>  TCG_REG_EBP,
> +TCG_REG_ECX,
> +TCG_REG_EDX,
> +TCG_REG_EAX,
> +};
> +
> +static const int tcg_target_call_iarg_regs[3] = {
> +TCG_REG_EAX,
> +TCG_REG_EDX,
> +TCG_REG_ECX
>  };
>  
> -static const int tcg_target_call_iarg_regs[3] = { TCG_REG_EAX, TCG_REG_EDX, 
> TCG_REG_ECX };
>  static const int tcg_target_call_oarg_regs[2] = { TCG_REG_EAX, TCG_REG_EDX };
>  
>  static uint8_t *tb_ret_addr;
> -- 
> 1.6.6.1
> 
> 
> 
> 

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net