[Qemu-devel] Qemu contribution but out the GSoC
Hello, This year i am not eligible to participate in gsoc. But really want to contribute to qemu project. Do i have any chance? Do you mentor projects outside gsoc? Can I somehow contribute to qemu project, out of the gsoc? Can I get mentor outside of the gsoc, like otherhttp://teachingopensource.org/index.php/FOSS_Mentor_Projects#FOSS_Projects_Interested_in_Mentoring_Students.2FEducatorsorganizations provide? -- Thanks, Devang S http://celeritas9.wordpress.comhttp://celeritas9.wordpress.com/2010/09/27/competition-for-high-grades-seriously-limits-the-quality-of-learning-at-all-levels-of-education/
[Qemu-devel] Re: [PATCH 0/2] avoid races on exec migration
On 03/09/2011 06:21 PM, Paolo Bonzini wrote:
QEMU has a sigchld handler that reaps any child process. -smb is the
only user of it and, in fact, QEMU inherited it from slirp. However,
this handler causes 'exec' based migration to randomly return 'status:
failed' in the monitor. This happens when the signal handler for SIGCHLD
is ran before the pclose() of exec migration.
The return status of fclose() is passed back as return status of
qemu_fclose(). If qemu_fclose() fails, then the exec_close() in
migration-exec.c returns a error code. This causes migrate_fd_cleanup()
to return an error, and thus finally we see why 'status: failed' occurs:
if (migrate_fd_cleanup(s) 0) {
if (old_vm_running) {
vm_start();
}
state = MIG_STATE_ERROR;
}
To avoid this, register the pids in a list and, on SIGCHLD, set up a
bottom-half that would go through the pids and reap them.
Since I'm at it, I'm moving iohandler stuff out of vl.c. The new
file isn't a perfect place to add the child watcher, but it's arguably
better than vl.c.
This should be applied to both master and stable.
Paolo Bonzini (2):
extract I/O handler lists to iohandler.c
add a service to reap zombies
Makefile.objs |2 +-
iohandler.c | 193 +
os-posix.c|9 ---
qemu-common.h |4 +
slirp/misc.c |5 +-
vl.c | 106 ++--
6 files changed, 207 insertions(+), 112 deletions(-)
create mode 100644 iohandler.c
Ping?
Paolo
Re: [Qemu-devel] [PATCH] cocoa: do not create a spurious window for -version
On Mar 19, 2011, at 2:44 PM, Andreas Färber wrote:
Hello Tristan,
Am 15.03.2011 um 14:18 schrieb Tristan Gingold:
When invoked with -version, qemu will exit just after displaying the version,
so there is no need to create a window.
Also handles --XXX options.
Signed-off-by: Tristan Gingold ging...@adacore.com
Looks good to me except for the qemu_main() indentation.
Ah. Sorry for the nit.
Should I fix it and enqueue it on my cocoa branch for the next pull?
Yes please.
Just wondering, since when do we support -- options?
No idea. Wasn't aware of that before someone else in our company used this
flag.
Thanks,
Tristan.
Andreas
---
ui/cocoa.m | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 20f91bc..1ff1ac6 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -865,10 +865,19 @@ int main (int argc, const char * argv[]) {
/* In case we don't need to display a window, let's not do that */
for (i = 1; i argc; i++) {
-if (!strcmp(argv[i], -vnc) ||
-!strcmp(argv[i], -nographic) ||
-!strcmp(argv[i], -curses)) {
+const char *opt = argv[i];
+
+if (opt[0] == '-') {
+/* Treat --foo the same as -foo. */
+if (opt[1] == '-') {
+opt++;
+}
+if (!strcmp(opt, -vnc) ||
+!strcmp(opt, -nographic) ||
+!strcmp(opt, -version) ||
+!strcmp(opt, -curses)) {
return qemu_main(gArgc, gArgv);
+}
}
}
--
1.7.3.GIT
[Qemu-devel] [PATCH 2/4] vnc: don't mess up with iohandlers in the vnc thread
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
Using qemu_mutex_lock_iothread() won't work because vnc_dpy_cpy(),
which will wait for the current job queue to finish, can be called with
the iothread lock held.
Instead, we now store the data in a temporary buffer, and use a bottom
half to notify the main thread that new data is available.
vnc_[un]lock_ouput() is still needed to access VncState members like
abort, csock or jobs_buffer.
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
ui/vnc-jobs-async.c | 48 +---
ui/vnc-jobs.h |1 +
ui/vnc.c| 12
ui/vnc.h|2 ++
4 files changed, 44 insertions(+), 19 deletions(-)
diff --git a/ui/vnc-jobs-async.c b/ui/vnc-jobs-async.c
index 1dfa6c3..4daf4b4 100644
--- a/ui/vnc-jobs-async.c
+++ b/ui/vnc-jobs-async.c
@@ -28,6 +28,7 @@
#include vnc.h
#include vnc-jobs.h
+#include qemu_socket.h
/*
* Locking:
@@ -155,6 +156,24 @@ void vnc_jobs_join(VncState *vs)
qemu_cond_wait(queue-cond, queue-mutex);
}
vnc_unlock_queue(queue);
+vnc_jobs_consume_buffer(vs);
+}
+
+void vnc_jobs_consume_buffer(VncState *vs)
+{
+bool flush;
+
+vnc_lock_output(vs);
+if (vs-jobs_buffer.offset) {
+vnc_write(vs, vs-jobs_buffer.buffer, vs-jobs_buffer.offset);
+buffer_reset(vs-jobs_buffer);
+}
+flush = vs-csock != -1 vs-abort != true;
+vnc_unlock_output(vs);
+
+if (flush) {
+ vnc_flush(vs);
+}
}
/*
@@ -197,7 +216,6 @@ static int vnc_worker_thread_loop(VncJobQueue *queue)
VncState vs;
int n_rectangles;
int saved_offset;
-bool flush;
vnc_lock_queue(queue);
while (QTAILQ_EMPTY(queue-jobs) !queue-exit) {
@@ -213,6 +231,7 @@ static int vnc_worker_thread_loop(VncJobQueue *queue)
vnc_lock_output(job-vs);
if (job-vs-csock == -1 || job-vs-abort == true) {
+vnc_unlock_output(job-vs);
goto disconnected;
}
vnc_unlock_output(job-vs);
@@ -233,10 +252,6 @@ static int vnc_worker_thread_loop(VncJobQueue *queue)
if (job-vs-csock == -1) {
vnc_unlock_display(job-vs-vd);
-/* output mutex must be locked before going to
- * disconnected:
- */
-vnc_lock_output(job-vs);
goto disconnected;
}
@@ -254,24 +269,19 @@ static int vnc_worker_thread_loop(VncJobQueue *queue)
vs.output.buffer[saved_offset] = (n_rectangles 8) 0xFF;
vs.output.buffer[saved_offset + 1] = n_rectangles 0xFF;
-/* Switch back buffers */
vnc_lock_output(job-vs);
-if (job-vs-csock == -1) {
-goto disconnected;
+if (job-vs-csock != -1) {
+buffer_reserve(job-vs-jobs_buffer, vs.output.offset);
+buffer_append(job-vs-jobs_buffer, vs.output.buffer,
+ vs.output.offset);
+/* Copy persistent encoding data */
+vnc_async_encoding_end(job-vs, vs);
+
+ qemu_bh_schedule(job-vs-bh);
}
-
-vnc_write(job-vs, vs.output.buffer, vs.output.offset);
-
-disconnected:
-/* Copy persistent encoding data */
-vnc_async_encoding_end(job-vs, vs);
-flush = (job-vs-csock != -1 job-vs-abort != true);
vnc_unlock_output(job-vs);
-if (flush) {
-vnc_flush(job-vs);
-}
-
+disconnected:
vnc_lock_queue(queue);
QTAILQ_REMOVE(queue-jobs, job, next);
vnc_unlock_queue(queue);
diff --git a/ui/vnc-jobs.h b/ui/vnc-jobs.h
index b8dab81..4c661f9 100644
--- a/ui/vnc-jobs.h
+++ b/ui/vnc-jobs.h
@@ -40,6 +40,7 @@ void vnc_jobs_join(VncState *vs);
#ifdef CONFIG_VNC_THREAD
+void vnc_jobs_consume_buffer(VncState *vs);
void vnc_start_worker_thread(void);
bool vnc_worker_thread_running(void);
void vnc_stop_worker_thread(void);
diff --git a/ui/vnc.c b/ui/vnc.c
index 1b68965..5d4beaa 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1011,7 +1011,10 @@ static void vnc_disconnect_finish(VncState *vs)
#ifdef CONFIG_VNC_THREAD
qemu_mutex_destroy(vs-output_mutex);
+qemu_bh_delete(vs-bh);
+buffer_free(vs-jobs_buffer);
#endif
+
for (i = 0; i VNC_STAT_ROWS; ++i) {
qemu_free(vs-lossy_rect[i]);
}
@@ -1226,6 +1229,14 @@ static long vnc_client_read_plain(VncState *vs)
return ret;
}
+#ifdef CONFIG_VNC_THREAD
+static void vnc_jobs_bh(void *opaque)
+{
+VncState *vs = opaque;
+
+vnc_jobs_consume_buffer(vs);
+}
+#endif
/*
* First function called whenever there is more data to be read from
@@ -2521,6 +2532,7 @@ static void vnc_connect(VncDisplay *vd, int csock)
#ifdef CONFIG_VNC_THREAD
qemu_mutex_init(vs-output_mutex);
+vs-bh = qemu_bh_new(vnc_jobs_bh, vs);
#endif
QTAILQ_INSERT_HEAD(vd-clients, vs, next);
diff --git a/ui/vnc.h b/ui/vnc.h
index f10c5dc..5599a4d 100644
--- a/ui/vnc.h
+++ b/ui/vnc.h
@@ -286,6 +286,8 @@ struct VncState
VncJob job;
#else
[Qemu-devel] [PATCH 4/4] vnc: Limit r/w access to size of allocated memory
From: Stefan Weil w...@mail.berlios.de
This fixes memory reads and writes which exceeded the upper limit
of allocated memory vd-guest.ds-data and vd-server-data.
Cc: Anthony Liguori aligu...@us.ibm.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
ui/vnc.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 90b6384..3138053 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2414,6 +2414,9 @@ static int vnc_refresh_server_surface(VncDisplay *vd)
* Update server dirty map.
*/
cmp_bytes = 16 * ds_get_bytes_per_pixel(vd-ds);
+if (cmp_bytes vd-ds-surface-linesize) {
+cmp_bytes = vd-ds-surface-linesize;
+}
guest_row = vd-guest.ds-data;
server_row = vd-server-data;
for (y = 0; y vd-guest.ds-height; y++) {
--
1.7.3.4
[Qemu-devel] [PATCH 0/4] VNC fixs collection
Hi Anthony, Here are some vnc related patchs that should be merged. Thanks, Corentin Chary (1): vnc: don't mess up with iohandlers in the vnc thread Michael Tokarev (1): vnc: tight: Fix crash after 2GB of output Stefan Weil (1): vnc: Limit r/w access to size of allocated memory Wen Congyang (1): fix vnc regression ui/vnc-enc-tight.c |5 +++-- ui/vnc-enc-zlib.c |4 ++-- ui/vnc-jobs-async.c | 48 +--- ui/vnc-jobs.h |1 + ui/vnc.c| 23 +-- ui/vnc.h|2 ++ 6 files changed, 58 insertions(+), 25 deletions(-) -- 1.7.3.4
[Qemu-devel] [PATCH 1/4] vnc: tight: Fix crash after 2GB of output
From: Michael Tokarev m...@tls.msk.ru
fix 2Gb integer overflow in in VNC tight and zlib encodings
As found by Roland Dreier rol...@purestorage.com (excellent
catch!), when amount of VNC compressed data produced by zlib
and sent to client exceeds 2Gb, integer overflow occurs because
currently, we calculate amount of data produced at each step by
comparing saved total_out with new total_out, and total_out is
something which grows without bounds. Compare it with previous
avail_out instead of total_out, and leave total_out alone.
The same code is used in vnc-enc-tight.c and vnc-enc-zlib.c,
so fix both cases.
There, there's no actual need to save previous_out value, since
capacity-offset (which is how that value is calculated) stays
the same so it can be recalculated again after call to deflate(),
but whole thing becomes less readable this way.
Reported-by: Roland Dreier rol...@purestorage.com
Signed-off-by: Michael Tokarev m...@tls.msk.ru
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
ui/vnc-enc-tight.c |5 +++--
ui/vnc-enc-zlib.c |4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c
index 2522936..87fdf35 100644
--- a/ui/vnc-enc-tight.c
+++ b/ui/vnc-enc-tight.c
@@ -868,8 +868,8 @@ static int tight_compress_data(VncState *vs, int stream_id,
size_t bytes,
zstream-avail_in = vs-tight.tight.offset;
zstream-next_out = vs-tight.zlib.buffer + vs-tight.zlib.offset;
zstream-avail_out = vs-tight.zlib.capacity - vs-tight.zlib.offset;
+previous_out = zstream-avail_out;
zstream-data_type = Z_BINARY;
-previous_out = zstream-total_out;
/* start encoding */
if (deflate(zstream, Z_SYNC_FLUSH) != Z_OK) {
@@ -878,7 +878,8 @@ static int tight_compress_data(VncState *vs, int stream_id,
size_t bytes,
}
vs-tight.zlib.offset = vs-tight.zlib.capacity - zstream-avail_out;
-bytes = zstream-total_out - previous_out;
+/* ...how much data has actually been produced by deflate() */
+bytes = previous_out - zstream-avail_out;
tight_send_compact_size(vs, bytes);
vnc_write(vs, vs-tight.zlib.buffer, bytes);
diff --git a/ui/vnc-enc-zlib.c b/ui/vnc-enc-zlib.c
index 3c6e6ab..e32e4cd 100644
--- a/ui/vnc-enc-zlib.c
+++ b/ui/vnc-enc-zlib.c
@@ -103,8 +103,8 @@ static int vnc_zlib_stop(VncState *vs)
zstream-avail_in = vs-zlib.zlib.offset;
zstream-next_out = vs-output.buffer + vs-output.offset;
zstream-avail_out = vs-output.capacity - vs-output.offset;
+previous_out = zstream-avail_out;
zstream-data_type = Z_BINARY;
-previous_out = zstream-total_out;
// start encoding
if (deflate(zstream, Z_SYNC_FLUSH) != Z_OK) {
@@ -113,7 +113,7 @@ static int vnc_zlib_stop(VncState *vs)
}
vs-output.offset = vs-output.capacity - zstream-avail_out;
-return zstream-total_out - previous_out;
+return previous_out - zstream-avail_out;
}
int vnc_zlib_send_framebuffer_update(VncState *vs, int x, int y, int w, int h)
--
1.7.3.4
[Qemu-devel] [PATCH 3/4] fix vnc regression
From: Wen Congyang we...@cn.fujitsu.com
This patch fix the following regression:
1. we should use bitmap_set() and bitmap_clear() to replace vnc_set_bits().
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
ui/vnc.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 5d4beaa..90b6384 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1656,17 +1656,21 @@ static void framebuffer_update_request(VncState *vs,
int incremental,
int x_position, int y_position,
int w, int h)
{
+int i;
+const size_t width = ds_get_width(vs-ds) / 16;
+
if (y_position ds_get_height(vs-ds))
y_position = ds_get_height(vs-ds);
if (y_position + h = ds_get_height(vs-ds))
h = ds_get_height(vs-ds) - y_position;
-int i;
vs-need_update = 1;
if (!incremental) {
vs-force_update = 1;
for (i = 0; i h; i++) {
-bitmap_set(vs-dirty[y_position + i], x_position / 16, w / 16);
+bitmap_set(vs-dirty[y_position + i], 0, width);
+bitmap_clear(vs-dirty[y_position + i], width,
+ VNC_DIRTY_WORDS * BITS_PER_LONG - width);
}
}
}
--
1.7.3.4
[Qemu-devel] Re: [PATCH 3/4] fix vnc regression
At 03/21/2011 04:34 PM, Corentin Chary Write:
From: Wen Congyang we...@cn.fujitsu.com
This patch fix the following regression:
1. we should use bitmap_set() and bitmap_clear() to replace vnc_set_bits().
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
Signed-off-by: Corentin Chary corentin.ch...@gmail.com
---
ui/vnc.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 5d4beaa..90b6384 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1656,17 +1656,21 @@ static void framebuffer_update_request(VncState *vs,
int incremental,
int x_position, int y_position,
int w, int h)
{
+int i;
+const size_t width = ds_get_width(vs-ds) / 16;
+
if (y_position ds_get_height(vs-ds))
y_position = ds_get_height(vs-ds);
if (y_position + h = ds_get_height(vs-ds))
h = ds_get_height(vs-ds) - y_position;
-int i;
vs-need_update = 1;
if (!incremental) {
vs-force_update = 1;
for (i = 0; i h; i++) {
-bitmap_set(vs-dirty[y_position + i], x_position / 16, w / 16);
+bitmap_set(vs-dirty[y_position + i], 0, width);
+bitmap_clear(vs-dirty[y_position + i], width,
+ VNC_DIRTY_WORDS * BITS_PER_LONG - width);
Sorry for my mistake. VNC_DIRTY_WORDS is removed, and we should use
VNC_DIRTY_BITS instead of VNC_DIRTY_WORDS * BITS_PER_LONG.
Thanks
Wen Congyang.
Here is the newest patch, and I forgot to resend it:
From 4516c6ce980507d3a13a306a8f08baebb678cce8 Mon Sep 17 00:00:00 2001
From: Wen Congyang we...@cn.fujitsu.com
Date: Mon, 14 Mar 2011 14:51:41 +0800
Subject: [PATCH] fix vnc regression
---
ui/vnc.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 1b68965..c9654d4 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1645,17 +1645,21 @@ static void framebuffer_update_request(VncState *vs,
int incremental,
int x_position, int y_position,
int w, int h)
{
+int i;
+const size_t width = ds_get_width(vs-ds) / 16;
+
if (y_position ds_get_height(vs-ds))
y_position = ds_get_height(vs-ds);
if (y_position + h = ds_get_height(vs-ds))
h = ds_get_height(vs-ds) - y_position;
-int i;
vs-need_update = 1;
if (!incremental) {
vs-force_update = 1;
for (i = 0; i h; i++) {
-bitmap_set(vs-dirty[y_position + i], x_position / 16, w / 16);
+bitmap_set(vs-dirty[y_position + i], 0, width);
+bitmap_clear(vs-dirty[y_position + i], width,
+ VNC_DIRTY_BITS - width);
}
}
}
--
1.7.1
}
}
}
[Qemu-devel] [PATCH] vnc: segmentation fault caused by incorrect 'bytes' count calculated in tight_compress_data()
tight_compress_data() calculates an incorrect 'bytes' count
if 'zstream-total_out' is greater than 0x7fff, because
the type of the variable 'previous_out' is 'int'.
852 int previous_out;
:
872 previous_out = zstream-total_out;
:
881 bytes = zstream-total_out - previous_out;
882
883 tight_send_compact_size(vs, bytes);
884 vnc_write(vs, vs-tight.zlib.buffer, bytes);
The incorrect 'bytes' count causes segmentation faults in
functions called by tight_compress_data(). For example:
(gdb) bt
#0 0x00396ab3d2b6 in __memcpy_ssse3_back () from /lib64/libc.so.6
#1 0x004b3b91 in buffer_append (buffer=0x322d660,
data=value optimized out, len=value optimized out)
at /usr/include/bits/string3.h:52
#2 0x004bbf02 in tight_compress_data (vs=0x32215b0,
stream_id=value optimized out, bytes=0x100024881,
level=value optimized out, strategy=value optimized out)
at ui/vnc-enc-tight.c:884
...
(gdb) x/i $rip
= 0x396ab3d2b6 __memcpy_ssse3_back+6710: movdqu -0x10(%rsi),%xmm0
(gdb) print $rsi+0x10
$1 = 0x103f2ab21
(gdb) x/xb 0x103f2ab21
0x103f2ab21:Cannot access memory at address 0x103f2ab21
The following program illustrates the problem.
$ cat t.c
#include stdio.h
main()
{
int previous_out;
unsigned long total_out = 0x8000;
size_t bytes;
previous_out = total_out;
total_out += 0x1;
bytes = total_out - previous_out;
printf(%lx\n, bytes);
}
$ cc t.c -o t
$ ./t
10001
The patch changes the type of 'previous_out' to 'uLong' which
is the same as the type of 'zstream-total_out'.
Signed-off-by: Ulrich Obergfell uober...@redhat.com
diff -up ./ui/vnc-enc-tight.c.orig0 ./ui/vnc-enc-tight.c
--- ./ui/vnc-enc-tight.c.orig0 2011-03-15 03:53:22.0 +0100
+++ ./ui/vnc-enc-tight.c2011-03-20 12:14:48.013560009 +0100
@@ -849,7 +849,7 @@ static int tight_compress_data(VncState
int level, int strategy)
{
z_streamp zstream = vs-tight.stream[stream_id];
-int previous_out;
+uLong previous_out;
if (bytes VNC_TIGHT_MIN_TO_COMPRESS) {
vnc_write(vs, vs-tight.tight.buffer, vs-tight.tight.offset);
Re: [Qemu-devel] [PATCH] vnc: segmentation fault caused by incorrect 'bytes' count calculated in tight_compress_data()
On Mon, Mar 21, 2011 at 8:48 AM, Ulrich Obergfell uober...@redhat.com wrote:
tight_compress_data() calculates an incorrect 'bytes' count
if 'zstream-total_out' is greater than 0x7fff, because
the type of the variable 'previous_out' is 'int'.
852 int previous_out;
:
872 previous_out = zstream-total_out;
:
881 bytes = zstream-total_out - previous_out;
882
883 tight_send_compact_size(vs, bytes);
884 vnc_write(vs, vs-tight.zlib.buffer, bytes);
The incorrect 'bytes' count causes segmentation faults in
functions called by tight_compress_data(). For example:
(gdb) bt
#0 0x00396ab3d2b6 in __memcpy_ssse3_back () from /lib64/libc.so.6
#1 0x004b3b91 in buffer_append (buffer=0x322d660,
data=value optimized out, len=value optimized out)
at /usr/include/bits/string3.h:52
#2 0x004bbf02 in tight_compress_data (vs=0x32215b0,
stream_id=value optimized out, bytes=0x100024881,
level=value optimized out, strategy=value optimized out)
at ui/vnc-enc-tight.c:884
...
(gdb) x/i $rip
= 0x396ab3d2b6 __memcpy_ssse3_back+6710: movdqu -0x10(%rsi),%xmm0
(gdb) print $rsi+0x10
$1 = 0x103f2ab21
(gdb) x/xb 0x103f2ab21
0x103f2ab21: Cannot access memory at address 0x103f2ab21
The following program illustrates the problem.
$ cat t.c
#include stdio.h
main()
{
int previous_out;
unsigned long total_out = 0x8000;
size_t bytes;
previous_out = total_out;
total_out += 0x1;
bytes = total_out - previous_out;
printf(%lx\n, bytes);
}
$ cc t.c -o t
$ ./t
10001
The patch changes the type of 'previous_out' to 'uLong' which
is the same as the type of 'zstream-total_out'.
Signed-off-by: Ulrich Obergfell uober...@redhat.com
diff -up ./ui/vnc-enc-tight.c.orig0 ./ui/vnc-enc-tight.c
--- ./ui/vnc-enc-tight.c.orig0 2011-03-15 03:53:22.0 +0100
+++ ./ui/vnc-enc-tight.c 2011-03-20 12:14:48.013560009 +0100
@@ -849,7 +849,7 @@ static int tight_compress_data(VncState
int level, int strategy)
{
z_streamp zstream = vs-tight.stream[stream_id];
- int previous_out;
+ uLong previous_out;
if (bytes VNC_TIGHT_MIN_TO_COMPRESS) {
vnc_write(vs, vs-tight.tight.buffer, vs-tight.tight.offset);
Hi Ulrich,
Looks a lot like vnc: tight: Fix crash after 2GB of output, right ?
--
Corentin Chary
http://xf.iksaif.net
Re: [Qemu-devel] Qemu contribution but out the GSoC
Hi Devang, On 21.03.2011, at 09:17, Devang S wrote: Hello, This year i am not eligible to participate in gsoc. But really want to contribute to qemu project. Do i have any chance? Do you mentor projects outside gsoc? Can I somehow contribute to qemu project, out of the gsoc? Can I get mentor outside of the gsoc, like other organizations provide? This mostly depends on two factors: 1) Would you have been accepted as student for gsoc? There's a certain skill level required to participate. If for example I'd have to spend 3 weeks full-time explaining things before you even could get started with real work, unfortunately the trade-off is too bad. 2) Is there anyone willing to mentor the project you're trying to do? Qemu is a very broad project. If you happen to choose a part of it that nobody understands, you might end up not getting anyone willing to mentor you :). Also keep in mind that Qemu is an open source project, so we all mentor each other all the time. That's what this whole patch review thing is about :). Alex
Re: [Qemu-devel] Qemu contribution but out the GSoC
On Mon, Mar 21, 2011 at 9:08 AM, Alexander Graf ag...@suse.de wrote: Hi Devang, On 21.03.2011, at 09:17, Devang S wrote: Hello, This year i am not eligible to participate in gsoc. But really want to contribute to qemu project. Do i have any chance? Do you mentor projects outside gsoc? Can I somehow contribute to qemu project, out of the gsoc? Can I get mentor outside of the gsoc, like other organizations provide? This mostly depends on two factors: 1) Would you have been accepted as student for gsoc? There's a certain skill level required to participate. If for example I'd have to spend 3 weeks full-time explaining things before you even could get started with real work, unfortunately the trade-off is too bad. 2) Is there anyone willing to mentor the project you're trying to do? Qemu is a very broad project. If you happen to choose a part of it that nobody understands, you might end up not getting anyone willing to mentor you :). Also keep in mind that Qemu is an open source project, so we all mentor each other all the time. That's what this whole patch review thing is about :). Alex Hi, Also, I'd suggest you to start here: http://wiki.qemu.org/Contribute/StartHere . You can also pick a GSOC 2010/2011 project, and start working on it outside of GSOC context if you want. And keep in mind that if you want to write code send patchs for QEMU, nobody can stop you :). -- Corentin Chary http://xf.iksaif.net
Re: [Qemu-devel] Qemu contribution but out the GSoC
On Mon, Mar 21, 2011 at 9:18 AM, Corentin Chary corentin.ch...@gmail.com wrote: On Mon, Mar 21, 2011 at 9:08 AM, Alexander Graf ag...@suse.de wrote: Hi Devang, On 21.03.2011, at 09:17, Devang S wrote: Hello, This year i am not eligible to participate in gsoc. But really want to contribute to qemu project. Do i have any chance? Do you mentor projects outside gsoc? Can I somehow contribute to qemu project, out of the gsoc? Can I get mentor outside of the gsoc, like other organizations provide? This mostly depends on two factors: 1) Would you have been accepted as student for gsoc? There's a certain skill level required to participate. If for example I'd have to spend 3 weeks full-time explaining things before you even could get started with real work, unfortunately the trade-off is too bad. 2) Is there anyone willing to mentor the project you're trying to do? Qemu is a very broad project. If you happen to choose a part of it that nobody understands, you might end up not getting anyone willing to mentor you :). Also keep in mind that Qemu is an open source project, so we all mentor each other all the time. That's what this whole patch review thing is about :). Alex Hi, Also, I'd suggest you to start here: http://wiki.qemu.org/Contribute/StartHere . You can also pick a GSOC 2010/2011 project, and start working on it outside of GSOC context if you want. And keep in mind that if you want to write code send patchs for QEMU, nobody can stop you :). Corentin is right - just work on something that interests you and send patches. You could start by tackling open bugs at https://bugs.launchpad.net/qemu. People have to pull their own weight, there is not a lot of internals documentation, you need to learn by reading the code. Official Summer of Code students will find the same thing is true. Stefan
[Qemu-devel] [PATCH] vmmouse: Fix initialization
Latest refactorings left vmmouse nonfunctional behind. Fix it by adding
the required device initialization.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/pc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 4d67d9f..6939c04 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -1142,6 +1142,7 @@ void pc_basic_device_init(qemu_irq *isa_irq,
vmmouse = isa_try_create(vmmouse);
if (vmmouse) {
qdev_prop_set_ptr(vmmouse-qdev, ps2_mouse, i8042);
+qdev_init_nofail(vmmouse-qdev);
}
port92 = isa_create_simple(port92);
port92_init(port92, a20_line[1]);
--
1.7.1
[Qemu-devel] [PATCH] vmmouse: Register vmstate via qdev
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/vmmouse.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/vmmouse.c b/hw/vmmouse.c
index ab8dbd6..1113f33 100644
--- a/hw/vmmouse.c
+++ b/hw/vmmouse.c
@@ -265,7 +265,6 @@ static int vmmouse_initfn(ISADevice *dev)
vmport_register(VMMOUSE_STATUS, vmmouse_ioport_read, s);
vmport_register(VMMOUSE_COMMAND, vmmouse_ioport_read, s);
vmport_register(VMMOUSE_DATA, vmmouse_ioport_read, s);
-vmstate_register(NULL, 0, vmstate_vmmouse, s);
return 0;
}
@@ -274,6 +273,7 @@ static ISADeviceInfo vmmouse_info = {
.init = vmmouse_initfn,
.qdev.name = vmmouse,
.qdev.size = sizeof(VMMouseState),
+.qdev.vmsd = vmstate_vmmouse,
.qdev.no_user = 1,
.qdev.reset= vmmouse_reset,
.qdev.props = (Property[]) {
--
1.7.1
[Qemu-devel] [PATCH] vmmouse: Fix typo preventing x86-64 build
Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- default-configs/x86_64-softmmu.mak |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/default-configs/x86_64-softmmu.mak b/default-configs/x86_64-softmmu.mak index 59b7893..8895028 100644 --- a/default-configs/x86_64-softmmu.mak +++ b/default-configs/x86_64-softmmu.mak @@ -4,7 +4,7 @@ include pci.mak CONFIG_VGA_PCI=y CONFIG_VGA_ISA=y CONFIG_VMWARE_VGA=y -CONFIG_VMMMOUSE=y +CONFIG_VMMOUSE=y CONFIG_SERIAL=y CONFIG_PARALLEL=y CONFIG_I8254=y -- 1.7.1
[Qemu-devel] [PATCH] enable kvm for ppc(32) on ppc64
ppc64 is backward compatible, likewise. Signed-off-by: René Rebe r...@exactcode.de --- qemu-0.14.0/configure 2011-02-16 14:44:04.0 + +++ qemu-0.14.0-fixed/configure 2011-03-18 16:46:14.0 + @@ -3038,6 +3038,8 @@ \( $target_arch2 = $cpu -o \ \( $target_arch2 = ppcemb -a $cpu = ppc \) -o \ \( $target_arch2 = ppc64 -a $cpu = ppc \) -o \ + \( $target_arch2 = ppc-a $cpu = ppc64 \) -o \ + \( $target_arch2 = ppcemb -a $cpu = ppc64 \) -o \ \( $target_arch2 = x86_64 -a $cpu = i386 \) -o \ \( $target_arch2 = i386 -a $cpu = x86_64 \) \) ; then echo CONFIG_KVM=y $config_target_mak -- René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin DE Legal: Amtsgericht Charlottenburg HRB 105123B, Tax-ID#: DE251602478 Managing Directors: Susanne Klaus, René Rebe http://exactcode.com | http://t2-project.org | http://rene.rebe.de
Re: [Qemu-devel] [PATCH] vnc: segmentation fault caused by incorrect 'bytes' count calculated in tight_compress_data()
Hi Ulrich, Looks a lot like vnc: tight: Fix crash after 2GB of output, right ? -- Corentin Chary http://xf.iksaif.net Hi Corentin, yes, this appears to be the same issue as: http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02044.html You posted your patch only a few minutes before I posted mine. Hence, I wasn't aware that a fix was already available. Regards, Uli
[Qemu-devel] [PATCH] fix applesmc REV key
Fix applesmc REV key string literal hex encoding. Signed-off-by: René Rebe r...@exactcode.de --- qemu-kvm-0.14.0/hw/applesmc.c.vanilla 2011-02-22 18:55:03.73225 + +++ qemu-kvm-0.14.0/hw/applesmc.c 2011-02-22 18:56:08.89225 + @@ -188,7 +188,7 @@ QLIST_REMOVE(d, node); } -applesmc_add_key(s, REV , 6, \0x01\0x13\0x0f\0x00\0x00\0x03); +applesmc_add_key(s, REV , 6, \x01\x13\x0f\x00\x00\x03); applesmc_add_key(s, OSK0, 32, s-osk); applesmc_add_key(s, OSK1, 32, s-osk + 32); applesmc_add_key(s, NATJ, 1, \0); -- René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin DE Legal: Amtsgericht Charlottenburg HRB 105123B, Tax-ID#: DE251602478 Managing Directors: Susanne Klaus, René Rebe http://exactcode.com | http://t2-project.org | http://rene.rebe.de
[Qemu-devel] Re: [PATCH] enable kvm for ppc(32) on ppc64
On 21.03.2011, at 11:18, René Rebe wrote: ppc64 is backward compatible, likewise. Signed-off-by: René Rebe r...@exactcode.de Acked-by: Alexander Graf ag...@suse.de --- qemu-0.14.0/configure 2011-02-16 14:44:04.0 + +++ qemu-0.14.0-fixed/configure 2011-03-18 16:46:14.0 + @@ -3038,6 +3038,8 @@ \( $target_arch2 = $cpu -o \ \( $target_arch2 = ppcemb -a $cpu = ppc \) -o \ \( $target_arch2 = ppc64 -a $cpu = ppc \) -o \ + \( $target_arch2 = ppc-a $cpu = ppc64 \) -o \ + \( $target_arch2 = ppcemb -a $cpu = ppc64 \) -o \ \( $target_arch2 = x86_64 -a $cpu = i386 \) -o \ \( $target_arch2 = i386 -a $cpu = x86_64 \) \) ; then echo CONFIG_KVM=y $config_target_mak -- René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin DE Legal: Amtsgericht Charlottenburg HRB 105123B, Tax-ID#: DE251602478 Managing Directors: Susanne Klaus, René Rebe http://exactcode.com | http://t2-project.org | http://rene.rebe.de
[Qemu-devel] Re: [PATCH] fix applesmc REV key
On 21.03.2011, at 11:33, René Rebe wrote: Fix applesmc REV key string literal hex encoding. Signed-off-by: René Rebe r...@exactcode.de Acked-by: Alexander Graf ag...@suse.de Alex --- qemu-kvm-0.14.0/hw/applesmc.c.vanilla 2011-02-22 18:55:03.73225 + +++ qemu-kvm-0.14.0/hw/applesmc.c 2011-02-22 18:56:08.89225 + @@ -188,7 +188,7 @@ QLIST_REMOVE(d, node); } -applesmc_add_key(s, REV , 6, \0x01\0x13\0x0f\0x00\0x00\0x03); +applesmc_add_key(s, REV , 6, \x01\x13\x0f\x00\x00\x03); applesmc_add_key(s, OSK0, 32, s-osk); applesmc_add_key(s, OSK1, 32, s-osk + 32); applesmc_add_key(s, NATJ, 1, \0); -- René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin DE Legal: Amtsgericht Charlottenburg HRB 105123B, Tax-ID#: DE251602478 Managing Directors: Susanne Klaus, René Rebe http://exactcode.com | http://t2-project.org | http://rene.rebe.de
[Qemu-devel] Query: gdbstub software breakpoint removal
Hi All, I can see that the software breakpoint queue is cleared in kvm_remove_breakpoint() in kvm-all.c. I.e QTAILQ_REMOVE(current_env-kvm_state-kvm_sw_breakpoints, bp, entry); is called when the breakpoint is cleared. While the queue is not cleared on kvm_remove_all_breakpoints(); Is there any specific reason for that? Thanks -Bharat
[Qemu-devel] Re: Query: gdbstub software breakpoint removal
On 2011-03-21 12:01, Bhushan Bharat-R65777 wrote: Hi All, I can see that the software breakpoint queue is cleared in kvm_remove_breakpoint() in kvm-all.c. I.e QTAILQ_REMOVE(current_env-kvm_state-kvm_sw_breakpoints, bp, entry); is called when the breakpoint is cleared. While the queue is not cleared on kvm_remove_all_breakpoints(); Is there any specific reason for that? Hmm, no particular reason that I recall. This rather looks like a very old leak. Patch welcome. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v21 00/11] usb-ccid
On Thu, Mar 17, 2011 at 2:49 PM, Alon Levy al...@redhat.com wrote: This patchset adds three new devices, usb-ccid, ccid-card-passthru and ccid-card-emulated, providing a CCID bus, a simple passthru protocol implementing card requiring a client, and a standalone emulated card. It also introduces a new directory libcaccard with CAC card emulation, CAC is a type of ISO 7816 smart card. I just build tested this patchset and got: $ make distclean $ ./configure --prefix=/usr --target-list=x86_64-softmmu --enable-io-thread --disable-strip $ make CCx86_64-softmmu/../libcacard/vcard_emul_nss.o ../libcacard/vcard_emul_nss.c:23:21: fatal error: pk11pub.h: No such file or directory compilation terminated. make[1]: *** [../libcacard/vcard_emul_nss.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 It seems the smartcard ./configure check needs to be stricter in checking for the presence of build dependencies. Stefan
[Qemu-devel] Re: [PATCH v3 3/3] piix_pci: optimize set irq path
On Sat, Mar 19, 2011 at 10:24:52PM +0900, Isaku Yamahata wrote:
optimize irq routing in piix_pic.c which has been a TODO.
So far piix3 tracks each pirq level and checks whether a given pic pins is
asserted by seeing if each pirq is mapped into the pic pin.
This is independent on irq routing, but data path is on slow path.
Given that irq routing is rarely changed and asserting pic pins is on
data path, the path that asserts pic pins should be optimized and
chainging irq routing should be on slow path.
The new behavior with this patch series is to use bitmap which is addressed
by pirq and pic pins with a given irq routing.
When pirq is asserted, the bitmap is set and see if the pic pins is
asserted by checking the bitmaps.
When irq routing is changed, rebuild the bitmap and re-assert pic pins.
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
Changes v1 - v2:
- some minor clean ups
- commit log message
---
hw/piix_pci.c | 94
+
1 files changed, 81 insertions(+), 13 deletions(-)
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index e88df43..f07e19d 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -37,8 +37,27 @@
typedef PCIHostState I440FXState;
+#define PIIX_NUM_PIC_IRQS 16 /* i8259 * 2 */
+#define PIIX_NUM_PIRQS 4ULL/* PIRQ[A-D] */
+#define PIIX_PIRQC 0x60
+
typedef struct PIIX3State {
PCIDevice dev;
+
+/*
+ * bitmap to track pic levels.
+ * The pic level is the logical OR of all the PCI irqs mapped to it
+ * So one PIC level is tracked by PIIX_NUM_PIRQS bits.
+ *
+ * PIRQ is mapped to PIC pins, we track it by
+ * PIIX_NUM_PIRQS * PIIX_NUM_PIC_IRQS = 64 bits with
+ * pic_irq * PIIX_NUM_PIRQS + pirq
+ */
+#if PIIX_NUM_PIC_IRQS * PIIX_NUM_PIRQS 64
+#error unable to encode pic state in 64bit in pic_levels.
+#endif
+uint64_t pic_levels;
+
qemu_irq *pic;
/* This member isn't used. Just for save/load compatibility */
@@ -254,25 +273,63 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int
*piix3_devfn, qemu_irq *
}
/* PIIX3 PCI to ISA bridge */
+static void piix3_set_irq_pic(PIIX3State *piix3, int pic_irq)
+{
+qemu_set_irq(piix3-pic[pic_irq],
+ !!(piix3-pic_levels
+((PIIX_NUM_PIRQS - 1) (pic_irq * PIIX_NUM_PIRQS;
+}
+
+static void piix3_set_irq_level(PIIX3State *piix3, int irq_num, int level,
+bool propagate)
+{
+int pic_irq;
+uint64_t mask;
+
+pic_irq = piix3-dev.config[PIIX_PIRQC + irq_num];
+if (pic_irq = PIIX_NUM_PIC_IRQS) {
+return;
+}
+
+mask = 1ULL ((pic_irq * PIIX_NUM_PIRQS) + irq_num);
+piix3-pic_levels = ~mask;
+piix3-pic_levels |= mask * !!level;
+
+if (propagate) {
+piix3_set_irq_pic(piix3, pic_irq);
+}
+}
static void piix3_set_irq(void *opaque, int irq_num, int level)
{
-int i, pic_irq, pic_level;
PIIX3State *piix3 = opaque;
+piix3_set_irq_level(piix3, irq_num, level, true);
+}
-/* now we change the pic irq level according to the piix irq mappings */
-/* XXX: optimize */
-pic_irq = piix3-dev.config[0x60 + irq_num];
-if (pic_irq 16) {
-/* The pic level is the logical OR of all the PCI irqs mapped
- to it */
-pic_level = 0;
-for (i = 0; i 4; i++) {
-if (pic_irq == piix3-dev.config[0x60 + i]) {
-pic_level |= pci_bus_get_irq_level(piix3-dev.bus, i);
-}
+/* irq routing is changed. so rebuild bitmap */
+static void piix3_update_irq_levels(PIIX3State *piix3)
+{
+int pirq;
+
+piix3-pic_levels = 0;
+for (pirq = 0; pirq PIIX_NUM_PIRQS; pirq++) {
+piix3_set_irq_level(piix3, pirq,
+pci_bus_get_irq_level(piix3-dev.bus, pirq),
+false);
+}
+}
+
+static void piix3_write_config(PCIDevice *dev,
+ uint32_t address, uint32_t val, int len)
+{
+pci_default_write_config(dev, address, val, len);
+if (ranges_overlap(address, len, PIIX_PIRQC, 4)) {
+PIIX3State *piix3 = DO_UPCAST(PIIX3State, dev, dev);
+int pic_irq;
+piix3_update_irq_levels(piix3);
+for (pic_irq = 0; pic_irq PIIX_NUM_PIC_IRQS; pic_irq++) {
+piix3_set_irq_pic(piix3, pic_irq);
}
We wouldn't need this loop if piix3_update_irq_levels
called piix3_set_irq_level with propagate enabled.
-qemu_set_irq(piix3-pic[pic_irq], pic_level);
}
}
@@ -312,6 +369,15 @@ static void piix3_reset(void *opaque)
pci_conf[0xab] = 0x00;
pci_conf[0xac] = 0x00;
pci_conf[0xae] = 0x00;
+
+d-pic_levels = 0;
+}
+
+static int piix3_post_load(void *opaque, int version_id)
+{
+PIIX3State
[Qemu-devel] vnc: severe memory leak caused by broken palette_destroy() function
The following commit breaks the code of the function palette_destroy().
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=e31e3694afef58ba191cbcc6875ec243e5971268
The broken code causes a severe memory leak of 'VncPalette' structures
because it never frees anything:
70 void palette_destroy(VncPalette *palette)
71 {
72 if (palette == NULL) {
73 qemu_free(palette);
74 }
75 }
Calling qemu_free() unconditionally could be considered. However,
the original code (prior to the aforementioned commit) returned
immediately if 'palette' was NULL. In order to be closer to the
original code, the proposed patch corrects the 'if' statement.
Signed-off-by: Ulrich Obergfell uober...@redhat.com
diff -up ./ui/vnc-palette.c.orig0 ./ui/vnc-palette.c
--- ./ui/vnc-palette.c.orig02011-03-15 03:53:22.0 +0100
+++ ./ui/vnc-palette.c 2011-03-20 11:52:57.257560295 +0100
@@ -69,7 +69,7 @@ void palette_init(VncPalette *palette, s
void palette_destroy(VncPalette *palette)
{
-if (palette == NULL) {
+if (palette) {
qemu_free(palette);
}
}
Re: [Qemu-devel] [PATCH v21 00/11] usb-ccid
On Mon, Mar 21, 2011 at 11:33:57AM +, Stefan Hajnoczi wrote: On Thu, Mar 17, 2011 at 2:49 PM, Alon Levy al...@redhat.com wrote: This patchset adds three new devices, usb-ccid, ccid-card-passthru and ccid-card-emulated, providing a CCID bus, a simple passthru protocol implementing card requiring a client, and a standalone emulated card. It also introduces a new directory libcaccard with CAC card emulation, CAC is a type of ISO 7816 smart card. I just build tested this patchset and got: $ make distclean $ ./configure --prefix=/usr --target-list=x86_64-softmmu --enable-io-thread --disable-strip $ make CCx86_64-softmmu/../libcacard/vcard_emul_nss.o ../libcacard/vcard_emul_nss.c:23:21: fatal error: pk11pub.h: No such file or directory compilation terminated. make[1]: *** [../libcacard/vcard_emul_nss.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 It seems the smartcard ./configure check needs to be stricter in checking for the presence of build dependencies. Stefan Can you give me the output of configure? specifically nss used yes? or nss used no?
[Qemu-devel] Trip Report -- 1st QEMU Users Forum, Grenoble, 18 March 2011
I went to the first QEMU Users Forum in Grenoble last week; this is my impressions and summary of what happened. I posted this to linaro-toolchain and it was suggested that qemu-devel folks might be interested in it too. Sorry if it's a bit TLDR... == Summary and general observations == This was a day long set of talks tacked onto the end of the DATE conference. There were about 40 attendees; the focus of the talks was mostly industrial and academic research QEMU users/hackers (a set of people who use and modify QEMU but who aren't very well represented on the qemu-devel list). A lot of the talks related to SystemC; at the moment people are rolling their own SystemC-QEMU bridges. In addition to the usual problems when you try to put two simulation engines together (each of which thinks it should be in control of the world) QEMU doesn't make this easy because it is not very modular and makes the assumption that only one QEMU exists in a process (lots of global variables, no locking, etc). There was a general perception from attendees that QEMU development community is biased towards KVM rather than TCG. I tend to agree with this, but think this is simply because (a) that's where the bulk of the contributors are and (b) people doing TCG related work don't always appear on the mailing list. (The quick throwaway prototype approach often used for research doesn't really mesh well with upstream's desire for solid long-term maintainable code, I guess.) QEMU could certainly be made more convenient for this group of users: greater modularisation and provision of just the instruction set simulator as a pluggable library, for instance. Also the work by STMicroelectronics on tracing/instrumentation plugins looks like it should be useful to reduce the need to hack extra instrumentation directly into QEMU's frontends. People generally seemed to think the forum was useful, but it hasn't been decided yet whether to repeat it next year, or perhaps to have some sort of joint event with the open-source qemu community. More detailed notes on each of the talks are below; the proceedings/slides should also appear at http://adt.cs.upb.de/quf within a few weeks. Of particular Linaro/ARM interest are: * the STMicroelectronics plugin framework so your DLL can get callbacks on interesting events and/or insert tracing or instrumentation into generated code * Nokia's work on getting useful timing/power type estimates out of QEMU by measuring key events (insn exec, cache miss, TLB miss, etc) and calibrating against real hardware to see how to weight these * a talk on parallelising QEMU, ie multicore on multicore * speeding up Neon by adding SIMD IR ops and translating to SSE The forum started with a brief introduction by the organiser, followed by an informal QA session with Nathan Froyd from CodeSourcery (...since his laptop with his presentation slides had died on the journey over from the US...) == Talk 1: QEMU and SystemC == M. Monton from GreenSocs presented a couple of approaches to using QEMU with SystemC. QEMU-SC is for systems which are mostly QEMU based with one or two SystemC devices -- QEMU is the master. Speed penalty is 8-14% over implementing the device natively. QBox makes the SystemC simulation the master, and QEMU is implemented as a TLM2 Initiator; this works for systems which are almost all SystemC and which you just want to add a QEMU core to. Speed penalty 100% (!) although they suspect this is an artifact of the current implementation and could be reduced to more like 25-30%. They'd like to see a unified effort to do SystemC and QEMU integration (you'll note that there are several talks here where the presenters had rolled their own integration). Source available from www.greensocs.com. == Talk 2: Combined Use of Dynamic Binary Translation and SystemC for Fast and Accurate MPSoc Simulation == Description of a system where QEMU is used as the core model in a SystemC simulation of a multiprocessor ARM system. The SystemC side includes models of caches, write buffers and so on; this looked like quite a low level detailed (high overhead) simulation. They simulate multiple clusters of multiple cores, which is tricky with QEMU because it has a design assumption of only one QEMU per process address space (lots of global variables, no locking, etc); they handle this by saving and restoring globals at SystemC synchronisation points, which sounded rather hacky to me. They get timing information out of their model by annotating the TCG intermediate representation ops with new ops indicating number of cycles used, whether to check for Icache/Dcache hit/miss, and so on. Clearly they've put a lot of work into this. They'd like a standalone, reentrant ISS, basically so it's easier to plug into other frameworks like SystemC. == Talk 3: QEMU/SystemC Cosimulation at Different Abstraction Levels == This talk was about modelling an RTOS in SystemC; I have to say I didn't really understand the
[Qemu-devel] Re: [PATCH v3 3/3] piix_pci: optimize set irq path
On Mon, Mar 21, 2011 at 01:37:07PM +0200, Michael S. Tsirkin wrote:
+static int piix3_post_load(void *opaque, int version_id)
+{
+PIIX3State *piix3 = opaque;
+piix3_update_irq_levels(piix3);
Couldn't figure out why would we not want to
propagate the interrupts here.
Could you explain please?
What happens if we do propagate them?
Nothing bad, right?
I wanted to be just conservative.
If you are brave enough to change the behavior, I'm fine with propagating
interrupts.
If we propagate the interrupts, guest OS may see interrupts
unnecessarily/spuriously injected after load.
Probably such interrupts doesn't harm OSes, so there is nothing
bad in theory as you said.
On the other hand, I hesitated to change the existing behavior because
it would be very difficult to debug it and to test many OSes.
--
yamahata
Re: [Qemu-devel] [PATCH] block: Flush image after open
On 03/09/2011 07:38 PM, Anthony Liguori wrote: On 03/09/2011 11:27 AM, Christoph Hellwig wrote: On Wed, Mar 09, 2011 at 05:15:53PM +0100, Kevin Wolf wrote: Quoting the bug report: qemu ensures that guest writes and qemu metadata writes hit the disk when necessary to prevent data corruption. However, if an image was in host pagecache prior to starting qemu, for example after running qemu-img convert, then nothing prevents writes from reaching the disk out of order, potentially causing corruption. I'm not entirely sure if there is a realistic case where we would get corruption, but it's probably a case of better safe than sorry. Except for SCSI with ordered tags (which we don't support) there are not ordering guarantees in the storage protocols, and as such the above explanation doesn't make any sense at all. Even if there was, a guest shouldn't be relying on the ordering of a write that comes from a non-guest. I don't understand the failure scenario here. $ cp x.img y.img $ qemu -drive file=y.img,cache=writeback read something from disk, send it over the network no guest flushes host crash The guest may expect that any or none of its writes hit the disk, but that anything that it read from the disk, stays there. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v21 00/11] usb-ccid
On Mon, Mar 21, 2011 at 11:33:57AM +, Stefan Hajnoczi wrote: On Thu, Mar 17, 2011 at 2:49 PM, Alon Levy al...@redhat.com wrote: This patchset adds three new devices, usb-ccid, ccid-card-passthru and ccid-card-emulated, providing a CCID bus, a simple passthru protocol implementing card requiring a client, and a standalone emulated card. It also introduces a new directory libcaccard with CAC card emulation, CAC is a type of ISO 7816 smart card. I just build tested this patchset and got: $ make distclean $ ./configure --prefix=/usr --target-list=x86_64-softmmu --enable-io-thread --disable-strip $ make CCx86_64-softmmu/../libcacard/vcard_emul_nss.o ../libcacard/vcard_emul_nss.c:23:21: fatal error: pk11pub.h: No such file or directory compilation terminated. make[1]: *** [../libcacard/vcard_emul_nss.o] Error 1 make: *** [subdir-x86_64-softmmu] Error 2 It seems the smartcard ./configure check needs to be stricter in checking for the presence of build dependencies. Stefan Thanks, this should fix it: diff --git a/Makefile.target b/Makefile.target index baa5c3f..fef56b4 100644 --- a/Makefile.target +++ b/Makefile.target @@ -350,7 +350,7 @@ obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) endif # CONFIG_SOFTMMU -obj-y += $(addprefix ../libcacard/, $(libcacard-$(CONFIG_SMARTCARD))) +obj-y += $(addprefix ../libcacard/, $(libcacard-$(CONFIG_SMARTCARD_NSS))) obj-y += $(addprefix ../, $(trace-obj-y)) obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o
[Qemu-devel] Re: [PATCH v3 3/3] piix_pci: optimize set irq path
On Mon, Mar 21, 2011 at 01:37:07PM +0200, Michael S. Tsirkin wrote:
+/* irq routing is changed. so rebuild bitmap */
+static void piix3_update_irq_levels(PIIX3State *piix3)
+{
+int pirq;
+
+piix3-pic_levels = 0;
+for (pirq = 0; pirq PIIX_NUM_PIRQS; pirq++) {
+piix3_set_irq_level(piix3, pirq,
+pci_bus_get_irq_level(piix3-dev.bus, pirq),
+false);
+}
+}
+
+static void piix3_write_config(PCIDevice *dev,
+ uint32_t address, uint32_t val, int len)
+{
+pci_default_write_config(dev, address, val, len);
+if (ranges_overlap(address, len, PIIX_PIRQC, 4)) {
+PIIX3State *piix3 = DO_UPCAST(PIIX3State, dev, dev);
+int pic_irq;
+piix3_update_irq_levels(piix3);
+for (pic_irq = 0; pic_irq PIIX_NUM_PIC_IRQS; pic_irq++) {
+piix3_set_irq_pic(piix3, pic_irq);
}
We wouldn't need this loop if piix3_update_irq_levels
called piix3_set_irq_level with propagate enabled.
No. piix3_update_irq_levels loops over PIRQs(= 4).
But we need to loop over all pic PINs(= 16) to raise/lower irqs.
--
yamahata
Re: [Qemu-devel] [PATCH v21 01/11] trace: move trace objects from Makefile to Makefile.objs
On Thu, Mar 17, 2011 at 5:23 PM, Alon Levy al...@redhat.com wrote: On Thu, Mar 17, 2011 at 04:45:15PM +, Stefan Hajnoczi wrote: On Thu, Mar 17, 2011 at 3:00 PM, Alon Levy al...@redhat.com wrote: On Thu, Mar 17, 2011 at 04:49:26PM +0200, Alon Levy wrote: --- Makefile | 32 Makefile.objs | 32 2 files changed, 32 insertions(+), 32 deletions(-) The commit message can be a little more verbose :( It will be: allow libcacard (later commit) to make use of the rules for building trace objects, to build libcacard/vscclient (and later still libcacard/libcacard.so). I will test this patch and get back to you within the next two or three days. Thanks, much appreciated. $ make distclean $ ./configure --prefix=/usr --target-list=x86_64-softmmu --enable-io-thread --disable-strip --enable-trace-backend=simple $ make [...] LINK libcacard/vscclient simpletrace.o: In function `get_clock': /home/stefanha/qemu/qemu-timer.h:92: undefined reference to `use_rt_clock' collect2: ld returned 1 exit status make[1]: *** [vscclient] Error 1 make: *** [subdir-libcacard] Error 2 Stefan
[Qemu-devel] Re: [PATCH v3 3/3] piix_pci: optimize set irq path
On Mon, Mar 21, 2011 at 09:10:32PM +0900, Isaku Yamahata wrote:
On Mon, Mar 21, 2011 at 01:37:07PM +0200, Michael S. Tsirkin wrote:
+static int piix3_post_load(void *opaque, int version_id)
+{
+PIIX3State *piix3 = opaque;
+piix3_update_irq_levels(piix3);
Couldn't figure out why would we not want to
propagate the interrupts here.
Could you explain please?
What happens if we do propagate them?
Nothing bad, right?
I wanted to be just conservative.
If you are brave enough to change the behavior, I'm fine with propagating
interrupts.
If we propagate the interrupts, guest OS may see interrupts
unnecessarily/spuriously injected after load.
Probably such interrupts doesn't harm OSes, so there is nothing
bad in theory as you said.
On the other hand, I hesitated to change the existing behavior because
it would be very difficult to debug it and to test many OSes.
I expect it won't change the behaviour because the interrupts
are level: at the moment e.g. pci devices already reassert
interrupts on load.
But I agree it better be a separate patch, and needs a lot of testing.
--
yamahata
[Qemu-devel] Re: [PATCH master, stable] virtio-pci: fix bus master work around on load
On 19.03.2011, at 23:30, Michael S. Tsirkin wrote: Commit c81131db15dd1844d0db1d51f3cd7a105cfd2cf3 detects old guests by comparing virtio and PCI status. It attempts to do this on load, as well, but load_config callback in a binding is invoked too early and so the virtio status isn't set yet. We could add yet another callback to the binding, to invoke after load, but it seems easier to reuse the existing vmstate callback. Signed-off-by: Michael S. Tsirkin m...@redhat.com Cc: Alexander Graf ag...@suse.de Looks good to me. I assume you have tested the code by running an old guest? Alex
Re: [Qemu-devel] vnc: severe memory leak caused by broken palette_destroy() function
On Mon, Mar 21, 2011 at 11:52 AM, Ulrich Obergfell uober...@redhat.com wrote:
The following commit breaks the code of the function palette_destroy().
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commit;h=e31e3694afef58ba191cbcc6875ec243e5971268
The broken code causes a severe memory leak of 'VncPalette' structures
because it never frees anything:
70 void palette_destroy(VncPalette *palette)
71 {
72 if (palette == NULL) {
73 qemu_free(palette);
74 }
75 }
Calling qemu_free() unconditionally could be considered. However,
the original code (prior to the aforementioned commit) returned
immediately if 'palette' was NULL. In order to be closer to the
original code, the proposed patch corrects the 'if' statement.
Signed-off-by: Ulrich Obergfell uober...@redhat.com
diff -up ./ui/vnc-palette.c.orig0 ./ui/vnc-palette.c
--- ./ui/vnc-palette.c.orig0 2011-03-15 03:53:22.0 +0100
+++ ./ui/vnc-palette.c 2011-03-20 11:52:57.257560295 +0100
@@ -69,7 +69,7 @@ void palette_init(VncPalette *palette, s
void palette_destroy(VncPalette *palette)
{
- if (palette == NULL) {
+ if (palette) {
qemu_free(palette);
}
}
Please drop the if (palette) check entirely because qemu_free(NULL) is
a nop. There's no need to perform this check at all.
Stefan
[Qemu-devel] Re: [PATCH v3 3/3] piix_pci: optimize set irq path
On Mon, Mar 21, 2011 at 02:31:11PM +0200, Michael S. Tsirkin wrote:
On Mon, Mar 21, 2011 at 09:10:32PM +0900, Isaku Yamahata wrote:
On Mon, Mar 21, 2011 at 01:37:07PM +0200, Michael S. Tsirkin wrote:
+static int piix3_post_load(void *opaque, int version_id)
+{
+PIIX3State *piix3 = opaque;
+piix3_update_irq_levels(piix3);
Couldn't figure out why would we not want to
propagate the interrupts here.
Could you explain please?
What happens if we do propagate them?
Nothing bad, right?
I wanted to be just conservative.
If you are brave enough to change the behavior, I'm fine with propagating
interrupts.
If we propagate the interrupts, guest OS may see interrupts
unnecessarily/spuriously injected after load.
Probably such interrupts doesn't harm OSes, so there is nothing
bad in theory as you said.
On the other hand, I hesitated to change the existing behavior because
it would be very difficult to debug it and to test many OSes.
I expect it won't change the behaviour because the interrupts
are level: at the moment e.g. pci devices already reassert
interrupts on load.
But I agree it better be a separate patch, and needs a lot of testing.
Like this?
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index f07e19d..8052c1e 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -280,8 +280,7 @@ static void piix3_set_irq_pic(PIIX3State *piix3, int
pic_irq)
((PIIX_NUM_PIRQS - 1) (pic_irq * PIIX_NUM_PIRQS;
}
-static void piix3_set_irq_level(PIIX3State *piix3, int irq_num, int level,
-bool propagate)
+static void piix3_set_irq_level(PIIX3State *piix3, int irq_num, int level)
{
int pic_irq;
uint64_t mask;
@@ -295,15 +294,13 @@ static void piix3_set_irq_level(PIIX3State *piix3, int
irq_num, int level,
piix3-pic_levels = ~mask;
piix3-pic_levels |= mask * !!level;
-if (propagate) {
-piix3_set_irq_pic(piix3, pic_irq);
-}
+piix3_set_irq_pic(piix3, pic_irq);
}
static void piix3_set_irq(void *opaque, int irq_num, int level)
{
PIIX3State *piix3 = opaque;
-piix3_set_irq_level(piix3, irq_num, level, true);
+piix3_set_irq_level(piix3, irq_num, level);
}
/* irq routing is changed. so rebuild bitmap */
@@ -314,8 +311,7 @@ static void piix3_update_irq_levels(PIIX3State *piix3)
piix3-pic_levels = 0;
for (pirq = 0; pirq PIIX_NUM_PIRQS; pirq++) {
piix3_set_irq_level(piix3, pirq,
-pci_bus_get_irq_level(piix3-dev.bus, pirq),
-false);
+pci_bus_get_irq_level(piix3-dev.bus, pirq));
}
}
--
yamahata
Re: [Qemu-devel] [PATCH] block: Flush image after open
Am 21.03.2011 13:23, schrieb Avi Kivity: On 03/09/2011 07:38 PM, Anthony Liguori wrote: On 03/09/2011 11:27 AM, Christoph Hellwig wrote: On Wed, Mar 09, 2011 at 05:15:53PM +0100, Kevin Wolf wrote: Quoting the bug report: qemu ensures that guest writes and qemu metadata writes hit the disk when necessary to prevent data corruption. However, if an image was in host pagecache prior to starting qemu, for example after running qemu-img convert, then nothing prevents writes from reaching the disk out of order, potentially causing corruption. I'm not entirely sure if there is a realistic case where we would get corruption, but it's probably a case of better safe than sorry. Except for SCSI with ordered tags (which we don't support) there are not ordering guarantees in the storage protocols, and as such the above explanation doesn't make any sense at all. Even if there was, a guest shouldn't be relying on the ordering of a write that comes from a non-guest. I don't understand the failure scenario here. $ cp x.img y.img $ qemu -drive file=y.img,cache=writeback read something from disk, send it over the network no guest flushes host crash The guest may expect that any or none of its writes hit the disk, but that anything that it read from the disk, stays there. Is it true for real hardware? Consider a reboot, you could still have some data in a volatile disk write cache if the OS that ran before the reboot hasn't flushed it. Kevin
[Qemu-devel] KVM call agenda for Mars 21th
Please, send in any agenda items you are interested in covening. - Merge patches speed. I just feel, that patches are not being handled fast enough, so ... I looked how much patches have been integrated since Mars 1st: (master)$ g log --pretty=fuller ed02c54d1fd5d35c06e62e3dae84ee5bb90097ef.. | grep ^Commit: | wc -l 121 121 patches total. Now, I looked at how much patches Anthony commited himself: (master)$ g log --pretty=fuller ed02c54d1fd5d35c06e62e3dae84ee5bb90097ef.. | grep ^Commit: | grep Anthony | wc -l 13 This feel pretty bad, having in account that I have almost 80 patches on the list waiting for action. As it appears that more people is also waiting for Anthony to merge things, I think we have a problem here. And no, I don't want to make Anthony feel bad, but I know that the kind of patches that I sent are for subsystems that only he merges. I think that we really have a problem integrating patches, it just takes too long. Thanks, Juan.
[Qemu-devel] Re: [PATCH v3 3/3] piix_pci: optimize set irq path
On Mon, Mar 21, 2011 at 09:56:56PM +0900, Isaku Yamahata wrote:
On Mon, Mar 21, 2011 at 02:31:11PM +0200, Michael S. Tsirkin wrote:
On Mon, Mar 21, 2011 at 09:10:32PM +0900, Isaku Yamahata wrote:
On Mon, Mar 21, 2011 at 01:37:07PM +0200, Michael S. Tsirkin wrote:
+static int piix3_post_load(void *opaque, int version_id)
+{
+PIIX3State *piix3 = opaque;
+piix3_update_irq_levels(piix3);
Couldn't figure out why would we not want to
propagate the interrupts here.
Could you explain please?
What happens if we do propagate them?
Nothing bad, right?
I wanted to be just conservative.
If you are brave enough to change the behavior, I'm fine with propagating
interrupts.
If we propagate the interrupts, guest OS may see interrupts
unnecessarily/spuriously injected after load.
Probably such interrupts doesn't harm OSes, so there is nothing
bad in theory as you said.
On the other hand, I hesitated to change the existing behavior because
it would be very difficult to debug it and to test many OSes.
I expect it won't change the behaviour because the interrupts
are level: at the moment e.g. pci devices already reassert
interrupts on load.
But I agree it better be a separate patch, and needs a lot of testing.
Like this?
Yes. But need to stress-test with migration, windows and linux guests
at least.
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index f07e19d..8052c1e 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -280,8 +280,7 @@ static void piix3_set_irq_pic(PIIX3State *piix3, int
pic_irq)
((PIIX_NUM_PIRQS - 1) (pic_irq * PIIX_NUM_PIRQS;
}
-static void piix3_set_irq_level(PIIX3State *piix3, int irq_num, int level,
-bool propagate)
+static void piix3_set_irq_level(PIIX3State *piix3, int irq_num, int level)
{
int pic_irq;
uint64_t mask;
@@ -295,15 +294,13 @@ static void piix3_set_irq_level(PIIX3State *piix3, int
irq_num, int level,
piix3-pic_levels = ~mask;
piix3-pic_levels |= mask * !!level;
-if (propagate) {
-piix3_set_irq_pic(piix3, pic_irq);
-}
+piix3_set_irq_pic(piix3, pic_irq);
}
static void piix3_set_irq(void *opaque, int irq_num, int level)
{
PIIX3State *piix3 = opaque;
-piix3_set_irq_level(piix3, irq_num, level, true);
+piix3_set_irq_level(piix3, irq_num, level);
}
/* irq routing is changed. so rebuild bitmap */
@@ -314,8 +311,7 @@ static void piix3_update_irq_levels(PIIX3State *piix3)
piix3-pic_levels = 0;
for (pirq = 0; pirq PIIX_NUM_PIRQS; pirq++) {
piix3_set_irq_level(piix3, pirq,
-pci_bus_get_irq_level(piix3-dev.bus, pirq),
-false);
+pci_bus_get_irq_level(piix3-dev.bus, pirq));
}
}
--
yamahata
[Qemu-devel] [PATCH 1/7] virtio-serial: Use a struct to pass config information from proxy
Instead of using a single variable to pass to the virtio_serial_init
function, use a struct so that expanding the number of variables to be
passed on later is easier.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-pci.c| 12 ++--
hw/virtio-serial-bus.c | 16
hw/virtio-serial.h |5 +
hw/virtio.h|3 ++-
4 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 3911b09..952b5d2 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -18,6 +18,7 @@
#include virtio.h
#include virtio-blk.h
#include virtio-net.h
+#include virtio-serial.h
#include pci.h
#include qemu-error.h
#include msix.h
@@ -109,8 +110,7 @@ typedef struct {
#ifdef CONFIG_LINUX
V9fsConf fsconf;
#endif
-/* Max. number of ports we can have for a the virtio-serial device */
-uint32_t max_virtserial_ports;
+virtio_serial_conf serial;
virtio_net_conf net;
bool ioeventfd_disabled;
bool ioeventfd_started;
@@ -770,12 +770,12 @@ static int virtio_serial_init_pci(PCIDevice *pci_dev)
proxy-class_code != PCI_CLASS_OTHERS) /* qemu-kvm */
proxy-class_code = PCI_CLASS_COMMUNICATION_OTHER;
-vdev = virtio_serial_init(pci_dev-qdev, proxy-max_virtserial_ports);
+vdev = virtio_serial_init(pci_dev-qdev, proxy-serial);
if (!vdev) {
return -1;
}
vdev-nvectors = proxy-nvectors == DEV_NVECTORS_UNSPECIFIED
-? proxy-max_virtserial_ports + 1
+? proxy-serial.max_virtserial_ports +
1
: proxy-nvectors;
virtio_init_pci(proxy, vdev,
PCI_VENDOR_ID_REDHAT_QUMRANET,
@@ -902,8 +902,8 @@ static PCIDeviceInfo virtio_info[] = {
DEV_NVECTORS_UNSPECIFIED),
DEFINE_PROP_HEX32(class, VirtIOPCIProxy, class_code, 0),
DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
-DEFINE_PROP_UINT32(max_ports, VirtIOPCIProxy,
max_virtserial_ports,
- 31),
+DEFINE_PROP_UINT32(max_ports, VirtIOPCIProxy,
+ serial.max_virtserial_ports, 31),
DEFINE_PROP_END_OF_LIST(),
},
.qdev.reset = virtio_pci_reset,
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index 8446bc2..c6feb43 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -811,19 +811,19 @@ void
virtio_serial_port_qdev_register(VirtIOSerialPortInfo *info)
qdev_register(info-qdev);
}
-VirtIODevice *virtio_serial_init(DeviceState *dev, uint32_t max_nr_ports)
+VirtIODevice *virtio_serial_init(DeviceState *dev, virtio_serial_conf *conf)
{
VirtIOSerial *vser;
VirtIODevice *vdev;
uint32_t i, max_supported_ports;
-if (!max_nr_ports)
+if (!conf-max_virtserial_ports)
return NULL;
/* Each port takes 2 queues, and one pair is for the control queue */
max_supported_ports = VIRTIO_PCI_QUEUE_MAX / 2 - 1;
-if (max_nr_ports max_supported_ports) {
+if (conf-max_virtserial_ports max_supported_ports) {
error_report(maximum ports supported: %u, max_supported_ports);
return NULL;
}
@@ -839,9 +839,9 @@ VirtIODevice *virtio_serial_init(DeviceState *dev, uint32_t
max_nr_ports)
vser-bus-vser = vser;
QTAILQ_INIT(vser-ports);
-vser-bus-max_nr_ports = max_nr_ports;
-vser-ivqs = qemu_malloc(max_nr_ports * sizeof(VirtQueue *));
-vser-ovqs = qemu_malloc(max_nr_ports * sizeof(VirtQueue *));
+vser-bus-max_nr_ports = conf-max_virtserial_ports;
+vser-ivqs = qemu_malloc(conf-max_virtserial_ports * sizeof(VirtQueue *));
+vser-ovqs = qemu_malloc(conf-max_virtserial_ports * sizeof(VirtQueue *));
/* Add a queue for host to guest transfers for port 0 (backward compat) */
vser-ivqs[0] = virtio_add_queue(vdev, 128, handle_input);
@@ -866,8 +866,8 @@ VirtIODevice *virtio_serial_init(DeviceState *dev, uint32_t
max_nr_ports)
vser-ovqs[i] = virtio_add_queue(vdev, 128, handle_output);
}
-vser-config.max_nr_ports = max_nr_ports;
-vser-ports_map = qemu_mallocz(((max_nr_ports + 31) / 32)
+vser-config.max_nr_ports = conf-max_virtserial_ports;
+vser-ports_map = qemu_mallocz(((conf-max_virtserial_ports + 31) / 32)
* sizeof(vser-ports_map[0]));
/*
* Reserve location 0 for a console port for backward compat
diff --git a/hw/virtio-serial.h b/hw/virtio-serial.h
index 8cb9fbe..5eb948e 100644
--- a/hw/virtio-serial.h
+++ b/hw/virtio-serial.h
@@ -45,6 +45,11 @@ struct virtio_console_control {
uint16_t value;/* Extra information for the key */
};
+struct virtio_serial_conf {
+/* Max. number of ports we can have for a virtio-serial device */
+uint32_t max_virtserial_ports;
+};
+
/* Some events for the internal messages
[Qemu-devel] [PULL #7 0/7] virtio-serial fixes, enhancements
Hello, This series fixes a few bugs reported against virtio-serial. Please apply. The following changes since commit e0efb993b817564ef84e462ac1fe35f89b57ad7b: Fix conversions from pointer to int and vice versa (2011-03-20 21:39:23 +) are available in the git repository at: git://git.kernel.org/pub/scm/virt/qemu/amit/virtio-serial.git for-anthony Amit Shah (7): virtio-serial: Use a struct to pass config information from proxy virtio-serial: Disallow generic ports at id 0 virtio-serial: Enable ioeventfd virtio-serial-bus: Simplify handle_output() function virtio-serial: Don't clear -have_data() pointer after unplug virtio-console: Keep chardev open for other users after hot-unplug char: Prevent multiple devices opening same chardev hw/qdev-properties.c |7 ++- hw/virtio-console.c| 16 ++-- hw/virtio-pci.c| 15 +-- hw/virtio-serial-bus.c | 28 +++- hw/virtio-serial.h |5 + hw/virtio.h|3 ++- qemu-char.c|4 qemu-char.h|1 + 8 files changed, 52 insertions(+), 27 deletions(-) -- 1.7.4
[Qemu-devel] [PATCH 2/7] virtio-serial: Disallow generic ports at id 0
Port 0 is reserved for virtconsole devices for backward compatibility
with the old -virtioconsole (from qemu 0.12) device type.
libvirt prior to commit 8e28c5d40200b4c5d483bd585d237b9d870372e5 used
port 0 for generic ports. libvirt will no longer do that, but disallow
instantiating generic ports at id 0 from qemu as well.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index c235b27..4440784 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -11,6 +11,7 @@
*/
#include qemu-char.h
+#include qemu-error.h
#include virtio-serial.h
typedef struct VirtConsole {
@@ -113,6 +114,14 @@ static int virtserialport_initfn(VirtIOSerialPort *port)
{
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
+if (port-id == 0) {
+/*
+ * Disallow a generic port at id 0, that's reserved for
+ * console ports.
+ */
+error_report(Port number 0 on virtio-serial devices reserved for
virtconsole devices for backward compatibility.);
+return -1;
+}
return generic_port_init(vcon, port);
}
--
1.7.4
[Qemu-devel] [PATCH 4/7] virtio-serial-bus: Simplify handle_output() function
There's no code change, just re-arrangement to simplify the function
after recent modifications.
Reported-by: Juan Quintela quint...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-serial-bus.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index c6feb43..a82fbe9 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -442,25 +442,19 @@ static void handle_output(VirtIODevice *vdev, VirtQueue
*vq)
{
VirtIOSerial *vser;
VirtIOSerialPort *port;
-bool discard;
vser = DO_UPCAST(VirtIOSerial, vdev, vdev);
port = find_port_by_vq(vser, vq);
-discard = false;
if (!port || !port-host_connected || !port-info-have_data) {
-discard = true;
-}
-
-if (discard) {
discard_vq_data(vq, vdev);
return;
}
-if (port-throttled) {
+
+if (!port-throttled) {
+do_flush_queued_data(port, vq, vdev);
return;
}
-
-do_flush_queued_data(port, vq, vdev);
}
static void handle_input(VirtIODevice *vdev, VirtQueue *vq)
--
1.7.4
[Qemu-devel] [PATCH 3/7] virtio-serial: Enable ioeventfd
Enable ioeventfd for virtio-serial devices by default. Commit
25db9ebe15125deb32958c6df74996f745edf1f9 lists the benefits of using
ioeventfd.
Copying a file from guest to host over a virtio-serial channel didn't
show much difference in time or io_exit rate.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-pci.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 952b5d2..ef65590 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -789,6 +789,7 @@ static int virtio_serial_exit_pci(PCIDevice *pci_dev)
{
VirtIOPCIProxy *proxy = DO_UPCAST(VirtIOPCIProxy, pci_dev, pci_dev);
+virtio_pci_stop_ioeventfd(proxy);
virtio_serial_exit(proxy-vdev);
return virtio_exit_pci(pci_dev);
}
@@ -898,6 +899,8 @@ static PCIDeviceInfo virtio_info[] = {
.init = virtio_serial_init_pci,
.exit = virtio_serial_exit_pci,
.qdev.props = (Property[]) {
+DEFINE_PROP_BIT(ioeventfd, VirtIOPCIProxy, flags,
+VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
DEFINE_PROP_UINT32(vectors, VirtIOPCIProxy, nvectors,
DEV_NVECTORS_UNSPECIFIED),
DEFINE_PROP_HEX32(class, VirtIOPCIProxy, class_code, 0),
--
1.7.4
[Qemu-devel] [PATCH 7/7] char: Prevent multiple devices opening same chardev
Prevent:
-chardev socket,path=/tmp/foo,server,nowait,id=c0 \
-device virtserialport,chardev=c0,id=vs0 \
-device virtserialport,chardev=c0,id=vs1
Reported-by: Mike Cao b...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/qdev-properties.c |7 ++-
qemu-char.c |4
qemu-char.h |1 +
3 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index a45b61e..1088a26 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -351,8 +351,13 @@ static int parse_chr(DeviceState *dev, Property *prop,
const char *str)
CharDriverState **ptr = qdev_get_prop_ptr(dev, prop);
*ptr = qemu_chr_find(str);
-if (*ptr == NULL)
+if (*ptr == NULL) {
return -ENOENT;
+}
+if ((*ptr)-assigned) {
+return -EEXIST;
+}
+(*ptr)-assigned = 1;
return 0;
}
diff --git a/qemu-char.c b/qemu-char.c
index cad35d7..c4557c3 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -197,6 +197,10 @@ void qemu_chr_add_handlers(CharDriverState *s,
IOEventHandler *fd_event,
void *opaque)
{
+if (!opaque) {
+/* chr driver being released. */
+s-assigned = 0;
+}
s-chr_can_read = fd_can_read;
s-chr_read = fd_read;
s-chr_event = fd_event;
diff --git a/qemu-char.h b/qemu-char.h
index 56d9954..fb96eef 100644
--- a/qemu-char.h
+++ b/qemu-char.h
@@ -70,6 +70,7 @@ struct CharDriverState {
char *label;
char *filename;
int opened;
+int assigned; /* chardev assigned to a device */
QTAILQ_ENTRY(CharDriverState) next;
};
--
1.7.4
[Qemu-devel] [PATCH 6/7] virtio-console: Keep chardev open for other users after hot-unplug
After a hot-unplug operation, the previous behaviour was to close the
chardev. That meant the chardev couldn't be re-used. Also, since
chardev hot-plug isn't possible so far, this means virtio-console
hot-plug isn't feasible as well.
With this change, the chardev is kept around. A new virtio-console
channel can then be hot-plugged with the same chardev and things will
continue to work.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index be59558..6b5237b 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -82,7 +82,11 @@ static int virtconsole_exitfn(VirtIOSerialPort *port)
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
if (vcon-chr) {
-qemu_chr_close(vcon-chr);
+ /*
+* Instead of closing the chardev, free it so it can be used
+* for other purposes.
+*/
+ qemu_chr_add_handlers(vcon-chr, NULL, NULL, NULL, NULL);
}
return 0;
--
1.7.4
[Qemu-devel] [PATCH 5/7] virtio-serial: Don't clear -have_data() pointer after unplug
After a port unplug operation, the port-info-have_data() pointer was
set to NULL. The problem is, the -info struct is shared by all ports,
effectively disabling writes to other ports.
Reported-by: juzhang juzh...@redhat.com
Signed-off-by: Amit Shah amit.s...@redhat.com
---
hw/virtio-console.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index 4440784..be59558 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -82,7 +82,6 @@ static int virtconsole_exitfn(VirtIOSerialPort *port)
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
if (vcon-chr) {
-port-info-have_data = NULL;
qemu_chr_close(vcon-chr);
}
--
1.7.4
Re: [Qemu-devel] [PATCH] block: Flush image after open
On 03/21/2011 03:02 PM, Kevin Wolf wrote: Am 21.03.2011 13:23, schrieb Avi Kivity: On 03/09/2011 07:38 PM, Anthony Liguori wrote: On 03/09/2011 11:27 AM, Christoph Hellwig wrote: On Wed, Mar 09, 2011 at 05:15:53PM +0100, Kevin Wolf wrote: Quoting the bug report: qemu ensures that guest writes and qemu metadata writes hit the disk when necessary to prevent data corruption. However, if an image was in host pagecache prior to starting qemu, for example after running qemu-img convert, then nothing prevents writes from reaching the disk out of order, potentially causing corruption. I'm not entirely sure if there is a realistic case where we would get corruption, but it's probably a case of better safe than sorry. Except for SCSI with ordered tags (which we don't support) there are not ordering guarantees in the storage protocols, and as such the above explanation doesn't make any sense at all. Even if there was, a guest shouldn't be relying on the ordering of a write that comes from a non-guest. I don't understand the failure scenario here. $ cp x.img y.img $ qemu -drive file=y.img,cache=writeback read something from disk, send it over the network no guest flushes host crash The guest may expect that any or none of its writes hit the disk, but that anything that it read from the disk, stays there. Is it true for real hardware? Consider a reboot, you could still have some data in a volatile disk write cache if the OS that ran before the reboot hasn't flushed it. That's if RESET doesn't flush the cache. It's probably false for fc or iscsi, but possibly true for IDE. But it can't happen for a single-boot host, or a dual boot host with no shared partitions. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v21 00/11] usb-ccid
On Mon, Mar 21, 2011 at 12:24 PM, Alon Levy al...@redhat.com wrote: Thanks, this should fix it: diff --git a/Makefile.target b/Makefile.target index baa5c3f..fef56b4 100644 --- a/Makefile.target +++ b/Makefile.target Thanks it fixes it. I didn't have libnss3-dev installed. Stefan
Re: [Qemu-devel] [PATCH v21 00/11] usb-ccid
Ack series
Acked-by: Hans de Goede hdego...@redhat.com
On 03/17/2011 03:49 PM, Alon Levy wrote:
This patchset adds three new devices, usb-ccid, ccid-card-passthru and
ccid-card-emulated, providing a CCID bus, a simple passthru protocol
implementing card requiring a client, and a standalone emulated card.
It also introduces a new directory libcaccard with CAC card emulation,
CAC is a type of ISO 7816 smart card.
Tree for pull: git://anongit.freedesktop.org/~alon/qemu usb_ccid.v20
v20-v21 changes:
* all: cosmetics
* libcacard, ccid-card-passthru:
* use qemu-{malloc,free} and qemu-thread, error_report
* libcacard:
* split to multiple patches
v19-v20 changes:
* checkpatch.pl. Here are the remaining errors with explanation:
* ignored 5 macro errors of the type
ERROR: Macros with complex values should be enclosed in parenthesis
because fixing them breaks current code, if it really bothers someone
I can fix it.
* four of them are in libcacard/card_7816t.h:
/* give the subfields a unified look */
..
#define a_cla a_header-ah_cla /* class */
#define a_ins a_header-ah_ins /* instruction */
#define a_p1 a_header-ah_p1 /* parameter 1 */
#define a_p2 a_header-ah_p2 /* parameter 2 */
* and the fifth:
#4946: FILE: libcacard/vcardt.h:31:
+#define VCARD_ATR_PREFIX(size) 0x3b, 0x66+(size), 0x00, 0xff, \
+ 'V', 'C', 'A', 'R', 'D', '_'
* Ignored this warning since I couldn't figure it out, and it's a test
file:
WARNING: externs should be avoided in .c files
#2343: FILE: libcacard/link_test.c:7:
+VCardStatus cac_card_init(const char *flags, VCard *card,
v18-v19 changes:
* more merges, down to a single digit number of patches.
* drop enumeration property, use string.
* rebased (trivial)
v17-v18 changes:
* merge vscard_common.h patches.
* actually provide a tree to pull.
v16-v17 changes:
* merged all the v15-v16 patches
* merged some more wherever it was easy (all same file commits).
* added signed off by to first four patches
* ccid.h: added copyright, removed underscore in defines, and replaced
non C89 comments
v15-v16 changes:
* split vscard_common introducing patch for ease of review
* sum of commit logs for the v15-v16 commits: (whitespace fixes
removed for space, see original commit messages in later patches)
* usb-ccid:
* fix abort on client answer after card remove
* enable migration
* remove side affect code from asserts
* return consistent self-powered state
* mask out reserved bits in ccid_set_parameters
* add missing abRFU in SetParameters (no affect on linux guest)
* vscard_common.h protocol change:
* VSCMsgInit capabilities and magic
* removed ReaderResponse, will use Error instead with code==VSC_SUCCESS.
* added Flush and FlushComplete, remove Reconnect.
* define VSCARD_MAGIC
* added error code VSC_SUCCESS.
* ccid-card-passthru
* return correct size
* return error instead of assert if client sent too large ATR
* don't assert if client sent too large a size, but add asserts for indices
to buffer
* reset vscard_in indices on chardev disconnect
* handle init from client
* error if no chardev supplied
* use ntoh, hton
* eradicate reader_id_t
* remove Reconnect usage (removed from VSCARD protocol)
* send VSC_SUCCESS on card insert/remove and reader add/remove
* ccid-card-emulated
* fix error reporting in initfn
v14-v15 changes:
* add patch with --enable-smartcard and --disable-smartcard and only
disable ccid-card-emulated if nss not found.
* add patch with description strings
* s/libcaccard/libcacard/ in docs/ccid.txt
v13-v14 changes:
- support device_del/device_add on ccid-card-* and usb-ccid
* usb-ccid:
* lose card reference when card device deleted
* check slot number and deny adding a slot if one is already added.
* ccid-card-*: use qdev_simple_unplug_cb in both emulated and passthru ccid
cards,
the exitfn already takes care of triggering card removal in the usb dev.
* libcacard:
* remove double include of config-host.mak
* add replay of card events to libcacard to support second and more emulation
* don't initialize more then once (doesn't support it right now, so one
thread, NSS thread, is left when device_del is done)
* add VCARD_EMUL_INIT_ALREADY_INITED
* ccid-card-emulated:
* take correct mutexes on signaling to fix deadlocks on device_del
* allow card insertion/removal event without proper reader insertion event
v12-v13 changes:
* libcacard:
* fix Makefile clean to remove vscclient
* fix double include of config-host in Makefile
* usb-ccid: remove attach/detach logic, usb is always attached. Guest
doesn't care if there is a reader attached with no card anyway.
* ccid-card-passthru: don't close chr_dev on removal, makes it possible
to use device_del/device_add to create remove/insertion for debugging.
v11-v12
[Qemu-devel] Re: [PULL 0/9] Block patches
Am 16.03.2011 11:47, schrieb Kevin Wolf: The following changes since commit cc015e9a5dde2f03f123357fa060acbdfcd570a4: add Win32 IPI service (2011-03-13 14:44:22 +) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Brian Wheeler (1): Fix ATA SMART and CHECK POWER MODE Feiran Zheng (1): hw/xen_disk: aio_inflight not released in handling ioreq when nr_segments==0 Jes Sorensen (1): Improve error handling in do_snapshot_blkdev() Kevin Wolf (3): Add error message for loading snapshot without VM state tools: Use real async.c instead of stubs Add qcow2 documentation Ryan Harper (1): Don't allow multiwrites against a block device without underlying medium Stefan Weil (2): block/vdi: Don't ignore immediate read/write failures block/qcow: Don't ignore immediate read/write and other failures Ping? Kevin
[Qemu-devel] [PULL] allow arbitrary scaling of timers
On 03/14/2011 08:14 AM, Paolo Bonzini wrote: On 03/13/2011 12:33 AM, Anthony Liguori wrote: Really nice series. The whole thing Reviewed-by: Anthony Liguori aligu...@us.ibm.com Did you really mean to RFC this? I don't think there's any sort of problem applying this as it's mostly mechanical. Yeah, it's just that the topic had been brought before and other people may have other ideas regarding the API. It's something pretty central so the API change warranted an RFC. If you want to apply it, now or in a few days, I certainly won't complain. The following changes since commit e0efb993b817564ef84e462ac1fe35f89b57ad7b: Fix conversions from pointer to int and vice versa (2011-03-20 21:39:23 +) are available in the git repository at: git://github.com/bonzini/qemu.git for-anthony Paolo Bonzini (5): add more helper functions with explicit milli/nanosecond resolution change all rt_clock references to use millisecond resolution accessors change all other clock references to use nanosecond resolution accessors add a generic scaling mechanism for timers remove qemu_get_clock audio/audio.c|4 +- audio/noaudio.c |4 +- audio/spiceaudio.c |4 +- audio/wavaudio.c |2 +- buffered_file.c |6 ++-- console.c|4 +- hw/acpi_piix4.c |8 +++--- hw/adlib.c |2 +- hw/apic.c|8 +++--- hw/arm_sysctl.c |2 +- hw/armv7m_nvic.c |8 +++--- hw/baum.c|4 +- hw/bt-hci-csr.c |4 +- hw/bt-hci.c | 12 +- hw/cuda.c| 24 ++-- hw/dp8393x.c |6 ++-- hw/etraxfs_timer.c |2 +- hw/fdc.c |4 +- hw/hpet.c| 14 +- hw/i8254.c | 12 +- hw/i8259.c |4 +- hw/ide/core.c|4 +- hw/intel-hda.c |2 +- hw/lan9118.c |4 +- hw/lm832x.c |6 ++-- hw/m48t59.c |6 ++-- hw/mc146818rtc.c | 16 ++-- hw/mips_timer.c | 10 hw/mpcore.c |6 ++-- hw/omap1.c | 30 hw/omap_gptimer.c| 14 +- hw/omap_synctimer.c |2 +- hw/pcnet.c |6 ++-- hw/pcspk.c |2 +- hw/pflash_cfi01.c|2 +- hw/pflash_cfi02.c|6 ++-- hw/pl031.c |8 +++--- hw/ppc.c | 52 +- hw/ppc405_uc.c |6 ++-- hw/ppc_prep.c|2 +- hw/ptimer.c | 14 +- hw/pxa2xx.c | 30 hw/pxa2xx_timer.c| 28 +++--- hw/rc4030.c |4 +- hw/rtl8139.c | 22 +- hw/sb16.c|4 +- hw/serial.c | 20 hw/soc_dma.c |4 +- hw/spitz.c |6 ++-- hw/stellaris.c |6 ++-- hw/sun4u.c | 12 +- hw/syborg_rtc.c |2 +- hw/tsc2005.c |4 +- hw/tsc210x.c | 20 hw/tusb6010.c|8 +++--- hw/twl92230.c|8 +++--- hw/usb-hid.c |6 ++-- hw/usb-musb.c|4 +- hw/usb-ohci.c|8 +++--- hw/usb-uhci.c|6 ++-- hw/vga.c |2 +- hw/virtio-net.c |6 ++-- hw/vt82c686.c|8 +++--- hw/wdt_i6300esb.c|4 +- hw/wdt_ib700.c |4 +- hw/xen_domainbuild.c |6 ++-- monitor.c|4 +- net/dump.c |2 +- qemu-char.c |8 +++--- qemu-timer.c | 60 + qemu-timer.h | 25 +++- savevm.c |6 ++-- slirp/slirp.c|2 +- target-ppc/kvm.c |4 +- target-ppc/kvm_ppc.c |6 ++-- ui/spice-core.c |4 +- ui/vnc.c | 10 usb-linux.c |4 +- vl.c | 12 +- 79 files changed, 364 insertions(+), 351 deletions(-) -- 1.7.4
[Qemu-devel] re: PRoot: A Step Forward for QEMU User-Mode
Hi, First, thanks for the report! On Mon, Mar 21, 2011 at 12:09:10PM +, Peter Maydell wrote: == Talk 11: PRoot: A Step Forward for QEMU User-Mode == STMicroelectronics again, presenting an alternative to the usual chroot plus binfmt_misc approach for running target binaries seamlessly under qemu's linux-user mode. It's a wrapper around qemu which uses ptrace to intercept the syscalls qemu makes to the host; in particular it can add the target-directory prefix to all filesystem access syscalls, and can turn an attempt to exec /bin/ls into an exec of qemu-linux-arm /bin/ls. The advantage over chroot is that it's more flexible and doesn't need root access to set up. They didn't give figures for how much overhead the syscall interception adds, though. Similar thing is done with scratchbox2, but with LD_PRELOAD instead of ptrace. LD_PRELOAD for all around the corners (static binaries etc) and the slowdown is major. ptrace would make at least the former problem go away. However, why do it behind Qemu's back anyway? In linux-user we already pass most filesystem access via path() function. Any needed filesystem redirections could be done there within Qemu itself. Riku
Re: [Qemu-devel] [PATCH] target-arm/helper.c: For float-int conversion helpers pass ints as ints
On Mon, Mar 14, 2011 at 05:23:11PM +, Peter Maydell wrote: Correct the argument and return types for the float-int conversion helper functions so that integer arguments and return values are declared as uint32_t/uint64_t, not float32/float64. This allows us to remove the hand-rolled functions which were doing bitwise copies between the types via unions. Reviewed-by: Nathan Froyd froy...@codesourcery.com I like the direction this patch goes; you aren't by any chance going to convert the passing/returning of float* to their appropriate int* types too, are you? -Nathan
Re: [Qemu-devel] [PATCH] target-arm/helper.c: For float-int conversion helpers pass ints as ints
On 21 March 2011 13:48, Nathan Froyd froy...@codesourcery.com wrote: On Mon, Mar 14, 2011 at 05:23:11PM +, Peter Maydell wrote: Correct the argument and return types for the float-int conversion helper functions so that integer arguments and return values are declared as uint32_t/uint64_t, not float32/float64. I like the direction this patch goes; you aren't by any chance going to convert the passing/returning of float* to their appropriate int* types too, are you? Nope -- I think that where we're passing or returning an actual IEEE single/double to a helper function float* is a better type than uint32_t: it gives information about what the helper's argument semantically is, and it means we don't have every helper that takes or returns a float have to include ugly calls to the boxing/unboxing macros. -- PMM
Re: [Qemu-devel] [PATCH] target-arm/helper.c: For float-int conversion helpers pass ints as ints
On Mon, Mar 21, 2011 at 02:04:31PM +, Peter Maydell wrote: On 21 March 2011 13:48, Nathan Froyd froy...@codesourcery.com wrote: I like the direction this patch goes; you aren't by any chance going to convert the passing/returning of float* to their appropriate int* types too, are you? Nope -- I think that where we're passing or returning an actual IEEE single/double to a helper function float* is a better type than uint32_t: it gives information about what the helper's argument semantically is, and it means we don't have every helper that takes or returns a float have to include ugly calls to the boxing/unboxing macros. I'm just concerned about what would happen if we turned on softfloat's float types are structure types bit; I'm pretty sure everything would break horribly on targets that don't pass small structures in registers. Admittedly, several targets would be broken by doing so, so it's not particularly urgent. -Nathan
[Qemu-devel] Re: [PATCH v3 3/3] piix_pci: optimize set irq path
On Sat, Mar 19, 2011 at 10:24:52PM +0900, Isaku Yamahata wrote:
optimize irq routing in piix_pic.c which has been a TODO.
So far piix3 tracks each pirq level and checks whether a given pic pins is
asserted by seeing if each pirq is mapped into the pic pin.
This is independent on irq routing, but data path is on slow path.
Given that irq routing is rarely changed and asserting pic pins is on
data path, the path that asserts pic pins should be optimized and
chainging irq routing should be on slow path.
The new behavior with this patch series is to use bitmap which is addressed
by pirq and pic pins with a given irq routing.
When pirq is asserted, the bitmap is set and see if the pic pins is
asserted by checking the bitmaps.
When irq routing is changed, rebuild the bitmap and re-assert pic pins.
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
Changes v1 - v2:
- some minor clean ups
- commit log message
---
hw/piix_pci.c | 94
+
1 files changed, 81 insertions(+), 13 deletions(-)
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index e88df43..f07e19d 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -37,8 +37,27 @@
typedef PCIHostState I440FXState;
+#define PIIX_NUM_PIC_IRQS 16 /* i8259 * 2 */
+#define PIIX_NUM_PIRQS 4ULL/* PIRQ[A-D] */
I've changed this to
((uint64_t)PCI_NUM_PINS)
Makes sense?
+#define PIIX_PIRQC 0x60
+
typedef struct PIIX3State {
PCIDevice dev;
+
+/*
+ * bitmap to track pic levels.
+ * The pic level is the logical OR of all the PCI irqs mapped to it
+ * So one PIC level is tracked by PIIX_NUM_PIRQS bits.
+ *
+ * PIRQ is mapped to PIC pins, we track it by
+ * PIIX_NUM_PIRQS * PIIX_NUM_PIC_IRQS = 64 bits with
+ * pic_irq * PIIX_NUM_PIRQS + pirq
+ */
+#if PIIX_NUM_PIC_IRQS * PIIX_NUM_PIRQS 64
+#error unable to encode pic state in 64bit in pic_levels.
+#endif
+uint64_t pic_levels;
+
qemu_irq *pic;
/* This member isn't used. Just for save/load compatibility */
@@ -254,25 +273,63 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int
*piix3_devfn, qemu_irq *
}
/* PIIX3 PCI to ISA bridge */
+static void piix3_set_irq_pic(PIIX3State *piix3, int pic_irq)
+{
+qemu_set_irq(piix3-pic[pic_irq],
+ !!(piix3-pic_levels
+((PIIX_NUM_PIRQS - 1) (pic_irq * PIIX_NUM_PIRQS;
+}
+
+static void piix3_set_irq_level(PIIX3State *piix3, int irq_num, int level,
+bool propagate)
+{
+int pic_irq;
+uint64_t mask;
+
+pic_irq = piix3-dev.config[PIIX_PIRQC + irq_num];
+if (pic_irq = PIIX_NUM_PIC_IRQS) {
+return;
+}
+
+mask = 1ULL ((pic_irq * PIIX_NUM_PIRQS) + irq_num);
+piix3-pic_levels = ~mask;
+piix3-pic_levels |= mask * !!level;
+
+if (propagate) {
+piix3_set_irq_pic(piix3, pic_irq);
+}
+}
static void piix3_set_irq(void *opaque, int irq_num, int level)
{
-int i, pic_irq, pic_level;
PIIX3State *piix3 = opaque;
+piix3_set_irq_level(piix3, irq_num, level, true);
+}
-/* now we change the pic irq level according to the piix irq mappings */
-/* XXX: optimize */
-pic_irq = piix3-dev.config[0x60 + irq_num];
-if (pic_irq 16) {
-/* The pic level is the logical OR of all the PCI irqs mapped
- to it */
-pic_level = 0;
-for (i = 0; i 4; i++) {
-if (pic_irq == piix3-dev.config[0x60 + i]) {
-pic_level |= pci_bus_get_irq_level(piix3-dev.bus, i);
-}
+/* irq routing is changed. so rebuild bitmap */
+static void piix3_update_irq_levels(PIIX3State *piix3)
+{
+int pirq;
+
+piix3-pic_levels = 0;
+for (pirq = 0; pirq PIIX_NUM_PIRQS; pirq++) {
+piix3_set_irq_level(piix3, pirq,
+pci_bus_get_irq_level(piix3-dev.bus, pirq),
+false);
+}
+}
+
+static void piix3_write_config(PCIDevice *dev,
+ uint32_t address, uint32_t val, int len)
+{
+pci_default_write_config(dev, address, val, len);
+if (ranges_overlap(address, len, PIIX_PIRQC, 4)) {
+PIIX3State *piix3 = DO_UPCAST(PIIX3State, dev, dev);
+int pic_irq;
+piix3_update_irq_levels(piix3);
+for (pic_irq = 0; pic_irq PIIX_NUM_PIC_IRQS; pic_irq++) {
+piix3_set_irq_pic(piix3, pic_irq);
}
-qemu_set_irq(piix3-pic[pic_irq], pic_level);
}
}
@@ -312,6 +369,15 @@ static void piix3_reset(void *opaque)
pci_conf[0xab] = 0x00;
pci_conf[0xac] = 0x00;
pci_conf[0xae] = 0x00;
+
+d-pic_levels = 0;
+}
+
+static int piix3_post_load(void *opaque, int version_id)
+{
+PIIX3State *piix3 = opaque;
+
Re: [Qemu-devel] [PATCH] target-arm/helper.c: For float-int conversion helpers pass ints as ints
On 21 March 2011 14:09, Nathan Froyd froy...@codesourcery.com wrote: I'm just concerned about what would happen if we turned on softfloat's float types are structure types bit; I'm pretty sure everything would break horribly on targets that don't pass small structures in registers. Admittedly, several targets would be broken by doing so, so it's not particularly urgent. Last time I turned that flag on half the targets didn't compile :-) I view it as more of a debugging aid and wouldn't expect anybody to ever actually run with it enabled. -- PMM
[Qemu-devel] Moving beyond image files
We've been evaluating block migration in a real environment to try to understand what the overhead of it is compared to normal migration. The results so far are pretty disappointing. The speed of local disks ends up becoming a big bottleneck even before the network does. This has got me thinking about what we could do to avoid local I/O via deduplication and other techniques. This has led me to wonder if its time to move beyond simple image files into something a bit more sophisticated. Ideally, I'd want a full Content Addressable Storage database like Venti but there are lots of performance concerns with something like that. I've been thinking about a middle ground and am looking for some feedback. Here's my current thinking: 1) All block I/O goes through a daemon. There may be more than one daemon to support multi-tenancy. 2) The daemon maintains metadata for each image that includes an extent mapping and then a clustered allocated bitmap within each extent (similar to FVD). At this point, it's basically sparse raw but through a single daemon. 3) All writes result in a sha1 being calculated before the write is completed. The daemon maintains a mapping of sha1's - clusters. A single sha1 may map to many clusters. The sha1 mapping can be made eventually consistent using a journal or even dirty bitmap. It can be partially rebuilt easily. I think this is where v1 stops. With just this level of functionality, I think we have some very interesting properties: a) Performance should be pretty close to raw b) Without doing any (significant) disk I/O, we know exactly what data an image is composed of. This means we can do an rsync style image streaming that uses potentially much less network I/O and potentially much less disk I/O. In a v2, I think you can add some interesting features that take advantage of the hashing. For instance: 4) If you run out of disk space, you can looking at a hash with a refcount 1, and split off a reference making it copy-on-write. Then you can treat the remaining references as free list entries. 5) Copy-on-write references potentially become very interesting for image streaming because you can avoid any I/O for blocks that are already stored locally. This is not fully baked yet but I thought I'd at least throw it out there as a topic for discussion. I think we've focused almost entirely on single images so I think it's worth thinking a little about different storage models. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] [PPC] Add support for 6 SPE instructions (evmra, evmwsmi{a{a}}, evmwumi{a{a}})
On Wed, Mar 16, 2011 at 11:21:22AM +0100, Fabien Chouteau wrote: Signed-off-by: Fabien Chouteau chout...@adacore.com Reviewed-by: Nathan Froyd froy...@codesourcery.com -Nathan
Re: [Qemu-devel] Moving beyond image files
On 21.03.2011, at 16:05, Anthony Liguori wrote: We've been evaluating block migration in a real environment to try to understand what the overhead of it is compared to normal migration. The results so far are pretty disappointing. The speed of local disks ends up becoming a big bottleneck even before the network does. This has got me thinking about what we could do to avoid local I/O via deduplication and other techniques. This has led me to wonder if its time to move beyond simple image files into something a bit more sophisticated. Ideally, I'd want a full Content Addressable Storage database like Venti but there are lots of performance concerns with something like that. I've been thinking about a middle ground and am looking for some feedback. Here's my current thinking: 1) All block I/O goes through a daemon. There may be more than one daemon to support multi-tenancy. 2) The daemon maintains metadata for each image that includes an extent mapping and then a clustered allocated bitmap within each extent (similar to FVD). At this point, it's basically sparse raw but through a single daemon. 3) All writes result in a sha1 being calculated before the write is completed. The daemon maintains a mapping of sha1's - clusters. A single sha1 may map to many clusters. The sha1 mapping can be made eventually consistent using a journal or even dirty bitmap. It can be partially rebuilt easily. I think this is where v1 stops. With just this level of functionality, I think we have some very interesting properties: a) Performance should be pretty close to raw b) Without doing any (significant) disk I/O, we know exactly what data an image is composed of. This means we can do an rsync style image streaming that uses potentially much less network I/O and potentially much less disk I/O. In a v2, I think you can add some interesting features that take advantage of the hashing. For instance: 4) If you run out of disk space, you can looking at a hash with a refcount 1, and split off a reference making it copy-on-write. Then you can treat the remaining references as free list entries. 5) Copy-on-write references potentially become very interesting for image streaming because you can avoid any I/O for blocks that are already stored locally. This is not fully baked yet but I thought I'd at least throw it out there as a topic for discussion. I think we've focused almost entirely on single images so I think it's worth thinking a little about different storage models. Wouldn't it make sense to have your file system be that daemon and add an interface to it so you can receive the sha1 sums (that you need for dedup anyways) to calculate rsync style diffs? That way you'd also speed up 2 other use cases: a) normal raw storage - no need to implement new protocols, file formats, etc b) real rsync on real data that is not vm images Alex
Re: [Qemu-devel] Moving beyond image files
On 03/21/2011 10:16 AM, Alexander Graf wrote: On 21.03.2011, at 16:05, Anthony Liguori wrote: 5) Copy-on-write references potentially become very interesting for image streaming because you can avoid any I/O for blocks that are already stored locally. This is not fully baked yet but I thought I'd at least throw it out there as a topic for discussion. I think we've focused almost entirely on single images so I think it's worth thinking a little about different storage models. Wouldn't it make sense to have your file system be that daemon I see that as purely an implementation detail. Regards, Anthony Liguori and add an interface to it so you can receive the sha1 sums (that you need for dedup anyways) to calculate rsync style diffs? That way you'd also speed up 2 other use cases: a) normal raw storage - no need to implement new protocols, file formats, etc b) real rsync on real data that is not vm images Alex
[Qemu-devel] RE: Query: gdbstub software breakpoint removal
Hi Jan, I will send a patch. Thanks -Bharat -Original Message- From: Jan Kiszka [mailto:jan.kis...@siemens.com] Sent: Monday, March 21, 2011 5:04 PM To: Bhushan Bharat-R65777 Cc: qemu-devel@nongnu.org Subject: Re: Query: gdbstub software breakpoint removal On 2011-03-21 12:01, Bhushan Bharat-R65777 wrote: Hi All, I can see that the software breakpoint queue is cleared in kvm_remove_breakpoint() in kvm-all.c. I.e QTAILQ_REMOVE(current_env- kvm_state-kvm_sw_breakpoints, bp, entry); is called when the breakpoint is cleared. While the queue is not cleared on kvm_remove_all_breakpoints(); Is there any specific reason for that? Hmm, no particular reason that I recall. This rather looks like a very old leak. Patch welcome. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct
This fairly simple patchset adds a new 'max_ram' field to the QEMUMachine structure so that a board model can specify the maximum RAM it will accept. We can then produce a friendly diagnostic message when the user tries to start qemu with a '-m' option asking for more RAM than that. (Currently most of the ARM devboard models respond with an obscure guest crash when the guest tries to access RAM and finds device registers instead.) If no maximum size is specified we default to the old behaviour of do not impose any limit. The advantage of doing this in vl.c rather than in each board (apart from avoiding code duplication) is that we can distinguish between the user asked for more RAM than we support (an error) and the global default RAM size is more than our maximum (just cap the RAM size to the board maximum). I did think about also adding a default_ram field so each board could default to the same amount of RAM that real hardware has, but since we allocate RAM up front rather than only when accessed, this would push the initial default allocated RAM size up from 128MB to 1GB on models like the PBX A9, and it didn't seem very friendly to do that. I'm happy to be persuaded back again, though :-) This patchset was prompted by bugs like: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/584480 https://bugs.launchpad.net/ubuntu/+source/rootstock/+bug/570588 Peter Maydell (2): Allow boards to specify maximum RAM size hw: Add maximum RAM specifications for ARM devboard models hw/boards.h |1 + hw/integratorcp.c |1 + hw/realview.c | 11 +++ hw/versatilepb.c |5 + vl.c | 16 +++- 5 files changed, 33 insertions(+), 1 deletions(-)
[Qemu-devel] [PATCH 2/2] hw: Add maximum RAM specifications for ARM devboard models
Specify the maximum memory permitted for the various ARM devboard
models (integratorcp, realview-eb, realview-eb-mpcore, realview-pb-a8,
realview-pbx-a9, versatilepb, versatileab). This means we now handle
attempts to specify too much RAM gracefully rather than causing
the guest to crash in an obscure fashion.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/integratorcp.c |1 +
hw/realview.c | 11 +++
hw/versatilepb.c |5 +
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/hw/integratorcp.c b/hw/integratorcp.c
index b049940..ccc44db 100644
--- a/hw/integratorcp.c
+++ b/hw/integratorcp.c
@@ -516,6 +516,7 @@ static QEMUMachine integratorcp_machine = {
.name = integratorcp,
.desc = ARM Integrator/CP (ARM926EJ-S),
.init = integratorcp_init,
+.max_ram = 256 * 1024 * 1024,
.is_default = 1,
};
diff --git a/hw/realview.c b/hw/realview.c
index a67861e..a158ade 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -432,6 +432,7 @@ static QEMUMachine realview_eb_machine = {
.desc = ARM RealView Emulation Baseboard (ARM926EJ-S),
.init = realview_eb_init,
.use_scsi = 1,
+.max_ram = 256 * 1024 * 1024,
};
static QEMUMachine realview_eb_mpcore_machine = {
@@ -440,12 +441,18 @@ static QEMUMachine realview_eb_mpcore_machine = {
.init = realview_eb_mpcore_init,
.use_scsi = 1,
.max_cpus = 4,
+.max_ram = 256 * 1024 * 1024,
};
static QEMUMachine realview_pb_a8_machine = {
.name = realview-pb-a8,
.desc = ARM RealView Platform Baseboard for Cortex-A8,
.init = realview_pb_a8_init,
+/* The PB-A8 has 512MB; qemu also supports an extra PBX-A9-like
+ * 512MB although strictly speaking that area of the address
+ * space is 'reserved' on the PB-A8.
+ */
+.max_ram = 1024 * 1024 * 1024,
};
static QEMUMachine realview_pbx_a9_machine = {
@@ -454,6 +461,10 @@ static QEMUMachine realview_pbx_a9_machine = {
.init = realview_pbx_a9_init,
.use_scsi = 1,
.max_cpus = 4,
+/* Realview PBX has 1GB of RAM (512MB on the motherboard
+ * and another 512MB on the daughterboard)
+ */
+.max_ram = 1024 * 1024 * 1024,
};
static void realview_machine_init(void)
diff --git a/hw/versatilepb.c b/hw/versatilepb.c
index 9f1bfcf..aeddd28 100644
--- a/hw/versatilepb.c
+++ b/hw/versatilepb.c
@@ -329,6 +329,10 @@ static QEMUMachine versatilepb_machine = {
.desc = ARM Versatile/PB (ARM926EJ-S),
.init = vpb_init,
.use_scsi = 1,
+/* Hardware allows for up to 512MB expansion memory in two
+ * non-contiguous sections, but we only support up to 256MB
+ */
+.max_ram = 256 * 1024 * 1024,
};
static QEMUMachine versatileab_machine = {
@@ -336,6 +340,7 @@ static QEMUMachine versatileab_machine = {
.desc = ARM Versatile/AB (ARM926EJ-S),
.init = vab_init,
.use_scsi = 1,
+.max_ram = 256 * 1024 * 1024,
};
static void versatile_machine_init(void)
--
1.7.1
[Qemu-devel] [PATCH 1/2] Allow boards to specify maximum RAM size
Allow boards to specify their maximum RAM size in the QEMUMachine struct.
This allows us to provide a useful diagnostic if the user tries to specify
a RAM size that the board cannot support.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/boards.h |1 +
vl.c| 16 +++-
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/hw/boards.h b/hw/boards.h
index 6f0f0d7..bf63f8d 100644
--- a/hw/boards.h
+++ b/hw/boards.h
@@ -19,6 +19,7 @@ typedef struct QEMUMachine {
QEMUMachineInitFunc *init;
int use_scsi;
int max_cpus;
+ram_addr_t max_ram;
unsigned int no_serial:1,
no_parallel:1,
use_virtcon:1,
diff --git a/vl.c b/vl.c
index b1a94aa..971ad90 100644
--- a/vl.c
+++ b/vl.c
@@ -166,6 +166,9 @@ int main(int argc, char **argv)
//#define DEBUG_NET
//#define DEBUG_SLIRP
+/* Note that this default RAM size is capped to any maximum
+ * RAM size specified in the board's QEMUMachine struct.
+ */
#define DEFAULT_RAM_SIZE 128
#define MAX_VIRTIO_CONSOLES 1
@@ -2910,8 +2913,19 @@ int main(int argc, char **argv, char **envp)
exit(1);
/* init the memory */
-if (ram_size == 0)
+if (ram_size == 0) {
ram_size = DEFAULT_RAM_SIZE * 1024 * 1024;
+if (machine-max_ram) {
+ram_size = MIN(ram_size, machine-max_ram);
+}
+} else if (machine-max_ram ram_size machine-max_ram) {
+/* Since you can only specify ram_size on the command line in MB it's
+ * OK to round down when printing the machine's maximum.
+ */
+fprintf(stderr, qemu: maximum permitted RAM size for '%s' is %ldM\n,
+machine-name, (machine-max_ram / (1024 * 1024)));
+exit(1);
+}
/* init the dynamic translator */
cpu_exec_init_all(tb_size * 1024 * 1024);
--
1.7.1
[Qemu-devel] OVMF, SeaBIOS non-CSM based legacy boot
This weekend I spent some time working on loading SeaBIOS from OVMF to start a legacy boot. I was able to get x86 x86-64 Linux to legacy boot using this method. Unfortunately, (I think) it is not nearly as nice a having a true CSM. Basically, you have to decide at some point in the OVMF boot that you want to legacy boot, and once you start SeaBIOS running, OVMF/UEFI will never be in the picture again (until system reset). Contrast this to using a CSM where you can: * Load a legacy option ROM (vbios, or disk rom), and use it during a UEFI boot * Fail a legacy boot, and potentially return back to UEFI if it fails. (Not in all cases, if the failed boot alters the system state significantly) * Specify via UEFI the boot process which disk to legacy boot in the CSM So, would this be valuable (in the short term) to help move forward QEMU's usage of OVMF and add UEFI support? Or would QEMU require true CSM support? Thanks, -Jordan
Re: [Qemu-devel] OVMF, SeaBIOS non-CSM based legacy boot
On 03/21/2011 01:14 PM, Jordan Justen wrote: This weekend I spent some time working on loading SeaBIOS from OVMF to start a legacy boot. I was able to get x86 x86-64 Linux to legacy boot using this method. Unfortunately, (I think) it is not nearly as nice a having a true CSM. Basically, you have to decide at some point in the OVMF boot that you want to legacy boot, and once you start SeaBIOS running, OVMF/UEFI Interesting. How much time does OVMF add to the total boot time when taking this approach? will never be in the picture again (until system reset). Contrast this to using a CSM where you can: * Load a legacy option ROM (vbios, or disk rom), and use it during a UEFI boot Is there gPXE for UEFI yet? Other than that, this probably matters most of with device passthrough. I think this is a limitation we could live with in the not-to-short term though. * Fail a legacy boot, and potentially return back to UEFI if it fails. (Not in all cases, if the failed boot alters the system state significantly) I think the most typical use-case here is -boot cd or -boot dc. From what I can tell, EFI support El Torito so it wouldn't be necessary to involve BIOS to handle booting from CDROMs. Is that correct? * Specify via UEFI the boot process which disk to legacy boot in the CSM I'm sure this is workable. So, would this be valuable (in the short term) to help move forward QEMU's usage of OVMF and add UEFI support? Or would QEMU require true CSM support? I think this certainly helps make the discussion more concrete. I don't see any show stoppers here. Regards, Anthony Liguori Thanks, -Jordan
[Qemu-devel] [PATCH] v9fs_walk: As per 9p2000 RFC, MAXWELEM = nwnames = 0.
The nwnames field in TWALK message is assumed to be =0 and = MAXWELEM
which is defined as macro P9_MAXWELEM (16) in virtio-9p.h as per 9p2000 RFC.
Appropriate changes are required in V9fsWalkState and v9fs_walk.
Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com
---
hw/9pfs/virtio-9p.c |5 -
hw/9pfs/virtio-9p.h |2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 9b44bd0..b782a19 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1805,7 +1805,7 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
vs-offset += pdu_unmarshal(vs-pdu, vs-offset, ddw, fid,
newfid, vs-nwnames);
-if (vs-nwnames) {
+if (vs-nwnames = P9_MAXWELEM) {
vs-wnames = qemu_mallocz(sizeof(vs-wnames[0]) * vs-nwnames);
vs-qids = qemu_mallocz(sizeof(vs-qids[0]) * vs-nwnames);
@@ -1814,6 +1814,9 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
vs-offset += pdu_unmarshal(vs-pdu, vs-offset, s,
vs-wnames[i]);
}
+} else {
+err = -EINVAL;
+goto out;
}
vs-fidp = lookup_fid(s, fid);
diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h
index e7d2326..119b12c 100644
--- a/hw/9pfs/virtio-9p.h
+++ b/hw/9pfs/virtio-9p.h
@@ -307,7 +307,7 @@ typedef struct V9fsStatStateDotl {
typedef struct V9fsWalkState {
V9fsPDU *pdu;
size_t offset;
-int16_t nwnames;
+uint16_t nwnames;
int name_idx;
V9fsQID *qids;
V9fsFidState *fidp;
--
1.7.1.1
Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct
On 03/21/2011 12:47 PM, Peter Maydell wrote: This fairly simple patchset adds a new 'max_ram' field to the QEMUMachine structure so that a board model can specify the maximum RAM it will accept. We can then produce a friendly diagnostic message when the user tries to start qemu with a '-m' option asking for more RAM than that. (Currently most of the ARM devboard models respond with an obscure guest crash when the guest tries to access RAM and finds device registers instead.) If no maximum size is specified we default to the old behaviour of do not impose any limit. The advantage of doing this in vl.c rather than in each board (apart from avoiding code duplication) is that we can distinguish between the user asked for more RAM than we support (an error) and the global default RAM size is more than our maximum (just cap the RAM size to the board maximum). I did think about also adding a default_ram field so each board could default to the same amount of RAM that real hardware has, but since we allocate RAM up front rather than only when accessed, this would push the initial default allocated RAM size up from 128MB to 1GB on models like the PBX A9, and it didn't seem very friendly to do that. I'm happy to be persuaded back again, though :-) I don't have any objections to these patches, but it makes me wonder if we should try to go further. There are certainly a lot of use-cases where the boards being emulated are extremely sensitive to the options specified. I wonder if we ought to provide a better way for boards to participate in command line validation. For instance, I know that many boards can only accept certain RAM sizes that map to realistic DIMM sizes. I don't have any great ideas here but wonder if it's something we should more seriously consider. Regards, Anthony Liguori This patchset was prompted by bugs like: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/584480 https://bugs.launchpad.net/ubuntu/+source/rootstock/+bug/570588 Peter Maydell (2): Allow boards to specify maximum RAM size hw: Add maximum RAM specifications for ARM devboard models hw/boards.h |1 + hw/integratorcp.c |1 + hw/realview.c | 11 +++ hw/versatilepb.c |5 + vl.c | 16 +++- 5 files changed, 33 insertions(+), 1 deletions(-)
Re: [Qemu-devel] [PATCH v3 1/2] hw/arm_sysctl.c: Add the Versatile Express system registers
On Mon, Mar 07, 2011 at 11:10:31AM +, Peter Maydell wrote:
Add support for the Versatile Express SYS_CFG registers, which provide
a generic means of reading or writing configuration information from
various parts of the board. We only implement shutdown and reset.
Also make the RESETCTL register RAZ/WI on Versatile Express rather
than reset the board. Other system registers are generally the same
as Versatile and Realview.
This includes a VMState version number bump for arm_sysctl,
since we have new register state to preserve. It also adds
sys_mci to the VMState while we're bumping the version number
(an accidental omission from commit b50ff6f5).
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/arm_sysctl.c | 64
++-
1 files changed, 63 insertions(+), 1 deletions(-)
Thanks, applied.
diff --git a/hw/arm_sysctl.c b/hw/arm_sysctl.c
index 799b007..b1110b4 100644
--- a/hw/arm_sysctl.c
+++ b/hw/arm_sysctl.c
@@ -27,11 +27,14 @@ typedef struct {
uint32_t resetlevel;
uint32_t proc_id;
uint32_t sys_mci;
+uint32_t sys_cfgdata;
+uint32_t sys_cfgctrl;
+uint32_t sys_cfgstat;
} arm_sysctl_state;
static const VMStateDescription vmstate_arm_sysctl = {
.name = realview_sysctl,
-.version_id = 1,
+.version_id = 2,
.minimum_version_id = 1,
.fields = (VMStateField[]) {
VMSTATE_UINT32(leds, arm_sysctl_state),
@@ -41,6 +44,10 @@ static const VMStateDescription vmstate_arm_sysctl = {
VMSTATE_UINT32(flags, arm_sysctl_state),
VMSTATE_UINT32(nvflags, arm_sysctl_state),
VMSTATE_UINT32(resetlevel, arm_sysctl_state),
+VMSTATE_UINT32_V(sys_mci, arm_sysctl_state, 2),
+VMSTATE_UINT32_V(sys_cfgdata, arm_sysctl_state, 2),
+VMSTATE_UINT32_V(sys_cfgctrl, arm_sysctl_state, 2),
+VMSTATE_UINT32_V(sys_cfgstat, arm_sysctl_state, 2),
VMSTATE_END_OF_LIST()
}
};
@@ -53,6 +60,7 @@ static const VMStateDescription vmstate_arm_sysctl = {
#define BOARD_ID_EB 0x140
#define BOARD_ID_PBA8 0x178
#define BOARD_ID_PBX 0x182
+#define BOARD_ID_VEXPRESS 0x190
static int board_id(arm_sysctl_state *s)
{
@@ -104,6 +112,10 @@ static uint32_t arm_sysctl_read(void *opaque,
target_phys_addr_t offset)
case 0x38: /* NVFLAGS */
return s-nvflags;
case 0x40: /* RESETCTL */
+if (board_id(s) == BOARD_ID_VEXPRESS) {
+/* reserved: RAZ/WI */
+return 0;
+}
return s-resetlevel;
case 0x44: /* PCICTL */
return 1;
@@ -142,7 +154,23 @@ static uint32_t arm_sysctl_read(void *opaque,
target_phys_addr_t offset)
case 0xcc: /* SYS_TEST_OSC3 */
case 0xd0: /* SYS_TEST_OSC4 */
return 0;
+case 0xa0: /* SYS_CFGDATA */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+return s-sys_cfgdata;
+case 0xa4: /* SYS_CFGCTRL */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+return s-sys_cfgctrl;
+case 0xa8: /* SYS_CFGSTAT */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+return s-sys_cfgstat;
default:
+bad_reg:
printf (arm_sysctl_read: Bad register offset 0x%x\n, (int)offset);
return 0;
}
@@ -190,6 +218,10 @@ static void arm_sysctl_write(void *opaque,
target_phys_addr_t offset,
s-nvflags = ~val;
break;
case 0x40: /* RESETCTL */
+if (board_id(s) == BOARD_ID_VEXPRESS) {
+/* reserved: RAZ/WI */
+break;
+}
if (s-lockval == LOCK_VALUE) {
s-resetlevel = val;
if (val 0x100)
@@ -216,7 +248,37 @@ static void arm_sysctl_write(void *opaque,
target_phys_addr_t offset,
case 0x98: /* OSCRESET3 */
case 0x9c: /* OSCRESET4 */
break;
+case 0xa0: /* SYS_CFGDATA */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+s-sys_cfgdata = val;
+return;
+case 0xa4: /* SYS_CFGCTRL */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+s-sys_cfgctrl = val ~(3 18);
+s-sys_cfgstat = 1;/* complete */
+switch (s-sys_cfgctrl) {
+case 0xc080:/* SYS_CFG_SHUTDOWN to motherboard */
+qemu_system_shutdown_request();
+break;
+case 0xc090:/* SYS_CFG_REBOOT to motherboard */
+qemu_system_reset_request();
+break;
+default:
+s-sys_cfgstat |= 2;/* error */
+}
+return;
+case 0xa8: /* SYS_CFGSTAT */
+if (board_id(s) != BOARD_ID_VEXPRESS) {
+goto bad_reg;
+}
+s-sys_cfgstat = val 3;
+
Re: [Qemu-devel] [PATCH v3 2/2] hw/vexpress.c: Add model of ARM Versatile Express board
On Mon, Mar 07, 2011 at 11:10:32AM +, Peter Maydell wrote:
Add a model of the ARM Versatile Express board (with A9MPx4
daughterboard).
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
Makefile.target |1 +
hw/vexpress.c | 224
+++
2 files changed, 225 insertions(+), 0 deletions(-)
create mode 100644 hw/vexpress.c
diff --git a/Makefile.target b/Makefile.target
index 220589e..949bd4e 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -315,6 +315,7 @@ obj-arm-y += framebuffer.o
obj-arm-y += syborg.o syborg_fb.o syborg_interrupt.o syborg_keyboard.o
obj-arm-y += syborg_serial.o syborg_timer.o syborg_pointer.o syborg_rtc.o
obj-arm-y += syborg_virtio.o
+obj-arm-y += vexpress.o
obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
diff --git a/hw/vexpress.c b/hw/vexpress.c
new file mode 100644
index 000..9ffd332
--- /dev/null
+++ b/hw/vexpress.c
@@ -0,0 +1,224 @@
+/*
+ * ARM Versatile Express emulation.
+ *
+ * Copyright (c) 2010 - 2011 B Labs Ltd.
+ * Copyright (c) 2011 Linaro Limited
+ * Written by Bahadir Balban, Amit Mahajan, Peter Maydell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include sysbus.h
+#include arm-misc.h
+#include primecell.h
+#include devices.h
+#include net.h
+#include sysemu.h
+#include boards.h
+
+#define SMP_BOOT_ADDR 0xe000
+
+#define VEXPRESS_BOARD_ID 0x8e0
+
+static struct arm_boot_info vexpress_binfo = {
+.smp_loader_start = SMP_BOOT_ADDR,
+};
+
+static void vexpress_a9_init(ram_addr_t ram_size,
+ const char *boot_device,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename, const char *cpu_model)
+{
+CPUState *env = NULL;
+ram_addr_t ram_offset, vram_offset, sram_offset;
+DeviceState *dev, *sysctl;
+SysBusDevice *busdev;
+qemu_irq *irqp;
+qemu_irq pic[64];
+int n;
+qemu_irq cpu_irq[4];
+uint32_t proc_id;
+uint32_t sys_id;
+ram_addr_t low_ram_size, vram_size, sram_size;
+
+if (!cpu_model) {
+cpu_model = cortex-a9;
+}
+
+for (n = 0; n smp_cpus; n++) {
+env = cpu_init(cpu_model);
+if (!env) {
+fprintf(stderr, Unable to find CPU definition\n);
+exit(1);
+}
+irqp = arm_pic_init_cpu(env);
+cpu_irq[n] = irqp[ARM_PIC_CPU_IRQ];
+}
+
+if (ram_size 0x4000) {
+/* 1GB is the maximum the address space permits */
+fprintf(stderr, vexpress: cannot model more than 1GB RAM\n);
+exit(1);
+}
+
+ram_offset = qemu_ram_alloc(NULL, vexpress.highmem, ram_size);
+low_ram_size = ram_size;
+if (low_ram_size 0x400) {
+low_ram_size = 0x400;
+}
+/* RAM is from 0x6000 upwards. The bottom 64MB of the
+ * address space should in theory be remappable to various
+ * things including ROM or RAM; we always map the RAM there.
+ */
+cpu_register_physical_memory(0x0, low_ram_size, ram_offset | IO_MEM_RAM);
+cpu_register_physical_memory(0x6000, ram_size,
+ ram_offset | IO_MEM_RAM);
+
+/* 0x1e00 A9MPCore (SCU) private memory region */
+dev = qdev_create(NULL, a9mpcore_priv);
+qdev_prop_set_uint32(dev, num-cpu, smp_cpus);
+qdev_init_nofail(dev);
+busdev = sysbus_from_qdev(dev);
+vexpress_binfo.smp_priv_base = 0x1e00;
+sysbus_mmio_map(busdev, 0, vexpress_binfo.smp_priv_base);
+for (n = 0; n smp_cpus; n++) {
+sysbus_connect_irq(busdev, n, cpu_irq[n]);
+}
+/* Interrupts [42:0] are from the motherboard;
+ * [47:43] are reserved; [63:48] are daughterboard
+ * peripherals. Note that some documentation numbers
+ * external interrupts starting from 32 (because the
+ * A9MP has internal interrupts 0..31).
+ */
+for (n = 0; n 64; n++) {
+pic[n] = qdev_get_gpio_in(dev, n);
+}
+
+/* Motherboard peripherals CS7 : 0x1000 .. 0x1002 */
+sys_id = 0x1190f500;
+proc_id = 0x0c000191;
+
+/* 0x1000 System registers */
+sysctl = qdev_create(NULL, realview_sysctl);
+qdev_prop_set_uint32(sysctl, sys_id,
Re: [Qemu-devel] [PATCH v2] e1000: Fix multi-descriptor packet checksum offload
On Mon, Mar 07, 2011 at 08:04:07PM +, Stefan Hajnoczi wrote:
The PCI/PCI-X Family of Gigabit Ethernet Controllers Software
Developer’s Manual states the following about the POPTS field:
Provides a number of options which control the handling of this
packet. This field is ignored except on the first data descriptor of
a packet.
The current implementation always loads the field and its checksum
offload flags. This patch uses only the first descriptor's POPTS field
in order to comply with the specification.
When Solaris sends multi-descriptor packets it fills in POPTS for the
first descriptor only. Therefore this patch is necessary in order to
perform checksum offload correctly for multi-descriptor packets.
Reported-by: Daniel Pecka dpe...@techniservit.cz
Reported-by: Gabriele A. Trombetti gabriele.trombe...@itb.cnr.it
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
v2:
* Fix Reported-by: details
hw/e1000.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
Thanks, applied.
diff --git a/hw/e1000.c b/hw/e1000.c
index 0a4574c..2a4d5c7 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -446,7 +446,9 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
return;
} else if (dtype == (E1000_TXD_CMD_DEXT | E1000_TXD_DTYP_D)) {
// data descriptor
-tp-sum_needed = le32_to_cpu(dp-upper.data) 8;
+if (tp-size == 0) {
+tp-sum_needed = le32_to_cpu(dp-upper.data) 8;
+}
tp-cptse = ( txd_lower E1000_TXD_CMD_TSE ) ? 1 : 0;
} else {
// legacy descriptor
--
1.7.2.3
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PULL] allow arbitrary scaling of timers
On Mon, Mar 21, 2011 at 02:35:32PM +0100, Paolo Bonzini wrote: On 03/14/2011 08:14 AM, Paolo Bonzini wrote: On 03/13/2011 12:33 AM, Anthony Liguori wrote: Really nice series. The whole thing Reviewed-by: Anthony Liguori aligu...@us.ibm.com Did you really mean to RFC this? I don't think there's any sort of problem applying this as it's mostly mechanical. Yeah, it's just that the topic had been brought before and other people may have other ideas regarding the API. It's something pretty central so the API change warranted an RFC. If you want to apply it, now or in a few days, I certainly won't complain. The following changes since commit e0efb993b817564ef84e462ac1fe35f89b57ad7b: Fix conversions from pointer to int and vice versa (2011-03-20 21:39:23 +) are available in the git repository at: git://github.com/bonzini/qemu.git for-anthony Paolo Bonzini (5): add more helper functions with explicit milli/nanosecond resolution change all rt_clock references to use millisecond resolution accessors change all other clock references to use nanosecond resolution accessors add a generic scaling mechanism for timers remove qemu_get_clock audio/audio.c|4 +- audio/noaudio.c |4 +- audio/spiceaudio.c |4 +- audio/wavaudio.c |2 +- buffered_file.c |6 ++-- console.c|4 +- hw/acpi_piix4.c |8 +++--- hw/adlib.c |2 +- hw/apic.c|8 +++--- hw/arm_sysctl.c |2 +- hw/armv7m_nvic.c |8 +++--- hw/baum.c|4 +- hw/bt-hci-csr.c |4 +- hw/bt-hci.c | 12 +- hw/cuda.c| 24 ++-- hw/dp8393x.c |6 ++-- hw/etraxfs_timer.c |2 +- hw/fdc.c |4 +- hw/hpet.c| 14 +- hw/i8254.c | 12 +- hw/i8259.c |4 +- hw/ide/core.c|4 +- hw/intel-hda.c |2 +- hw/lan9118.c |4 +- hw/lm832x.c |6 ++-- hw/m48t59.c |6 ++-- hw/mc146818rtc.c | 16 ++-- hw/mips_timer.c | 10 hw/mpcore.c |6 ++-- hw/omap1.c | 30 hw/omap_gptimer.c| 14 +- hw/omap_synctimer.c |2 +- hw/pcnet.c |6 ++-- hw/pcspk.c |2 +- hw/pflash_cfi01.c|2 +- hw/pflash_cfi02.c|6 ++-- hw/pl031.c |8 +++--- hw/ppc.c | 52 +- hw/ppc405_uc.c |6 ++-- hw/ppc_prep.c|2 +- hw/ptimer.c | 14 +- hw/pxa2xx.c | 30 hw/pxa2xx_timer.c| 28 +++--- hw/rc4030.c |4 +- hw/rtl8139.c | 22 +- hw/sb16.c|4 +- hw/serial.c | 20 hw/soc_dma.c |4 +- hw/spitz.c |6 ++-- hw/stellaris.c |6 ++-- hw/sun4u.c | 12 +- hw/syborg_rtc.c |2 +- hw/tsc2005.c |4 +- hw/tsc210x.c | 20 hw/tusb6010.c|8 +++--- hw/twl92230.c|8 +++--- hw/usb-hid.c |6 ++-- hw/usb-musb.c|4 +- hw/usb-ohci.c|8 +++--- hw/usb-uhci.c|6 ++-- hw/vga.c |2 +- hw/virtio-net.c |6 ++-- hw/vt82c686.c|8 +++--- hw/wdt_i6300esb.c|4 +- hw/wdt_ib700.c |4 +- hw/xen_domainbuild.c |6 ++-- monitor.c|4 +- net/dump.c |2 +- qemu-char.c |8 +++--- qemu-timer.c | 60 + qemu-timer.h | 25 +++- savevm.c |6 ++-- slirp/slirp.c|2 +- target-ppc/kvm.c |4 +- target-ppc/kvm_ppc.c |6 ++-- ui/spice-core.c |4 +- ui/vnc.c | 10 usb-linux.c |4 +- vl.c | 12 +- 79 files changed, 364 insertions(+), 351 deletions(-) Thanks, pulled. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] Re: [PULL 0/9] Block patches
On Mon, Mar 21, 2011 at 02:31:37PM +0100, Kevin Wolf wrote: Am 16.03.2011 11:47, schrieb Kevin Wolf: The following changes since commit cc015e9a5dde2f03f123357fa060acbdfcd570a4: add Win32 IPI service (2011-03-13 14:44:22 +) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Brian Wheeler (1): Fix ATA SMART and CHECK POWER MODE Feiran Zheng (1): hw/xen_disk: aio_inflight not released in handling ioreq when nr_segments==0 Jes Sorensen (1): Improve error handling in do_snapshot_blkdev() Kevin Wolf (3): Add error message for loading snapshot without VM state tools: Use real async.c instead of stubs Add qcow2 documentation Ryan Harper (1): Don't allow multiwrites against a block device without underlying medium Stefan Weil (2): block/vdi: Don't ignore immediate read/write failures block/qcow: Don't ignore immediate read/write and other failures Ping? Pulled. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 0/2] Let boards state maximum RAM limits in QEMUMachine struct
On Tue, 22 Mar 2011 04:47:18 am Peter Maydell wrote: This fairly simple patchset adds a new 'max_ram' field to the QEMUMachine structure so that a board model can specify the maximum RAM it will accept. We can then produce a friendly diagnostic message when the user tries to start qemu with a '-m' option asking for more RAM than that. (Currently most of the ARM devboard models respond with an obscure guest crash when the guest tries to access RAM and finds device registers instead.) As a user, I've been bitten by this. Without understanding how qemu works, the problem is quite surprising: all I've done is increased the RAM, and now it just crashes. I don't think my review of the code will count for much, and I'd prefer to see the code added rather than not, but you could move the cmd.c macros (MEGABYTES and TO_MEGABYTES) to some common header and just use those. They are pretty ugly though... Brad
Re: [Qemu-devel] OVMF, SeaBIOS non-CSM based legacy boot
On Mon, Mar 21, 2011 at 6:27 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 03/21/2011 01:14 PM, Jordan Justen wrote: This weekend I spent some time working on loading SeaBIOS from OVMF to start a legacy boot. I was able to get x86 x86-64 Linux to legacy boot using this method. Unfortunately, (I think) it is not nearly as nice a having a true CSM. Basically, you have to decide at some point in the OVMF boot that you want to legacy boot, and once you start SeaBIOS running, OVMF/UEFI Interesting. How much time does OVMF add to the total boot time when taking this approach? will never be in the picture again (until system reset). Contrast this to using a CSM where you can: * Load a legacy option ROM (vbios, or disk rom), and use it during a UEFI boot Is there gPXE for UEFI yet? I have never tried it myself, but I think it should work. CCed Michael Brown to check. Stefan
Re: [Qemu-devel] [PATCH v5 04/10] softfloat: Drop [u]int16 types in favor of [u]int_fast16_t
On Tue, Mar 08, 2011 at 07:54:39PM +0100, Andreas Färber wrote: Am 08.03.2011 um 09:29 schrieb Peter Maydell: Maybe we should have a patchset that does the uncontroversial change (bits32-uint32_t c, which I think should be purely mechanical) while we argue about this bit? That should be patch 03 (or 02-03). :) I have just applied patches 01 to 03. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH] v9fs_walk: As per 9p2000 RFC, MAXWELEM = nwnames = 0.
On Mon, Mar 21, 2011 at 6:31 PM, Harsh Prateek Bora
ha...@linux.vnet.ibm.com wrote:
The nwnames field in TWALK message is assumed to be =0 and = MAXWELEM
which is defined as macro P9_MAXWELEM (16) in virtio-9p.h as per 9p2000 RFC.
Appropriate changes are required in V9fsWalkState and v9fs_walk.
Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com
---
hw/9pfs/virtio-9p.c | 5 -
hw/9pfs/virtio-9p.h | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 9b44bd0..b782a19 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1805,7 +1805,7 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
vs-offset += pdu_unmarshal(vs-pdu, vs-offset, ddw, fid,
newfid, vs-nwnames);
- if (vs-nwnames) {
+ if (vs-nwnames = P9_MAXWELEM) {
vs-wnames = qemu_mallocz(sizeof(vs-wnames[0]) * vs-nwnames);
vs-qids = qemu_mallocz(sizeof(vs-qids[0]) * vs-nwnames);
@@ -1814,6 +1814,9 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
vs-offset += pdu_unmarshal(vs-pdu, vs-offset, s,
vs-wnames[i]);
}
+ } else {
+ err = -EINVAL;
+ goto out;
}
v9fs_walk_complete() will attempt to free wnames, qids, and the wnames
strings. Freeing the strings will crash because we're indexing into
an array based off a NULL pointer.
It would be very handy to have a PDU-level test suite. You could then
construct a PDU with an invalid nwnames field and exercise this code
path. Perhaps a debug ioctl in Linux v9fs that allows a userspace
tool to pass PDUs through will do?
Stefan
Re: [Qemu-devel] OVMF, SeaBIOS non-CSM based legacy boot
On Monday 21 Mar 2011 21:06:24 Stefan Hajnoczi wrote: On Mon, Mar 21, 2011 at 6:27 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 03/21/2011 01:14 PM, Jordan Justen wrote: This weekend I spent some time working on loading SeaBIOS from OVMF to start a legacy boot. I was able to get x86 x86-64 Linux to legacy boot using this method. Unfortunately, (I think) it is not nearly as nice a having a true CSM. Basically, you have to decide at some point in the OVMF boot that you want to legacy boot, and once you start SeaBIOS running, OVMF/UEFI Interesting. How much time does OVMF add to the total boot time when taking this approach? will never be in the picture again (until system reset). Contrast this to using a CSM where you can: * Load a legacy option ROM (vbios, or disk rom), and use it during a UEFI boot Is there gPXE for UEFI yet? I have never tried it myself, but I think it should work. CCed Michael Brown to check. Yes, iPXE for UEFI exists and works. Last tested by me about a week ago, on various IBM UEFI systems. Compared to a legacy BIOS network boot, you can't do anything very interesting with UEFI. Features such as iSCSI, FCoE, AoE, HTTP all work with a legacy BIOS but not with UEFI. A legacy BIOS network boot allows you to boot an operating system; a UEFI network boot only allows you to boot an EFI executable (which could be a second-stage OS loader). UEFI as a platform has a long way to go before it matches the network boot functionality available through iPXE in a legacy BIOS. Michael
Re: [Qemu-devel] [PATCH v3 2/2] hw/vexpress.c: Add model of ARM Versatile Express board
On 21 March 2011 20:41, Aurelien Jarno aurel...@aurel32.net wrote:
On Mon, Mar 07, 2011 at 11:10:32AM +, Peter Maydell wrote:
+ /* 0x4e00 LAN9118 Ethernet */
+ if (nd_table[0].vlan) {
+ lan9118_init(nd_table[0], 0x4e00, pic[15]);
+ }
It basically means we silently ignore all other network cards the user
asked. Shouldn't we but a warning/error in that case?
Well, if you ask for one network card that's the wrong kind
you get an error:
qemu-system-arm: qemu: Unsupported NIC model: ne2k_pci
but you're right that if you ask for several cards we ignore
the other ones.
I just copied this code pattern from hw/integratorcp.c ; if you
want to suggest a better code fragment I'm happy to revise
the patch.
(hw/versatilepb.c is even worse, if I'm reading the code right
it creates rtl8139 cards regardless of what model you ask for...)
Conceptually, though, it seems to me that the right place to
put the user specified a network card/a USB device/whatever
but nothing in the board model used it checks is in the
generic code. Otherwise even boards with no network support
at all need to have boilerplate reject any network card
specification code, for instance, all boards without USB need
code to reject attempts to define USB devices, and so on...
For having the possibility to add more than one card, I guess it's
possible to simulated the PCI controller? Well if the board has any PCI
controller.
Sadly PCI is not supported by the A9MPx4 daughterboard.
Otherwise the patch looks fine to me, it's very nice being able to boot
an ARM board with more than 256MB of RAM.
PS: PBX-A9 also supports 1GB RAM :-) (but for different reasons
doesn't have PCI support and also the model is decidedly inaccurate).
-- PMM
Re: [Qemu-devel] OVMF, SeaBIOS non-CSM based legacy boot
On Mon, Mar 21, 2011 at 11:27, Anthony Liguori anth...@codemonkey.ws wrote: On 03/21/2011 01:14 PM, Jordan Justen wrote: This weekend I spent some time working on loading SeaBIOS from OVMF to start a legacy boot. I was able to get x86 x86-64 Linux to legacy boot using this method. Unfortunately, (I think) it is not nearly as nice a having a true CSM. Basically, you have to decide at some point in the OVMF boot that you want to legacy boot, and once you start SeaBIOS running, OVMF/UEFI Interesting. How much time does OVMF add to the total boot time when taking this approach? SeaBIOS has OVMF beat hands-down for boot time at this point. (For what it's worth, I have not focused on boot time for OVMF at all.) It is several seconds for OVMF, vs. lightning-fast for SeaBIOS. :) This approach is essentially OVMF booting for a bit, and then forking off to load SeaBIOS at some point. So, we could make it take very little extra time if we were able to determine very early in the OVMF boot that this is the boot type that we wanted. At this point, I'm not sure how it could be determined. Some ideas (none great): 1. Let the user press a hotkey such as 'u' for UEFI, and thus wait ~ 1 second for the key. (Yuck :) 2. Push UEFI variable support forward. During the first boot determine if a legacy boot is needed, and save a variable that can be accessed early on to trigger SeaBIOS loading very quickly for future boots. 3. Always boot mostly through the OVMF boot sequence, and if we don't see a GPT formatted disk or a UEFI bootable removable media, then run SeaBIOS. 4. Perhaps the VM can signal to the firmware which boot type to use... Is there gPXE for UEFI yet? I don't know too much about network boot for UEFI, but I know there is UEFI PXE support. I'm not familar with gPXE. Other than that, this probably matters most of with device passthrough. I think this is a limitation we could live with in the not-to-short term though. * Fail a legacy boot, and potentially return back to UEFI if it fails. (Not in all cases, if the failed boot alters the system state significantly) I think the most typical use-case here is -boot cd or -boot dc. From what I can tell, EFI support El Torito so it wouldn't be necessary to involve BIOS to handle booting from CDROMs. Is that correct? If there is any sort of legacy boot, then either we'd need to boot SeaBIOS or have CSM support. If it is a UEFI boot, then El Torito is used so a disk image is available with a UEFI boot loader present. There is one big difference here between how VM's generally specify the boot disk vs. a UEFI system. In a UEFI system, normally the boot path is not known during the first boot of the machine. At some point the boot path will be programmed into a non-volatile variable. Often this will be written by the OS installer. The point is, normally an 'outside mechanism' like '-boot ?' is not present. If the user wants to alter the boot order, they can by pressing a key during the firmware boot process. Also, -boot does map very well to UEFI in a lot of cases. For example, boot option 1 in a UEFI system may be something like /dev/sda1:/efi/boot/ubuntu.efi and option 2 could be /dev/sda1:/efi/boot/fedora.efi. Right now, OVMF doesn't support the qemu -boot parameter... So, would this be valuable (in the short term) to help move forward QEMU's usage of OVMF and add UEFI support? Or would QEMU require true CSM support? I think this certainly helps make the discussion more concrete. I don't see any show stoppers here. Ok, it sounds like it could be a useful path to consider, given the lack of a CSM. I'll continue to look at it some more... Thanks, -Jordan
Re: [Qemu-devel] OVMF, SeaBIOS non-CSM based legacy boot
On Mon, Mar 21, 2011 at 14:17, Michael Brown mbr...@fensystems.co.uk wrote: On Monday 21 Mar 2011 21:06:24 Stefan Hajnoczi wrote: On Mon, Mar 21, 2011 at 6:27 PM, Anthony Liguori anth...@codemonkey.ws Is there gPXE for UEFI yet? I have never tried it myself, but I think it should work. CCed Michael Brown to check. Yes, iPXE for UEFI exists and works. Last tested by me about a week ago, on various IBM UEFI systems. Compared to a legacy BIOS network boot, you can't do anything very interesting with UEFI. Features such as iSCSI, FCoE, AoE, HTTP all work with a legacy BIOS but not with UEFI. A legacy BIOS network boot allows you to boot an operating system; a UEFI network boot only allows you to boot an EFI executable (which could be a second-stage OS loader). Your input on network boot is much more valuable than mine. (I'm certainly no expert here...) But, for a UEFI system, loading a UEFI executable is equivalent to starting the OS. Whether that executable is a second stage loader, or contains the OS kernel, it up to the OS implementation. -Jordan
Re: [Qemu-devel] [PATCH] v9fs_walk: As per 9p2000 RFC, MAXWELEM = nwnames = 0.
On 3/21/2011 2:16 PM, Stefan Hajnoczi wrote:
On Mon, Mar 21, 2011 at 6:31 PM, Harsh Prateek Bora
ha...@linux.vnet.ibm.com wrote:
The nwnames field in TWALK message is assumed to be =0 and = MAXWELEM
which is defined as macro P9_MAXWELEM (16) in virtio-9p.h as per 9p2000 RFC.
Appropriate changes are required in V9fsWalkState and v9fs_walk.
Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com
---
hw/9pfs/virtio-9p.c |5 -
hw/9pfs/virtio-9p.h |2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 9b44bd0..b782a19 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1805,7 +1805,7 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
vs-offset += pdu_unmarshal(vs-pdu, vs-offset, ddw, fid,
newfid, vs-nwnames);
-if (vs-nwnames) {
+if (vs-nwnames = P9_MAXWELEM) {
vs-wnames = qemu_mallocz(sizeof(vs-wnames[0]) * vs-nwnames);
vs-qids = qemu_mallocz(sizeof(vs-qids[0]) * vs-nwnames);
@@ -1814,6 +1814,9 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
vs-offset += pdu_unmarshal(vs-pdu, vs-offset, s,
vs-wnames[i]);
}
+} else {
+err = -EINVAL;
vs-nwnames = 0; will take care of v9fs_walk_complete() issue Stefan brought
up.
+goto out;
}
v9fs_walk_complete() will attempt to free wnames, qids, and the wnames
strings. Freeing the strings will crash because we're indexing into
an array based off a NULL pointer.
It would be very handy to have a PDU-level test suite. You could then
construct a PDU with an invalid nwnames field and exercise this code
path. Perhaps a debug ioctl in Linux v9fs that allows a userspace
tool to pass PDUs through will do?
Ioctl way was ruled out in the past discussion. But yes we have in plan on to
introduce
a test suite of this kind. Malahal (who is on vacation) will start this work
from early April.
Thanks,
JV
Stefan
Re: [Qemu-devel] Moving beyond image files
On Mon, Mar 21, 2011 at 3:05 PM, Anthony Liguori aligu...@us.ibm.com wrote: 2) The daemon maintains metadata for each image that includes an extent mapping and then a clustered allocated bitmap within each extent (similar to FVD). s/clustered allocated bitmap/cluster allocation bitmap/ ? 3) All writes result in a sha1 being calculated before the write is completed. The daemon maintains a mapping of sha1's - clusters. A single sha1 may map to many clusters. The sha1 mapping can be made eventually consistent using a journal or even dirty bitmap. It can be partially rebuilt easily. Can you explain this in more detail? A write to a single sector of a cluster causes what to happen? Why is the hash calculated before acking the write and not queued in the background if the hash mapping is only eventually consistent? For v3: 1. Snapshots. 2. You can connect remote daemons for read-only master images. If an image is backed off a remote image, reads to unallocated clusters are sent to the remote. This also allows for a master image daemon to keep refcounts of how many instances are currently based of an image, and if they copy/stream that data they can drop instances and storage administrators know the master image is safe for deletion. Stefan
Re: [Qemu-devel] [PATCH] v9fs_walk: As per 9p2000 RFC, MAXWELEM = nwnames = 0.
On 3/21/2011 2:34 PM, Venkateswararao Jujjuri (JV) wrote:
On 3/21/2011 2:16 PM, Stefan Hajnoczi wrote:
On Mon, Mar 21, 2011 at 6:31 PM, Harsh Prateek Bora
ha...@linux.vnet.ibm.com wrote:
The nwnames field in TWALK message is assumed to be =0 and = MAXWELEM
which is defined as macro P9_MAXWELEM (16) in virtio-9p.h as per 9p2000 RFC.
Appropriate changes are required in V9fsWalkState and v9fs_walk.
Signed-off-by: Harsh Prateek Bora ha...@linux.vnet.ibm.com
---
hw/9pfs/virtio-9p.c |5 -
hw/9pfs/virtio-9p.h |2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 9b44bd0..b782a19 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -1805,7 +1805,7 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
vs-offset += pdu_unmarshal(vs-pdu, vs-offset, ddw, fid,
newfid, vs-nwnames);
-if (vs-nwnames) {
+if (vs-nwnames = P9_MAXWELEM) {
vs-wnames = qemu_mallocz(sizeof(vs-wnames[0]) * vs-nwnames);
vs-qids = qemu_mallocz(sizeof(vs-qids[0]) * vs-nwnames);
@@ -1814,6 +1814,9 @@ static void v9fs_walk(V9fsState *s, V9fsPDU *pdu)
vs-offset += pdu_unmarshal(vs-pdu, vs-offset, s,
vs-wnames[i]);
}
+} else {
+err = -EINVAL;
vs-nwnames = 0; will take care of v9fs_walk_complete() issue Stefan brought
up.
+goto out;
Or you can have same check if (vs-nwnames = P9_MAXWELEM) { in the
v9fs_walk_complete() too; basically you need to be consistant with the checking.
- JV
}
v9fs_walk_complete() will attempt to free wnames, qids, and the wnames
strings. Freeing the strings will crash because we're indexing into
an array based off a NULL pointer.
It would be very handy to have a PDU-level test suite. You could then
construct a PDU with an invalid nwnames field and exercise this code
path. Perhaps a debug ioctl in Linux v9fs that allows a userspace
tool to pass PDUs through will do?
Ioctl way was ruled out in the past discussion. But yes we have in plan on to
introduce
a test suite of this kind. Malahal (who is on vacation) will start this work
from early April.
Thanks,
JV
Stefan
Re: [Qemu-devel] OVMF, SeaBIOS non-CSM based legacy boot
On Mon, Mar 21, 2011 at 9:17 PM, Michael Brown mbr...@fensystems.co.uk wrote: On Monday 21 Mar 2011 21:06:24 Stefan Hajnoczi wrote: On Mon, Mar 21, 2011 at 6:27 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 03/21/2011 01:14 PM, Jordan Justen wrote: This weekend I spent some time working on loading SeaBIOS from OVMF to start a legacy boot. I was able to get x86 x86-64 Linux to legacy boot using this method. Unfortunately, (I think) it is not nearly as nice a having a true CSM. Basically, you have to decide at some point in the OVMF boot that you want to legacy boot, and once you start SeaBIOS running, OVMF/UEFI Interesting. How much time does OVMF add to the total boot time when taking this approach? will never be in the picture again (until system reset). Contrast this to using a CSM where you can: * Load a legacy option ROM (vbios, or disk rom), and use it during a UEFI boot Is there gPXE for UEFI yet? I have never tried it myself, but I think it should work. CCed Michael Brown to check. Yes, iPXE for UEFI exists and works. Last tested by me about a week ago, on various IBM UEFI systems. Compared to a legacy BIOS network boot, you can't do anything very interesting with UEFI. Features such as iSCSI, FCoE, AoE, HTTP all work with a legacy BIOS but not with UEFI. A legacy BIOS network boot allows you to boot an operating system; a UEFI network boot only allows you to boot an EFI executable (which could be a second-stage OS loader). Would it be possible to enable the more interesting things by registering as a network device or block device with UEFI? I don't know much about UEFI but I seem to remember that you can do that rather than being a pure bootloader that loads an EFI executable? Stefan
[Qemu-devel] Re: CPU type qemu64 breaks guest code
On 03/14/2011 03:13 PM, Alexander Graf wrote:
Hi guys,
While I was off on vacation a pretty nasty bug emerged. It's our old
friend the non-existent -cpu qemu64 CPU type. To refresh your memories,
this is the definition of the default 64-bit CPU type in Qemu:
{
.name = qemu64,
.level = 4,
.vendor1 = CPUID_VENDOR_AMD_1,
.vendor2 = CPUID_VENDOR_AMD_2,
.vendor3 = CPUID_VENDOR_AMD_3,
.family = 6,
.model = 2,
.stepping = 3,
...
Well, yes, this is strange, and a different CPU model mimicking some
really existing CPU would be better. But in my experience this opens up
a can of worms, since a different family will trigger a lot of other
nasty code that was silent before. Although I think that eventually we
will not get around it doing so, but we should use a lot of testing
before triggering tons of regressions.
What about the kvm64 CPU model? Back then I used quite some testing to
find a model which runs pretty well, so I came up with 15/6/1, which
seemed to be relatively sane. We could try copying this F/M/S over to
qemu64, I suppose with emulation the issues are easier to fix than in KVM.
Another idea I think I already posted some time ago was to make kvm64
the new default if KVM is enabled. This wouldn't solve the above issue
for TCG of course, but would make further development easier, since we
would have a better separation between KVM and TCG and could tweak each
independently.
Before I left, we already had weird build breakages where gcc simply
abort()ed when running inside of KVM. This breakage has been tracked
down to libgmp, which has this code
(http://gmplib.org:8000/gmp-5.0/file/1ebe39104437/mpn/x86_64/fat/fat.c):
if (strcmp (vendor_string, GenuineIntel) == 0)
{
}
else if (strcmp (vendor_string, AuthenticAMD) == 0)
{
switch (family)
{
case 5:
case 6:
abort ();
break;
case 15:
/* CPUVEC_SETUP_athlon */
break;
}
The reasoning behind it is that for AMD, all 64-bit CPUs were family
15.
I guess that should be fixed there, as it is obviously nonsense. I
haven't check what they actually need that family 6 does not provide, if
it is long mode, then this bit should be checked.
This breakage is obviously pretty bad for guests running qemu and
shows once again that deriving from real hardware is a bad idea. I guess
the best way to move forward is to change the CPU type to something that
actually exists in the real world - even if we have to strip off some
features.
I found that there is no valid combination for both Intel and AMD. We
had to go to family 15, and it seems that there is no F/M/S combination
that were both a valid K8 and a Pentium4 processor. The 15/6/1 mentioned
before was the closest match I could find.
Summarizing I would suggest:
1) Make kvm64 the new default model if KVM is used. Maybe we could tie
this to the qemu-0.15 machine type.
2) Test as many OSes as possible whether they show strange behavior.
In my experience we could catch most of the stuff with just booting
the system, with Linux -kernel vmlinuz suffices (without a rootfs).
3) If we are happy with that, tweak the qemu64 model to those values,
too.
4) Write some note somewhere to let users know what they could do to
fix problems that rise due to the new model.
I can easily send patches and will try to contribute to testing, if that
plan sounds OK.
--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Re: [Qemu-devel] eepro100 and qemu0.14: unknown word write
2011/3/21 Sébastien BRICE s...@so-sweet.org: Hi everyone I have been using qemu-kvm with success the last two years and its really amazing. I am new to this mailing list and i am requesting your assistance because i struggle to have my virtual card working with an 'exotic' virtual System seb@debian:~/qemu-kvm-0.14.0$ kvm -net nic,model=i82557b /media/prologue.img Whatever i try the guest system never initializes the Intel 100 Pro NIC Card as it is supposed to do And thats almost working with eep100.c source and -net nic,model=i82557b option But each time the qemu hangs with: eepro100: feature is missing in this emulation: unknown word write ... default: logout(addr=%s val=0x%04x\n, regname(addr), val); missing(unknown word write); } } Can you set DEBUG_EEPRO100 in the source file, rebuild and let us know what extra debug output you get? Just change the #if 0 around the define near the top of the file to #if 1. Alex
[Qemu-devel] [PATCH v22 01/11] trace: move trace objects from Makefile to Makefile.objs
--- Makefile | 32 Makefile.objs | 32 2 files changed, 32 insertions(+), 32 deletions(-) diff --git a/Makefile b/Makefile index 89e88b4..209e14d 100644 --- a/Makefile +++ b/Makefile @@ -112,38 +112,6 @@ ui/vnc.o: QEMU_CFLAGS += $(VNC_TLS_CFLAGS) bt-host.o: QEMU_CFLAGS += $(BLUEZ_CFLAGS) -ifeq ($(TRACE_BACKEND),dtrace) -trace.h: trace.h-timestamp trace-dtrace.h -else -trace.h: trace.h-timestamp -endif -trace.h-timestamp: $(SRC_PATH)/trace-events config-host.mak - $(call quiet-command,sh $(SRC_PATH)/scripts/tracetool --$(TRACE_BACKEND) -h $ $@, GEN trace.h) - @cmp -s $@ trace.h || cp $@ trace.h - -trace.c: trace.c-timestamp -trace.c-timestamp: $(SRC_PATH)/trace-events config-host.mak - $(call quiet-command,sh $(SRC_PATH)/scripts/tracetool --$(TRACE_BACKEND) -c $ $@, GEN trace.c) - @cmp -s $@ trace.c || cp $@ trace.c - -trace.o: trace.c $(GENERATED_HEADERS) - -trace-dtrace.h: trace-dtrace.dtrace - $(call quiet-command,dtrace -o $@ -h -s $, GEN trace-dtrace.h) - -# Normal practice is to name DTrace probe file with a '.d' extension -# but that gets picked up by QEMU's Makefile as an external dependancy -# rule file. So we use '.dtrace' instead -trace-dtrace.dtrace: trace-dtrace.dtrace-timestamp -trace-dtrace.dtrace-timestamp: $(SRC_PATH)/trace-events config-host.mak - $(call quiet-command,sh $(SRC_PATH)/scripts/tracetool --$(TRACE_BACKEND) -d $ $@, GEN trace-dtrace.dtrace) - @cmp -s $@ trace-dtrace.dtrace || cp $@ trace-dtrace.dtrace - -trace-dtrace.o: trace-dtrace.dtrace $(GENERATED_HEADERS) - $(call quiet-command,dtrace -o $@ -G -s $, GEN trace-dtrace.o) - -simpletrace.o: simpletrace.c $(GENERATED_HEADERS) - version.o: $(SRC_PATH)/version.rc config-host.mak $(call quiet-command,$(WINDRES) -I. -o $@ $, RC$(TARGET_DIR)$@) diff --git a/Makefile.objs b/Makefile.objs index a52f42f..be4c4d9 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -309,6 +309,38 @@ libdis-$(CONFIG_SPARC_DIS) += sparc-dis.o # trace ifeq ($(TRACE_BACKEND),dtrace) +trace.h: trace.h-timestamp trace-dtrace.h +else +trace.h: trace.h-timestamp +endif +trace.h-timestamp: $(SRC_PATH)/trace-events config-host.mak + $(call quiet-command,sh $(SRC_PATH)/scripts/tracetool --$(TRACE_BACKEND) -h $ $@, GEN trace.h) + @cmp -s $@ trace.h || cp $@ trace.h + +trace.c: trace.c-timestamp +trace.c-timestamp: $(SRC_PATH)/trace-events config-host.mak + $(call quiet-command,sh $(SRC_PATH)/scripts/tracetool --$(TRACE_BACKEND) -c $ $@, GEN trace.c) + @cmp -s $@ trace.c || cp $@ trace.c + +trace.o: trace.c $(GENERATED_HEADERS) + +trace-dtrace.h: trace-dtrace.dtrace + $(call quiet-command,dtrace -o $@ -h -s $, GEN trace-dtrace.h) + +# Normal practice is to name DTrace probe file with a '.d' extension +# but that gets picked up by QEMU's Makefile as an external dependancy +# rule file. So we use '.dtrace' instead +trace-dtrace.dtrace: trace-dtrace.dtrace-timestamp +trace-dtrace.dtrace-timestamp: $(SRC_PATH)/trace-events config-host.mak + $(call quiet-command,sh $(SRC_PATH)/scripts/tracetool --$(TRACE_BACKEND) -d $ $@, GEN trace-dtrace.dtrace) + @cmp -s $@ trace-dtrace.dtrace || cp $@ trace-dtrace.dtrace + +trace-dtrace.o: trace-dtrace.dtrace $(GENERATED_HEADERS) + $(call quiet-command,dtrace -o $@ -G -s $, GEN trace-dtrace.o) + +simpletrace.o: simpletrace.c $(GENERATED_HEADERS) + +ifeq ($(TRACE_BACKEND),dtrace) trace-obj-y = trace-dtrace.o else trace-obj-y = trace.o -- 1.7.4.1
[Qemu-devel] [PATCH v22 02/11] qemu-thread.h: include inttypes.h
qemu-thread.h relies on uint64_t being defined, but doesn't include inttypes.h explicitly. This makes it easier to use it from vscclient (part of libcacard). --- qemu-thread.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/qemu-thread.h b/qemu-thread.h index edc7ab6..0a73d50 100644 --- a/qemu-thread.h +++ b/qemu-thread.h @@ -1,6 +1,8 @@ #ifndef __QEMU_THREAD_H #define __QEMU_THREAD_H 1 +#include inttypes.h + typedef struct QemuMutex QemuMutex; typedef struct QemuCond QemuCond; typedef struct QemuThread QemuThread; -- 1.7.4.1
[Qemu-devel] [PATCH v22 00/11] usb-ccid
This patchset adds three new devices, usb-ccid, ccid-card-passthru and
ccid-card-emulated, providing a CCID bus, a simple passthru protocol
implementing card requiring a client, and a standalone emulated card.
It also introduces a new directory libcaccard with CAC card emulation,
CAC is a type of ISO 7816 smart card.
Tree for pull: git://anongit.freedesktop.org/~alon/qemu usb_ccid.v20
v21-v22 changes:
* libcacard:
* fix configure to not link libcacard if nss not found
(reported by Stefan Hajnoczi)
* fix vscclient linkage with simpletrace backend
(reported by Stefan Hajnoczi)
* card_7816.c: add missing break in ERROR_DATA_NOT_FOUND
(reported by William van de Velde)
v20-v21 changes:
* all: cosmetics
* libcacard, ccid-card-passthru:
* use qemu-{malloc,free} and qemu-thread, error_report
* libcacard:
* split to multiple patches
v19-v20 changes:
* checkpatch.pl. Here are the remaining errors with explanation:
* ignored 5 macro errors of the type
ERROR: Macros with complex values should be enclosed in parenthesis
because fixing them breaks current code, if it really bothers someone
I can fix it.
* four of them are in libcacard/card_7816t.h:
/* give the subfields a unified look */
..
#define a_cla a_header-ah_cla /* class */
#define a_ins a_header-ah_ins /* instruction */
#define a_p1 a_header-ah_p1 /* parameter 1 */
#define a_p2 a_header-ah_p2 /* parameter 2 */
* and the fifth:
#4946: FILE: libcacard/vcardt.h:31:
+#define VCARD_ATR_PREFIX(size) 0x3b, 0x66+(size), 0x00, 0xff, \
+ 'V', 'C', 'A', 'R', 'D', '_'
* Ignored this warning since I couldn't figure it out, and it's a test
file:
WARNING: externs should be avoided in .c files
#2343: FILE: libcacard/link_test.c:7:
+VCardStatus cac_card_init(const char *flags, VCard *card,
v18-v19 changes:
* more merges, down to a single digit number of patches.
* drop enumeration property, use string.
* rebased (trivial)
v17-v18 changes:
* merge vscard_common.h patches.
* actually provide a tree to pull.
v16-v17 changes:
* merged all the v15-v16 patches
* merged some more wherever it was easy (all same file commits).
* added signed off by to first four patches
* ccid.h: added copyright, removed underscore in defines, and replaced
non C89 comments
v15-v16 changes:
* split vscard_common introducing patch for ease of review
* sum of commit logs for the v15-v16 commits: (whitespace fixes
removed for space, see original commit messages in later patches)
* usb-ccid:
* fix abort on client answer after card remove
* enable migration
* remove side affect code from asserts
* return consistent self-powered state
* mask out reserved bits in ccid_set_parameters
* add missing abRFU in SetParameters (no affect on linux guest)
* vscard_common.h protocol change:
* VSCMsgInit capabilities and magic
* removed ReaderResponse, will use Error instead with code==VSC_SUCCESS.
* added Flush and FlushComplete, remove Reconnect.
* define VSCARD_MAGIC
* added error code VSC_SUCCESS.
* ccid-card-passthru
* return correct size
* return error instead of assert if client sent too large ATR
* don't assert if client sent too large a size, but add asserts for indices
to buffer
* reset vscard_in indices on chardev disconnect
* handle init from client
* error if no chardev supplied
* use ntoh, hton
* eradicate reader_id_t
* remove Reconnect usage (removed from VSCARD protocol)
* send VSC_SUCCESS on card insert/remove and reader add/remove
* ccid-card-emulated
* fix error reporting in initfn
v14-v15 changes:
* add patch with --enable-smartcard and --disable-smartcard and only
disable ccid-card-emulated if nss not found.
* add patch with description strings
* s/libcaccard/libcacard/ in docs/ccid.txt
v13-v14 changes:
- support device_del/device_add on ccid-card-* and usb-ccid
* usb-ccid:
* lose card reference when card device deleted
* check slot number and deny adding a slot if one is already added.
* ccid-card-*: use qdev_simple_unplug_cb in both emulated and passthru ccid
cards,
the exitfn already takes care of triggering card removal in the usb dev.
* libcacard:
* remove double include of config-host.mak
* add replay of card events to libcacard to support second and more emulation
* don't initialize more then once (doesn't support it right now, so one
thread, NSS thread, is left when device_del is done)
* add VCARD_EMUL_INIT_ALREADY_INITED
* ccid-card-emulated:
* take correct mutexes on signaling to fix deadlocks on device_del
* allow card insertion/removal event without proper reader insertion event
v12-v13 changes:
* libcacard:
* fix Makefile clean to remove vscclient
* fix double include of config-host in Makefile
* usb-ccid: remove attach/detach logic, usb is always attached. Guest
doesn't care if there is a reader attached with no card anyway.
* ccid-card-passthru: don't
[Qemu-devel] [PATCH v22 09/11] libcacard: add docs
From: Robert Relyea rrel...@redhat.com --- docs/libcacard.txt | 483 1 files changed, 483 insertions(+), 0 deletions(-) create mode 100644 docs/libcacard.txt diff --git a/docs/libcacard.txt b/docs/libcacard.txt new file mode 100644 index 000..5dee6fa --- /dev/null +++ b/docs/libcacard.txt @@ -0,0 +1,483 @@ +This file documents the CAC (Common Access Card) library in the libcacard +subdirectory. + +Virtual Smart Card Emulator + +This emulator is designed to provide emulation of actual smart cards to a +virtual card reader running in a guest virtual machine. The emulated smart +cards can be representations of real smart cards, where the necessary functions +such as signing, card removal/insertion, etc. are mapped to real, physical +cards which are shared with the client machine the emulator is running on, or +the cards could be pure software constructs. + +The emulator is structured to allow multiple replacable or additional pieces, +so it can be easily modified for future requirements. The primary envisioned +modifications are: + +1) The socket connection to the virtual card reader (presumably a CCID reader, +but other ISO-7816 compatible readers could be used). The code that handles +this is in vscclient.c. + +2) The virtual card low level emulation. This is currently supplied by using +NSS. This emulation could be replaced by implementations based on other +security libraries, including but not limitted to openssl+pkcs#11 library, +raw pkcs#11, Microsoft CAPI, direct opensc calls, etc. The code that handles +this is in vcard_emul_nss.c. + +3) Emulation for new types of cards. The current implementation emulates the +original DoD CAC standard with separate pki containers. This emulator lives in +cac.c. More than one card type emulator could be included. Other cards could +be emulated as well, including PIV, newer versions of CAC, PKCS #15, etc. + + +Replacing the Socket Based Virtual Reader Interface. + +The current implementation contains a replacable module vscclient.c. The +current vscclient.c implements a sockets interface to the virtual ccid reader +on the guest. CCID commands that are pertinent to emulation are passed +across the socket, and their responses are passed back along that same socket. +The protocol that vscclient uses is defined in vscard_common.h and connects +to a qemu ccid usb device. Since this socket runs as a client, vscclient.c +implements a program with a main entry. It also handles argument parsing for +the emulator. + +An application that wants to use the virtual reader can replace vscclient.c +with it's own implementation that connects to it's own CCID reader. The calls +that the CCID reader can call are: + + VReaderList * vreader_get_reader_list(); + + This function returns a list of virtual readers. These readers may map to + physical devices, or simulated devices depending on vcard the back end. Each + reader in the list should represent a reader to the virtual machine. Virtual + USB address mapping is left to the CCID reader front end. This call can be + made any time to get an updated list. The returned list is a copy of the + internal list that can be referenced by the caller without locking. This copy + must be freed by the caller with vreader_list_delete when it is no longer + needed. + + VReaderListEntry *vreader_list_get_first(VReaderList *); + + This function gets the first entry on the reader list. Along with + vreader_list_get_next(), vreader_list_get_first() can be used to walk the + reader list returned from vreader_get_reader_list(). VReaderListEntries are + part of the list themselves and do not need to be freed separately from the + list. If there are no entries on the list, it will return NULL. + + VReaderListEntry *vreader_list_get_next(VReaderListEntry *); + + This function gets the next entry in the list. If there are no more entries + it will return NULL. + + VReader * vreader_list_get_reader(VReaderListEntry *) + + This function returns the reader stored in the reader List entry. Caller gets + a new reference to a reader. The caller must free it's reference when it is + finished with vreader_free(). + + void vreader_free(VReader *reader); + + This function frees a reference to a reader. Reader's are reference counted + and are automatically deleted when the last reference is freed. + + void vreader_list_delete(VReaderList *list); + + This function frees the list, all the elements on the list, and all the + reader references held by the list. + + VReaderStatus vreader_power_on(VReader *reader, char *atr, int *len); + + This functions simulates a card power on. Virtual cards do not care about + the actual voltage and other physical parameters, but it does care that the + card is actually on or off. Cycling the card causes the card to reset. If + the caller provides enough space, vreader_power_on will return
[Qemu-devel] [PATCH v22 04/11] introduce libcacard/vscard_common.h
---
Signed-off-by: Alon Levy al...@redhat.com
v20-v21 changes: (Jes Sorenson review)
* license set to 2+
* long comment fixes, remove empty line at eof.
* add reference to COPYING
v19-v20 changes:
* checkpatch.pl
v15-v16 changes:
Protocol change:
* VSCMsgInit capabilities and magic
* removed ReaderResponse, will use Error instead with code==VSC_SUCCESS.
* adaded Flush and FlushComplete, remove Reconnect.
* define VSCARD_MAGIC
* added error code VSC_SUCCESS.
Fixes:
* update VSCMsgInit comment
* fix message type enum
* remove underscore from wrapping define
* update copyright
* updated comments.
* Header comment updated
* remove C++ style comment
* fix comment for VSCMsgError
* give names to enums in typedefs
---
libcacard/vscard_common.h | 178 +
1 files changed, 178 insertions(+), 0 deletions(-)
create mode 100644 libcacard/vscard_common.h
diff --git a/libcacard/vscard_common.h b/libcacard/vscard_common.h
new file mode 100644
index 000..bebd52d
--- /dev/null
+++ b/libcacard/vscard_common.h
@@ -0,0 +1,178 @@
+/* Virtual Smart Card protocol definition
+ *
+ * This protocol is between a host using virtual smart card readers,
+ * and a client providing the smart cards, perhaps by emulating them or by
+ * access to real cards.
+ *
+ * Definitions for this protocol:
+ * Host - user of the card
+ * Client - owner of the card
+ *
+ * The current implementation passes the raw APDU's from 7816 and additionally
+ * contains messages to setup and teardown readers, handle insertion and
+ * removal of cards, negotiate the protocol via capabilities and provide
+ * for error responses.
+ *
+ * Copyright (c) 2011 Red Hat.
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ */
+
+#ifndef VSCARD_COMMON_H
+#define VSCARD_COMMON_H
+
+#include stdint.h
+
+#define VERSION_MAJOR_BITS 11
+#define VERSION_MIDDLE_BITS 11
+#define VERSION_MINOR_BITS 10
+
+#define MAKE_VERSION(major, middle, minor) \
+ ((major (VERSION_MINOR_BITS + VERSION_MIDDLE_BITS)) \
+ | (middle VERSION_MINOR_BITS) \
+ | (minor))
+
+/*
+ * IMPORTANT NOTE on VERSION
+ *
+ * The version below MUST be changed whenever a change in this file is made.
+ *
+ * The last digit, the minor, is for bug fix changes only.
+ *
+ * The middle digit is for backward / forward compatible changes, updates
+ * to the existing messages, addition of fields.
+ *
+ * The major digit is for a breaking change of protocol, presumably
+ * something that cannot be accomodated with the existing protocol.
+ */
+
+#define VSCARD_VERSION MAKE_VERSION(0, 0, 2)
+
+typedef enum VSCMsgType {
+VSC_Init = 1,
+VSC_Error,
+VSC_ReaderAdd,
+VSC_ReaderRemove,
+VSC_ATR,
+VSC_CardRemove,
+VSC_APDU,
+VSC_Flush,
+VSC_FlushComplete
+} VSCMsgType;
+
+typedef enum VSCErrorCode {
+VSC_SUCCESS = 0,
+VSC_GENERAL_ERROR = 1,
+VSC_CANNOT_ADD_MORE_READERS,
+VSC_CARD_ALREAY_INSERTED,
+} VSCErrorCode;
+
+#define VSCARD_UNDEFINED_READER_ID 0x
+#define VSCARD_MINIMAL_READER_ID0
+
+#define VSCARD_MAGIC (*(uint32_t *)VSCD)
+
+/*
+ * Header
+ * Each message starts with the header.
+ * type - message type
+ * reader_id - used by messages that are reader specific
+ * length - length of payload (not including header, i.e. zero for
+ * messages containing empty payloads)
+ */
+typedef struct VSCMsgHeader {
+uint32_t type;
+uint32_t reader_id;
+uint32_t length;
+uint8_tdata[0];
+} VSCMsgHeader;
+
+/*
+ * VSCMsgInit Client - Host
+ * Client sends it on connection, with its own capabilities.
+ * Host replies with VSCMsgInit filling in its capabilities.
+ *
+ * It is not meant to be used for negotiation, i.e. sending more then
+ * once from any side, but could be used for that in the future.
+ */
+typedef struct VSCMsgInit {
+uint32_t magic;
+uint32_t version;
+uint32_t capabilities[1]; /* receiver must check length,
+ array may grow in the future*/
+} VSCMsgInit;
+
+/*
+ * VSCMsgError Client - Host
+ * This message is a response to any of:
+ * Reader Add
+ * Reader Remove
+ * Card Remove
+ * If the operation was successful then VSC_SUCCESS
+ * is returned, other wise a specific error code.
+ */
+typedef struct VSCMsgError {
+uint32_t code;
+} VSCMsgError;
+
+/*
+ * VSCMsgReaderAdd Client - Host
+ * Host replies with allocated reader id in VSCMsgError with code==SUCCESS.
+ *
+ * name - name of the reader on client side, UTF-8 encoded. Only used
+ * for client presentation (may be translated to the device presented to the
+ * guest), protocol wise only reader_id is important.
+ */
+typedef struct VSCMsgReaderAdd {
+uint8_tname[0];
+} VSCMsgReaderAdd;
+
+/*
+ * VSCMsgReaderRemove Client - Host
+ * The client's reader has been removed.
+ */
+typedef
[Qemu-devel] [PATCH v22 03/11] usb-ccid: add CCID bus
A CCID device is a smart card reader. It is a USB device, defined at [1].
This patch introduces the usb-ccid device that is a ccid bus. Next patches will
introduce two card types to use it, a passthru card and an emulated card.
[1] http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.
Signed-off-by: Alon Levy al...@redhat.com
---
changes from v20-v21: (Jes Sorenson review)
* cosmetic changes - fix multi line comments.
* reorder fields in USBCCIDState
* add reference to COPYING
* add --enable-smartcard and --disable-smartcard here (moved
from last patch)
changes from v19-v20:
* checkpatch.pl
changes from v18-v19:
* merged: ccid.h: add copyright, fix define and remove non C89 comments
* add qdev.desc
changes from v15-v16:
Behavioral changes:
* fix abort on client answer after card remove
* enable migration
* remove side affect code from asserts
* return consistent self-powered state
* mask out reserved bits in ccid_set_parameters
* add missing abRFU in SetParameters (no affect on linux guest)
whitefixes / comments / consts defines:
* remove stale comment
* remove ccid_print_pending_answers if no DEBUG_CCID
* replace printf's with DPRINTF, remove DEBUG_CCID, add verbosity defines
* use error_report
* update copyright (most of the code is not original)
* reword known bug comment
* add missing closing quote in comment
* add missing whitespace on one line
* s/CCID_SetParameter/CCID_SetParameters/
* add comments
* use define for max packet size
Comment for return consistent self-powered state:
the Configuration Descriptor bmAttributes claims we are self powered,
but we were returning not self powered to USB_REQ_GET_STATUS control message.
In practice, this message is not sent by a linux 2.6.35.10-74.fc14.x86_64
guest (not tested on other guests), unless you issue lsusb -v as root (for
example).
---
Makefile.objs |1 +
configure | 11 +
hw/ccid.h | 59 +++
hw/usb-ccid.c | 1419 +
4 files changed, 1490 insertions(+), 0 deletions(-)
create mode 100644 hw/ccid.h
create mode 100644 hw/usb-ccid.c
diff --git a/Makefile.objs b/Makefile.objs
index be4c4d9..6c5cfb6 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -199,6 +199,7 @@ hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o
hw-obj-$(CONFIG_DMA) += dma.o
hw-obj-$(CONFIG_HPET) += hpet.o
hw-obj-$(CONFIG_APPLESMC) += applesmc.o
+hw-obj-$(CONFIG_SMARTCARD) += usb-ccid.o
# PPC devices
hw-obj-$(CONFIG_OPENPIC) += openpic.o
diff --git a/configure b/configure
index a166de0..3b0174e 100755
--- a/configure
+++ b/configure
@@ -174,6 +174,7 @@ trace_backend=nop
trace_file=trace
spice=
rbd=
+smartcard=
# parse CC options first
for opt do
@@ -719,6 +720,10 @@ for opt do
;;
--enable-rbd) rbd=yes
;;
+ --disable-smartcard) smartcard=no
+ ;;
+ --enable-smartcard) smartcard=yes
+ ;;
*) echo ERROR: unknown option $opt; show_help=yes
;;
esac
@@ -914,6 +919,8 @@ echoDefault:trace-pid
echo --disable-spice disable spice
echo --enable-spice enable spice
echo --enable-rbd enable building the rados block device (rbd)
+echo --disable-smartcard disable smartcard support
+echo --enable-smartcard enable smartcard support
echo
echo NOTE: The object files are built at the place where configure is
launched
exit 1
@@ -2809,6 +2816,10 @@ if test $spice = yes ; then
echo CONFIG_SPICE=y $config_host_mak
fi
+if test $smartcard = yes ; then
+ echo CONFIG_SMARTCARD=y $config_host_mak
+fi
+
# XXX: suppress that
if [ $bsd = yes ] ; then
echo CONFIG_BSD=y $config_host_mak
diff --git a/hw/ccid.h b/hw/ccid.h
new file mode 100644
index 000..dbfc13c
--- /dev/null
+++ b/hw/ccid.h
@@ -0,0 +1,59 @@
+/*
+ * CCID Passthru Card Device emulation
+ *
+ * Copyright (c) 2011 Red Hat.
+ * Written by Alon Levy.
+ *
+ * This code is licenced under the GNU LGPL, version 2 or later.
+ */
+
+#ifndef CCID_H
+#define CCID_H
+
+#include qdev.h
+
+typedef struct CCIDCardState CCIDCardState;
+typedef struct CCIDCardInfo CCIDCardInfo;
+
+/*
+ * state of the CCID Card device (i.e. hw/ccid-card-*.c)
+ */
+struct CCIDCardState {
+DeviceState qdev;
+uint32_tslot; /* For future use with multiple slot reader. */
+};
+
+/*
+ * callbacks to be used by the CCID device (hw/usb-ccid.c) to call
+ * into the smartcard device (hw/ccid-card-*.c)
+ */
+struct CCIDCardInfo {
+DeviceInfo qdev;
+void (*print)(Monitor *mon, CCIDCardState *card, int indent);
+const uint8_t *(*get_atr)(CCIDCardState *card, uint32_t *len);
+void (*apdu_from_guest)(CCIDCardState *card,
+const uint8_t *apdu,
+uint32_t len);
+int (*exitfn)(CCIDCardState *card);
+int (*initfn)(CCIDCardState *card);
+};
+
+/*
+ * API for smartcard calling the CCID device (used by hw/ccid-card-*.c)
+ */
+void
[Qemu-devel] [PATCH v22 11/11] ccid: add docs
Add documentation for the usb-ccid device and accompanying two card devices, ccid-card-emulated and ccid-card-passthru. Signed-off-by: Alon Levy al...@redhat.com --- docs/ccid.txt | 135 + 1 files changed, 135 insertions(+), 0 deletions(-) create mode 100644 docs/ccid.txt diff --git a/docs/ccid.txt b/docs/ccid.txt new file mode 100644 index 000..b8e504a --- /dev/null +++ b/docs/ccid.txt @@ -0,0 +1,135 @@ +Qemu CCID Device Documentation. + +Contents +1. USB CCID device +2. Building +3. Using ccid-card-emulated with hardware +4. Using ccid-card-emulated with certificates +5. Using ccid-card-passthru with client side hardware +6. Using ccid-card-passthru with client side certificates +7. Passthrough protocol scenario +8. libcacard + +1. USB CCID device + +The USB CCID device is a USB device implementing the CCID specification, which +lets one connect smart card readers that implement the same spec. For more +information see the specification: + + Universal Serial Bus + Device Class: Smart Card + CCID + Specification for + Integrated Circuit(s) Cards Interface Devices + Revision 1.1 + April 22rd, 2005 + +Smartcard are used for authentication, single sign on, decryption in +public/private schemes and digital signatures. A smartcard reader on the client +cannot be used on a guest with simple usb passthrough since it will then not be +available on the client, possibly locking the computer when it is removed. On +the other hand this device can let you use the smartcard on both the client and +the guest machine. It is also possible to have a completely virtual smart card +reader and smart card (i.e. not backed by a physical device) using this device. + +2. Building + +The cryptographic functions and access to the physical card is done via NSS. + +Installing NSS: + +In redhat/fedora: +yum install nss-devel +In ubuntu/debian: +apt-get install libnss3-dev +(not tested on ubuntu) + +Configuring and building: +./configure --enable-smartcard make + +3. Using ccid-card-emulated with hardware + +Assuming you have a working smartcard on the host with the current +user, using NSS, qemu acts as another NSS client using ccid-card-emulated: + +qemu -usb -device usb-ccid -device ccid-card-emualated + +4. Using ccid-card-emulated with certificates + +You must create the certificates. This is a one time process. We use NSS +certificates: + +certutil -d /etc/pki/nssdb -x -t CT,CT,CT -S -s CN=cert1 -n cert1 + +Note: you must have exactly three certificates. + +Assuming the current user can access the certificates (use certutil -L to +verify), you can use the emulated card type with the certificates backend: + +qemu -usb -device usb-ccid -device ccid-card-emulated,backend=certificates,cert1=cert1,cert2=cert2,cert3=cert3 + +5. Using ccid-card-passthru with client side hardware + +on the host specify the ccid-card-passthru device with a suitable chardev: + +qemu -chardev socket,server,host=0.0.0.0,port=2001,id=ccid,nowait -usb -device usb-ccid -device ccid-card-passthru,chardev=ccid + +on the client run vscclient, built when you built the libcacard library: +libcacard/vscclient qemu-host 2001 + +6. Using ccid-card-passthru with client side certificates + +Run qemu as per #5, and run vscclient as follows: +(Note: vscclient command line interface is in a state of change) + +libcacard/vscclient -e db=\/etc/pki/nssdb\ use_hw=no soft=(,Test,CAC,,cert1,cert2,cert3) qemu-host 2001 + +7. Passthrough protocol scenario + +This is a typical interchange of messages when using the passthru card device. +usb-ccid is a usb device. It defaults to an unattached usb device on startup. +usb-ccid expects a chardev and expects the protocol defined in +cac_card/vscard_common.h to be passed over that. +The usb-ccid device can be in one of three modes: + * detached + * attached with no card + * attached with card + +A typical interchange is: (the arrow shows who started each exchange, it can be client +originated or guest originated) + +client event | vscclient |passthru| usb-ccid | guest event +-- + | VSC_Init|| | + | VSC_ReaderAdd || attach| + | || | sees new usb device. +card inserted - | || | + | VSC_ATR | insert | insert | see new card + | || | + | VSC_APDU| VSC_APDU | | - guest sends APDU +client-physical | || | +card APDU exchange|
[Qemu-devel] [PATCH v22 08/11] libcacard: add passthru
From: Robert Relyea rrel...@redhat.com
In this mode libcacard doesn't emulate a card, but just passes apdu's
straight to the underlying card.
Not to be confused with ccid-card-passthru, which doesn't use libcacard
at all. So with this functionality in libcacard you can talk directly
to the host accessible card, for instance for provisioning or other
functions not available through the CAC interface. This can also be
used from a remote client for the same purpose.
---
Makefile.objs |2 +-
libcacard/passthru.c| 609 +++
libcacard/passthru.h| 53
libcacard/vcard_emul_type.c |6 +
libcacard/vscclient.c | 22 ++-
5 files changed, 688 insertions(+), 4 deletions(-)
create mode 100644 libcacard/passthru.c
create mode 100644 libcacard/passthru.h
diff --git a/Makefile.objs b/Makefile.objs
index f703781..ed77dfd 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -354,7 +354,7 @@ endif
##
# smartcard
-libcacard-y = cac.o event.o vcard.o vreader.o vcard_emul_nss.o
vcard_emul_type.o card_7816.o
+libcacard-y = cac.o event.o passthru.o vcard.o vreader.o vcard_emul_nss.o
vcard_emul_type.o card_7816.o
vl.o: QEMU_CFLAGS+=$(GPROF_CFLAGS)
diff --git a/libcacard/passthru.c b/libcacard/passthru.c
new file mode 100644
index 000..d78e2db
--- /dev/null
+++ b/libcacard/passthru.c
@@ -0,0 +1,609 @@
+/*
+ * implement the applets for the CAC card.
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ */
+#ifdef USE_PASSTHRU
+#include stdlib.h
+#include string.h
+
+#include pcsclite.h
+
+#include qemu-thread.h
+
+#include vcard.h
+#include vcard_emul.h
+#include card_7816.h
+#include vreader.h
+#include vcard_emul.h
+#include passthru.h
+
+/*
+ * Passthru applet private data
+ */
+struct VCardAppletPrivateStruct {
+char *reader_name;
+/* pcsc-lite parameters */
+SCARDHANDLE hCard;
+uint32_t hProtocol;
+SCARD_IO_REQUEST *send_io;
+unsigned char atr[MAX_ATR_SIZE];
+int atr_len;
+};
+
+static SCARDCONTEXT global_context;
+
+#define MAX_RESPONSE_LENGTH 261 /*65537 */
+/*
+ * handle all the APDU's that are common to all CAC applets
+ */
+static VCardStatus
+passthru_process_apdu(VCard *card, VCardAPDU *apdu, VCardResponse **response)
+{
+LONG rv;
+unsigned char buf[MAX_RESPONSE_LENGTH];
+uint32_t len = MAX_RESPONSE_LENGTH;
+VCardAppletPrivate *applet_private = NULL;
+SCARD_IO_REQUEST receive_io;
+
+applet_private = vcard_get_current_applet_private(card, 0);
+if (applet_private == NULL) {
+*response = vcard_make_response(VCARD7816_STATUS_EXC_ERROR);
+return VCARD_DONE;
+}
+
+rv = SCardTransmit(applet_private-hCard, applet_private-send_io,
+ apdu-a_data, apdu-a_len, receive_io, buf, len);
+if (rv != SCARD_S_SUCCESS) {
+*response = vcard_make_response(VCARD7816_STATUS_EXC_ERROR);
+return VCARD_DONE;
+}
+
+*response = vcard_response_new_data(buf, len);
+if (*response == NULL) {
+*response =
+vcard_make_response(VCARD7816_STATUS_EXC_ERROR_MEMORY_FAILURE);
+} else {
+(*response)-b_total_len = (*response)-b_len;
+}
+return VCARD_DONE;
+}
+
+static void
+passthru_card_set_atr(VCard *card, unsigned char *atr, int atr_len)
+{
+VCardAppletPrivate *applet_private = NULL;
+applet_private = vcard_get_current_applet_private(card, 0);
+if (applet_private == NULL) {
+return;
+}
+applet_private-atr_len = MIN(atr_len, sizeof(applet_private-atr));
+memcpy(applet_private-atr, atr, applet_private-atr_len);
+}
+
+static void passthru_card_get_atr(VCard *card, unsigned char *atr, int
*atr_len)
+{
+VCardAppletPrivate *applet_private = NULL;
+SCARD_READERSTATE *state;
+
+applet_private = vcard_get_current_applet_private(card, 0);
+if ((applet_private == NULL) || (applet_private-atr_len == 0)) {
+vcard_emul_get_atr(card, atr, atr_len);
+return;
+}
+*atr_len = MIN(applet_private-atr_len, *atr_len);
+memcpy(atr, applet_private-atr, *atr_len);
+return;
+}
+
+/*
+ * reset the inter call state between applet selects
+ */
+static VCardStatus
+passthru_reset(VCard *card, int channel)
+{
+return VCARD_DONE;
+}
+
+static VCardStatus
+passthru_pcsc_lite_init()
+{
+LONG rv;
+if (global_context != 0) {
+return VCARD_DONE;
+}
+rv = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL,
global_context);
+if (rv != SCARD_S_SUCCESS) {
+return VCARD_FAIL;
+}
+return VCARD_DONE;
+}
+
+/*
+ * match if s1 is completely contained in s2
+ */
+static int
+string_match(const char *s1, const char *s2)
+{
+int len = strlen(s1);
+const char *start;
+
+for (start = strchr(s2, *s1); start; start = strchr(start+1,
[Qemu-devel] [PATCH v22 07/11] libcacard: add vscclient
From: Robert Relyea rrel...@redhat.com
client to talk to ccid-card-passthru and use smartcard on client to
perform actual operations.
---
libcacard/Makefile|7 +-
libcacard/vscclient.c | 730 +
2 files changed, 736 insertions(+), 1 deletions(-)
create mode 100644 libcacard/vscclient.c
diff --git a/libcacard/Makefile b/libcacard/Makefile
index 410fa1e..85e3376 100644
--- a/libcacard/Makefile
+++ b/libcacard/Makefile
@@ -12,6 +12,11 @@ endif
QEMU_OBJS=$(QEMU_THREAD) $(oslib-obj-y) $(trace-obj-y) qemu-malloc.o
qemu-timer-common.o
+vscclient: $(libcacard-y) $(QEMU_OBJS) vscclient.o
+ $(call quiet-command,$(CC) $(libcacard_libs) -lrt -o $@ $^, LINK
$(TARGET_DIR)$@)
+
+all: vscclient
+
clean:
- rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~
+ rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~ vscclient
diff --git a/libcacard/vscclient.c b/libcacard/vscclient.c
new file mode 100644
index 000..8dde449
--- /dev/null
+++ b/libcacard/vscclient.c
@@ -0,0 +1,730 @@
+/*
+ * Tester for VSCARD protocol, client side.
+ *
+ * Can be used with ccid-card-passthru.
+ *
+ * Copyright (c) 2011 Red Hat.
+ * Written by Alon Levy.
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2.1 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ */
+
+#include sys/types.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+
+#include sys/types.h
+#include sys/socket.h
+#include netdb.h
+#include netinet/in.h
+#include arpa/inet.h
+
+#include qemu-thread.h
+#include qemu-common.h
+
+#include vscard_common.h
+
+#include vreader.h
+#include vcard_emul.h
+#include vevent.h
+
+int verbose;
+
+int sock;
+
+static void
+print_byte_array(
+uint8_t *arrBytes,
+unsigned int nSize
+) {
+int i;
+for (i = 0; i nSize; i++) {
+printf(%02X , arrBytes[i]);
+}
+printf(\n);
+}
+
+static void
+print_usage(void) {
+printf(vscclient [-c certname .. -e emul_args -d level%s]
+host port\n,
+#ifdef USE_PASSTHRU
+ -p);
+printf( -p use passthrough mode\n);
+#else
+ );
+#endif
+vcard_emul_usage();
+}
+
+static QemuMutex write_lock;
+
+static int
+send_msg(
+VSCMsgType type,
+uint32_t reader_id,
+const void *msg,
+unsigned int length
+) {
+int rv;
+VSCMsgHeader mhHeader;
+
+qemu_mutex_lock(write_lock);
+
+if (verbose 10) {
+printf(sending type=%d id=%d, len =%d (0x%x)\n,
+ type, reader_id, length, length);
+}
+
+mhHeader.type = htonl(type);
+mhHeader.reader_id = 0;
+mhHeader.length = htonl(length);
+rv = write(
+sock,
+mhHeader,
+sizeof(mhHeader)
+);
+if (rv 0) {
+/* Error */
+printf(write header error\n);
+close(sock);
+qemu_mutex_unlock(write_lock);
+return 16;
+}
+rv = write(
+sock,
+msg,
+length
+);
+if (rv 0) {
+/* Error */
+printf(write error\n);
+close(sock);
+qemu_mutex_unlock(write_lock);
+return 16;
+}
+qemu_mutex_unlock(write_lock);
+
+return 0;
+}
+
+static VReader *pending_reader;
+static QemuMutex pending_reader_lock;
+static QemuCond pending_reader_condition;
+
+#define MAX_ATR_LEN 40
+static void *
+event_thread(void *arg)
+{
+unsigned char atr[MAX_ATR_LEN];
+int atr_len = MAX_ATR_LEN;
+VEvent *event = NULL;
+unsigned int reader_id;
+
+
+while (1) {
+const char *reader_name;
+
+event = vevent_wait_next_vevent();
+if (event == NULL) {
+break;
+}
+reader_id = vreader_get_id(event-reader);
+if (reader_id == VSCARD_UNDEFINED_READER_ID
+event-type != VEVENT_READER_INSERT) {
+/* ignore events from readers qemu has rejected */
+/* if qemu is still deciding on this reader, wait to see if need to
+ * forward this event */
+qemu_mutex_lock(pending_reader_lock);
+if (!pending_reader || (pending_reader != event-reader)) {
+/* wasn't for a pending reader, this reader has already been
+ * rejected by qemu */
+qemu_mutex_unlock(pending_reader_lock);
+vevent_delete(event);
+continue;
+}
+/* this reader hasn't been told it's status from qemu yet, wait for
+ * that status */
+while (pending_reader != NULL) {
+qemu_cond_wait(pending_reader_condition,
pending_reader_lock);
+}
+qemu_mutex_unlock(pending_reader_lock);
+/* now recheck the id */
+reader_id = vreader_get_id(event-reader);
+if (reader_id == VSCARD_UNDEFINED_READER_ID) {
+/* this reader was rejected */
+vevent_delete(event);
+continue;
+}
+/* reader
