[Qemu-devel] [PATCH 3/4] megasas: Add some more functions to keep Windows happy
We shouldn't announce we have BIOS disabled, otherwise
Windows will barf. And Windows7 insists on sending CLUSTER
commands, so we can just implement them, too.
Signed-off-by: Hannes Reinecke
---
hw/megasas.c | 24 ++--
hw/mfi.h |1 +
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/hw/megasas.c b/hw/megasas.c
index c3b74ef..e91c96b 100644
--- a/hw/megasas.c
+++ b/hw/megasas.c
@@ -556,7 +556,6 @@ static int megasas_dcmd_get_bios_info(MPTState *d, struct
megasas_cmd_t *cmd)
memset(&info, 0x0, sizeof(info));
info.continue_on_error = 1;
-info.do_not_int_13 = 1;
memcpy(cmd->iov_buf, (uint8_t *)&info, sizeof(info));
return sizeof(info);
@@ -572,6 +571,18 @@ static int megasas_dcmd_get_fw_time(MPTState *d, struct
megasas_cmd_t *cmd)
return sizeof(fw_time);
}
+static int megasas_dcmd_set_fw_time(MPTState *d, struct megasas_cmd_t *cmd)
+{
+uint64_t fw_time;
+
+memcpy(&fw_time, cmd->frame->dcmd.mbox, sizeof(fw_time));
+DPRINTF("set fw time %lx\n", fw_time);
+fw_time = megasas_fw_time();
+memcpy(cmd->iov_buf, (uint8_t *)&fw_time, sizeof(fw_time));
+
+return sizeof(fw_time);
+}
+
static int megasas_dcmd_pd_get_list(MPTState *s, struct megasas_cmd_t *cmd)
{
struct mfi_pd_list info;
@@ -865,7 +876,6 @@ static int megasas_handle_dcmd(MPTState *s, struct
megasas_cmd_t *cmd)
size = megasas_dcmd_set_properties(s, cmd);
retval = MFI_STAT_OK;
break;
- case 0x01080102:
case MFI_DCMD_CFG_READ:
case MFI_DCMD_CFG_FOREIGN_READ:
case MFI_DCMD_CTRL_EVENT_GETINFO:
@@ -878,6 +888,12 @@ static int megasas_handle_dcmd(MPTState *s, struct
megasas_cmd_t *cmd)
#endif
retval = MFI_STAT_INVALID_DCMD;
break;
+ case MFI_DCMD_CLUSTER_RESET_ALL:
+ case MFI_DCMD_CLUSTER_RESET_LD:
+ /* Cluster reset commands have a size of 0 */
+ size = 0;
+ retval = MFI_STAT_OK;
+ break;
case MFI_DCMD_CTRL_GET_BIOS_INFO:
size = megasas_dcmd_get_bios_info(s, cmd);
retval = MFI_STAT_OK;
@@ -886,6 +902,10 @@ static int megasas_handle_dcmd(MPTState *s, struct
megasas_cmd_t *cmd)
size = megasas_dcmd_get_fw_time(s, cmd);
retval = MFI_STAT_OK;
break;
+ case MFI_DCMD_CTRL_SET_TIME:
+ size = megasas_dcmd_set_fw_time(s, cmd);
+ retval = MFI_STAT_OK;
+ break;
case 0x010e0301:
case 0x010e0302:
case 0x010e8481:
diff --git a/hw/mfi.h b/hw/mfi.h
index 312563e..0beb1b6 100644
--- a/hw/mfi.h
+++ b/hw/mfi.h
@@ -167,6 +167,7 @@ typedef enum {
MFI_DCMD_CTRL_SHUTDOWN =0x0105,
MFI_DCMD_HIBERNATE_SHUTDOWN = 0x0106,
MFI_DCMD_CTRL_GET_TIME =0x01080101,
+ MFI_DCMD_CTRL_SET_TIME =0x01080102,
MFI_DCMD_CTRL_GET_BIOS_INFO = 0x010c0100,
MFI_DCMD_CTRL_FACTORY_DEFAULTS =0x010d,
MFI_DCMD_CTRL_MFC_DEFAULTS_GET =0x010e0201,
--
1.6.0.2
[Qemu-devel] Re: [PATCH 1/2] Compile pckbd only once
On 05/17/2010 07:45 PM, Blue Swirl wrote: Use a qemu_irq to indicate A20 line changes. Move I/O port 92 to pckbd.c. Looks good, hypothetical Mac hardware support (Macs only use USB keyboards) would need a new chipset implementation and that can take care of implementing port 92. Thanks. Paolo
[Qemu-devel] [PATCH 10/10] vnc: update copyrights for vnc-encoding-tight.c
Signed-off-by: Corentin Chary --- vnc-encoding-tight.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c index b836569..0c661a9 100644 --- a/vnc-encoding-tight.c +++ b/vnc-encoding-tight.c @@ -1,9 +1,14 @@ /* * QEMU VNC display driver: tight encoding * + * From libvncserver/tight.c + * Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved. + * Copyright (C) 2000, 2001 Const Kaplinsky. All Rights Reserved. + * * Copyright (C) 2006 Anthony Liguori * Copyright (C) 2006 Fabrice Bellard * Copyright (C) 2009 Red Hat, Inc + * Copyright (C) 2019 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 -- 1.7.0.2
[Qemu-devel] [PATCH 03/10] vnc: only use a single zlib stream
According to http://tigervnc.org/cgi-bin/rfbproto#zlib-encoding
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 02/10] vnc: really call zlib if we want zlib
Signed-off-by: Corentin Chary
---
vnc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/vnc.c b/vnc.c
index a91c3a3..d0c0d00 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 4/4] megasas: Implement ABORT_CMD
Win7 is impatient during shutdown and is sending 'ABORT_CMD' frames.
Haven't tried to figure out _why_, but we should be handling them
nevertheless.
Signed-off-by: Hannes Reinecke
---
hw/megasas.c | 49 -
hw/mfi.h |2 +-
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/hw/megasas.c b/hw/megasas.c
index e91c96b..c249914 100644
--- a/hw/megasas.c
+++ b/hw/megasas.c
@@ -241,13 +241,13 @@ static inline int megasas_next_index(MPTState *s, int
index)
return index;
}
-static inline struct megasas_cmd_t *megasas_next_frame(MPTState *s,
+static inline struct megasas_cmd_t *megasas_lookup_frame(MPTState *s,
target_phys_addr_t frame)
{
struct megasas_cmd_t *cmd = NULL;
-int num = 0, tail, index;
+int num = 0, index;
-tail = index = s->reply_queue_index;
+index = s->reply_queue_index;
while (num < MEGASAS_MAX_FRAMES) {
if (s->frames[index].pa && s->frames[index].pa == frame) {
@@ -257,14 +257,25 @@ static inline struct megasas_cmd_t
*megasas_next_frame(MPTState *s,
index = megasas_next_index(s, index);
num++;
}
+
+return cmd;
+}
+
+static inline struct megasas_cmd_t *megasas_next_frame(MPTState *s,
+target_phys_addr_t frame)
+{
+struct megasas_cmd_t *cmd = NULL;
+int num = 0, index;
+
+cmd = megasas_lookup_frame(s, frame);
if (cmd) {
#ifdef DEBUG_MEGASAS_QUEUE
- DPRINTF("Found mapped frame %x context %x pa %lx\n", index,
+ DPRINTF("Found mapped frame %x context %x pa %lx\n", cmd->index,
cmd->frame->header.context, cmd->pa);
#endif
return cmd;
}
-index = tail;
+index = s->reply_queue_index;
num = 0;
while (num < MEGASAS_MAX_FRAMES) {
if (!s->frames[index].pa) {
@@ -1067,6 +1078,31 @@ static void megasas_command_complete(SCSIRequest *req)
megasas_dequeue_frame(cmd->state, context);
}
+static int megasas_handle_abort(MPTState *s, struct megasas_cmd_t *cmd)
+{
+uint32_t abort_ctx = le32_to_cpu(cmd->frame->abort.abort_context);
+target_phys_addr_t abort_addr, addr_hi, addr_lo;
+struct megasas_cmd_t *abort_cmd;
+
+addr_hi = le32_to_cpu(cmd->frame->abort.abort_mfi_addr_hi);
+addr_lo = le32_to_cpu(cmd->frame->abort.abort_mfi_addr_lo);
+abort_addr = (addr_hi << 32) | addr_lo;
+
+abort_cmd = megasas_lookup_frame(s, abort_addr);
+if (!abort_cmd) {
+ DPRINTF("No active command for frame context %x\n", abort_ctx);
+ return MFI_STAT_OK;
+}
+if (abort_cmd->frame->header.context != abort_ctx) {
+ DPRINTF("abort frame %x: invalid context %x\n", abort_cmd->index,
+ abort_cmd->frame->header.context);
+ return MFI_STAT_ABORT_NOT_POSSIBLE;
+}
+DPRINTF("aborting frame context %x\n", abort_ctx);
+megasas_abort_command(abort_cmd);
+return MFI_STAT_OK;
+}
+
static void megasas_handle_frame(MPTState *s, target_phys_addr_t frame_addr,
uint32_t frame_count)
{
@@ -1098,6 +1134,9 @@ static void megasas_handle_frame(MPTState *s,
target_phys_addr_t frame_addr,
case MFI_CMD_DCMD:
frame_status = megasas_handle_dcmd(s, cmd);
break;
+ case MFI_CMD_ABORT:
+ frame_status = megasas_handle_abort(s, cmd);
+ break;
case MFI_CMD_PD_SCSI_IO:
case MFI_CMD_LD_SCSI_IO:
frame_status = megasas_handle_scsi(s, cmd);
diff --git a/hw/mfi.h b/hw/mfi.h
index 0beb1b6..f73cda7 100644
--- a/hw/mfi.h
+++ b/hw/mfi.h
@@ -125,7 +125,7 @@
#define MFI_FWSTATE_MAXSGL_MASK0x00ff
#define MFI_FWSTATE_MAXCMD_MASK0x
#define MFI_FWSTATE_HOSTMEMREQD_MASK 0x0800
-#define MFI_FWSTATE_BOOT_MESSAGE_PENDING 0x9000
+
/*
* Control bits to drive the card to ready state. These go into the IDB
* register.
--
1.6.0.2
[Qemu-devel] [PATCH 1/4] megasas: Add more controller property definitions
The megaraid_sas driver has some more controller property defintions.
Signed-off-by: Hannes Reinecke
---
hw/mfi.h | 41 +++--
1 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/hw/mfi.h b/hw/mfi.h
index f3c82e0..312563e 100644
--- a/hw/mfi.h
+++ b/hw/mfi.h
@@ -508,7 +508,7 @@ struct mfi_init_qinfo {
uint32_tci_addr_hi;
} __attribute__ ((packed));
-/* SAS (?) controller properties, part of mfi_ctrl_info */
+/* Controller properties */
struct mfi_ctrl_props {
uint16_tseq_num;
uint16_tpred_fail_poll_interval;
@@ -531,7 +531,44 @@ struct mfi_ctrl_props {
uint16_tecc_bucket_leak_rate;
uint8_t restore_hotspare_on_insertion;
uint8_t expose_encl_devices;
- uint8_t reserved[38];
+ uint8_t maintainPdFailHistory;
+ uint8_t disallowHostRequestReordering;
+ uint8_t abortCCOnError;
+ uint8_t loadBalanceMode;
+ uint8_t disableAutoDetectBackplane;
+ uint8_t snapVDSpace;
+ struct {
+ uint32_tcopyBackDisabled: 1; // set TRUE to
disable copyBack (0=copback enabled)
+ uint32_tSMARTerEnabled : 1;
+ uint32_tprCorrectUnconfiguredAreas : 1;
+ uint32_tuseFdeOnly : 1;
+ uint32_tdisableNCQ : 1;
+ uint32_tSSDSMARTerEnabled : 1;
+ uint32_tSSDPatrolReadEnabled: 1;
+ uint32_tenableSpinDownUnconfigured : 1;
+ uint32_tautoEnhancedImport : 1;
+ uint32_tenableSecretKeyControl : 1;
+ uint32_tdisableOnlineCtrlReset : 1;
+ uint32_tallowBootWithPinnedCache : 1;
+ uint32_tdisableSpinDownHS : 1;
+ uint32_tenableJBOD : 1;
+ uint32_treserved:18;
+ } OnOffProperties;
+ uint8_t autoSnapVDSpace; /* % of source LD to be
+ * reserved for auto snapshot
+ * in snapshot repository, for
+ * metadata and user data
+ * 1=5%, 2=10%, 3=15% and so on
+ */
+ uint8_t viewSpace; /* snapshot writeable VIEWs
+ * capacity as a % of source LD
+ * capacity. 0=READ only
+ * 1=5%, 2=10%, 3=15% and so on
+ */
+ uint16_tspinDownTime;/* # of idle minutes before device
+ * is spun down (0=use FW defaults)
+ */
+ uint8_t reserved[24];
} __attribute__ ((packed));
/* PCI information about the card. */
--
1.6.0.2
[Qemu-devel] [PATCH 09/10] vnc: tight: add palette encoding
Signed-off-by: Corentin Chary
---
vnc-encoding-tight.c | 430 --
1 files changed, 418 insertions(+), 12 deletions(-)
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index 44984f9..b836569 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -27,6 +27,8 @@
#include
+#include "qdict.h"
+#include "qint.h"
#include "vnc.h"
#include "vnc-encoding-tight.h"
@@ -55,6 +57,279 @@ 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++; \
+} else if (ci == c1) { \
+n1++; \
+} else \
+
[Qemu-devel] [PATCH 06/10] vnc: add support for tight fill encoding
Signed-off-by: Corentin Chary
---
vnc-encoding-tight.c | 245 +-
1 files changed, 244 insertions(+), 1 deletions(-)
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index 0d328c2..5ea90c0 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -54,6 +54,135 @@ 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_ptr)
+{
+int cx, cy;
+
+/* Try to extend the area upwards. */
+for ( cy = *y_ptr - 1;
+ cy >= y && check_solid_tile(vs, *x_ptr, cy, *w_ptr, 1, &color, true);
+ cy-- );
+*h_ptr += *y_ptr - (cy + 1);
+*y_ptr = cy + 1;
+
+/* .
[Qemu-devel] [PATCH 08/10] vnc: remove memory leaks in zlib and tight encoding
Also introduce a new helper to free buffers: buffer_free()
Signed-off-by: Corentin Chary
---
vnc-encoding-tight.c | 11 +++
vnc-encoding-zlib.c |8
vnc.c| 23 ++-
vnc.h|4 +++-
4 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index 229927e..44984f9 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -499,6 +499,17 @@ static int find_large_solid_color_rect(VncState *vs, int
x, int y,
return n + send_rect_simple(vs, x, y, w, h);
}
+void vnc_tight_clear(VncState *vs)
+{
+int i;
+for (i=0; itight_stream); i++)
+if (vs->tight_stream[i].opaque)
+deflateEnd(&vs->tight_stream[i]);
+
+buffer_free(&vs->tight);
+buffer_free(&vs->tight_zlib);
+}
+
int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y,
int w, int h)
{
diff --git a/vnc-encoding-zlib.c b/vnc-encoding-zlib.c
index 6b68540..e5a431e 100644
--- a/vnc-encoding-zlib.c
+++ b/vnc-encoding-zlib.c
@@ -143,3 +143,11 @@ int vnc_zlib_send_framebuffer_update(VncState *vs, int x,
int y, int w, int h)
return 1;
}
+
+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 f660c10..0dac736 100644
--- a/vnc.c
+++ b/vnc.c
@@ -503,7 +503,15 @@ uint8_t *buffer_end(Buffer *buffer)
void buffer_reset(Buffer *buffer)
{
-buffer->offset = 0;
+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)
@@ -922,17 +930,14 @@ 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);
+vnc_tight_clear(vs);
+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 ea6e70b..18a4e8b 100644
--- a/vnc.h
+++ b/vnc.h
@@ -383,7 +383,7 @@ int buffer_empty(Buffer *buffer);
uint8_t *buffer_end(Buffer *buffer);
void buffer_reset(Buffer *buffer);
void buffer_append(Buffer *buffer, const void *data, size_t len);
-
+void buffer_free(Buffer *buffer);
/* Misc helpers */
@@ -403,10 +403,12 @@ int 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_clear(VncState *vs);
void *vnc_zlib_zalloc(void *x, unsigned items, unsigned size);
void vnc_zlib_zfree(void *x, void *addr);
int vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
+void vnc_tight_clear(VncState *vs);
int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y, int w, int
h);
#endif /* __QEMU_VNC_H */
--
1.7.0.2
[Qemu-devel] [PATCH 05/10] vnc: add basic tight support
This patch only add support for "basic" compression
without any filter.
Signed-off-by: Corentin Chary
---
Makefile |2 +
Makefile.objs |1 +
vnc-encoding-hextile.c |5 +-
vnc-encoding-tight.c | 287
vnc-encoding-tight.h | 200 +
vnc-encoding-zlib.c| 17 ++-
vnc.c | 37 +--
vnc.h | 17 +++-
8 files changed, 544 insertions(+), 22 deletions(-)
create mode 100644 vnc-encoding-tight.c
create mode 100644 vnc-encoding-tight.h
diff --git a/Makefile b/Makefile
index eb9e02b..99d9c5d 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-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-tight.c b/vnc-encoding-tight.c
new file mode 100644
index 000..0d328c2
--- /dev/null
+++ b/vnc-encoding-tight.c
@@ -0,0 +1,287 @@
+/*
+ * QEMU VNC display driver: tight encoding
+ *
+ * Copyright (C) 2006 Anthony Liguori
+ * Copyright (C) 2006 Fabrice Bellard
+ * Copyright (C) 2009 Red Hat, Inc
+ *
+ * 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, 2
[Qemu-devel] [PATCH 0/4] megasas update for Windows 7
Hi Nic, this is a patchset to get megasas running smoothly with Windows 7. I have implemented some more missing functions and tweaked the controller settings to keep Windows 7 happy. With this Windows7 boots up just nicely using megasas for the root disk. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc
On 05/17/2010 10:21 PM, Gerd Hoffmann wrote: Dunno. Gerd, what do you think? There is a PCIDevice for each function. PCIDevice->devfn (aka addr property) contains slot+function. So hw/pci.c can figure which device functions belong to the same slot. The pci hotplug code might need some fixes to handle multi-function devices correctly though (I guess this is the original issue?). The original issue is that the code does not model reality. Yes, it only hurts with multifunction devices. We need a PCIDevice->devaddr and PCIDevice->function[]->fnaddr. unplug is probably easy, plug might be harder. You have to plug-in all functions belonging to the slot first, then signal the guest that the slot has been hotplugged, which might need changes in the monitor protocol. We need to plug in a device, not functions. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] [PATCH 07/10] vnc: don't clear zlib stream on set_encoding
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 tight and zlib encodings.
Signed-off-by: Corentin Chary
---
vnc-encoding-tight.c |7 ---
vnc-encoding-zlib.c |5 -
vnc.c|2 --
vnc.h|2 --
4 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index 5ea90c0..229927e 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -499,13 +499,6 @@ static int find_large_solid_color_rect(VncState *vs, int
x, int y,
return n + send_rect_simple(vs, x, y, w, h);
}
-void vnc_tight_init(VncState *vs)
-{
-int i;
-for (i=0; itight_stream); i++)
-vs->tight_stream[i].opaque = NULL;
-}
-
int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y,
int w, int h)
{
diff --git a/vnc-encoding-zlib.c b/vnc-encoding-zlib.c
index 17a61bf..6b68540 100644
--- a/vnc-encoding-zlib.c
+++ b/vnc-encoding-zlib.c
@@ -143,8 +143,3 @@ int vnc_zlib_send_framebuffer_update(VncState *vs, int x,
int y, int w, int h)
return 1;
}
-
-void vnc_zlib_init(VncState *vs)
-{
-vs->zlib_stream.opaque = NULL;
-}
diff --git a/vnc.c b/vnc.c
index c7b76ff..f660c10 100644
--- a/vnc.c
+++ b/vnc.c
@@ -1610,8 +1610,6 @@ static void set_encodings(VncState *vs, int32_t
*encodings, size_t n_encodings)
int i;
unsigned int enc = 0;
-vnc_zlib_init(vs);
-vnc_tight_init(vs);
vs->features = 0;
if (!vs->vnc_encoding)
vs->vnc_encoding = -1;
diff --git a/vnc.h b/vnc.h
index ec7f481..ea6e70b 100644
--- a/vnc.h
+++ b/vnc.h
@@ -403,12 +403,10 @@ int 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_zalloc(void *x, unsigned items, unsigned size);
void vnc_zlib_zfree(void *x, void *addr);
int vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
-void vnc_tight_init(VncState *vs);
int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y, int w, int
h);
#endif /* __QEMU_VNC_H */
--
1.7.0.2
[Qemu-devel] (no subject)
>From 42415cc70a087e9a280667eddbeb2af1029c96a0 Mon Sep 17 00:00:00 2001 From: Corentin Chary Date: Tue, 18 May 2010 09:23:48 +0200 Subject: [PATCH 00/10] vnc encodings Cc: Anthony Liguori , Alexander Graf , Adam Litke Hi, I this series you'll find zlib fixes and a new tight encoding. 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 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 (10): vnc: refactor set_encodings vnc: really call zlib if we want zlib vnc: only use a single zlib stream vnc: adjust compression zstream level vnc: add basic tight support vnc: add support for tight fill encoding vnc: don't clear zlib stream on set_encoding vnc: remove memory leaks in zlib and tight encoding vnc: tight: add palette encoding vnc: update copyrights for vnc-encoding-tight.c Makefile |2 + Makefile.objs |1 + vnc-encoding-hextile.c |5 +- vnc-encoding-tight.c | 945 vnc-encoding-tight.h | 200 ++ vnc-encoding-zlib.c| 43 ++- vnc.c | 79 +++-- vnc.h | 24 +- 8 files changed, 1246 insertions(+), 53 deletions(-) create mode 100644 vnc-encoding-tight.c create mode 100644 vnc-encoding-tight.h
[Qemu-devel] [PATCH 04/10] vnc: adjust compression zstream level
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 2/4] megasas: Implement get_bios and get_time DCMDs
Some more functions.
Signed-off-by: Hannes Reinecke
---
hw/megasas.c | 73 ++---
1 files changed, 64 insertions(+), 9 deletions(-)
diff --git a/hw/megasas.c b/hw/megasas.c
index 8f95596..c3b74ef 100644
--- a/hw/megasas.c
+++ b/hw/megasas.c
@@ -6,7 +6,7 @@
* This code is licenced under the LGPL.
*/
-
+#include
#include
#include "hw.h"
@@ -210,6 +210,26 @@ static int megasas_get_inq(SCSIDevice *sdev, int pg,
uint8_t *buf, int buflen)
}
/*
+ * Utility functions
+ */
+static uint64_t megasas_fw_time(void)
+{
+const time_t now = time(NULL);
+struct tm *curtime;
+uint64_t bcd_time;
+
+curtime = gmtime(&now);
+bcd_time = ((uint64_t)curtime->tm_sec & 0xff) << 48 |
+ ((uint64_t)curtime->tm_min & 0xff) << 40 |
+ ((uint64_t)curtime->tm_hour & 0xff) << 32 |
+ ((uint64_t)curtime->tm_mday & 0xff) << 24 |
+ ((uint64_t)curtime->tm_mon & 0xff) << 16 |
+ ((uint64_t)(curtime->tm_year + 1900) & 0x);
+
+return bcd_time;
+}
+
+/*
* Frame handling
*/
@@ -462,6 +482,8 @@ static int megasas_ctrl_get_info(MPTState *s, struct
megasas_cmd_t *cmd)
info.device.port_count = 2;
memcpy(info.product_name,"MegaRAID SAS 8708EM2", 20);
+sprintf(info.package_version,"%s-QEMU", QEMU_VERSION);
+info.current_fw_time = megasas_fw_time();
info.max_arms = 32;
info.max_spans = 8;
info.max_arrays = MEGASAS_MAX_LUNS;
@@ -477,14 +499,16 @@ static int megasas_ctrl_get_info(MPTState *s, struct
megasas_cmd_t *cmd)
info.nvram_size = 32;
info.flash_size = 16;
info.raid_levels = MFI_INFO_RAID_0;
-info.adapter_ops = MFI_INFO_AOPS_RBLD_RATE | MFI_INFO_AOPS_SELF_DIAGNOSTIC
| MFI_INFO_AOPS_MIXED_ARRAY;
+info.adapter_ops = MFI_INFO_AOPS_RBLD_RATE |
+ MFI_INFO_AOPS_SELF_DIAGNOSTIC |
+ MFI_INFO_AOPS_MIXED_ARRAY;
info.ld_ops = MFI_INFO_LDOPS_DISK_CACHE_POLICY |
MFI_INFO_LDOPS_ACCESS_POLICY |
MFI_INFO_LDOPS_IO_POLICY |
MFI_INFO_LDOPS_WRITE_POLICY |
MFI_INFO_LDOPS_READ_POLICY;
info.max_strips_per_io = 42;
-info.stripe_sz_ops.min = 6;
+info.stripe_sz_ops.min = 4;
info.stripe_sz_ops.max = 0xf;
info.properties.pred_fail_poll_interval = 300;
info.properties.intr_throttle_cnt = 16;
@@ -513,17 +537,41 @@ static int megasas_mfc_get_defaults(MPTState *s, struct
megasas_cmd_t *cmd)
memset(&info, 0x0, sizeof(info));
-info.stripe_size = 64;
+info.stripe_size = 8;
info.flush_time = 4;
+info.background_rate = 30;
info.allow_mix_in_enclosure = 1;
info.allow_mix_in_ld = 1;
info.direct_pd_mapping = 1;
info.bios_enumerate_lds = 1;
+info.disable_ctrl_r = 1;
memcpy(cmd->iov_buf, (uint8_t *)&info, sizeof(info));
return sizeof(info);
}
+static int megasas_dcmd_get_bios_info(MPTState *d, struct megasas_cmd_t *cmd)
+{
+struct mfi_bios_data info;
+
+memset(&info, 0x0, sizeof(info));
+info.continue_on_error = 1;
+info.do_not_int_13 = 1;
+memcpy(cmd->iov_buf, (uint8_t *)&info, sizeof(info));
+
+return sizeof(info);
+}
+
+static int megasas_dcmd_get_fw_time(MPTState *d, struct megasas_cmd_t *cmd)
+{
+uint64_t fw_time;
+
+fw_time = megasas_fw_time();
+memcpy(cmd->iov_buf, (uint8_t *)&fw_time, sizeof(fw_time));
+
+return sizeof(fw_time);
+}
+
static int megasas_dcmd_pd_get_list(MPTState *s, struct megasas_cmd_t *cmd)
{
struct mfi_pd_list info;
@@ -732,11 +780,11 @@ static int megasas_dcmd_dummy(MPTState *s, struct
megasas_cmd_t *cmd)
static int megasas_handle_dcmd(MPTState *s, struct megasas_cmd_t *cmd)
{
-int opcode, size = 0;
+int opcode, size = 0, len;
int retval = 0;
opcode = le32_to_cpu(cmd->frame->dcmd.opcode);
-megasas_map_dcmd(cmd);
+len = megasas_map_dcmd(cmd);
#ifdef DEBUG_MEGASAS_MFI
DPRINTF("MFI DCMD opcode %x\n", opcode);
#endif
@@ -830,16 +878,23 @@ static int megasas_handle_dcmd(MPTState *s, struct
megasas_cmd_t *cmd)
#endif
retval = MFI_STAT_INVALID_DCMD;
break;
+ case MFI_DCMD_CTRL_GET_BIOS_INFO:
+ size = megasas_dcmd_get_bios_info(s, cmd);
+ retval = MFI_STAT_OK;
+ break;
+ case MFI_DCMD_CTRL_GET_TIME:
+ size = megasas_dcmd_get_fw_time(s, cmd);
+ retval = MFI_STAT_OK;
+ break;
case 0x010e0301:
case 0x010e0302:
case 0x010e8481:
- case MFI_DCMD_CTRL_GET_TIME:
- DPRINTF("MFI DCMD %x dummy return\n", opcode);
+ DPRINTF("MFI DCMD %x dummy return %d bytes\n", opcode, len);
size = megasas_dcmd_dummy(s, cmd);
retval = MFI_STAT_OK;
break;
default:
- DPRINTF("MFI DCMD %x unhandled\n", opcode);
+ DPRINTF("MFI DCMD %x unhandled (len %d)\n", opcode, len);
retval = MFI_STAT_INVALID_DCMD;
break;
}
--
1.6.0.2
[Qemu-devel] [PATCH 01/10] vnc: refactor set_encodings
Signed-off-by: Corentin Chary
---
vnc.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/vnc.c b/vnc.c
index 1f7ad73..a91c3a3 100644
--- a/vnc.c
+++ b/vnc.c
@@ -1587,6 +1587,13 @@ static void send_ext_audio_ack(VncState *vs)
vnc_flush(vs);
}
+static void set_encoding(VncState *vs, int encoding)
+{
+if (vs->vnc_encoding == -1) {
+vs->vnc_encoding = encoding;
+}
+}
+
static void set_encodings(VncState *vs, int32_t *encodings, size_t n_encodings)
{
int i;
@@ -1603,24 +1610,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;
-}
+set_encoding(vs, 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;
-}
+set_encoding(vs, enc);
break;
case VNC_ENCODING_ZLIB:
vs->features |= VNC_FEATURE_ZLIB_MASK;
-if (vs->vnc_encoding != -1) {
-vs->vnc_encoding = enc;
-}
+set_encoding(vs, enc);
break;
case VNC_ENCODING_DESKTOPRESIZE:
vs->features |= VNC_FEATURE_RESIZE_MASK;
--
1.7.0.2
Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
On Tue, 18 May 2010, Kevin Wolf wrote: > Am 17.05.2010 23:43, schrieb Anthony Liguori: > > On 05/17/2010 04:35 PM, malc wrote: > >> There's one thing that SDL does marvelously well - it's just one fairly > >> small and self contained library that doesn't unleash dependency hell on > >> the user. > >> > >>> The fact that we have cocoa support in the tree is basically an admission > >>> of > >>> failure with SDL. > >>> > >> I don't think so, the way i see it: someone had an itch (i.e. an > >> application that does not integrate well with his windowing environment) > >> and he scratched it. > >> > > > > SDL doesn't integrate well into a modern Gnome desktop either. I don't > > see why we have Cocoa and not Gtk. If the answer is, someone needs to > > send patches, expect patches soon :-) > > So with this argument, we'll not only get a GTK backend, but Qt and > Windows backends, too? But then you can't reasonably say any more that > DirectFB would be too much additional code to maintain. My personal opinion is that SDL does a decent job at rendering a window in a X11 environment, but given the current SDL limitation with directfb, we need another output mechanism to cover that case, so that we can have multiple guests fullscreen on different host virtual terminals. This is an important use case for embedded environments. I don't think GTK or Qt would add much to what SDL already offers, unless we want to develop our own management GUI for qemu, but I don't think is a very good idea. I think it would be better to implement an accelerated frontend for rendering the framebuffer, like opengl or xv.
Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
Am 17.05.2010 23:43, schrieb Anthony Liguori: > On 05/17/2010 04:35 PM, malc wrote: >> There's one thing that SDL does marvelously well - it's just one fairly >> small and self contained library that doesn't unleash dependency hell on >> the user. >> >>> The fact that we have cocoa support in the tree is basically an admission of >>> failure with SDL. >>> >> I don't think so, the way i see it: someone had an itch (i.e. an >> application that does not integrate well with his windowing environment) >> and he scratched it. >> > > SDL doesn't integrate well into a modern Gnome desktop either. I don't > see why we have Cocoa and not Gtk. If the answer is, someone needs to > send patches, expect patches soon :-) So with this argument, we'll not only get a GTK backend, but Qt and Windows backends, too? But then you can't reasonably say any more that DirectFB would be too much additional code to maintain. Kevin
[Qemu-devel] Re: [PATCH RFC] virtio_blk: Use blk-iopoll for host->guest notify
On Fri, May 14, 2010 at 05:30:56PM -0500, Brian Jackson wrote: > Any preliminary numbers? latency, throughput, cpu use? What about comparing > different "weights"? I am running benchmarks and will report results when they are in. Stefan
[Qemu-devel] Suggested Parameters for SLES 10 64-bit
Hi, we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are not very stable by now. With ACPI they end up in a kernel panic at boot time and without they occasionally hang during boot or shortly after. Has anyone experience with suitable kvm and/or kernel parameters to get this stable? Thanks, Peter
[Qemu-devel] Re: [PATCH 01/10] vnc: refactor set_encodings
On 18.05.2010, at 09:31, Corentin Chary wrote: This is missing a patch description. When people later on either cherry-pick your commits or simply git show them, it's almost impossible to know what's going on. So please always put in a patch description. Alex > Signed-off-by: Corentin Chary > --- > vnc.c | 19 ++- > 1 files changed, 10 insertions(+), 9 deletions(-)
Re: [Qemu-devel] Qemu-KVM 0.12.4 Guest entered Paused State
Hi Anthony, unfortunately its not that easy. There is enough free disk space on the host, there is enough free mem and there are also enough free hugetables. The guest has its own storage on an iSCSI SAN. I run the dist-upgrade in the guest, btw. Any idea how I can figure out what happened. There is no output on the console. BR, Peter 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. 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 .
[Qemu-devel] Re: [PATCH 01/10] vnc: refactor set_encodings
On 18.05.2010, at 09:31, Corentin Chary wrote: > Signed-off-by: Corentin Chary I'm also missing a cover letter explaining what your patch set does. As a general rule of thumb, whenever your patch set spans more than 2 patches, a cover letter is really helpful. To generate one, use git-format-patch --cover-letter. Alex
Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
On 05/18/10 11:12, Stefano Stabellini wrote: I think it would be better to implement an accelerated frontend for rendering the framebuffer, like opengl or xv. Well. xv is pretty pointless IMHO. gl makes sense. But to have some effect this needs some major restructions in qemu, the current DisplayState infrastructure can't handle anything but a simple, stupid framebuffer. There isn't much to accelerate, except maybe scaling the guest display to fullscreen on the host. qxl + spice will change that though. qxl is a paravirtualized gfx adapter. Guest sends rendering commands. The spice protocol sends the rendering commands over the wire to the spice client, which in turn will render them (and can use gl to accelerate that). cheers, Gerd
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
On 18.05.2010, at 11:14, Peter Lieven wrote: > Hi, > > we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned > Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are not > very stable by now. With ACPI they end up in a kernel panic at boot time and > without > they occasionally hang during boot or shortly after. Could you please post the panics you get? What does hang during boot mean? The easiest way to get them is probably to start the guest with -serial stdio and pass "console=ttyS0" on the grub command line. > Has anyone experience with suitable kvm and/or kernel parameters to get > this stable? It should be reasonably stable already. The only issue I'm aware of is the missing kvm-clock, so don't expect your timekeeping inside the guest to be 100% sane. Alex
Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
On 05/18/10 11:29, Stefano Stabellini wrote: On Tue, 18 May 2010, Gerd Hoffmann wrote: On 05/18/10 11:12, Stefano Stabellini wrote: I think it would be better to implement an accelerated frontend for rendering the framebuffer, like opengl or xv. Well. xv is pretty pointless IMHO. gl makes sense. But to have some effect this needs some major restructions in qemu, the current DisplayState infrastructure can't handle anything but a simple, stupid framebuffer. There isn't much to accelerate, except maybe scaling the guest display to fullscreen on the host. qxl + spice will change that though. qxl is a paravirtualized gfx adapter. Guest sends rendering commands. The spice protocol sends the rendering commands over the wire to the spice client, which in turn will render them (and can use gl to accelerate that). Is the spice client going to live in qemu, or is it going to be separate? Separate. project website: http://www.spice-space.org/ spice bits: http://cgit.freedesktop.org/~kraxel/spice/log/?h=api.v6 qemu patches: http://cgit.freedesktop.org/spice/qemu/log/?h=spice.v6.0 cheers, Gerd
Re: [Qemu-devel] [PATCH] virtio-blk: Avoid zeroing every request structure
Am 14.05.2010 23:52, schrieb Stefan Hajnoczi: > The VirtIOBlockRequest structure is about 40 KB in size. This patch > avoids zeroing every request by only initializing fields that are read. > The other fields are either written to or may not be used at all. > > Oprofile shows about 10% of CPU samples in memset called by > virtio_blk_alloc_request(). The workload is > dd if=/dev/vda of=/dev/null iflag=direct bs=8k running concurrently 4 > times. This patch makes memset disappear to the bottom of the profile. > > Signed-off-by: Stefan Hajnoczi Thanks, applied to the block branch. Kevin
[Qemu-devel] Re: [QEMU-KVM]: Megasas + TCM_Loop + SG_IO into Windows XP guests
Nicholas A. Bellinger wrote: > On Fri, 2010-05-14 at 02:42 -0700, Nicholas A. Bellinger wrote: >> On Fri, 2010-05-14 at 09:22 +0200, Hannes Reinecke wrote: >>> Nicholas A. Bellinger wrote: Greetings Hannes and co, >> >>> Let's see if I can find some time working on the megasas emulation. >>> Maybe I find something. >>> Last time I checked it was with a Windows7 build, but I didn't do >>> any real tests there. Basically just checking if the system boots up :-) >>> >> Nothing fancy just yet. This is involving a normal NTFS filesystem >> format on a small TCM/FILEIO LUN using scsi-generic and a userspace >> FILEIO with scsi-disk. >> >> This involves the XP guest waiting until the very last READ_10 once the >> format has completed (eg: all WRITE and VERIFY CDBs complete with GOOD >> status AFAICT) before announcing that mkfs.ntfs failed without any >> helpful exception message (due to missing metadata of some sort I would >> assume..?) >> >> So perhaps dumping QEMU and TCM_Loop SCSI payloads to determine if any >> correct blocks from megasas_handle_io() are actually making it out to >> KVM host is going to be my next option. ;) >> > > Greetings Hannes, > > So I spent some more time with XP guests this weekend, and I noticed two > things immediately when using hw/lsi53c895a.c instead of hw/megasas.c > with the same two TCM_Loop SAS LUNs via SG_IO from last week: > > 1) With lsi53c895a, XP guests are able to boot successfully w/ out the > synchronous SG_IO hack that is currently required to get past the first > 36-byte INQUIRY for megasas + XP SP2 > > 2) With lsi53c895a, XP is able to successfully create and mount a NTFS > filesystem, reboot, and read blocks appear to be functioning properly. > FYI I have not run any 'write known pattern then read-back and compare > blocks' data integrity tests from with in the XP guests just yet, but I > am confident that TCM scatterlist -> se_mem_t mapping is working as > expected on the KVM Host. > > Futhermore, after formatting a 5 GB TCM/FILEIO LUN with lsi53c895a, and > then rebooting with megasas with the same two configured TCM_Loop SG_IO > devices, it appears to be able to mount and read blocks successfully. > Attempting to write new blocks on the mounted filesystem also appears to > work to some degree, but throughput slows down to a crawl during XP > guest buffer cache flush, which is likely attributed to the use of my > quick SYNC SG_IO hack. > > So it appears that there are two seperate issues here, and AFAICT they > both look to be XP and megasas specific. For #2, it may be something > about the format of the incoming scatterlists generated during XP's > mkfs.ntfs that is causing some issues. While watching output during fs > creation, I noticed the following WRITE_10s with a starting 4088 byte > scatterlist and a trailing 8 byte scatterlist: > > megasas: writel mmio 40: 2b0b003 > megasas: Found mapped frame 2 context 82b0b000 pa 2b0b000 > megasas: Enqueue frame context 82b0b000 tail 493 busy 1 > megasas: LD SCSI dev 2 lun 0 sdev 0xdc0230 xfer 16384 > scsi-generic: Using cur_addr: 0x0ff6c008 cur_len: 0x0ff8 > scsi-generic: Adding iovec for mem: 0x7f1783b96008 len: 0x0ff8 > scsi-generic: Using cur_addr: 0x0fd6e000 cur_len: 0x1000 > scsi-generic: Adding iovec for mem: 0x7f1783998000 len: 0x1000 > scsi-generic: Using cur_addr: 0x0fe2f000 cur_len: 0x1000 > scsi-generic: Adding iovec for mem: 0x7f1783a59000 len: 0x1000 > scsi-generic: Using cur_addr: 0x0fdf cur_len: 0x1000 > scsi-generic: Adding iovec for mem: 0x7f1783a1a000 len: 0x1000 > scsi-generic: Using cur_addr: 0x0fded000 cur_len: 0x0008 > scsi-generic: Adding iovec for mem: 0x7f1783a17000 len: 0x0008 > scsi-generic: execute IOV: iovec_count: 5, dxferp: 0xd92420, dxfer_len: 16384 > scsi-generic: ---> Issuing SG_IO CDB len 10: 0x2a 00 00 > 00 fa be 00 00 20 00 > scsi-generic: scsi_write_complete() ret = 0 > scsi-generic: Command complete 0x0xd922c0 tag=0x82b0b000 status=0 > megasas: LD SCSI req 0xd922c0 cmd 0xda92c0 lun 0xdc0230 finished with status > 0 len 16384 > megasas: Complete frame context 82b0b000 tail 493 busy 0 doorbell 0 > > Also, the final READ_10 that produces the 'could not create filesystem' > exception is for LBA 63 and XP looking for the first FS blocks after > GPT. > > Could there be some breakage in megasas with a length < PAGE_SIZE for > the scatterlist..?As lsi53c895a seems to work OK for this case, is > there something about the logic of parsing the incoming struct > scatterlists that is different between the two HBA drivers..? AFAICT > both are using Gerd's common code in hw/scsi-bus.c, unless there is > something about megasas_map_sgl() that is causing issues with the > above..? > The usual disclaimer here: I'm less than happy with the current SCSI disk handling. Currently we
[Qemu-devel] How can I simulate TCC8900 to run Linux kernel?
Hi, I am a newbie. I'm trying to run a linux kernel for tcc8900, but it failed to run. Is that qemu 0.11 not support ARM1176JZF-S processor? What can I do? Any advise will be welcome. Thank you!
Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
On Tue, 18 May 2010, Gerd Hoffmann wrote: > On 05/18/10 11:12, Stefano Stabellini wrote: > > I think it would be better to implement an accelerated frontend for > > rendering the framebuffer, like opengl or xv. > > Well. xv is pretty pointless IMHO. gl makes sense. But to have some > effect this needs some major restructions in qemu, the current > DisplayState infrastructure can't handle anything but a simple, stupid > framebuffer. There isn't much to accelerate, except maybe scaling the > guest display to fullscreen on the host. > > qxl + spice will change that though. qxl is a paravirtualized gfx > adapter. Guest sends rendering commands. The spice protocol sends the > rendering commands over the wire to the spice client, which in turn will > render them (and can use gl to accelerate that). Is the spice client going to live in qemu, or is it going to be separate?
Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc
Anthony Liguori writes: > On 05/15/2010 01:19 AM, Avi Kivity wrote: >> On 05/15/2010 01:54 AM, Luiz Capitulino wrote: >>> On Fri, 14 May 2010 19:03:36 +0200 >>> Markus Armbruster wrote: >>> > What about PCI domains? Good point. Better to provide for them neatly now, instead of kludging them in later. >>> When I did this conversion I asked Micheal for help with that and >>> he said >>> QEMU doesn't support PCI domains. >> >> That's very different from "will never support pci domains". >> >> The protocol must be forward looking, or we will need endless fixes >> for it. > > But we can always add a domain property to extend the address (with a > default domain of 0). Why not add it right away? Note that if we'd decide to adopt Avi's suggestion to make this "a nested object (list of buses, each containing a list of slots, each containing a list of functions)", then we can't easily add domains later, because that would insert a level of nesting near the top.
Re: [Qemu-devel] Re: [PATCH 01/10] vnc: refactor set_encodings
On Tue, May 18, 2010 at 11:18 AM, Alexander Graf wrote: > > On 18.05.2010, at 09:31, Corentin Chary wrote: > > This is missing a patch description. When people later on either cherry-pick > your commits or simply git show them, it's almost impossible to know what's > going on. > So please always put in a patch description. > > > Alex > In this case, the description is all in the subject and the patch is pretty obvious. Should I really add something like "Create a new set_encoding() function to remove duplicate code in set_encodings()." ? -- Corentin Chary http://xf.iksaif.net
Re: [Qemu-devel] Re: [PATCH 01/10] vnc: refactor set_encodings
On 18.05.2010, at 11:53, Corentin Chary wrote: > On Tue, May 18, 2010 at 11:19 AM, Alexander Graf wrote: >> >> On 18.05.2010, at 09:31, Corentin Chary wrote: >> >>> Signed-off-by: Corentin Chary >> >> I'm also missing a cover letter explaining what your patch set does. As a >> general rule of thumb, whenever your patch set spans more than 2 patches, a >> cover letter is really helpful. To generate one, use git-format-patch >> --cover-letter. >> >> >> Alex >> >> >> > > There is a cover-letter, but I accidentally put a '\n' and the > beginning ( see > http://thread.gmane.org/gmane.comp.emulators.qemu/70495 ). I see :). Sounds like you should just rework all the patch descriptions so people actually know what's going on within the patch without reading it and then give it a go for v2. Alex
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Alexander Graf wrote:
On 18.05.2010, at 11:14, Peter Lieven wrote:
Hi,
we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned
Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are not
very stable by now. With ACPI they end up in a kernel panic at boot time and
without
they occasionally hang during boot or shortly after.
Could you please post the panics you get? What does hang during boot mean?
with acpi=off it hangs after starting powersaved
The easiest way to get them is probably to start the guest with -serial stdio and pass
"console=ttyS0" on the grub command line.
without acpi=off it hangs always with a lookup. one time it happened
directly after initializing hpet0.
btw, is it safe to turn of hpet for linux guests in genereal?
regarding missing kvm-clock. i made the experience that some guests
crash after live migration
with clocksource=kvm_clock while they don't with clocksource=acpi_pm.
this is off topic here,
but its also something i would like to debug with someone.
Starting cupsddone
Starting ZENworks Management Daemon done
IA-32 Microcode Update Driver v1.14 unregistered
Starting INET services. (xinetd) done
Checking/updating CPU microcode done
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
..dead
Try to get initial date and time via NTP from 212.110.100.1 done
Starting network time protocol daemon (NTPD) done
Starting Name Service Cache Daemondone
NetBackup SAN Client Fibre Transport daemon started.
Starting powersaved: done
Starting mail service (Postfix)
NMI Watchdog detected LOCKUP on CPU 0
CPU 0
Modules linked in: ipv6 button battery ac apparmor aamatch_pcre loop
usbhid dm_mod 8139cp mii uhci_hcd e1000 i2c_piix4 usbcore ide_cd
i2c_core cdrom parport_pc lp parport ext3 jbd sg sym53c8xx
scsi_transport_spi edd fan thermal processor piix sd_mod scsi_mod
ide_disk ide_core
Pid: 3134, comm: powersaved Not tainted 2.6.16.46-0.12-smp #1
RIP: 0010:[] {paranoid_restore+81}
RSP: :8041afd8 EFLAGS: 00010086
RAX: 88021d50 RBX: 88021e18 RCX: b4c562b6
RDX: 01f7 RSI: 88021e18 RDI: 01f7
RBP: R08: 04e2 R09: 80417d60
R10: 001f R11: 8800752c R12: 88021d00
R13: 04e2 R14: 80417dac R15: 0040
FS: 2ae1d26ee760() GS:803be000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 00555b30 CR3: 000210fe9000 CR4: 06e0
Process powersaved (pid: 3134, threadinfo 810210ff2000, task
810211f83850)
Stack: 802dabf1 0010 00010086 8041afd8
Call Trace: {paranoid_restore+81}
{paranoid_restore+81}
Code: 48 cf 65 48 8b 0c 25 10 00 00 00 48 81 e9 d8 1f 00 00 8b 59
console shuts up ...
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
Has anyone experience with suitable kvm and/or kernel parameters to get
this stable?
It should be reasonably stable already. The only issue I'm aware of is the
missing kvm-clock, so don't expect your timekeeping inside the guest to be 100%
sane.
Alex
--
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] Re: [PATCH 01/10] vnc: refactor set_encodings
On Tue, May 18, 2010 at 11:19 AM, Alexander Graf wrote: > > On 18.05.2010, at 09:31, Corentin Chary wrote: > >> Signed-off-by: Corentin Chary > > I'm also missing a cover letter explaining what your patch set does. As a > general rule of thumb, whenever your patch set spans more than 2 patches, a > cover letter is really helpful. To generate one, use git-format-patch > --cover-letter. > > > Alex > > > There is a cover-letter, but I accidentally put a '\n' and the beginning ( see http://thread.gmane.org/gmane.comp.emulators.qemu/70495 ). -- Corentin Chary http://xf.iksaif.net
Re: [Qemu-devel] Re: [PATCH 01/10] vnc: refactor set_encodings
On 18.05.2010, at 11:56, Corentin Chary wrote: > On Tue, May 18, 2010 at 11:18 AM, Alexander Graf wrote: >> >> On 18.05.2010, at 09:31, Corentin Chary wrote: >> >> This is missing a patch description. When people later on either cherry-pick >> your commits or simply git show them, it's almost impossible to know what's >> going on. >> So please always put in a patch description. >> >> >> Alex >> > > In this case, the description is all in the subject and the patch is > pretty obvious. > Should I really add something like "Create a new set_encoding() > function to remove duplicate code in set_encodings()." ? Yes. If possible, including the reasoning behind it. Something like: Currently the code to specify which encoding we use is written out individually every time. Since we want to be able to add code to every singe occurence, let's move it to a helper function. Alex
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
On 18.05.2010, at 11:57, Peter Lieven wrote:
> Alexander Graf wrote:
>> On 18.05.2010, at 11:14, Peter Lieven wrote:
>>
>>
>>> Hi,
>>>
>>> we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned
>>> Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are
>>> not
>>> very stable by now. With ACPI they end up in a kernel panic at boot time
>>> and without
>>> they occasionally hang during boot or shortly after.
>>>
>>
>> Could you please post the panics you get? What does hang during boot mean?
>>
> with acpi=off it hangs after starting powersaved
>> The easiest way to get them is probably to start the guest with -serial
>> stdio and pass "console=ttyS0" on the grub command line.
>>
>>
> without acpi=off it hangs always with a lookup. one time it happened directly
> after initializing hpet0.
> btw, is it safe to turn of hpet for linux guests in genereal?
>
> regarding missing kvm-clock. i made the experience that some guests crash
> after live migration
> with clocksource=kvm_clock while they don't with clocksource=acpi_pm. this is
> off topic here,
> but its also something i would like to debug with someone.
>
>
> Starting cupsddone
> Starting ZENworks Management Daemon done
> IA-32 Microcode Update Driver v1.14 unregistered
> Starting INET services. (xinetd) done
> Checking/updating CPU microcode done
> NET: Registered protocol family 10
> lo: Disabled Privacy Extensions
> IPv6 over IPv4 tunneling driver
> ..dead
> Try to get initial date and time via NTP from 212.110.100.1 done
> Starting network time protocol daemon (NTPD) done
> Starting Name Service Cache Daemondone
> NetBackup SAN Client Fibre Transport daemon started.
> Starting powersaved: done
> Starting mail service (Postfix)
> NMI Watchdog detected LOCKUP on CPU 0
What host kernel are you running on? Or rather, what host kvm module version?
> CPU 0
> Modules linked in: ipv6 button battery ac apparmor aamatch_pcre loop usbhid
> dm_mod 8139cp mii uhci_hcd e1000 i2c_piix4 usbcore ide_cd i2c_core cdrom
> parport_pc lp parport ext3 jbd sg sym53c8xx scsi_transport_spi edd fan
> thermal processor piix sd_mod scsi_mod ide_disk ide_core
> Pid: 3134, comm: powersaved Not tainted 2.6.16.46-0.12-smp #1
This looks old. The SP3 GM version is 2.6.16.60-0.54.5. This release is
definitely out of support :(.
After some searching I found the RPM. That's the SLES10 SP1 GM kernel version.
I don't think anyone ever tested that one on kvm.
> RIP: 0010:[] {paranoid_restore+81}
Yeah, great. That one's not helpful at all:
0x802dabf1 : iretq
> RSP: :8041afd8 EFLAGS: 00010086
> RAX: 88021d50 RBX: 88021e18 RCX: b4c562b6
> RDX: 01f7 RSI: 88021e18 RDI: 01f7
> RBP: R08: 04e2 R09: 80417d60
> R10: 001f R11: 8800752c R12: 88021d00
> R13: 04e2 R14: 80417dac R15: 0040
> FS: 2ae1d26ee760() GS:803be000() knlGS:
> CS: 0010 DS: ES: CR0: 8005003b
> CR2: 00555b30 CR3: 000210fe9000 CR4: 06e0
> Process powersaved (pid: 3134, threadinfo 810210ff2000, task
> 810211f83850)
> Stack: 802dabf1 0010 00010086 8041afd8
>
>
> Call Trace: {paranoid_restore+81}
> {paranoid_restore+81}
>
> Code: 48 cf 65 48 8b 0c 25 10 00 00 00 48 81 e9 d8 1f 00 00 8b 59
> console shuts up ...
> <0>Kernel panic - not syncing: Aiee, killing interrupt handler!
Please try out different values for -cpu. I think powersaved gets confused by
the invalid CPU type we're emulating.
Alex
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
hi alex,
what 64-bit -cpu types do you suggest?
when i boot the kernel with "nohpet" it simply hangs shortly after
powersaved...
br,
peter
Alexander Graf wrote:
On 18.05.2010, at 11:57, Peter Lieven wrote:
Alexander Graf wrote:
On 18.05.2010, at 11:14, Peter Lieven wrote:
Hi,
we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned
Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are not
very stable by now. With ACPI they end up in a kernel panic at boot time and
without
they occasionally hang during boot or shortly after.
Could you please post the panics you get? What does hang during boot mean?
with acpi=off it hangs after starting powersaved
The easiest way to get them is probably to start the guest with -serial stdio and pass
"console=ttyS0" on the grub command line.
without acpi=off it hangs always with a lookup. one time it happened directly
after initializing hpet0.
btw, is it safe to turn of hpet for linux guests in genereal?
regarding missing kvm-clock. i made the experience that some guests crash after
live migration
with clocksource=kvm_clock while they don't with clocksource=acpi_pm. this is
off topic here,
but its also something i would like to debug with someone.
Starting cupsddone
Starting ZENworks Management Daemon done
IA-32 Microcode Update Driver v1.14 unregistered
Starting INET services. (xinetd) done
Checking/updating CPU microcode done
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
..dead
Try to get initial date and time via NTP from 212.110.100.1 done
Starting network time protocol daemon (NTPD) done
Starting Name Service Cache Daemondone
NetBackup SAN Client Fibre Transport daemon started.
Starting powersaved: done
Starting mail service (Postfix)
NMI Watchdog detected LOCKUP on CPU 0
What host kernel are you running on? Or rather, what host kvm module version?
CPU 0
Modules linked in: ipv6 button battery ac apparmor aamatch_pcre loop usbhid
dm_mod 8139cp mii uhci_hcd e1000 i2c_piix4 usbcore ide_cd i2c_core cdrom
parport_pc lp parport ext3 jbd sg sym53c8xx scsi_transport_spi edd fan thermal
processor piix sd_mod scsi_mod ide_disk ide_core
Pid: 3134, comm: powersaved Not tainted 2.6.16.46-0.12-smp #1
This looks old. The SP3 GM version is 2.6.16.60-0.54.5. This release is
definitely out of support :(.
After some searching I found the RPM. That's the SLES10 SP1 GM kernel version.
I don't think anyone ever tested that one on kvm.
RIP: 0010:[] {paranoid_restore+81}
Yeah, great. That one's not helpful at all:
0x802dabf1 : iretq
RSP: :8041afd8 EFLAGS: 00010086
RAX: 88021d50 RBX: 88021e18 RCX: b4c562b6
RDX: 01f7 RSI: 88021e18 RDI: 01f7
RBP: R08: 04e2 R09: 80417d60
R10: 001f R11: 8800752c R12: 88021d00
R13: 04e2 R14: 80417dac R15: 0040
FS: 2ae1d26ee760() GS:803be000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 00555b30 CR3: 000210fe9000 CR4: 06e0
Process powersaved (pid: 3134, threadinfo 810210ff2000, task
810211f83850)
Stack: 802dabf1 0010 00010086 8041afd8
Call Trace: {paranoid_restore+81}
{paranoid_restore+81}
Code: 48 cf 65 48 8b 0c 25 10 00 00 00 48 81 e9 d8 1f 00 00 8b 59
console shuts up ...
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
Please try out different values for -cpu. I think powersaved gets confused by
the invalid CPU type we're emulating.
Alex
--
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
.
[Qemu-devel] VNC encoding ZLibHex?
Hi, has someone enough background to say if it was worth implementing ZLibHex encoding to qemu/kvm? If yes, I would go for that. BR, Peter
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Sorry, ommitted your questions. This particular system
is still runnung on
/kernel: /2.6.31-14-server, /bin: /qemu-kvm-0.12.2, /mod: /kvm-kmod-2.6.32.7
If there where any fixes improvements I can try on:
/kernel: /2.6.33.3, /bin: /qemu-kvm-0.12.4, /mod: /2.6.33.3
BR,
Peter
Alexander Graf wrote:
On 18.05.2010, at 11:57, Peter Lieven wrote:
Alexander Graf wrote:
On 18.05.2010, at 11:14, Peter Lieven wrote:
Hi,
we try to migrate some Suse Linux Enterprise 10 64-bit guests from abandoned
Virtual Iron by Iron Port to qemu-kvm 0.12.4. Unfortunately the guests are not
very stable by now. With ACPI they end up in a kernel panic at boot time and
without
they occasionally hang during boot or shortly after.
Could you please post the panics you get? What does hang during boot mean?
with acpi=off it hangs after starting powersaved
The easiest way to get them is probably to start the guest with -serial stdio and pass
"console=ttyS0" on the grub command line.
without acpi=off it hangs always with a lookup. one time it happened directly
after initializing hpet0.
btw, is it safe to turn of hpet for linux guests in genereal?
regarding missing kvm-clock. i made the experience that some guests crash after
live migration
with clocksource=kvm_clock while they don't with clocksource=acpi_pm. this is
off topic here,
but its also something i would like to debug with someone.
Starting cupsddone
Starting ZENworks Management Daemon done
IA-32 Microcode Update Driver v1.14 unregistered
Starting INET services. (xinetd) done
Checking/updating CPU microcode done
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
..dead
Try to get initial date and time via NTP from 212.110.100.1 done
Starting network time protocol daemon (NTPD) done
Starting Name Service Cache Daemondone
NetBackup SAN Client Fibre Transport daemon started.
Starting powersaved: done
Starting mail service (Postfix)
NMI Watchdog detected LOCKUP on CPU 0
What host kernel are you running on? Or rather, what host kvm module version?
CPU 0
Modules linked in: ipv6 button battery ac apparmor aamatch_pcre loop usbhid
dm_mod 8139cp mii uhci_hcd e1000 i2c_piix4 usbcore ide_cd i2c_core cdrom
parport_pc lp parport ext3 jbd sg sym53c8xx scsi_transport_spi edd fan thermal
processor piix sd_mod scsi_mod ide_disk ide_core
Pid: 3134, comm: powersaved Not tainted 2.6.16.46-0.12-smp #1
This looks old. The SP3 GM version is 2.6.16.60-0.54.5. This release is
definitely out of support :(.
After some searching I found the RPM. That's the SLES10 SP1 GM kernel version.
I don't think anyone ever tested that one on kvm.
RIP: 0010:[] {paranoid_restore+81}
Yeah, great. That one's not helpful at all:
0x802dabf1 : iretq
RSP: :8041afd8 EFLAGS: 00010086
RAX: 88021d50 RBX: 88021e18 RCX: b4c562b6
RDX: 01f7 RSI: 88021e18 RDI: 01f7
RBP: R08: 04e2 R09: 80417d60
R10: 001f R11: 8800752c R12: 88021d00
R13: 04e2 R14: 80417dac R15: 0040
FS: 2ae1d26ee760() GS:803be000() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 00555b30 CR3: 000210fe9000 CR4: 06e0
Process powersaved (pid: 3134, threadinfo 810210ff2000, task
810211f83850)
Stack: 802dabf1 0010 00010086 8041afd8
Call Trace: {paranoid_restore+81}
{paranoid_restore+81}
Code: 48 cf 65 48 8b 0c 25 10 00 00 00 48 81 e9 d8 1f 00 00 8b 59
console shuts up ...
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!
Please try out different values for -cpu. I think powersaved gets confused by
the invalid CPU type we're emulating.
Alex
--
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] Suggested Parameters for SLES 10 64-bit
Hi Peter, On 18.05.2010, at 12:18, Peter Lieven wrote: > Sorry, ommitted your questions. This particular system > is still runnung on Please don't top post. > > /kernel: /2.6.31-14-server, /bin: /qemu-kvm-0.12.2, /mod: /kvm-kmod-2.6.32.7 This looks reasonable. Alex
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
On 18.05.2010, at 12:12, Peter Lieven wrote: > hi alex, > > what 64-bit -cpu types do you suggest? For starters I'd say try -cpu host. Alex
Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
On Tue, 18 May 2010, Gerd Hoffmann wrote: > On 05/18/10 11:29, Stefano Stabellini wrote: > > On Tue, 18 May 2010, Gerd Hoffmann wrote: > >> On 05/18/10 11:12, Stefano Stabellini wrote: > >>> I think it would be better to implement an accelerated frontend for > >>> rendering the framebuffer, like opengl or xv. > >> > >> Well. xv is pretty pointless IMHO. gl makes sense. But to have some > >> effect this needs some major restructions in qemu, the current > >> DisplayState infrastructure can't handle anything but a simple, stupid > >> framebuffer. There isn't much to accelerate, except maybe scaling the > >> guest display to fullscreen on the host. > >> > >> qxl + spice will change that though. qxl is a paravirtualized gfx > >> adapter. Guest sends rendering commands. The spice protocol sends the > >> rendering commands over the wire to the spice client, which in turn will > >> render them (and can use gl to accelerate that). > > > > Is the spice client going to live in qemu, or is it going to be > > separate? > > Separate. > > project website: http://www.spice-space.org/ > spice bits: http://cgit.freedesktop.org/~kraxel/spice/log/?h=api.v6 > qemu patches: http://cgit.freedesktop.org/spice/qemu/log/?h=spice.v6.0 Then I guess we don't actually need any accelerated rendering in qemu, even though it might still be nice for avoiding a memcpy. I am curious about one thing: if the spice client is running on the same host as the VM and qemu, is there any plan for sharing memory somehow between the two components? OR is it not believed to be necessary to reach good performances?
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
hi alex, unfortunately -cpu host, -cpu qemu64, -cpu core2duo, -cpu kvm64 (which should be default) doesn't help all other cpus available are 32-bit afaik. as i said if i boot with with kernel parameter "nohpet", but acpi on the guest just hangs at 100% cpu. would a backtrace help? br, peter Alexander Graf wrote: On 18.05.2010, at 12:12, Peter Lieven wrote: hi alex, what 64-bit -cpu types do you suggest? For starters I'd say try -cpu host. Alex -- 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] Suggested Parameters for SLES 10 64-bit
On 18.05.2010, at 13:01, Peter Lieven wrote: > hi alex, > > unfortunately -cpu host, -cpu qemu64, -cpu core2duo, -cpu kvm64 (which should > be default) doesn't help > all other cpus available are 32-bit afaik. > > as i said if i boot with with kernel parameter "nohpet", but acpi on the > guest just hangs at 100% cpu. > > would a backtrace help? Sigh. Is there any way to upgrade the system to SP3? Preferably incl. the latest maintenance update? Alex
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Alexander Graf wrote: On 18.05.2010, at 13:01, Peter Lieven wrote: hi alex, unfortunately -cpu host, -cpu qemu64, -cpu core2duo, -cpu kvm64 (which should be default) doesn't help all other cpus available are 32-bit afaik. as i said if i boot with with kernel parameter "nohpet", but acpi on the guest just hangs at 100% cpu. would a backtrace help? Sigh. Is there any way to upgrade the system to SP3? Preferably incl. the latest maintenance update? yes, we will try this. if you don't suspect it is a generall problem with qemu-kvm that should be fixed. keep you posted. thanks for you help, peter Alex -- 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 .
[Qemu-devel] Re: qemu-kvm hangs if multipath device is queing
hi kevin, here is the backtrace of (hopefully) all threads: ^C Program received signal SIGINT, Interrupt. [Switching to Thread 0x7f39b72656f0 (LWP 10695)] 0x7f39b6c3ea94 in __lll_lock_wait () from /lib/libpthread.so.0 (gdb) thread apply all bt Thread 2 (Thread 0x7f39b57b8950 (LWP 10698)): #0 0x7f39b6c3eedb in read () from /lib/libpthread.so.0 #1 0x0049e723 in qemu_laio_completion_cb (opaque=0x22b4010) at linux-aio.c:125 #2 0x0049e8ad in laio_cancel (blockacb=0x22ba310) at linux-aio.c:184 #3 0x0049a309 in bdrv_aio_cancel (acb=0x22ba310) at block.c:1800 #4 0x00587a52 in dma_aio_cancel (acb=0x22ba170) at /usr/src/qemu-kvm-0.12.4/dma-helpers.c:138 #5 0x0049a309 in bdrv_aio_cancel (acb=0x22ba170) at block.c:1800 #6 0x00444aac in ide_dma_cancel (bm=0x2800fd8) at /usr/src/qemu-kvm-0.12.4/hw/ide/core.c:2834 #7 0x00445001 in bmdma_cmd_writeb (opaque=0x2800fd8, addr=49152, val=8) at /usr/src/qemu-kvm-0.12.4/hw/ide/pci.c:44 #8 0x004c85f0 in ioport_write (index=0, address=49152, data=8) at ioport.c:80 #9 0x004c8977 in cpu_outb (addr=49152, val=8 '\b') at ioport.c:198 #10 0x00429731 in kvm_handle_io (port=49152, data=0x7f39b7263000, direction=1, size=1, count=1) at /usr/src/qemu-kvm-0.12.4/kvm-all.c:535 #11 0x0042bb8b in kvm_run (env=0x22ba5d0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:968 #12 0x0042cea2 in kvm_cpu_exec (env=0x22ba5d0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1651 #13 0x0042d62c in kvm_main_loop_cpu (env=0x22ba5d0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1893 #14 0x0042d76d in ap_main_loop (_env=0x22ba5d0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #15 0x7f39b6c383ba in start_thread () from /lib/libpthread.so.0 #16 0x7f39b5cbafcd in clone () from /lib/libc.so.6 #17 0x in ?? () Thread 1 (Thread 0x7f39b72656f0 (LWP 10695)): #0 0x7f39b6c3ea94 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x7f39b6c3a190 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x7f39b6c39a7e in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x0042e739 in kvm_mutex_lock () at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2524 #4 0x0042e76e in qemu_mutex_lock_iothread () at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2537 #5 0x0040c262 in main_loop_wait (timeout=1000) at /usr/src/qemu-kvm-0.12.4/vl.c:3995 #6 0x0042dcf1 in kvm_main_loop () at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:2126 #7 0x0040c98c in main_loop () at /usr/src/qemu-kvm-0.12.4/vl.c:4212 #8 0x0041054b in main (argc=30, argv=0x7fff019f1ca8, envp=0x7fff019f1da0) at /usr/src/qemu-kvm-0.12.4/vl.c:6252
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
On 18.05.2010, at 13:08, Peter Lieven wrote: > Alexander Graf wrote: >> On 18.05.2010, at 13:01, Peter Lieven wrote: >> >> >>> hi alex, >>> >>> unfortunately -cpu host, -cpu qemu64, -cpu core2duo, -cpu kvm64 (which >>> should be default) doesn't help >>> all other cpus available are 32-bit afaik. >>> >>> as i said if i boot with with kernel parameter "nohpet", but acpi on the >>> guest just hangs at 100% cpu. >>> >>> would a backtrace help? >>> >> >> Sigh. Is there any way to upgrade the system to SP3? Preferably incl. the >> latest maintenance update? >> > yes, we will try this. if you don't suspect it is a generall problem with > qemu-kvm that should > be fixed. keep you posted. Alright. Installing SLES10 SP1 in a VM in parallel. Alex
Re: [Qemu-devel] Qemu-KVM 0.12.3 and Multipath -> Assertion
hi, will this patch make it into 0.12.4.1 ? br, peter Christoph Hellwig wrote: On Tue, May 04, 2010 at 04:01:35PM +0200, Kevin Wolf wrote: Great, I'm going to submit it as a proper patch then. Christoph, by now I'm pretty sure it's right, but can you have another look if this is correct, anyway? It looks correct to me - we really shouldn't update the the fields until bdrv_aio_cancel has returned. In fact we cannot cancel a request more often than we can, so there's a fairly high chance it will complete. Reviewed-by: Christoph Hellwig -- 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 .
[Qemu-devel] Re: [QEMU-KVM]: Megasas + TCM_Loop + SG_IO into Windows XP guests
On Tue, 2010-05-18 at 11:43 +0200, Hannes Reinecke wrote: > Nicholas A. Bellinger wrote: > > On Fri, 2010-05-14 at 02:42 -0700, Nicholas A. Bellinger wrote: > >> On Fri, 2010-05-14 at 09:22 +0200, Hannes Reinecke wrote: > >>> Nicholas A. Bellinger wrote: > Greetings Hannes and co, > > >> > >>> Let's see if I can find some time working on the megasas emulation. > >>> Maybe I find something. > >>> Last time I checked it was with a Windows7 build, but I didn't do > >>> any real tests there. Basically just checking if the system boots up :-) > >>> > >> Nothing fancy just yet. This is involving a normal NTFS filesystem > >> format on a small TCM/FILEIO LUN using scsi-generic and a userspace > >> FILEIO with scsi-disk. > >> > >> This involves the XP guest waiting until the very last READ_10 once the > >> format has completed (eg: all WRITE and VERIFY CDBs complete with GOOD > >> status AFAICT) before announcing that mkfs.ntfs failed without any > >> helpful exception message (due to missing metadata of some sort I would > >> assume..?) > >> > >> So perhaps dumping QEMU and TCM_Loop SCSI payloads to determine if any > >> correct blocks from megasas_handle_io() are actually making it out to > >> KVM host is going to be my next option. ;) > >> > > > > Greetings Hannes, > > > > So I spent some more time with XP guests this weekend, and I noticed two > > things immediately when using hw/lsi53c895a.c instead of hw/megasas.c > > with the same two TCM_Loop SAS LUNs via SG_IO from last week: > > > > 1) With lsi53c895a, XP guests are able to boot successfully w/ out the > > synchronous SG_IO hack that is currently required to get past the first > > 36-byte INQUIRY for megasas + XP SP2 > > > > 2) With lsi53c895a, XP is able to successfully create and mount a NTFS > > filesystem, reboot, and read blocks appear to be functioning properly. > > FYI I have not run any 'write known pattern then read-back and compare > > blocks' data integrity tests from with in the XP guests just yet, but I > > am confident that TCM scatterlist -> se_mem_t mapping is working as > > expected on the KVM Host. > > > > Futhermore, after formatting a 5 GB TCM/FILEIO LUN with lsi53c895a, and > > then rebooting with megasas with the same two configured TCM_Loop SG_IO > > devices, it appears to be able to mount and read blocks successfully. > > Attempting to write new blocks on the mounted filesystem also appears to > > work to some degree, but throughput slows down to a crawl during XP > > guest buffer cache flush, which is likely attributed to the use of my > > quick SYNC SG_IO hack. > > > > So it appears that there are two seperate issues here, and AFAICT they > > both look to be XP and megasas specific. For #2, it may be something > > about the format of the incoming scatterlists generated during XP's > > mkfs.ntfs that is causing some issues. While watching output during fs > > creation, I noticed the following WRITE_10s with a starting 4088 byte > > scatterlist and a trailing 8 byte scatterlist: > > > > megasas: writel mmio 40: 2b0b003 > > megasas: Found mapped frame 2 context 82b0b000 pa 2b0b000 > > megasas: Enqueue frame context 82b0b000 tail 493 busy 1 > > megasas: LD SCSI dev 2 lun 0 sdev 0xdc0230 xfer 16384 > > scsi-generic: Using cur_addr: 0x0ff6c008 cur_len: 0x0ff8 > > scsi-generic: Adding iovec for mem: 0x7f1783b96008 len: 0x0ff8 > > scsi-generic: Using cur_addr: 0x0fd6e000 cur_len: 0x1000 > > scsi-generic: Adding iovec for mem: 0x7f1783998000 len: 0x1000 > > scsi-generic: Using cur_addr: 0x0fe2f000 cur_len: 0x1000 > > scsi-generic: Adding iovec for mem: 0x7f1783a59000 len: 0x1000 > > scsi-generic: Using cur_addr: 0x0fdf cur_len: 0x1000 > > scsi-generic: Adding iovec for mem: 0x7f1783a1a000 len: 0x1000 > > scsi-generic: Using cur_addr: 0x0fded000 cur_len: 0x0008 > > scsi-generic: Adding iovec for mem: 0x7f1783a17000 len: 0x0008 > > scsi-generic: execute IOV: iovec_count: 5, dxferp: 0xd92420, dxfer_len: > > 16384 > > scsi-generic: ---> Issuing SG_IO CDB len 10: 0x2a 00 00 > > 00 fa be 00 00 20 00 > > scsi-generic: scsi_write_complete() ret = 0 > > scsi-generic: Command complete 0x0xd922c0 tag=0x82b0b000 status=0 > > megasas: LD SCSI req 0xd922c0 cmd 0xda92c0 lun 0xdc0230 finished with > > status 0 len 16384 > > megasas: Complete frame context 82b0b000 tail 493 busy 0 doorbell 0 > > > > Also, the final READ_10 that produces the 'could not create filesystem' > > exception is for LBA 63 and XP looking for the first FS blocks after > > GPT. > > > > Could there be some breakage in megasas with a length < PAGE_SIZE for > > the scatterlist..?As lsi53c895a seems to work OK for this case, is > > there something about the logic of parsing the incoming struct > > scatterlists that is different between the two HBA drivers..? AFAICT > > bot
Re: [Qemu-devel] Re: [PATCH 1/2] QMP: Introduce commands doc
Jan Kiszka writes: > Luiz Capitulino wrote: >> On Fri, 14 May 2010 19:08:07 +0200 >> Jan Kiszka wrote: >> >>> Avi Kivity wrote: On 05/14/2010 08:01 PM, Avi Kivity wrote: > On 05/14/2010 07:52 PM, Jan Kiszka wrote: >>> 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. >> Even if it's temporary - maintaining it in a separate file looks rather >> unhandy. >> >> Can't we generate the per-command documentation snippets also from >> qemu-monitor.hx and merge them with a header/footer into some text file? >> That .hx file is the one anyone adding/converting commands has to touch >> anyway. > If we do, then the generated documentation should be included in the > patch changelog for review. > I mean, a patch introducing or modifying a monitor command. >>> The snippets should be readable by themselves. I'm only proposing to >>> keep them in the central file, at the same location where the others >>> are. There is no difference compared to existing monitor commands, we >>> just add the third documentation snippet, this time for QMP. >> >> It's not only the snippets. We add a json type for each parameter, a >> more descriptive info and notes. Only QMP commands should be shown >> this way. > > Whatever its semantic is, technically it's a text block of a few lines > that has to be added somewhere. The current documentation is just a block of text, yes. Fine for human consumption. Useless for QMP self-documentation, i.e. machine-readable documentation exposed over QMP. There, we need a bit more structure. qemu-monitor.gx is a sub-optimal permanent place for command documentation. The command documentation source should live right next to the command code, because that increases its chances to get updated along with the code. Naturally, we also need a way to generate something like qmp-commands.txt from it, for easier review, and for the human users of QMP. >> I'm sure there's a way to hack the qemu's doc script to do all this, >> but the right solution is to move _everything_ to json and generate good, >> well formatted documentation from there (along with self-description). > > I'm not talking about The Right solution, I'm talking about a more handy > temporary setup. When do you plan to refactor the command documentation > that way? And how many commands will be touched in the meantime? We need self-documentation badly right after we declare QMP stable, i.e. 0.13. Because any change after that needs to be discoverable by QMP clients. Ideally, we put it in before 0.13. If we can't pull that off, then early in the 0.14 cycle. Help appreciated! >> Also, adapting things will take time and this will delay even more this >> doc to be merged, which is what I'm trying to avoid. >> > > I can provide you the patch for hxtool and Makefile (a few lines), and > I'm willing to split up the existing doc, just drop me a note. Moving it from one temporary, sub-optimal place (QMP/qmp-commands.txt) to another temporary, sub-optimal place (qemu-monitor.hx) doesn't seem like a win to me. Should temporary macro wizardry be required for that (hxtool patch), the deal gets even less appealing. >So > nothing needs to be delayed any further. Well, it's being delayed :) Let's commit the sucker as is. We can still move it into qemu-monitor.hx afterwards. Commits are cheap, waiting for the perfect patch isn't.
Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
On 05/18/10 12:34, Stefano Stabellini wrote: I am curious about one thing: if the spice client is running on the same host as the VM and qemu, is there any plan for sharing memory somehow between the two components? OR is it not believed to be necessary to reach good performances? Well. We don't have shm for vnc. And I think the reason simply is that it feels fast enougth even without shm. Spice tries to reduce the network bandwith needed with image caching, so with spice the gains by using shm should be even smaller than with vnc. I'm not aware of anyone trying + benchmark it, but I don't expect major gains. cheers, Gerd
[Qemu-devel] Re: [PATCH 1/4] megasas: Add more controller property definitions
On Tue, 2010-05-18 at 08:56 +0200, Hannes Reinecke wrote:
> The megaraid_sas driver has some more controller property defintions.
>
> Signed-off-by: Hannes Reinecke
> ---
> hw/mfi.h | 41 +++--
> 1 files changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/hw/mfi.h b/hw/mfi.h
> index f3c82e0..312563e 100644
> --- a/hw/mfi.h
> +++ b/hw/mfi.h
> @@ -508,7 +508,7 @@ struct mfi_init_qinfo {
> uint32_tci_addr_hi;
> } __attribute__ ((packed));
>
> -/* SAS (?) controller properties, part of mfi_ctrl_info */
> +/* Controller properties */
> struct mfi_ctrl_props {
> uint16_tseq_num;
> uint16_tpred_fail_poll_interval;
> @@ -531,7 +531,44 @@ struct mfi_ctrl_props {
> uint16_tecc_bucket_leak_rate;
> uint8_t restore_hotspare_on_insertion;
> uint8_t expose_encl_devices;
> - uint8_t reserved[38];
> + uint8_t maintainPdFailHistory;
> + uint8_t disallowHostRequestReordering;
> + uint8_t abortCCOnError;
> + uint8_t loadBalanceMode;
> + uint8_t disableAutoDetectBackplane;
> + uint8_t snapVDSpace;
> + struct {
> + uint32_tcopyBackDisabled: 1; // set TRUE to
> disable copyBack (0=copback enabled)
> + uint32_tSMARTerEnabled : 1;
> + uint32_tprCorrectUnconfiguredAreas : 1;
> + uint32_tuseFdeOnly : 1;
> + uint32_tdisableNCQ : 1;
> + uint32_tSSDSMARTerEnabled : 1;
> + uint32_tSSDPatrolReadEnabled: 1;
> + uint32_tenableSpinDownUnconfigured : 1;
> + uint32_tautoEnhancedImport : 1;
> + uint32_tenableSecretKeyControl : 1;
> + uint32_tdisableOnlineCtrlReset : 1;
> + uint32_tallowBootWithPinnedCache : 1;
> + uint32_tdisableSpinDownHS : 1;
> + uint32_tenableJBOD : 1;
> + uint32_treserved:18;
> + } OnOffProperties;
> + uint8_t autoSnapVDSpace; /* % of source LD to be
> + * reserved for auto snapshot
> + * in snapshot repository, for
> + * metadata and user data
> + * 1=5%, 2=10%, 3=15% and so on
> + */
> + uint8_t viewSpace; /* snapshot writeable VIEWs
> + * capacity as a % of source LD
> + * capacity. 0=READ only
> + * 1=5%, 2=10%, 3=15% and so on
> + */
> + uint16_tspinDownTime;/* # of idle minutes before device
> + * is spun down (0=use FW defaults)
> + */
> + uint8_t reserved[24];
> } __attribute__ ((packed));
>
> /* PCI information about the card. */
Thanks, commited as d2ad0ac2085e00
Best,
--nab
Re: [Qemu-devel] VNC encoding ZLibHex?
On Tue, May 18, 2010 at 12:15 PM, Peter Lieven wrote: > Hi, > > has someone enough background to say if it was worth implementing ZLibHex > encoding > to qemu/kvm? > > If yes, I would go for that. > > BR, > Peter The best way to know it would be to setup a vnc server with zlibhex support (libvncserver and ultravnc seems to support that encoding) and get some numbers (you can choose the prefered encoding with most of the vnc clients). -- Corentin Chary http://xf.iksaif.net
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
hi alex, here is a backtrace of the sles 10 sp1 vm running on qemu-kvm 0.12.4. hanging at boot. a colleguage is meanwhile upgraded a cloned system to sp3 to see if it is also not working. ^C Program received signal SIGINT, Interrupt. [Switching to Thread 0x7f0b753c76f0 (LWP 25532)] 0x7f0b73e13742 in select () from /lib/libc.so.6 (gdb) thread apply all bt Thread 5 (Thread 0x7f0b72115950 (LWP 25546)): #0 0x7f0b73e12cd7 in ioctl () from /lib/libc.so.6 #1 0x0042b945 in kvm_run (env=0x201cb10) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:921 #2 0x0042cea2 in kvm_cpu_exec (env=0x201cb10) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1651 #3 0x0042d62c in kvm_main_loop_cpu (env=0x201cb10) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1893 #4 0x0042d76d in ap_main_loop (_env=0x201cb10) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #5 0x7f0b74d983ba in start_thread () from /lib/libpthread.so.0 #6 0x7f0b73e1afcd in clone () from /lib/libc.so.6 #7 0x in ?? () Thread 4 (Thread 0x7f0b72916950 (LWP 25545)): #0 0x7f0b73d69461 in sigtimedwait () from /lib/libc.so.6 #1 0x0042d1e5 in kvm_main_loop_wait (env=0x200ed90, timeout=1000) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1752 #2 0x0042d64a in kvm_main_loop_cpu (env=0x200ed90) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1896 #3 0x0042d76d in ap_main_loop (_env=0x200ed90) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #4 0x7f0b74d983ba in start_thread () from /lib/libpthread.so.0 #5 0x7f0b73e1afcd in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 3 (Thread 0x7f0b73117950 (LWP 25544)): #0 0x7f0b73d69461 in sigtimedwait () from /lib/libc.so.6 #1 0x0042d1e5 in kvm_main_loop_wait (env=0x2001010, timeout=1000) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1752 #2 0x0042d64a in kvm_main_loop_cpu (env=0x2001010) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1896 #3 0x0042d76d in ap_main_loop (_env=0x2001010) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #4 0x7f0b74d983ba in start_thread () from /lib/libpthread.so.0 #5 0x7f0b73e1afcd in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 2 (Thread 0x7f0b73918950 (LWP 25543)): #0 0x7f0b73d69461 in sigtimedwait () from /lib/libc.so.6 #1 0x0042d1e5 in kvm_main_loop_wait (env=0x1fe75b0, timeout=1000) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1752 #2 0x0042d64a in kvm_main_loop_cpu (env=0x1fe75b0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1896 #3 0x0042d76d in ap_main_loop (_env=0x1fe75b0) at /usr/src/qemu-kvm-0.12.4/qemu-kvm.c:1943 #4 0x7f0b74d983ba in start_thread () from /lib/libpthread.so.0 #5 0x7f0b73e1afcd in clone () from /lib/libc.so.6 #6 0x in ?? () Thread 1 (Thread 0x7f0b753c76f0 (LWP 25532)): ---Type to continue, or q to quit--- #0 0x7f0b73e13742 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=43, argv=0x7fffcc0c3398, envp=0x7fffcc0c34f8) at /usr/src/qemu-kvm-0.12.4/vl.c:6252 Alexander Graf wrote: On 18.05.2010, at 13:08, Peter Lieven wrote: Alexander Graf wrote: On 18.05.2010, at 13:01, Peter Lieven wrote: hi alex, unfortunately -cpu host, -cpu qemu64, -cpu core2duo, -cpu kvm64 (which should be default) doesn't help all other cpus available are 32-bit afaik. as i said if i boot with with kernel parameter "nohpet", but acpi on the guest just hangs at 100% cpu. would a backtrace help? Sigh. Is there any way to upgrade the system to SP3? Preferably incl. the latest maintenance update? yes, we will try this. if you don't suspect it is a generall problem with qemu-kvm that should be fixed. keep you posted. Alright. Installing SLES10 SP1 in a VM in parallel. Alex -- 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] VNC encoding ZLibHex?
is there any standard tests that can be run for comparing different encodings? i am not familiar whit that unfortunately. br, peter Corentin Chary wrote: The best way to know it would be to setup a vnc server with zlibhex support (libvncserver and ultravnc seems to support that encoding) and get some numbers (you can choose the prefered encoding with most of the vnc clients).
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
during my tests i also got the following error: Freeing initrd memory: 2860k freed not found! ..MP-BIOS bug: 8254 timer not connected to IO-APIC failed. timer doesn't work through the IO-APIC - disabling NMI Watchdog!
Re: [Qemu-devel] [PATCH 4/8] monitor: Add basic device state visualization
Jan Kiszka writes:
> This introduces device_show, a monitor command that saves the vmstate of
> a qdev device and visualizes it. QMP is also supported. Buffers are cut
> after 16 byte by default, but the full content can be requested via
> '-f'. To pretty-print sub-arrays, vmstate is extended to store the start
> index name.
>
> Signed-off-by: Jan Kiszka
Neato! Comments inline.
> ---
> hw/hw.h |2 +
> hw/qdev.c | 287
> +++
> hw/qdev.h |2 +
> qemu-monitor.hx | 16 +++
> 4 files changed, 307 insertions(+), 0 deletions(-)
>
> diff --git a/hw/hw.h b/hw/hw.h
> index 328b704..1ff8e40 100644
> --- a/hw/hw.h
> +++ b/hw/hw.h
> @@ -299,6 +299,7 @@ enum VMStateFlags {
>
> typedef struct {
> const char *name;
> +const char *start_index;
> size_t offset;
> size_t size;
> size_t start;
Why is start_index a string?
> @@ -414,6 +415,7 @@ extern const VMStateInfo vmstate_info_unused_buffer;
> .size = sizeof(_type), \
> .flags = VMS_ARRAY, \
> .offset = vmstate_offset_sub_array(_state, _field, _type, _start), \
> +.start_index = (stringify(_start)), \
> }
>
> #define VMSTATE_VARRAY_INT32(_field, _state, _field_num, _version, _info,
> _type) {\
> diff --git a/hw/qdev.c b/hw/qdev.c
> index fe49e71..c989010 100644
> --- a/hw/qdev.c
> +++ b/hw/qdev.c
> @@ -29,6 +29,9 @@
> #include "qdev.h"
> #include "sysemu.h"
> #include "monitor.h"
> +#include "qjson.h"
> +#include "qint.h"
> +#include "qbuffer.h"
>
> static int qdev_hotplug = 0;
>
> @@ -824,3 +827,287 @@ int do_device_del(Monitor *mon, const QDict *qdict,
> QObject **ret_data)
> }
> return qdev_unplug(dev);
> }
> +
> +static int print_array_index(Monitor *mon, const char *start, int index)
> +{
> +char index_str[32];
> +int len;
> +
> +if (start) {
> +len = snprintf(index_str, sizeof(index_str), "[%s+%02x]", start,
> + index);
> +} else {
> +len = snprintf(index_str, sizeof(index_str), "[%02x]", index);
> +}
> +monitor_printf(mon, index_str);
> +return len;
You go via the snprintf() detour just because monitor_printf() doesn't
return the number of characters printed. Wouldn't it be better to fix
that?
> +}
> +
> +#define NAME_COLUMN_WIDTH 23
> +
> +static void print_field(Monitor *mon, const QDict *qfield, int indent);
> +
> +static void print_elem(Monitor *mon, const QObject *qelem, size_t size,
> + int column_pos, int indent)
> +{
> +int64_t data_size;
> +const void *data;
> +int n;
> +
> +if (qobject_type(qelem) == QTYPE_QDICT) {
> +if (column_pos >= 0) {
> +monitor_printf(mon, ".\n");
> +}
> +} else {
> +monitor_printf(mon, ":");
> +column_pos++;
> +if (column_pos < NAME_COLUMN_WIDTH) {
> +monitor_printf(mon, "%*c", NAME_COLUMN_WIDTH - column_pos, ' ');
> +}
> +}
> +
> +switch (qobject_type(qelem)) {
> +case QTYPE_QDICT:
> +print_field(mon, qobject_to_qdict(qelem), indent + 2);
> +break;
> +case QTYPE_QBUFFER:
> +data = qbuffer_get_data(qobject_to_qbuffer(qelem));
> +data_size = qbuffer_get_size(qobject_to_qbuffer(qelem));
> +for (n = 0; n < data_size; ) {
> +monitor_printf(mon, " %02x", *((uint8_t *)data+n));
> +if (++n < size) {
> +if (n % 16 == 0) {
> +monitor_printf(mon, "\n%*c", NAME_COLUMN_WIDTH, ' ');
> +} else if (n % 8 == 0) {
> +monitor_printf(mon, " -");
> +}
> +}
> +}
> +if (data_size < size) {
> +monitor_printf(mon, " ...");
> +}
> +monitor_printf(mon, "\n");
> +break;
> +case QTYPE_QINT:
> +monitor_printf(mon, " %0*x\n", (int)size * 2,
> + (int)qint_get_int(qobject_to_qint(qelem)));
I'm confused. Doesn't casting qint_get_int() to int lose bits?
> +break;
> +default:
> +assert(0);
> +}
> +}
> +
> +static void print_field(Monitor *mon, const QDict *qfield, int indent)
> +{
> +const char *name = qdict_get_str(qfield, "name");
> +const char *start = qdict_get_try_str(qfield, "start");
> +int64_t size = qdict_get_int(qfield, "size");
> +QList *qlist = qdict_get_qlist(qfield, "elems");
> +QListEntry *entry, *sub_entry;
> +QList *sub_list;
> +int elem_no = 0;
> +
> +QLIST_FOREACH_ENTRY(qlist, entry) {
> +QObject *qelem = qlist_entry_obj(entry);
> +int pos = indent + strlen(name);
> +
> +if (qobject_type(qelem) == QTYPE_QLIST) {
> +monitor_printf(mon, "%*c%s", indent, ' ', name);
> +pos += print_array_index(mon, start, elem_no);
> +
Re: [Qemu-devel] Qemu-KVM 0.12.3 and Multipath -> Assertion
Am 18.05.2010 13:13, schrieb Peter Lieven: > hi, > > will this patch make it into 0.12.4.1 ? > > br, > peter Anthony, can you please cherry-pick commit 38d8dfa1 into stable-0.12? Kevin > > Christoph Hellwig wrote: >> On Tue, May 04, 2010 at 04:01:35PM +0200, Kevin Wolf wrote: >> >>> Great, I'm going to submit it as a proper patch then. >>> >>> Christoph, by now I'm pretty sure it's right, but can you have another >>> look if this is correct, anyway? >>> >> >> It looks correct to me - we really shouldn't update the the fields >> until bdrv_aio_cancel has returned. In fact we cannot cancel a request >> more often than we can, so there's a fairly high chance it will >> complete. >> >> >> Reviewed-by: Christoph Hellwig
Re: [Qemu-devel] VNC encoding ZLibHex?
On Tue, May 18, 2010 at 2:01 PM, Peter Lieven wrote: > is there any standard tests that can be run for comparing > different encodings? i am not familiar whit that unfortunately. > > br, > peter I'm not aware of standard tests (and if anyone know some, please let me know). Here is how I did my tests for zlib, hextile and tight [1]. I installed a kubuntu with qemu and hacked SDL_viewer example from libvncserver to be able to select an encoding (I can give you the line to modify if you want). Then launched (several times) qemu with ./qemu -m 512 -hda kubuntu.img -vnc :0 & sleep 0.5; ./SDL_viewer 127.0.0.1 On another term I launch tcpdump -i lo0 -nvv port 5900 | python tcpstat.py > dump.csv (but you can use wireshark, etc ...) [1] http://xf.iksaif.net/blog/index.php?post/2010/05/18/QEMU%3A-some-charts-on-tight-zlib-and-hextile -- Corentin Chary http://xf.iksaif.net
Re: [Qemu-devel] [PATCH 1/8] qdev: Allow device addressing via 'driver.instance'
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. Is an instance number a good user interface? Gerd, what do you think? [...]
Re: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer
Jan Kiszka writes: > Avi Kivity wrote: >> On 05/17/2010 10:57 AM, Jan Kiszka wrote: >>> Avi Kivity wrote: >>> On 05/17/2010 10:40 AM, Jan Kiszka wrote: >> The alternative is to have a schema. Sun RPC/XDR doesn't carry any type >> information (you can't even distinguish between a number and text) yet C >> clients have to problem extracting typed information from it. >> >> Having __class__ everywhere means we're carrying the schema in every >> message instead of just once. >> >> > The device_show command is already an example where you don't have a > predefined schema. It is derived from the data stream the encodes the > vmstate fields. So far we have no collision between base64-encoded > buffers and real strings, but this may actually change when we start > annotating the fields with symbolic constants. > > What is the receiver to do with it? If it doesn't know the schema (and there is no schema), then all it can do is display the key/values. If it does know the schema, then __class__ is unnecessary. >>> There is a schema describing the fields (name, size, number of >>> elements), >> >> Surely the schema has to describe the type as well? If it does, you can >> use the schema to generate a classes at compile time. Doesn't that tie you to a specific version of QMP at compile-time? >>> but their types (int, buffer, sub-field, array of X) are >>> derived from the JSON objects (ie. the JSON parser does this job). >>> >> >> The names of fields are also type information. > > Not in the case of device_show. The clients have no idea of the vmstate > structures before they were transfered. Granted, that will likely remain > a special case in the QMP command set. qdev device properties are similar. Right now, they occur only as arguments of device_add. When do_info_qtree() gets converted, they'll appear in results. [...]
Re: [Qemu-devel] Re: [PATCH 3/8] Add QBuffer
Anthony Liguori writes: > On 05/17/2010 02:45 AM, Avi Kivity wrote: >> On 05/17/2010 10:40 AM, Jan Kiszka wrote: >>> The alternative is to have a schema. Sun RPC/XDR doesn't carry any type information (you can't even distinguish between a number and text) yet C clients have to problem extracting typed information from it. Having __class__ everywhere means we're carrying the schema in every message instead of just once. >>> The device_show command is already an example where you don't have a >>> predefined schema. It is derived from the data stream the encodes the >>> vmstate fields. So far we have no collision between base64-encoded >>> buffers and real strings, but this may actually change when we start >>> annotating the fields with symbolic constants. >> >> What is the receiver to do with it? >> >> If it doesn't know the schema (and there is no schema), then all it >> can do is display the key/values. If it does know the schema, then >> __class__ is unnecessary. >> >> My worry is that __class__ will make the protocol more ad-hoc. >> >>> I really don't see the problem with __class__. Being a text protocol, >>> JSON is already fairly verbose. >> >> The problem is not the verbosity, it's that information is carried >> too late. Many clients want to know this information at compile >> time or initialization time, and we are providing it at object >> instantiating time. > > Whether a protocol is self-describing is orthogonal to whether it's > well defined (ala a schema). A self-describing protocol is very > convenient for dynamic languages like Python. We should also provide > a formal schema though for languages that require IDL to generate > bindings (like C). And that schema should be available over QMP.
Re: [Qemu-devel] [PATCH 1/8] qdev: Allow device addressing via 'driver.instance'
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. 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. cheers, Gerd
Re: [Qemu-devel] [PATCH 2/2] all vga: fail graicefully when vga ports are taken
Gerd Hoffmann writes: > Try to pci hotplug a vga card, watch qemu die with hw_error(). > This patch fixes it. Looks good. Are there any other hot-pluggable devices that acquire single-use resources such as fixed I/O ports?
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Peter, Peter Lieven wrote: > hi alex, > > here is a backtrace of the sles 10 sp1 vm running on qemu-kvm 0.12.4. > hanging at boot. Please do not top post! Seriously. One more time and I'll stop responding. I tried to reproduce this locally on an openSUSE 11.1 system using latest qemu-kvm.git/stable-0.12 which should basically be 0.12.4: $ /sbin/modinfo kvm-intel ... version:kvm-kmod-78.2.6.30.1-20.4 ... ag...@busu:~/git/qemu-kvm> cat /proc/cpuinfo processor: 0 vendor_id: AuthenticAMD cpu family: 16 model: 2 model name: AMD Phenom(tm) 9550 Quad-Core Processor stepping: 3 cpu MHz: 1100.000 cache size: 512 KB physical id: 0 siblings: 4 core id: 0 cpu cores: 4 apicid: 0 initial apicid: 0 fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs bogomips: 4409.11 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate The freshly installed sles10 sp1 image works just fine.
[Qemu-devel] Re: [PATCH 1/8] qdev: Allow device addressing via 'driver.instance'
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. 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. Agreed. The problem here is that we sent the instance_id on the wire, so for "legacy" devices that used an instance_id != -1, we are stuck with it :( Guess why a friend calls "backwards compatibility": A Curse of Bible proportions :( Later, Juan.
Re: [Qemu-devel] [PATCH 2/2] all vga: fail graicefully when vga ports are taken
On 05/18/10 14:33, Markus Armbruster wrote: Gerd Hoffmann writes: Try to pci hotplug a vga card, watch qemu die with hw_error(). This patch fixes it. Looks good. Are there any other hot-pluggable devices that acquire single-use resources such as fixed I/O ports? Any PCI device doing ISA compatibility stuff I'd guess, which makes IDE a candidate. Checking ... Yes (hw/ide/piix.c): ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6); ide_init_ioport(&d->bus[1], 0x170, 0x376); Those are tagged with "no-user" though due to being hard-coded in pc.c, so any attempt to hot-plug one of those should fail way before it attempts to grab the I/O ports. cheers, Gerd
Re: [Qemu-devel] [PATCH 1/2] QMP: Introduce commands doc
On Tue, 18 May 2010 11:51:26 +0200 Markus Armbruster wrote: > Anthony Liguori writes: > > > On 05/15/2010 01:19 AM, Avi Kivity wrote: > >> On 05/15/2010 01:54 AM, Luiz Capitulino wrote: > >>> On Fri, 14 May 2010 19:03:36 +0200 > >>> Markus Armbruster wrote: > >>> > > What about PCI domains? > Good point. Better to provide for them neatly now, instead of kludging > them in later. > >>> When I did this conversion I asked Micheal for help with that and > >>> he said > >>> QEMU doesn't support PCI domains. > >> > >> That's very different from "will never support pci domains". > >> > >> The protocol must be forward looking, or we will need endless fixes > >> for it. > > > > But we can always add a domain property to extend the address (with a > > default domain of 0). > > Why not add it right away? The plan is to merge the doc and work on all changes suggested by Avi (always coordinating with libvirt, of course). Although query-pci is not used there. > Note that if we'd decide to adopt Avi's suggestion to make this "a > nested object (list of buses, each containing a list of slots, each > containing a list of functions)", then we can't easily add domains > later, because that would insert a level of nesting near the top. Right.
[Qemu-devel] [PATCH v2 03/10] vnc: only use a single zlib stream
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 v2 09/10] vnc: tight: add palette encoding
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 | 430 --
1 files changed, 418 insertions(+), 12 deletions(-)
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index 44984f9..b836569 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -27,6 +27,8 @@
#include
+#include "qdict.h"
+#include "qint.h"
#include "vnc.h"
#include "vnc-encoding-tight.h"
@@ -55,6 +57,279 @@ 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++; \
+} else
[Qemu-devel] [PATCH v2 02/10] vnc: really call zlib if we want zlib
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 a91c3a3..d0c0d00 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 v2 01/10] vnc: refactor set_encodings
Create a new set_encoding() function to remove
duplicated code in set_encodings().
Signed-off-by: Corentin Chary
---
vnc.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/vnc.c b/vnc.c
index 1f7ad73..a91c3a3 100644
--- a/vnc.c
+++ b/vnc.c
@@ -1587,6 +1587,13 @@ static void send_ext_audio_ack(VncState *vs)
vnc_flush(vs);
}
+static void set_encoding(VncState *vs, int encoding)
+{
+if (vs->vnc_encoding == -1) {
+vs->vnc_encoding = encoding;
+}
+}
+
static void set_encodings(VncState *vs, int32_t *encodings, size_t n_encodings)
{
int i;
@@ -1603,24 +1610,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;
-}
+set_encoding(vs, 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;
-}
+set_encoding(vs, enc);
break;
case VNC_ENCODING_ZLIB:
vs->features |= VNC_FEATURE_ZLIB_MASK;
-if (vs->vnc_encoding != -1) {
-vs->vnc_encoding = enc;
-}
+set_encoding(vs, enc);
break;
case VNC_ENCODING_DESKTOPRESIZE:
vs->features |= VNC_FEATURE_RESIZE_MASK;
--
1.7.0.2
[Qemu-devel] [PATCH v2 00/10] vnc-encodings
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 Since v1: added commit descriptions for all patchs Corentin Chary (10): vnc: refactor set_encodings vnc: really call zlib if we want zlib vnc: only use a single zlib stream vnc: adjust compression zstream level vnc: add basic tight support vnc: add support for tight fill encoding vnc: don't clear zlib stream on set_encoding vnc: remove memory leaks in zlib and tight encoding vnc: tight: add palette encoding vnc: update copyrights for vnc-encoding-tight.c Makefile |2 + Makefile.objs |1 + vnc-encoding-hextile.c |5 +- vnc-encoding-tight.c | 945 vnc-encoding-tight.h | 199 ++ vnc-encoding-zlib.c| 43 ++- vnc.c | 79 +++-- vnc.h | 24 +- 8 files changed, 1245 insertions(+), 53 deletions(-) create mode 100644 vnc-encoding-tight.c create mode 100644 vnc-encoding-tight.h
[Qemu-devel] [PATCH v2 08/10] vnc: remove memory leaks in zlib and tight encoding
Free buffers used by tight and zlib encodings, lso introduce
a new helper to free buffers: buffer_free()
Signed-off-by: Corentin Chary
---
vnc-encoding-tight.c | 11 +++
vnc-encoding-zlib.c |8
vnc.c| 23 ++-
vnc.h|4 +++-
4 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index 229927e..44984f9 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -499,6 +499,17 @@ static int find_large_solid_color_rect(VncState *vs, int
x, int y,
return n + send_rect_simple(vs, x, y, w, h);
}
+void vnc_tight_clear(VncState *vs)
+{
+int i;
+for (i=0; itight_stream); i++)
+if (vs->tight_stream[i].opaque)
+deflateEnd(&vs->tight_stream[i]);
+
+buffer_free(&vs->tight);
+buffer_free(&vs->tight_zlib);
+}
+
int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y,
int w, int h)
{
diff --git a/vnc-encoding-zlib.c b/vnc-encoding-zlib.c
index 6b68540..e5a431e 100644
--- a/vnc-encoding-zlib.c
+++ b/vnc-encoding-zlib.c
@@ -143,3 +143,11 @@ int vnc_zlib_send_framebuffer_update(VncState *vs, int x,
int y, int w, int h)
return 1;
}
+
+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 f660c10..0dac736 100644
--- a/vnc.c
+++ b/vnc.c
@@ -503,7 +503,15 @@ uint8_t *buffer_end(Buffer *buffer)
void buffer_reset(Buffer *buffer)
{
-buffer->offset = 0;
+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)
@@ -922,17 +930,14 @@ 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);
+vnc_tight_clear(vs);
+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 ea6e70b..18a4e8b 100644
--- a/vnc.h
+++ b/vnc.h
@@ -383,7 +383,7 @@ int buffer_empty(Buffer *buffer);
uint8_t *buffer_end(Buffer *buffer);
void buffer_reset(Buffer *buffer);
void buffer_append(Buffer *buffer, const void *data, size_t len);
-
+void buffer_free(Buffer *buffer);
/* Misc helpers */
@@ -403,10 +403,12 @@ int 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_clear(VncState *vs);
void *vnc_zlib_zalloc(void *x, unsigned items, unsigned size);
void vnc_zlib_zfree(void *x, void *addr);
int vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
+void vnc_tight_clear(VncState *vs);
int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y, int w, int
h);
#endif /* __QEMU_VNC_H */
--
1.7.0.2
[Qemu-devel] [PATCH v2 10/10] vnc: update copyrights for vnc-encoding-tight.c
Add missing copyrights in vnc-encoding-tight.c, since the code is mostly inspired from libvncserver/tight.c. Signed-off-by: Corentin Chary --- vnc-encoding-tight.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c index b836569..0c661a9 100644 --- a/vnc-encoding-tight.c +++ b/vnc-encoding-tight.c @@ -1,9 +1,14 @@ /* * QEMU VNC display driver: tight encoding * + * From libvncserver/tight.c + * Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved. + * Copyright (C) 2000, 2001 Const Kaplinsky. All Rights Reserved. + * * Copyright (C) 2006 Anthony Liguori * Copyright (C) 2006 Fabrice Bellard * Copyright (C) 2009 Red Hat, Inc + * Copyright (C) 2019 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 -- 1.7.0.2
[Qemu-devel] [PATCH v2 04/10] vnc: adjust compression zstream level
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 v2 06/10] vnc: add support for tight fill encoding
Fill encoding detects rectangle using only one color and send only
one pixel value.
Signed-off-by: Corentin Chary
---
vnc-encoding-tight.c | 245 +-
1 files changed, 244 insertions(+), 1 deletions(-)
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index 0d328c2..5ea90c0 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -54,6 +54,135 @@ 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_ptr)
+{
+int cx, cy;
+
+/* Try to extend the area upwards. */
+for ( cy = *y_ptr - 1;
+ cy >= y && check_solid_tile(vs, *x_ptr, cy, *w_ptr, 1, &color, true);
+
[Qemu-devel] [PATCH v2 07/10] vnc: don't clear zlib stream on set_encoding
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 tight and zlib encodings.
Signed-off-by: Corentin Chary
---
vnc-encoding-tight.c |7 ---
vnc-encoding-zlib.c |5 -
vnc.c|2 --
vnc.h|2 --
4 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index 5ea90c0..229927e 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -499,13 +499,6 @@ static int find_large_solid_color_rect(VncState *vs, int
x, int y,
return n + send_rect_simple(vs, x, y, w, h);
}
-void vnc_tight_init(VncState *vs)
-{
-int i;
-for (i=0; itight_stream); i++)
-vs->tight_stream[i].opaque = NULL;
-}
-
int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y,
int w, int h)
{
diff --git a/vnc-encoding-zlib.c b/vnc-encoding-zlib.c
index 17a61bf..6b68540 100644
--- a/vnc-encoding-zlib.c
+++ b/vnc-encoding-zlib.c
@@ -143,8 +143,3 @@ int vnc_zlib_send_framebuffer_update(VncState *vs, int x,
int y, int w, int h)
return 1;
}
-
-void vnc_zlib_init(VncState *vs)
-{
-vs->zlib_stream.opaque = NULL;
-}
diff --git a/vnc.c b/vnc.c
index c7b76ff..f660c10 100644
--- a/vnc.c
+++ b/vnc.c
@@ -1610,8 +1610,6 @@ static void set_encodings(VncState *vs, int32_t
*encodings, size_t n_encodings)
int i;
unsigned int enc = 0;
-vnc_zlib_init(vs);
-vnc_tight_init(vs);
vs->features = 0;
if (!vs->vnc_encoding)
vs->vnc_encoding = -1;
diff --git a/vnc.h b/vnc.h
index ec7f481..ea6e70b 100644
--- a/vnc.h
+++ b/vnc.h
@@ -403,12 +403,10 @@ int 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_zalloc(void *x, unsigned items, unsigned size);
void vnc_zlib_zfree(void *x, void *addr);
int vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h);
-void vnc_tight_init(VncState *vs);
int vnc_tight_send_framebuffer_update(VncState *vs, int x, int y, int w, int
h);
#endif /* __QEMU_VNC_H */
--
1.7.0.2
[Qemu-devel] [PATCH v2 05/10] vnc: add basic tight support
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-hextile.c |5 +-
vnc-encoding-tight.c | 287
vnc-encoding-tight.h | 199 +
vnc-encoding-zlib.c| 17 ++-
vnc.c | 37 +--
vnc.h | 17 +++-
8 files changed, 543 insertions(+), 22 deletions(-)
create mode 100644 vnc-encoding-tight.c
create mode 100644 vnc-encoding-tight.h
diff --git a/Makefile b/Makefile
index eb9e02b..99d9c5d 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-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-tight.c b/vnc-encoding-tight.c
new file mode 100644
index 000..0d328c2
--- /dev/null
+++ b/vnc-encoding-tight.c
@@ -0,0 +1,287 @@
+/*
+ * QEMU VNC display driver: tight encoding
+ *
+ * Copyright (C) 2006 Anthony Liguori
+ * Copyright (C) 2006 Fabrice Bellard
+ * Copyright (C) 2009 Red Hat, Inc
+ *
+ * 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,
Re: [Qemu-devel] Re: [PATCH 1/2] QMP: Introduce commands doc
On Tue, 18 May 2010 13:21:36 +0200 Markus Armbruster wrote: > Jan Kiszka writes: [...] > > nothing needs to be delayed any further. > > Well, it's being delayed :) > > Let's commit the sucker as is. We can still move it into > qemu-monitor.hx afterwards. Commits are cheap, waiting for the perfect > patch isn't. Jan has already adapted qemu-monitor.hx and moved the entire doc into there. I didn't take a look at the patches yet, though. Will do it today and work on the (_doc_) proposed changes in the process.
[Qemu-devel] Re: [PATCH v2 04/10] vnc: adjust compression zstream level
Corentin Chary wrote: > Adjust zlib compression level if needed by calling deflateParams. > > Signed-off-by: Corentin Chary > Wow, I didn't know it was that easy :). Acked-by: Alexander Graf
[Qemu-devel] Re: [PATCH v2 03/10] vnc: only use a single zlib stream
Corentin Chary wrote: > 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. > How about when we start to implement zrle or zhextile? Wouldn't those need different streams? Alex
[Qemu-devel] Re: [PATCH v2 02/10] vnc: really call zlib if we want zlib
Corentin Chary wrote: > send_framebuffer_update() was calling hextile instead of zlib > since commit 70a4568fe0c5a64adaa3da5030b7109e5199e692. > > Signed-off-by: Corentin Chary > Acked-by: Alexander Graf
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Alexander Graf wrote: Peter, Peter Lieven wrote: hi alex, here is a backtrace of the sles 10 sp1 vm running on qemu-kvm 0.12.4. hanging at boot. Please do not top post! Seriously. One more time and I'll stop responding. I tried to reproduce this locally on an openSUSE 11.1 system using latest qemu-kvm.git/stable-0.12 which should basically be 0.12.4: $ /sbin/modinfo kvm-intel ... version:kvm-kmod-78.2.6.30.1-20.4 ... ag...@busu:~/git/qemu-kvm> cat /proc/cpuinfo processor: 0 vendor_id: AuthenticAMD cpu family: 16 model: 2 model name: AMD Phenom(tm) 9550 Quad-Core Processor stepping: 3 cpu MHz: 1100.000 cache size: 512 KB physical id: 0 siblings: 4 core id: 0 cpu cores: 4 apicid: 0 initial apicid: 0 fpu: yes fpu_exception: yes cpuid level: 5 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs bogomips: 4409.11 TLB size: 1024 4K pages clflush size: 64 cache_alignment: 64 address sizes: 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate The freshly installed sles10 sp1 image works just fine. we are running on intel xeons here: processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 26 model name: Intel(R) Xeon(R) CPU L5530 @ 2.40GHz stepping: 5 cpu MHz: 2394.403 cache size: 8192 KB physical id: 1 siblings: 4 core id: 0 cpu cores: 4 apicid: 16 initial apicid: 16 fpu: yes fpu_exception: yes cpuid level: 11 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid bogomips: 4788.80 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: kvm-kmod is 2.6.32.7 ... which commandline parameters do you supply to qemu-kvm? which kernel parameters do you use for the sles 10 guest?
[Qemu-devel] Re: [PATCH RFC] virtio_blk: Use blk-iopoll for host->guest notify
On Tue, May 18 2010, Stefan Hajnoczi wrote: > On Fri, May 14, 2010 at 05:30:56PM -0500, Brian Jackson wrote: > > Any preliminary numbers? latency, throughput, cpu use? What about comparing > > different "weights"? > > I am running benchmarks and will report results when they are in. I'm very interested as well, I have been hoping for some more adoption of this. I have mptsas and mpt2sas patches pending as well. I have not done enough and fully exhaustive weight analysis, so note me down for wanting such an analysis on virtio_blk as well. -- Jens Axboe
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Alexander Graf wrote: Peter Lieven wrote: we are running on intel xeons here: That might be the reason. Does it break when passing -no-kvm? processor: 0 vendor_id: GenuineIntel cpu family: 6 model: 26 model name: Intel(R) Xeon(R) CPU L5530 @ 2.40GHz stepping: 5 cpu MHz: 2394.403 cache size: 8192 KB physical id: 1 siblings: 4 core id: 0 cpu cores: 4 apicid: 16 initial apicid: 16 fpu: yes fpu_exception: yes cpuid level: 11 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow vnmi flexpriority ept vpid bogomips: 4788.80 clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: kvm-kmod is 2.6.32.7 ... which commandline parameters do you supply to qemu-kvm? None :) It seems to stop working if i supply -no-kvm-irqchip. Can you try to reproduce this? We introduced that parameter because we encountered some problems with the e1000 kernel driver stopped to work in some guests after live migration with a "nobody cared about interupt" (i don't know the exact error anymore). supplying -no-kvm-irqchip made live migration of these guests possible... Sounds that familiar to someone? Peter which kernel parameters do you use for the sles 10 guest? Just the default. I took the SP1 DVD, installed it and booted it up. All is fine: $ ./x86_64-softmmu/qemu-system-x86_64 -snapshot /media/studio/images/SUSE/sles10/sles10sp1.x86_64.raw -vnc :10 Running on Intel might be the culprit though. I'll try and check if booting the image on an Intel box works. Alex
[Qemu-devel] Re: [PATCH v2 01/10] vnc: refactor set_encodings
Corentin Chary wrote: > Create a new set_encoding() function to remove > duplicated code in set_encodings(). > > Signed-off-by: Corentin Chary > Acked-by: Alexander Graf Keep in mind that this still means that the last requested compression algorithm is used, which is reverse according to spec. Alex
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Peter Lieven wrote: > we are running on intel xeons here: That might be the reason. Does it break when passing -no-kvm? > > processor: 0 > vendor_id: GenuineIntel > cpu family: 6 > model: 26 > model name: Intel(R) Xeon(R) CPU L5530 @ 2.40GHz > stepping: 5 > cpu MHz: 2394.403 > cache size: 8192 KB > physical id: 1 > siblings: 4 > core id: 0 > cpu cores: 4 > apicid: 16 > initial apicid: 16 > fpu: yes > fpu_exception: yes > cpuid level: 11 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good > xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est > tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow > vnmi flexpriority ept vpid > bogomips: 4788.80 > clflush size: 64 > cache_alignment: 64 > address sizes: 40 bits physical, 48 bits virtual > power management: > > kvm-kmod is 2.6.32.7 > ... > > which commandline parameters do you supply to qemu-kvm? None :) > > which kernel parameters do you use for the sles 10 guest? Just the default. I took the SP1 DVD, installed it and booted it up. All is fine: $ ./x86_64-softmmu/qemu-system-x86_64 -snapshot /media/studio/images/SUSE/sles10/sles10sp1.x86_64.raw -vnc :10 Running on Intel might be the culprit though. I'll try and check if booting the image on an Intel box works. Alex
[Qemu-devel] Re: qemu-kvm hangs if multipath device is queing
Am 18.05.2010 13:10, schrieb Peter Lieven: > hi kevin, > > here is the backtrace of (hopefully) all threads: > > ^C > Program received signal SIGINT, Interrupt. > [Switching to Thread 0x7f39b72656f0 (LWP 10695)] > 0x7f39b6c3ea94 in __lll_lock_wait () from /lib/libpthread.so.0 > > (gdb) thread apply all bt > > Thread 2 (Thread 0x7f39b57b8950 (LWP 10698)): > #0 0x7f39b6c3eedb in read () from /lib/libpthread.so.0 > #1 0x0049e723 in qemu_laio_completion_cb (opaque=0x22b4010) at > linux-aio.c:125 > #2 0x0049e8ad in laio_cancel (blockacb=0x22ba310) at > linux-aio.c:184 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. We'll be stuck in an endless loop if the request doesn't complete, which might well happen in your scenario. Not sure what the right thing to do is. We probably need to fail the bdrv_aio_cancel to avoid blocking the whole program, but I have no idea what device emulations should do on that condition. As long as we can't handle that condition correctly, leaving the hang in place is probably the best option. Maybe add some sleep to avoid 100% CPU consumption. Kevin
Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
On 05/18/2010 03:09 AM, Kevin Wolf wrote: Am 17.05.2010 23:43, schrieb Anthony Liguori: On 05/17/2010 04:35 PM, malc wrote: There's one thing that SDL does marvelously well - it's just one fairly small and self contained library that doesn't unleash dependency hell on the user. The fact that we have cocoa support in the tree is basically an admission of failure with SDL. I don't think so, the way i see it: someone had an itch (i.e. an application that does not integrate well with his windowing environment) and he scratched it. SDL doesn't integrate well into a modern Gnome desktop either. I don't see why we have Cocoa and not Gtk. If the answer is, someone needs to send patches, expect patches soon :-) So with this argument, we'll not only get a GTK backend, but Qt and Windows backends, too? But then you can't reasonably say any more that DirectFB would be too much additional code to maintain. Yes, that's the point. Instead of having a single backend (SDL) and expecting SDL to do everything for us, we would support multiple backends (like DirectFB). Regards, Anthony Liguori Kevin
[Qemu-devel] Re: [PATCH 1/8] qdev: Allow device addressing via 'driver.instance'
Hi, Agreed. The problem here is that we sent the instance_id on the wire, so for "legacy" devices that used an instance_id != -1, we are stuck with it :( Another way would be to fill the instance id with something useful, say encode the pci address there for pci devices. That should be good enough to reliably identify devices even after hot-plugging them in and out. Of course this has transition isses too. But maybe it is easier to handle than replacing instance_id with something entirely different. And it also makes the instance id less useful to address devices in a human-friendly way. cheers, Gerd
[Qemu-devel] Re: [PATCH v2 05/10] vnc: add basic tight support
On 05/18/2010 07:49 AM, Corentin Chary wrote:
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-hextile.c |5 +-
vnc-encoding-tight.c | 287
vnc-encoding-tight.h | 199 +
vnc-encoding-zlib.c| 17 ++-
vnc.c | 37 +--
vnc.h | 17 +++-
8 files changed, 543 insertions(+), 22 deletions(-)
create mode 100644 vnc-encoding-tight.c
create mode 100644 vnc-encoding-tight.h
diff --git a/Makefile b/Makefile
index eb9e02b..99d9c5d 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-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-tight.c b/vnc-encoding-tight.c
new file mode 100644
index 000..0d328c2
--- /dev/null
+++ b/vnc-encoding-tight.c
@@ -0,0 +1,287 @@
+/*
+ * QEMU VNC display driver: tight encoding
+ *
+ * Copyright (C) 2006 Anthony Liguori
+ * Copyright (C) 2006 Fabrice Bellard
+ * Copyright (C) 2009 Red Hat, Inc
+ *
+ * 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,
[Qemu-devel] Re: [PATCH v2 06/10] vnc: add support for tight fill encoding
On 05/18/2010 07:49 AM, Corentin Chary wrote:
Fill encoding detects rectangle using only one color and send only
one pixel value.
Signed-off-by: Corentin Chary
---
vnc-encoding-tight.c | 245 +-
1 files changed, 244 insertions(+), 1 deletions(-)
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index 0d328c2..5ea90c0 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -54,6 +54,135 @@ 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_ptr)
+{
+int cx, cy;
+
+/* Try to extend the area upwards. */
+for ( cy = *y_ptr - 1;
+ cy>= y&& check_solid_t
Re: [Qemu-devel] Suggested Parameters for SLES 10 64-bit
Peter Lieven writes: > Starting mail service (Postfix) > NMI Watchdog detected LOCKUP on CPU 0 You could simply turn off the NMI watchdog (nmi_watchdog=0 at the kernel command line) Perhaps the PMU emulation is not complete and nmi watchdog needs PMU. It's not really needed normally. -Andi -- a...@linux.intel.com -- Speaking for myself only.
[Qemu-devel] Re: [PATCH v2 10/10] vnc: update copyrights for vnc-encoding-tight.c
On 05/18/2010 07:49 AM, Corentin Chary wrote: Add missing copyrights in vnc-encoding-tight.c, since the code is mostly inspired from libvncserver/tight.c. Signed-off-by: Corentin Chary --- vnc-encoding-tight.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c index b836569..0c661a9 100644 --- a/vnc-encoding-tight.c +++ b/vnc-encoding-tight.c @@ -1,9 +1,14 @@ /* * QEMU VNC display driver: tight encoding * + * From libvncserver/tight.c + * Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved. + * Copyright (C) 2000, 2001 Const Kaplinsky. All Rights Reserved. + * * Copyright (C) 2006 Anthony Liguori * Copyright (C) 2006 Fabrice Bellard * Copyright (C) 2009 Red Hat, Inc + * Copyright (C) 2019 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 This should come earlier in the series and also needs to carry a LICENSE. If it's truly under 'All Rights Reserved', then we cannot incorporate this code into QEMU. Regards, Anthony Liguori
[Qemu-devel] Re: [PATCH v2 03/10] vnc: only use a single zlib stream
On 05/18/2010 07:51 AM, Alexander Graf wrote: Corentin Chary wrote: 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. How about when we start to implement zrle or zhextile? Wouldn't those need different streams? Only tight uses multiple streams. zrle just uses one. zhextile doesn't exist and if it did, it wouldn't be better than Tight because Tight is essentially zhextile :-) Regards, Anthony Liguori Alex
Re: [Qemu-devel] VNC encoding ZLibHex?
On 05/18/2010 05:15 AM, Peter Lieven wrote: Hi, has someone enough background to say if it was worth implementing ZLibHex encoding to qemu/kvm? The way I look at it, hextile is capable of a 16x16 tile that can be raw, filled, or can contain colored subrects. Tight allows arbitrary tile size, can be raw, filled, or paletted. Paletted is going to be a pretty close approximation to colored subrects (probably superior). Since Tight is compressed, the result should be that Tight always does better than compressed hextile. Not to mention the fact that ZLibHex is not supported very well across clients. Regards, Anthony Liguori If yes, I would go for that. BR, Peter
