[Qemu-devel] Re: [PATCH] add support for protocol driver create_options
At Fri, 21 May 2010 13:40:31 +0200, Kevin Wolf wrote: Am 20.05.2010 07:36, schrieb MORITA Kazutaka: This patch enables protocol drivers to use their create options which are not supported by the format. For example, protcol drivers can use a backing_file option with raw format. Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp Hm, this is not stackable, right? Though I do see that making it stackable would require some bigger changes, so maybe we can get away with claiming that this approach covers everything that happens in practice. If we accept that this is the desired behaviour, the code looks good to me. As you say, this patch isn't stackable; we must specify a image name with at most 1 format and 1 protocol. I cannot think of a situation where we want to use more than one protocol to create qemu images, so this seems to be enough to me. Thanks, Kazutaka
[Qemu-devel] Re: [PATCH] add support for protocol driver create_options
At Fri, 21 May 2010 18:57:36 +0200,
Kevin Wolf wrote:
Am 20.05.2010 07:36, schrieb MORITA Kazutaka:
+
+/*
+ * Append an option list (list) to an option list (dest).
+ *
+ * If dest is NULL, a new copy of list is created.
+ *
+ * Returns a pointer to the first element of dest (or the newly allocated
copy)
+ */
+QEMUOptionParameter *append_option_parameters(QEMUOptionParameter *dest,
+QEMUOptionParameter *list)
+{
+size_t num_options, num_dest_options;
+
+num_options = count_option_parameters(dest);
+num_dest_options = num_options;
+
+num_options += count_option_parameters(list);
+
+dest = qemu_realloc(dest, (num_options + 1) *
sizeof(QEMUOptionParameter));
+
+while (list list-name) {
+if (get_option_parameter(dest, list-name) == NULL) {
+dest[num_dest_options++] = *list;
You need to add a dest[num_dest_options].name = NULL; here. Otherwise
the next loop iteration works on uninitialized memory and possibly an
unterminated list. I got a segfault for that reason.
I forgot to add it, sorry.
Fixed version is below.
Thanks,
Kazutaka
==
This patch enables protocol drivers to use their create options which
are not supported by the format. For example, protcol drivers can use
a backing_file option with raw format.
Signed-off-by: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
---
block.c |7 +++
block.h |1 +
qemu-img.c| 49 ++---
qemu-option.c | 53 ++---
qemu-option.h |2 ++
5 files changed, 86 insertions(+), 26 deletions(-)
diff --git a/block.c b/block.c
index 202f895..3ed35ed 100644
--- a/block.c
+++ b/block.c
@@ -56,7 +56,6 @@ static int bdrv_read_em(BlockDriverState *bs, int64_t
sector_num,
uint8_t *buf, int nb_sectors);
static int bdrv_write_em(BlockDriverState *bs, int64_t sector_num,
const uint8_t *buf, int nb_sectors);
-static BlockDriver *find_protocol(const char *filename);
static QTAILQ_HEAD(, BlockDriverState) bdrv_states =
QTAILQ_HEAD_INITIALIZER(bdrv_states);
@@ -210,7 +209,7 @@ int bdrv_create_file(const char* filename,
QEMUOptionParameter *options)
{
BlockDriver *drv;
-drv = find_protocol(filename);
+drv = bdrv_find_protocol(filename);
if (drv == NULL) {
drv = bdrv_find_format(file);
}
@@ -283,7 +282,7 @@ static BlockDriver *find_hdev_driver(const char *filename)
return drv;
}
-static BlockDriver *find_protocol(const char *filename)
+BlockDriver *bdrv_find_protocol(const char *filename)
{
BlockDriver *drv1;
char protocol[128];
@@ -469,7 +468,7 @@ int bdrv_file_open(BlockDriverState **pbs, const char
*filename, int flags)
BlockDriver *drv;
int ret;
-drv = find_protocol(filename);
+drv = bdrv_find_protocol(filename);
if (!drv) {
return -ENOENT;
}
diff --git a/block.h b/block.h
index b95a9c0..bd11cc0 100644
--- a/block.h
+++ b/block.h
@@ -54,6 +54,7 @@ void bdrv_info_stats(Monitor *mon, QObject **ret_data);
void bdrv_init(void);
void bdrv_init_with_whitelist(void);
+BlockDriver *bdrv_find_protocol(const char *filename);
BlockDriver *bdrv_find_format(const char *format_name);
BlockDriver *bdrv_find_whitelisted_format(const char *format_name);
int bdrv_create(BlockDriver *drv, const char* filename,
diff --git a/qemu-img.c b/qemu-img.c
index d3c30a7..8ae7184 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -252,8 +252,8 @@ static int img_create(int argc, char **argv)
const char *base_fmt = NULL;
const char *filename;
const char *base_filename = NULL;
-BlockDriver *drv;
-QEMUOptionParameter *param = NULL;
+BlockDriver *drv, *proto_drv;
+QEMUOptionParameter *param = NULL, *create_options = NULL;
char *options = NULL;
flags = 0;
@@ -286,33 +286,42 @@ static int img_create(int argc, char **argv)
}
}
+/* Get the filename */
+if (optind = argc)
+help();
+filename = argv[optind++];
+
/* Find driver and parse its options */
drv = bdrv_find_format(fmt);
if (!drv)
error(Unknown file format '%s', fmt);
+proto_drv = bdrv_find_protocol(filename);
+if (!proto_drv)
+error(Unknown protocol '%s', filename);
+
+create_options = append_option_parameters(create_options,
+ drv-create_options);
+create_options = append_option_parameters(create_options,
+ proto_drv-create_options);
+
if (options !strcmp(options, ?)) {
-print_option_help(drv-create_options);
+print_option_help(create_options);
return 0;
}
/* Create parameter list with default values */
-param = parse_option_parameters(, drv-create_options, param);
+param = parse_option_parameters(, create_options,
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On 05/23/2010 07:30 PM, Michael S. Tsirkin wrote:
Maybe we should use atomics on index then?
This should only be helpful if you access the cacheline several times in
a row. That's not the case in virtio (or here).
So why does it help?
We actually do access the cacheline several times in a row here (but not
in virtio?):
case SHARE:
while (count MAX_BOUNCES) {
/* Spin waiting for other side to change it. */
while (counter-cacheline1 != count);
Broadcast a read request.
count++;
counter-cacheline1 = count;
Broadcast an invalidate request.
count++;
}
break;
case LOCKSHARE:
while (count MAX_BOUNCES) {
/* Spin waiting for other side to change it. */
while
(__sync_val_compare_and_swap(counter-cacheline1, count, count+1)
!= count);
Broadcast a 'read for ownership' request.
count += 2;
}
break;
So RMW should certainly by faster using single-instruction RMW
operations (or using prefetchw).
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
At Sun, 23 May 2010 15:01:59 +0300, Avi Kivity wrote: On 05/21/2010 12:29 AM, Anthony Liguori wrote: I'd be more interested in enabling people to build these types of storage systems without touching qemu. Both sheepdog and ceph ultimately transmit I/O over a socket to a central daemon, right? That incurs an extra copy. So could we not standardize a protocol for this that both sheepdog and ceph could implement? The protocol already exists, nbd. It doesn't support snapshotting etc. but we could extend it. I have no objection to use another protocol for Sheepdog support, but I think nbd protocol is unsuitable for the large storage pool with many VM images. It is because nbd protocol doesn't support specifing a file name to open. If we use nbd with such a storage system, the server needs to listen ports as many as the number of VM images. As far as I see the protocol, It looks difficult to extend it without breaking backward compatibility. Regards, Kazutaka But IMO what's needed is a plugin API for the block layer.
[Qemu-devel] [Bug 584121] Re: migration always fails on 32bit qemu-kvm-0.12+ (sigsegv)
** Tags added: 32bit migration qemu-kvm sigsegv -- migration always fails on 32bit qemu-kvm-0.12+ (sigsegv) https://bugs.launchpad.net/bugs/584121 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: On a 32bit host (or when running 32bit userspace on 64bit host), migration always fails with a crash of qemu-kvm process. See http://marc.info/?l=kvmm=127351472231666 for more information.
[Qemu-devel] [Bug 584131] Re: some guests hangs after migration (qemu-kvm-0.12)
** Tags added: irq lost migration qemu-kvm -- some guests hangs after migration (qemu-kvm-0.12) https://bugs.launchpad.net/bugs/584131 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Status in Debian GNU/Linux: New Bug description: There's a quite good bugreport in Debian BTS about this, #580649: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580649 This is not the same as lp#341682, since it's now 0.12. Full initial message from #580649: From: Apollon Oikonomopoulos apoi...@gmail.com To: Debian Bug Tracking System sub...@bugs.debian.org Subject: qemu-kvm: Guests hang after live migration Date: Fri, 07 May 2010 16:29:10 +0300 Package: qemu-kvm Version: 0.12.3+dfsg-4 Severity: important Hi, qemu-kvm 0.12.3 causes guests to hang after a live migration. The crash seems to be related to the guest's virtio subsystem, as per the following backtrace obtained _in the guest_: May 7 14:17:32 kot kernel: [ 285.035681] irq 11: nobody cared (try booting with the irqpoll option) May 7 14:17:32 kot kernel: [ 285.035681] Pid: 0, comm: swapper Not tainted 2.6.26-2-amd64 #1 May 7 14:17:32 kot kernel: [ 285.035681] May 7 14:17:32 kot kernel: [ 285.035681] Call Trace: May 7 14:17:32 kot kernel: [ 285.035681] IRQ [a008b06c] :virtio_pci:vp_interrupt+0x27/0xb8 May 7 14:17:32 kot kernel: [ 285.035681] [8026c6d3] __report_bad_irq+0x30/0x72 May 7 14:17:32 kot kernel: [ 285.035681] [8026c912] note_interrupt+0x1fd/0x23b May 7 14:17:32 kot kernel: [ 285.035681] [8026d19b] handle_fasteoi_irq+0xa5/0xc8 May 7 14:17:32 kot kernel: [ 285.035681] [8020f5dc] do_IRQ+0x6d/0xd9 May 7 14:17:32 kot kernel: [ 285.035681] [8020b093] default_idle+0x0/0x49 May 7 14:17:32 kot kernel: [ 285.035681] [8020c45d] ret_from_intr+0x0/0x19 May 7 14:17:32 kot kernel: [ 285.035681] EOI [8021a717] lapic_next_event+0x0/0x13 May 7 14:17:32 kot kernel: [ 285.035681] [8021eb64] native_safe_halt+0x2/0x3 May 7 14:17:32 kot kernel: [ 285.035681] [8021eb64] native_safe_halt+0x2/0x3 May 7 14:17:32 kot kernel: [ 285.035681] [8020b0bd] default_idle+0x2a/0x49 May 7 14:17:32 kot kernel: [ 285.035681] [8020ad04] cpu_idle+0x8e/0xb8 May 7 14:17:32 kot kernel: [ 285.035681] May 7 14:17:32 kot kernel: [ 285.035681] handlers: May 7 14:17:32 kot kernel: [ 285.035681] [8038f27b] (usb_hcd_irq+0x0/0x78) May 7 14:17:32 kot kernel: [ 285.035681] [a008b045] (vp_interrupt+0x0/0xb8 [virtio_pci]) May 7 14:17:32 kot kernel: [ 285.035681] Disabling IRQ #11 This happens in a reproducible fashion on a guest with the following setup: * Virtio net + block devices * 8 CPU SMP * 521 MB RAM * Debian Lenny with 2.6.26-2-amd64 Just migrating the guest a couple of times with a bit of I/O activity will cause it to freeze completely. It does *not* seem to impact the following: * Guests with no virtio devices * Guests running 2.6.32-4-amd64 * Guests running under qemu-kvm-0.11.1 Thus, it seems to be virtio-specific and possibly related to the guest kernel, but since qemu-kvm-0.11.1 works fine, I'm filing it as a qemu-kvm regression and not a kernel bug. Thank you
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On Mon, May 24, 2010 at 09:37:05AM +0300, Avi Kivity wrote:
On 05/23/2010 07:30 PM, Michael S. Tsirkin wrote:
Maybe we should use atomics on index then?
This should only be helpful if you access the cacheline several times in
a row. That's not the case in virtio (or here).
So why does it help?
We actually do access the cacheline several times in a row here (but not
in virtio?):
case SHARE:
while (count MAX_BOUNCES) {
/* Spin waiting for other side to change it. */
while (counter-cacheline1 != count);
Broadcast a read request.
count++;
counter-cacheline1 = count;
Broadcast an invalidate request.
count++;
}
break;
case LOCKSHARE:
while (count MAX_BOUNCES) {
/* Spin waiting for other side to change it. */
while
(__sync_val_compare_and_swap(counter-cacheline1, count, count+1)
!= count);
Broadcast a 'read for ownership' request.
count += 2;
}
break;
So RMW should certainly by faster using single-instruction RMW
operations (or using prefetchw).
Okay, but why is lockunshare faster than unshare?
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
[Qemu-devel] [PATCH v2 1/3] add some tests for invalid JSON
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
check-qjson.c | 98 -
1 files changed, 97 insertions(+), 1 deletions(-)
diff --git a/check-qjson.c b/check-qjson.c
index 109e777..a04e334 100644
--- a/check-qjson.c
+++ b/check-qjson.c
@@ -628,11 +628,90 @@ START_TEST(simple_varargs)
}
END_TEST
+START_TEST(empty_input)
+{
+QObject *obj = qobject_from_json();
+fail_unless(obj == NULL);
+}
+END_TEST
+
+START_TEST(unterminated_string)
+{
+QObject *obj = qobject_from_json(\abc);
+fail_unless(obj == NULL);
+}
+END_TEST
+
+START_TEST(unterminated_sq_string)
+{
+QObject *obj = qobject_from_json('abc);
+fail_unless(obj == NULL);
+}
+END_TEST
+
+START_TEST(unterminated_escape)
+{
+QObject *obj = qobject_from_json(\abc\\\);
+fail_unless(obj == NULL);
+}
+END_TEST
+
+START_TEST(unterminated_array)
+{
+QObject *obj = qobject_from_json([32);
+fail_unless(obj == NULL);
+}
+END_TEST
+
+START_TEST(unterminated_array_comma)
+{
+QObject *obj = qobject_from_json([32,);
+fail_unless(obj == NULL);
+}
+END_TEST
+
+START_TEST(invalid_array_comma)
+{
+QObject *obj = qobject_from_json([32,});
+fail_unless(obj == NULL);
+}
+END_TEST
+
+START_TEST(unterminated_dict)
+{
+QObject *obj = qobject_from_json({'abc':32);
+fail_unless(obj == NULL);
+}
+END_TEST
+
+START_TEST(unterminated_dict_comma)
+{
+QObject *obj = qobject_from_json({'abc':32,);
+fail_unless(obj == NULL);
+}
+END_TEST
+
+#if 0
+START_TEST(invalid_dict_comma)
+{
+QObject *obj = qobject_from_json({'abc':32,});
+fail_unless(obj == NULL);
+}
+END_TEST
+
+START_TEST(unterminated_literal)
+{
+QObject *obj = qobject_from_json(nul);
+fail_unless(obj == NULL);
+}
+END_TEST
+#endif
+
static Suite *qjson_suite(void)
{
Suite *suite;
TCase *string_literals, *number_literals, *keyword_literals;
-TCase *dicts, *lists, *whitespace, *varargs;
+TCase *dicts, *lists, *whitespace, *varargs, *errors;
string_literals = tcase_create(String Literals);
tcase_add_test(string_literals, simple_string);
@@ -658,6 +737,22 @@ static Suite *qjson_suite(void)
varargs = tcase_create(Varargs);
tcase_add_test(varargs, simple_varargs);
+errors = tcase_create(Invalid JSON);
+tcase_add_test(errors, empty_input);
+tcase_add_test(errors, unterminated_string);
+tcase_add_test(errors, unterminated_escape);
+tcase_add_test(errors, unterminated_sq_string);
+tcase_add_test(errors, unterminated_array);
+tcase_add_test(errors, unterminated_array_comma);
+tcase_add_test(errors, invalid_array_comma);
+tcase_add_test(errors, unterminated_dict);
+tcase_add_test(errors, unterminated_dict_comma);
+#if 0
+/* FIXME: this print parse error messages on stderr. */
+tcase_add_test(errors, invalid_dict_comma);
+tcase_add_test(errors, unterminated_literal);
+#endif
+
suite = suite_create(QJSON test-suite);
suite_add_tcase(suite, string_literals);
suite_add_tcase(suite, number_literals);
@@ -666,6 +761,7 @@ static Suite *qjson_suite(void)
suite_add_tcase(suite, lists);
suite_add_tcase(suite, whitespace);
suite_add_tcase(suite, varargs);
+suite_add_tcase(suite, errors);
return suite;
}
--
1.6.6.1
[Qemu-devel] [PATCH 2/5] Factorize common migration incoming code
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration-exec.c | 14 +-
migration-fd.c | 14 +-
migration-tcp.c | 15 ++-
migration-unix.c | 15 ++-
migration.c | 13 +
migration.h |2 ++
6 files changed, 21 insertions(+), 52 deletions(-)
diff --git a/migration-exec.c b/migration-exec.c
index 5435827..07af11a 100644
--- a/migration-exec.c
+++ b/migration-exec.c
@@ -111,20 +111,8 @@ err_after_alloc:
static void exec_accept_incoming_migration(void *opaque)
{
QEMUFile *f = opaque;
-int ret;
-ret = qemu_loadvm_state(f);
-if (ret 0) {
-fprintf(stderr, load of migration failed\n);
-goto err;
-}
-qemu_announce_self();
-DPRINTF(successfully loaded vm state\n);
-
-if (autostart)
-vm_start();
-
-err:
+process_incoming_migration(f);
qemu_set_fd_handler2(qemu_stdio_fd(f), NULL, NULL, NULL, NULL);
qemu_fclose(f);
}
diff --git a/migration-fd.c b/migration-fd.c
index 0abd372..6d14505 100644
--- a/migration-fd.c
+++ b/migration-fd.c
@@ -104,20 +104,8 @@ err_after_alloc:
static void fd_accept_incoming_migration(void *opaque)
{
QEMUFile *f = opaque;
-int ret;
-ret = qemu_loadvm_state(f);
-if (ret 0) {
-fprintf(stderr, load of migration failed\n);
-goto err;
-}
-qemu_announce_self();
-DPRINTF(successfully loaded vm state\n);
-
-if (autostart)
-vm_start();
-
-err:
+process_incoming_migration(f);
qemu_set_fd_handler2(qemu_stdio_fd(f), NULL, NULL, NULL, NULL);
qemu_fclose(f);
}
diff --git a/migration-tcp.c b/migration-tcp.c
index 95ce722..20f2e37 100644
--- a/migration-tcp.c
+++ b/migration-tcp.c
@@ -143,7 +143,7 @@ static void tcp_accept_incoming_migration(void *opaque)
socklen_t addrlen = sizeof(addr);
int s = (unsigned long)opaque;
QEMUFile *f;
-int c, ret;
+int c;
do {
c = qemu_accept(s, (struct sockaddr *)addr, addrlen);
@@ -162,18 +162,7 @@ static void tcp_accept_incoming_migration(void *opaque)
goto out;
}
-ret = qemu_loadvm_state(f);
-if (ret 0) {
-fprintf(stderr, load of migration failed\n);
-goto out_fopen;
-}
-qemu_announce_self();
-DPRINTF(successfully loaded vm state\n);
-
-if (autostart)
-vm_start();
-
-out_fopen:
+process_incoming_migration(f);
qemu_fclose(f);
out:
qemu_set_fd_handler2(s, NULL, NULL, NULL, NULL);
diff --git a/migration-unix.c b/migration-unix.c
index 49de1b9..57232c0 100644
--- a/migration-unix.c
+++ b/migration-unix.c
@@ -149,7 +149,7 @@ static void unix_accept_incoming_migration(void *opaque)
socklen_t addrlen = sizeof(addr);
int s = (unsigned long)opaque;
QEMUFile *f;
-int c, ret;
+int c;
do {
c = qemu_accept(s, (struct sockaddr *)addr, addrlen);
@@ -168,18 +168,7 @@ static void unix_accept_incoming_migration(void *opaque)
goto out;
}
-ret = qemu_loadvm_state(f);
-if (ret 0) {
-fprintf(stderr, load of migration failed\n);
-goto out_fopen;
-}
-qemu_announce_self();
-DPRINTF(successfully loaded vm state\n);
-
-if (autostart)
-vm_start();
-
-out_fopen:
+process_incoming_migration(f);
qemu_fclose(f);
out:
qemu_set_fd_handler2(s, NULL, NULL, NULL, NULL);
diff --git a/migration.c b/migration.c
index cf30a8e..6ab5d90 100644
--- a/migration.c
+++ b/migration.c
@@ -54,6 +54,19 @@ int qemu_start_incoming_migration(const char *uri)
return ret;
}
+void process_incoming_migration(QEMUFile *f)
+{
+if (qemu_loadvm_state(f) 0) {
+fprintf(stderr, load of migration failed\n);
+exit(0);
+}
+qemu_announce_self();
+DPRINTF(successfully loaded vm state\n);
+
+if (autostart)
+vm_start();
+}
+
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
MigrationState *s = NULL;
diff --git a/migration.h b/migration.h
index dd423a1..017e9c3 100644
--- a/migration.h
+++ b/migration.h
@@ -50,6 +50,8 @@ struct FdMigrationState
void *opaque;
};
+void process_incoming_migration(QEMUFile *f);
+
int qemu_start_incoming_migration(const char *uri);
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data);
--
1.6.6.1
[Qemu-devel] [PATCH 0/5] Add QMP migration events
Hi This series does: - exit incoming migration on failure. For exec/fd migrations, once there was a failure, there was nothing useful to do. And for tcp migration, not exiting created interesting bugs when trying to migrate again to a process with a faild migration. - Factorize common migration code, no more duplication, makes easier to do global migration things, like QMP events. - Introduce QMP events, both for incoming and outgoing migration. Now, the million dollar question: Why I didn't refactorize outgoing migration? I tried, and have it partially done on my local tree. But it depends (too much) of current_migration global variable - Libvirt folks will also want info migrate to work on the incoming side, i.e. current_migraition has to also be updated on incoming side. Done until here, but then I hit the wall incoming migration is synchronous. To make the monitor work on incoming migration, we need to change buffered_file.c abstraction to also work for incoming fd's, or another similar solution. I am open to suggestions about what to do here. This series are quite simple (the unfinished part is more complex), will send the other part as an RFC later. Please review and consider to apply it. Later, Juan. Juan Quintela (5): Exit if incoming migration fails Factorize common migration incoming code QMP: Introduce MIGRATION events QMP: Emit migration events on incoming migration QMP: Emit migration events on outgoing migration QMP/qmp-events.txt | 50 ++ migration-exec.c | 17 +++-- migration-fd.c | 15 ++- migration-tcp.c| 17 - migration-unix.c | 17 - migration.c| 35 --- migration.h|4 +++- monitor.c | 12 monitor.h |4 vl.c |5 - 10 files changed, 114 insertions(+), 62 deletions(-)
[Qemu-devel] [PATCH 1/5] Exit if incoming migration fails
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration.c | 14 +++---
migration.h |2 +-
vl.c|5 -
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/migration.c b/migration.c
index 05f6cc5..cf30a8e 100644
--- a/migration.c
+++ b/migration.c
@@ -36,22 +36,22 @@ static uint32_t max_throttle = (32 20);
static MigrationState *current_migration;
-void qemu_start_incoming_migration(const char *uri)
+int qemu_start_incoming_migration(const char *uri)
{
const char *p;
+int ret = -1;
if (strstart(uri, tcp:, p))
-tcp_start_incoming_migration(p);
+ret = tcp_start_incoming_migration(p);
#if !defined(WIN32)
else if (strstart(uri, exec:, p))
-exec_start_incoming_migration(p);
+ret = exec_start_incoming_migration(p);
else if (strstart(uri, unix:, p))
-unix_start_incoming_migration(p);
+ret = unix_start_incoming_migration(p);
else if (strstart(uri, fd:, p))
-fd_start_incoming_migration(p);
+ret = fd_start_incoming_migration(p);
#endif
-else
-fprintf(stderr, unknown migration protocol: %s\n, uri);
+return ret;
}
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data)
diff --git a/migration.h b/migration.h
index 385423f..dd423a1 100644
--- a/migration.h
+++ b/migration.h
@@ -50,7 +50,7 @@ struct FdMigrationState
void *opaque;
};
-void qemu_start_incoming_migration(const char *uri);
+int qemu_start_incoming_migration(const char *uri);
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data);
diff --git a/vl.c b/vl.c
index d77b47c..3dfab9e 100644
--- a/vl.c
+++ b/vl.c
@@ -3841,7 +3841,10 @@ int main(int argc, char **argv, char **envp)
}
if (incoming) {
-qemu_start_incoming_migration(incoming);
+if (qemu_start_incoming_migration(incoming) 0) {
+fprintf(stderr, unknown migration protocol: %s\n, incoming);
+exit(1);
+}
} else if (autostart) {
vm_start();
}
--
1.6.6.1
[Qemu-devel] [PATCH 3/5] QMP: Introduce MIGRATION events
They are emitted when migration starts, ends, has a failure or is canceled.
Signed-off-by: Juan Quintela quint...@redhat.com
---
QMP/qmp-events.txt | 50 ++
monitor.c | 12
monitor.h |4
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
index 01ec85f..234360f 100644
--- a/QMP/qmp-events.txt
+++ b/QMP/qmp-events.txt
@@ -26,6 +26,56 @@ Example:
Note: If action is stop, a STOP event will eventually follow the
BLOCK_IO_ERROR event.
+MIGRATION_CANCELED
+--
+
+Emitted when migration is canceled. This is emitted in the source.
+Target will emit MIGRATION_CANCELED (no way to differentiate a FAILED
+and CANCELED migration).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_CANCELED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_ENDED
+---
+
+Emitted when migration starts (both in source and target)
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_ENDED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_FAILED
+
+
+Emitted when migration fails (both is source and target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_FAILED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_STARTED
+-
+
+Emitted when migration starts (both in source and target).
+
+Data: None
+
+Example:
+
+{ event: MIGRATION_STARTED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
RESET
-
diff --git a/monitor.c b/monitor.c
index a1ebc5d..723ca73 100644
--- a/monitor.c
+++ b/monitor.c
@@ -444,6 +444,18 @@ void monitor_protocol_event(MonitorEvent event, QObject
*data)
case QEVENT_WATCHDOG:
event_name = WATCHDOG;
break;
+case QEVENT_MIGRATION_STARTED:
+event_name = MIGRATION_STARTED;
+break;
+case QEVENT_MIGRATION_ENDED:
+event_name = MIGRATION_ENDED;
+break;
+case QEVENT_MIGRATION_FAILED:
+event_name = MIGRATION_FAILED;
+break;
+case QEVENT_MIGRATION_CANCELED:
+event_name = MIGRATION_CANCELED;
+break;
default:
abort();
break;
diff --git a/monitor.h b/monitor.h
index ea15469..34bcd38 100644
--- a/monitor.h
+++ b/monitor.h
@@ -28,6 +28,10 @@ typedef enum MonitorEvent {
QEVENT_BLOCK_IO_ERROR,
QEVENT_RTC_CHANGE,
QEVENT_WATCHDOG,
+QEVENT_MIGRATION_STARTED,
+QEVENT_MIGRATION_ENDED,
+QEVENT_MIGRATION_FAILED,
+QEVENT_MIGRATION_CANCELED,
QEVENT_MAX,
} MonitorEvent;
--
1.6.6.1
[Qemu-devel] [PATCH 4/5] QMP: Emit migration events on incoming migration
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/migration.c b/migration.c
index 6ab5d90..7fba993 100644
--- a/migration.c
+++ b/migration.c
@@ -56,10 +56,13 @@ int qemu_start_incoming_migration(const char *uri)
void process_incoming_migration(QEMUFile *f)
{
+monitor_protocol_event(QEVENT_MIGRATION_STARTED, NULL);
if (qemu_loadvm_state(f) 0) {
+monitor_protocol_event(QEVENT_MIGRATION_FAILED, NULL);
fprintf(stderr, load of migration failed\n);
exit(0);
}
+monitor_protocol_event(QEVENT_MIGRATION_ENDED, NULL);
qemu_announce_self();
DPRINTF(successfully loaded vm state\n);
--
1.6.6.1
[Qemu-devel] [PATCH 5/5] QMP: Emit migration events on outgoing migration
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration-exec.c |3 ++-
migration-fd.c |1 +
migration-tcp.c |2 ++
migration-unix.c |2 ++
migration.c |5 +
5 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/migration-exec.c b/migration-exec.c
index 07af11a..ebc9256 100644
--- a/migration-exec.c
+++ b/migration-exec.c
@@ -20,6 +20,7 @@
#include sysemu.h
#include buffered_file.h
#include block.h
+#include monitor.h
//#define DEBUG_MIGRATION_EXEC
@@ -91,9 +92,9 @@ MigrationState *exec_start_outgoing_migration(Monitor *mon,
s-mig_state.shared = inc;
s-state = MIG_STATE_ACTIVE;
+monitor_protocol_event(QEVENT_MIGRATION_STARTED, NULL);
s-mon = NULL;
s-bandwidth_limit = bandwidth_limit;
-
if (!detach) {
migrate_fd_monitor_suspend(s, mon);
}
diff --git a/migration-fd.c b/migration-fd.c
index 6d14505..9c4c7ae 100644
--- a/migration-fd.c
+++ b/migration-fd.c
@@ -83,6 +83,7 @@ MigrationState *fd_start_outgoing_migration(Monitor *mon,
s-mig_state.blk = blk;
s-mig_state.shared = inc;
+monitor_protocol_event(QEVENT_MIGRATION_STARTED, NULL);
s-state = MIG_STATE_ACTIVE;
s-mon = NULL;
s-bandwidth_limit = bandwidth_limit;
diff --git a/migration-tcp.c b/migration-tcp.c
index 20f2e37..11a1203 100644
--- a/migration-tcp.c
+++ b/migration-tcp.c
@@ -18,6 +18,7 @@
#include sysemu.h
#include buffered_file.h
#include block.h
+#include monitor.h
//#define DEBUG_MIGRATION_TCP
@@ -102,6 +103,7 @@ MigrationState *tcp_start_outgoing_migration(Monitor *mon,
s-mig_state.blk = blk;
s-mig_state.shared = inc;
+monitor_protocol_event(QEVENT_MIGRATION_STARTED, NULL);
s-state = MIG_STATE_ACTIVE;
s-mon = NULL;
s-bandwidth_limit = bandwidth_limit;
diff --git a/migration-unix.c b/migration-unix.c
index 57232c0..08f29a3 100644
--- a/migration-unix.c
+++ b/migration-unix.c
@@ -18,6 +18,7 @@
#include sysemu.h
#include buffered_file.h
#include block.h
+#include monitor.h
//#define DEBUG_MIGRATION_UNIX
@@ -101,6 +102,7 @@ MigrationState *unix_start_outgoing_migration(Monitor *mon,
s-mig_state.blk = blk;
s-mig_state.shared = inc;
+monitor_protocol_event(QEVENT_MIGRATION_STARTED, NULL);
s-state = MIG_STATE_ACTIVE;
s-mon = NULL;
s-bandwidth_limit = bandwidth_limit;
diff --git a/migration.c b/migration.c
index 7fba993..ff84504 100644
--- a/migration.c
+++ b/migration.c
@@ -302,6 +302,7 @@ void migrate_fd_monitor_suspend(FdMigrationState *s,
Monitor *mon)
void migrate_fd_error(FdMigrationState *s)
{
DPRINTF(setting error state\n);
+monitor_protocol_event(QEVENT_MIGRATION_FAILED, NULL);
s-state = MIG_STATE_ERROR;
migrate_fd_cleanup(s);
}
@@ -399,8 +400,10 @@ void migrate_fd_put_ready(void *opaque)
if (old_vm_running) {
vm_start();
}
+monitor_protocol_event(QEVENT_MIGRATION_FAILED, NULL);
state = MIG_STATE_ERROR;
} else {
+monitor_protocol_event(QEVENT_MIGRATION_ENDED, NULL);
state = MIG_STATE_COMPLETED;
}
migrate_fd_cleanup(s);
@@ -423,6 +426,7 @@ void migrate_fd_cancel(MigrationState *mig_state)
DPRINTF(cancelling migration\n);
+monitor_protocol_event(QEVENT_MIGRATION_CANCELED, NULL);
s-state = MIG_STATE_CANCELLED;
qemu_savevm_state_cancel(s-mon, s-file);
@@ -436,6 +440,7 @@ void migrate_fd_release(MigrationState *mig_state)
DPRINTF(releasing state\n);
if (s-state == MIG_STATE_ACTIVE) {
+monitor_protocol_event(QEVENT_MIGRATION_CANCELED, NULL);
s-state = MIG_STATE_CANCELLED;
migrate_fd_cleanup(s);
}
--
1.6.6.1
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On Sun, May 23, 2010 at 1:01 PM, Avi Kivity a...@redhat.com wrote: On 05/21/2010 12:29 AM, Anthony Liguori wrote: I'd be more interested in enabling people to build these types of storage systems without touching qemu. Both sheepdog and ceph ultimately transmit I/O over a socket to a central daemon, right? That incurs an extra copy. Besides a shared memory approach, I wonder if the splice() family of syscalls could be used to send/receive data through a storage daemon without the daemon looking at or copying the data? Stefan
RE: [Qemu-devel] Graphics Device Passthrough
On Sun, 23 May 2010, adhyas.avas...@nokia.com wrote: In the options for qemu, I did see an option that allowed me to define a host bus:dev:fn number to be accessible to the guest. This was not one of the USB options I believe. So I assumed some kind of pass-through support is present. For a PCI pass-through, we probably would not need to emulate the device completely (or else what is the need of pass-through). We can emulate just a few of the capabilities, and the command/INT registers that are needed to be emulated. Even VMware pass-throughs the rest AFAIK. I didn’t realize qemu-kvm did not have this support yet. PS: I have read papers that read about similar experiments people have carried on qemu. Didn't realize no code was checked back in the source tree. Thanks for letting me know. Xen supports graphic device passthrought since version 4.0, if you are interested the wiki page is here: http://wiki.xensource.com/xenwiki/XenVGAPassthrough depending on the device you want to passthrough it might be easy or very difficult though...
[Qemu-devel] [PATCH v2 0/3] json lexer tests and removal of lookahead
This is the same as the patches I sent last Friday, but split better and without the extraneous change to the seabios submodule. v1-v2: rearranged patches more coherently Paolo Bonzini (3): add some tests for invalid JSON implement optional lookahead in json lexer remove unnecessary lookaheads check-qjson.c | 98 - json-lexer.c | 106 +++- 2 files changed, 148 insertions(+), 56 deletions(-)
[Qemu-devel] Re: [PATCH 1/5] Exit if incoming migration fails
-void qemu_start_incoming_migration(const char *uri)
+int qemu_start_incoming_migration(const char *uri)
{
const char *p;
+int ret = -1;
Maybe -ENOSYS or -EPROTONOSUPPORT, since the *_start_incoming_migration
functions return a negative errno value?
if (incoming) {
-qemu_start_incoming_migration(incoming);
+if (qemu_start_incoming_migration(incoming) 0) {
+fprintf(stderr, unknown migration protocol: %s\n, incoming);
+exit(1);
+}
Dually, if you have a failure from *_start_incoming_migration, this
fprintf is spurious.
Paolo
[Qemu-devel] Re: [PATCH 3/5] QMP: Introduce MIGRATION events
On 05/24/2010 10:25 AM, Juan Quintela wrote:
+MIGRATION_CANCELED
+--
+
+Emitted when migration is canceled. This is emitted in the source.
+Target will emit MIGRATION_CANCELED (no way to differentiate a FAILED
+and CANCELED migration).
Copy-paste error? (or if not, parse error on my side).
+Data: None
+
+Example:
+
+{ event: MIGRATION_CANCELED,
+timestamp: {seconds: 1274687575, microseconds: 592483} }
+
+MIGRATION_ENDED
+---
+
+Emitted when migration starts (both in source and target)
Likewise.
Paolo
[Qemu-devel] [PATCH v2 2/3] implement optional lookahead in json lexer
Not requiring one extra character when lookahead is not necessary
ensures that clients behave properly even if they, for example,
send QMP requests without a trailing newline.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
json-lexer.c | 58 +++---
1 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/json-lexer.c b/json-lexer.c
index d1d8033..41b37f4 100644
--- a/json-lexer.c
+++ b/json-lexer.c
@@ -65,6 +65,12 @@ enum json_lexer_state {
#define TERMINAL(state) [0 ... 0x7F] = (state)
+/* Return whether TERMINAL is a terminal state and the transition to it
+ from OLD_STATE required lookahead. This happens whenever the table
+ below uses the TERMINAL macro. */
+#define TERMINAL_NEEDED_LOOKAHEAD(old_state, terminal) \
+(json_lexer[(old_state)][0] == (terminal))
+
static const uint8_t json_lexer[][256] = {
[IN_DONE_STRING] = {
TERMINAL(JSON_STRING),
@@ -279,35 +285,41 @@ void json_lexer_init(JSONLexer *lexer, JSONLexerEmitter
func)
static int json_lexer_feed_char(JSONLexer *lexer, char ch)
{
+int char_consumed, new_state;
+
lexer-x++;
if (ch == '\n') {
lexer-x = 0;
lexer-y++;
}
-lexer-state = json_lexer[lexer-state][(uint8_t)ch];
-
-switch (lexer-state) {
-case JSON_OPERATOR:
-case JSON_ESCAPE:
-case JSON_INTEGER:
-case JSON_FLOAT:
-case JSON_KEYWORD:
-case JSON_STRING:
-lexer-emit(lexer, lexer-token, lexer-state, lexer-x, lexer-y);
-case JSON_SKIP:
-lexer-state = json_lexer[IN_START][(uint8_t)ch];
-QDECREF(lexer-token);
-lexer-token = qstring_new();
-break;
-case ERROR:
-return -EINVAL;
-default:
-break;
-}
-
-qstring_append_chr(lexer-token, ch);
+do {
+new_state = json_lexer[lexer-state][(uint8_t)ch];
+char_consumed = !TERMINAL_NEEDED_LOOKAHEAD(lexer-state, new_state);
+if (char_consumed) {
+qstring_append_chr(lexer-token, ch);
+}
+switch (new_state) {
+case JSON_OPERATOR:
+case JSON_ESCAPE:
+case JSON_INTEGER:
+case JSON_FLOAT:
+case JSON_KEYWORD:
+case JSON_STRING:
+lexer-emit(lexer, lexer-token, new_state, lexer-x, lexer-y);
+case JSON_SKIP:
+QDECREF(lexer-token);
+lexer-token = qstring_new();
+new_state = IN_START;
+break;
+case ERROR:
+return -EINVAL;
+default:
+break;
+}
+lexer-state = new_state;
+} while (!char_consumed);
return 0;
}
@@ -329,7 +341,7 @@ int json_lexer_feed(JSONLexer *lexer, const char *buffer,
size_t size)
int json_lexer_flush(JSONLexer *lexer)
{
-return json_lexer_feed_char(lexer, 0);
+return lexer-state == IN_START ? 0 : json_lexer_feed_char(lexer, 0);
}
void json_lexer_destroy(JSONLexer *lexer)
--
1.6.6.1
[Qemu-devel] [PATCH v2 3/3] remove unnecessary lookaheads
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
json-lexer.c | 48
1 files changed, 16 insertions(+), 32 deletions(-)
diff --git a/json-lexer.c b/json-lexer.c
index 41b37f4..ec96fb4 100644
--- a/json-lexer.c
+++ b/json-lexer.c
@@ -29,7 +29,6 @@
enum json_lexer_state {
ERROR = 0,
-IN_DONE_STRING,
IN_DQ_UCODE3,
IN_DQ_UCODE2,
IN_DQ_UCODE1,
@@ -57,9 +56,7 @@ enum json_lexer_state {
IN_ESCAPE_I,
IN_ESCAPE_I6,
IN_ESCAPE_I64,
-IN_ESCAPE_DONE,
IN_WHITESPACE,
-IN_OPERATOR_DONE,
IN_START,
};
@@ -72,10 +69,6 @@ enum json_lexer_state {
(json_lexer[(old_state)][0] == (terminal))
static const uint8_t json_lexer[][256] = {
-[IN_DONE_STRING] = {
-TERMINAL(JSON_STRING),
-},
-
/* double quote string */
[IN_DQ_UCODE3] = {
['0' ... '9'] = IN_DQ_STRING,
@@ -110,7 +103,7 @@ static const uint8_t json_lexer[][256] = {
[IN_DQ_STRING] = {
[1 ... 0xFF] = IN_DQ_STRING,
['\\'] = IN_DQ_STRING_ESCAPE,
-[''] = IN_DONE_STRING,
+[''] = JSON_STRING,
},
/* single quote string */
@@ -147,7 +140,7 @@ static const uint8_t json_lexer[][256] = {
[IN_SQ_STRING] = {
[1 ... 0xFF] = IN_SQ_STRING,
['\\'] = IN_SQ_STRING_ESCAPE,
-['\''] = IN_DONE_STRING,
+['\''] = JSON_STRING,
},
/* Zero */
@@ -213,27 +206,18 @@ static const uint8_t json_lexer[][256] = {
['\n'] = IN_WHITESPACE,
},
-/* operator */
-[IN_OPERATOR_DONE] = {
-TERMINAL(JSON_OPERATOR),
-},
-
/* escape */
-[IN_ESCAPE_DONE] = {
-TERMINAL(JSON_ESCAPE),
-},
-
[IN_ESCAPE_LL] = {
-['d'] = IN_ESCAPE_DONE,
+['d'] = JSON_ESCAPE,
},
[IN_ESCAPE_L] = {
-['d'] = IN_ESCAPE_DONE,
+['d'] = JSON_ESCAPE,
['l'] = IN_ESCAPE_LL,
},
[IN_ESCAPE_I64] = {
-['d'] = IN_ESCAPE_DONE,
+['d'] = JSON_ESCAPE,
},
[IN_ESCAPE_I6] = {
@@ -245,11 +229,11 @@ static const uint8_t json_lexer[][256] = {
},
[IN_ESCAPE] = {
-['d'] = IN_ESCAPE_DONE,
-['i'] = IN_ESCAPE_DONE,
-['p'] = IN_ESCAPE_DONE,
-['s'] = IN_ESCAPE_DONE,
-['f'] = IN_ESCAPE_DONE,
+['d'] = JSON_ESCAPE,
+['i'] = JSON_ESCAPE,
+['p'] = JSON_ESCAPE,
+['s'] = JSON_ESCAPE,
+['f'] = JSON_ESCAPE,
['l'] = IN_ESCAPE_L,
['I'] = IN_ESCAPE_I,
},
@@ -261,12 +245,12 @@ static const uint8_t json_lexer[][256] = {
['0'] = IN_ZERO,
['1' ... '9'] = IN_NONZERO_NUMBER,
['-'] = IN_NEG_NONZERO_NUMBER,
-['{'] = IN_OPERATOR_DONE,
-['}'] = IN_OPERATOR_DONE,
-['['] = IN_OPERATOR_DONE,
-[']'] = IN_OPERATOR_DONE,
-[','] = IN_OPERATOR_DONE,
-[':'] = IN_OPERATOR_DONE,
+['{'] = JSON_OPERATOR,
+['}'] = JSON_OPERATOR,
+['['] = JSON_OPERATOR,
+[']'] = JSON_OPERATOR,
+[','] = JSON_OPERATOR,
+[':'] = JSON_OPERATOR,
['a' ... 'z'] = IN_KEYWORD,
['%'] = IN_ESCAPE,
[' '] = IN_WHITESPACE,
--
1.6.6.1
[Qemu-devel] Re: [[RfC PATCH]] linux fbdev display driver prototype.
On Fri, 21 May 2010, Julian Pidancet wrote: This looks very promissing. I just got a couple of observations: - Your patch does not work on my machine with the vesafb driver. It reports can't handle 8 bpp frame buffers. It turns out that the vesafb driver seems to initialize the framebuffer in PSEUDOCOLOR mode. I think we should add a piece of code which tries reinitialize the framebuffer with the suitable parametters (32bpp/TRUECOLOR). It works fine with inteldrmfb though. 32bpp would be ideal, but we could probably handle 24 and 16 bpp too - You should register a Display Allocator and override the create_displaysurface() method like I did in the DirectFB driver. This way you save qemu a data copy. fbdev_render_32() should only be used when the guest framebuffer is not compatible with the physical framebuffer (guest_bpp != physical_bbp || guest_linesize != physical_linesize). agreed - A cool feature would be to be able to stretch the guest display in fullscreen. My DirectFB driver implements a fullscreen toggle command by pressing the Ctrl-Alt-Return keys. I think Stefano added a SDL zoom feature a while ago which we could reuse for this. sdl_zoom.c is actually generic and not SDL specific, so it shouldn't be difficult to reuse it here
[Qemu-devel] strange bug with virtio-blk-pci properties
Running: $ qemu-system-x86_64 -device virtio-blk-pci,logical_block_size=4096,physical_block_size=4096,drive=boot -drive file=/tmp/a.qcow2,if=none,id=boot gives me: Floating point exception The crash is in hw/virtio-blk.c:505 blkcfg.blk_size is zero because s-conf-logical_block_size is zero. Running: $ qemu-system-x86_64 -device virtio-blk-pci,physical_block_size=4096,logical_block_size=4096,drive=boot -drive file=/tmp/a.qcow2,if=none,id=boot works. -- Gleb.
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On 05/24/2010 11:05 AM, Michael S. Tsirkin wrote: Okay, but why is lockunshare faster than unshare? No idea. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On 05/24/2010 11:27 AM, Stefan Hajnoczi wrote: On Sun, May 23, 2010 at 1:01 PM, Avi Kivitya...@redhat.com wrote: On 05/21/2010 12:29 AM, Anthony Liguori wrote: I'd be more interested in enabling people to build these types of storage systems without touching qemu. Both sheepdog and ceph ultimately transmit I/O over a socket to a central daemon, right? That incurs an extra copy. Besides a shared memory approach, I wonder if the splice() family of syscalls could be used to send/receive data through a storage daemon without the daemon looking at or copying the data? Excellent idea. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On 05/24/2010 10:12 AM, MORITA Kazutaka wrote: At Sun, 23 May 2010 15:01:59 +0300, Avi Kivity wrote: On 05/21/2010 12:29 AM, Anthony Liguori wrote: I'd be more interested in enabling people to build these types of storage systems without touching qemu. Both sheepdog and ceph ultimately transmit I/O over a socket to a central daemon, right? That incurs an extra copy. So could we not standardize a protocol for this that both sheepdog and ceph could implement? The protocol already exists, nbd. It doesn't support snapshotting etc. but we could extend it. I have no objection to use another protocol for Sheepdog support, but I think nbd protocol is unsuitable for the large storage pool with many VM images. It is because nbd protocol doesn't support specifing a file name to open. If we use nbd with such a storage system, the server needs to listen ports as many as the number of VM images. As far as I see the protocol, It looks difficult to extend it without breaking backward compatibility. The server would be local and talk over a unix domain socket, perhaps anonymous. nbd has other issues though, such as requiring a copy and no support for metadata operations such as snapshot and file size extension. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] Hi. Regarding QEMU's GDB server and MMU
Hi all. I am very new to dev for QEMU, so I have some very basic questions. 1) I understand that QEMU has a built-in GDB server that is somewhat a simulation of a JTAG device on dev boards, connected directly to the CPU. Is that a correct analogy? 2) How can the GDB server handle a MMU? Would it see physical or virtual addresses? Do I need a special client that can handle this? Thanks! :-) -- Use the source, Luke!
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
At Mon, 24 May 2010 14:05:58 +0300, Avi Kivity wrote: On 05/24/2010 10:12 AM, MORITA Kazutaka wrote: At Sun, 23 May 2010 15:01:59 +0300, Avi Kivity wrote: On 05/21/2010 12:29 AM, Anthony Liguori wrote: I'd be more interested in enabling people to build these types of storage systems without touching qemu. Both sheepdog and ceph ultimately transmit I/O over a socket to a central daemon, right? That incurs an extra copy. So could we not standardize a protocol for this that both sheepdog and ceph could implement? The protocol already exists, nbd. It doesn't support snapshotting etc. but we could extend it. I have no objection to use another protocol for Sheepdog support, but I think nbd protocol is unsuitable for the large storage pool with many VM images. It is because nbd protocol doesn't support specifing a file name to open. If we use nbd with such a storage system, the server needs to listen ports as many as the number of VM images. As far as I see the protocol, It looks difficult to extend it without breaking backward compatibility. The server would be local and talk over a unix domain socket, perhaps anonymous. nbd has other issues though, such as requiring a copy and no support for metadata operations such as snapshot and file size extension. Sorry, my explanation was unclear. I'm not sure how running servers on localhost can solve the problem. What I wanted to say was that we cannot specify the image of VM. With nbd protocol, command line arguments are as follows: $ qemu nbd:hostname:port As this syntax shows, with nbd protocol the client cannot pass the VM image name to the server. Regards, Kazutaka
[Qemu-devel] Unable to install Windows XP and 2003 with libvirt
The problem has already been reported on the list here : http://lists.nongnu.org/archive/html/qemu-devel/2010-03/msg01725.html Any information on what can be done to solve that problem ? Is there any available patch for KVM ? Thank you, -- Laurent Léonard
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On 05/24/2010 02:42 PM, MORITA Kazutaka wrote: The server would be local and talk over a unix domain socket, perhaps anonymous. nbd has other issues though, such as requiring a copy and no support for metadata operations such as snapshot and file size extension. Sorry, my explanation was unclear. I'm not sure how running servers on localhost can solve the problem. The local server can convert from the local (nbd) protocol to the remote (sheepdog, ceph) protocol. What I wanted to say was that we cannot specify the image of VM. With nbd protocol, command line arguments are as follows: $ qemu nbd:hostname:port As this syntax shows, with nbd protocol the client cannot pass the VM image name to the server. We would extend it to allow it to connect to a unix domain socket: qemu nbd:unix:/path/to/socket The server at the other end would associate the socket with a filename and forward it to the server using the remote protocol. However, I don't think nbd would be a good protocol. My preference would be for a plugin API, or for a new local protocol that uses splice() to avoid copies. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] Re: [PATCH 1/5] Exit if incoming migration fails
On Mon, May 24, 2010 at 10:25:25AM +0200, Juan Quintela wrote:
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration.c | 14 +++---
migration.h |2 +-
vl.c|5 -
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/migration.c b/migration.c
index 05f6cc5..cf30a8e 100644
--- a/migration.c
+++ b/migration.c
@@ -36,22 +36,22 @@ static uint32_t max_throttle = (32 20);
static MigrationState *current_migration;
-void qemu_start_incoming_migration(const char *uri)
+int qemu_start_incoming_migration(const char *uri)
{
const char *p;
+int ret = -1;
if (strstart(uri, tcp:, p))
-tcp_start_incoming_migration(p);
+ret = tcp_start_incoming_migration(p);
#if !defined(WIN32)
else if (strstart(uri, exec:, p))
-exec_start_incoming_migration(p);
+ret = exec_start_incoming_migration(p);
else if (strstart(uri, unix:, p))
-unix_start_incoming_migration(p);
+ret = unix_start_incoming_migration(p);
else if (strstart(uri, fd:, p))
-fd_start_incoming_migration(p);
+ret = fd_start_incoming_migration(p);
#endif
-else
-fprintf(stderr, unknown migration protocol: %s\n, uri);
I think we need this message, this is where we know
reason for failure is bad protocol.
+return ret;
}
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data)
diff --git a/migration.h b/migration.h
index 385423f..dd423a1 100644
--- a/migration.h
+++ b/migration.h
@@ -50,7 +50,7 @@ struct FdMigrationState
void *opaque;
};
-void qemu_start_incoming_migration(const char *uri);
+int qemu_start_incoming_migration(const char *uri);
int do_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data);
diff --git a/vl.c b/vl.c
index d77b47c..3dfab9e 100644
--- a/vl.c
+++ b/vl.c
@@ -3841,7 +3841,10 @@ int main(int argc, char **argv, char **envp)
}
if (incoming) {
-qemu_start_incoming_migration(incoming);
+if (qemu_start_incoming_migration(incoming) 0) {
+fprintf(stderr, unknown migration protocol: %s\n, incoming);
+exit(1);
+}
Let's put here: 'Migration failed. Exit code %s(%d), exiting.\n'
and then exit(ret);
} else if (autostart) {
vm_start();
}
--
1.6.6.1
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On Mon, 24 May 2010 14:56:29 +0300 Avi Kivity a...@redhat.com wrote: On 05/24/2010 02:42 PM, MORITA Kazutaka wrote: The server would be local and talk over a unix domain socket, perhaps anonymous. nbd has other issues though, such as requiring a copy and no support for metadata operations such as snapshot and file size extension. Sorry, my explanation was unclear. I'm not sure how running servers on localhost can solve the problem. The local server can convert from the local (nbd) protocol to the remote (sheepdog, ceph) protocol. Please note that this shouldn't be relevant to the block driver based on ceph, as it does not use a local daemon -- it connects to the Object Storage Devices directly over the network. Best regards Cláudio
Re: [Qemu-devel] [PATCH 1/2] ioport: add function to check whenever a port is assigned or not
+int is_ioport_assigned(pio_addr_t addr)
Shouldn't we move this into register_ioport_{read,write}, and have that fail
if the port has already been assigned?
Paul
[Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
On Sun, 23 May 2010 09:57:43 +0200 Jan Kiszka jan.kis...@web.de wrote: Avi Kivity wrote: [...] +- full: report full state (json-bool, optional) Is this needed for QMP? The client can always truncate it to any length. The effect may not be needed for QMP, but I do need this channel from the command line to the monitor pretty-printer. I could just stick full: json-bool back into the return dict, but that would look somehow strange IMO. We could have a form of optional key which is only present internally, we have that async commands.
[Qemu-devel] [RFC/ PATCH 0/4] qemu: Extend AIO threading framework to a generic one.
Hi, This patch series is strictly RFC only. It decouples the asynchrnous threading framework implementation from posix-aio-compat.c to implement a generic asynchrnous task offloading threading framework which can be used by other subsystems within QEMU. Currently within QEMU, the AIO subsystem (paio) creates a bunch of asynchronous threads to offload any blocking operations so that the vcpu threads and the IO thread can go back to servicing any other guest requests. We would want to make use of this offloading framework in case of the virtio-9p subsystem, where so that the vcpu thread can offload POSIX operations on to the asynchronous threads and resume servicing any other guest requests. The asynchrnous threads, after finishing the POSIX operations can then transfer the control over to the IO thread so that the latter can handle the post_posix_operation(). The post_posix_operation() could in turn offload more work to be handled by the asynnchronous thread pool or sends the results of the operation to the guest. The patch series also implements a patch that converts v9fs_stat() call to make use of the asynchrnous threading framework. This is an example of how the other calls could be converted eventually. I had a doubt with respect to the original code where the communication between the asynchronous aio threads and the io-thread occurs. In posix-aio-compat.c, we do not do a write(wfd) from the context of the asynchrnous thread, but instead send a SIGUSR2, the handler of which does a write(wfd), thereby causing the iothread blocked on select() to unblock. Why do we send a signal, and not execute whatever aio_signal_handler() is from the context of the asynchronous thread ? Is it to ensure that the io-thread does not miss any write(wfd) ? In this patch series, I have made the virtio-9p make use of SIGUSR1 to mimic similar behaviour. This is just a temporary piece of code to get virtio-9p use the async framework for now. The patch series passed fsstress test without any issues. Awaiting your comments. --- Aneesh Kumar K.V (1): qemu: Generic asynchronous threading framework to offload tasks Gautham R Shenoy (3): qemu: Convert AIO code to use the generic threading infrastructure. virtio-9p: Add async helper functions virtio-9p: convert lstat to use async infrastructure. Makefile.objs |2 + async-work.c | 152 + async-work.h | 85 +++ hw/virtio-9p.c | 195 ++-- hw/virtio-9p.h |4 + posix-aio-compat.c | 155 - 6 files changed, 458 insertions(+), 135 deletions(-) create mode 100644 async-work.c create mode 100644 async-work.h -- Thanks and Regards gautham.
[Qemu-devel] [RFC/ PATCH 1/4] qemu: Generic asynchronous threading framework to offload tasks
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This patch creates a generic asynchronous-task-offloading infrastructure. It's
extracted out of the threading framework that is being used by paio.
The reason for extracting out this generic infrastructure of the
posix-aio-compat.c is so that other subsystems, such as virtio-9p could make use
of it for offloading tasks that could block.
[...@in.ibm.com: work_item_pool, async_work_init, async_work_release,
async_cancel_work]
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
Makefile.objs |2 +
async-work.c | 152 +
async-work.h | 85
3 files changed, 239 insertions(+), 0 deletions(-)
create mode 100644 async-work.c
create mode 100644 async-work.h
diff --git a/Makefile.objs b/Makefile.objs
index ecdd53e..faf3d67 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -9,6 +9,7 @@ qobject-obj-y += qerror.o
block-obj-y = cutils.o cache-utils.o qemu-malloc.o qemu-option.o module.o
block-obj-y += nbd.o block.o aio.o aes.o osdep.o qemu-config.o
+block-obj-y += async-work.o
block-obj-$(CONFIG_POSIX) += posix-aio-compat.o
block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
@@ -44,6 +45,7 @@ fsdev-obj-$(CONFIG_LINUX) += $(addprefix fsdev/,
$(fsdev-nested-y))
# system emulation, i.e. a single QEMU executable should support all
# CPUs and machines.
+#common-obj-y = $(asyncwork-obj-y)
common-obj-y = $(block-obj-y)
common-obj-y += $(net-obj-y)
common-obj-y += $(qobject-obj-y)
diff --git a/async-work.c b/async-work.c
new file mode 100644
index 000..5195bbf
--- /dev/null
+++ b/async-work.c
@@ -0,0 +1,152 @@
+/*
+ * Async work support
+ *
+ * Copyright IBM, Corp. 2010
+ *
+ * Authors:
+ * Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+#include stdio.h
+#include errno.h
+#include string.h
+#include stdlib.h
+#include signal.h
+#include async-work.h
+#include osdep.h
+
+static void async_abort(int err, const char *what)
+{
+fprintf(stderr, %s failed: %s\n, what, strerror(err));
+abort();
+}
+
+static void *async_worker_thread(void *data)
+{
+struct async_queue *queue = data;
+
+while (1) {
+struct work_item *work;
+int ret = 0;
+qemu_timeval tv;
+struct timespec ts;
+
+qemu_gettimeofday(tv);
+ts.tv_sec = tv.tv_sec + 10;
+ts.tv_nsec = 0;
+
+pthread_mutex_lock((queue-lock));
+
+while (QTAILQ_EMPTY((queue-request_list))
+ (ret != ETIMEDOUT)) {
+ret = pthread_cond_timedwait((queue-cond),
+(queue-lock), ts);
+}
+
+if (QTAILQ_EMPTY((queue-request_list)))
+goto check_exit;
+
+work = QTAILQ_FIRST((queue-request_list));
+QTAILQ_REMOVE((queue-request_list), work, node);
+queue-idle_threads--;
+pthread_mutex_unlock((queue-lock));
+
+/* execute the work function */
+work-func(work);
+async_work_release(queue, work);
+
+pthread_mutex_lock((queue-lock));
+queue-idle_threads++;
+
+check_exit:
+if ((queue-idle_threads 0)
+(queue-cur_threads queue-min_threads)) {
+/* we retain minimum number of threads */
+break;
+}
+pthread_mutex_unlock((queue-lock));
+}
+
+queue-idle_threads--;
+queue-cur_threads--;
+pthread_mutex_unlock((queue-lock));
+
+return NULL;
+}
+
+static void spawn_async_thread(struct async_queue *queue)
+{
+int ret;
+pthread_attr_t attr;
+pthread_t thread_id;
+sigset_t set, oldset;
+
+queue-cur_threads++;
+queue-idle_threads++;
+ret = pthread_attr_init(attr);
+if (ret) {
+async_abort(ret, pthread_attr_init);
+}
+
+/* create a detached thread so that we don't need to wait on it */
+ret = pthread_attr_setdetachstate(attr, PTHREAD_CREATE_DETACHED);
+if (ret) {
+async_abort(ret, pthread_attr_setdetachstate);
+}
+
+/* block all signals */
+if (sigfillset(set)) {
+async_abort(errno, sigfillset);
+}
+
+if (sigprocmask(SIG_SETMASK, set, oldset)) {
+async_abort(errno, sigprocmask);
+}
+
+ret = pthread_create(thread_id, attr, async_worker_thread, queue);
+if (ret) {
+async_abort(ret, pthread_create);
+}
+
+if (sigprocmask(SIG_SETMASK, oldset, NULL)) {
+async_abort(errno, sigprocmask restore);
+}
+}
+
+void qemu_async_submit(struct async_queue *queue, struct work_item *work)
+{
+pthread_mutex_lock((queue-lock));
+if (queue-idle_threads == 0 queue-cur_threads queue-max_threads) {
+spawn_async_thread(queue);
+}
+QTAILQ_INSERT_TAIL((queue-request_list), work, node);
+
[Qemu-devel] [RFC/ PATCH 2/4] qemu: Convert AIO code to use the generic threading infrastructure.
This patch makes the paio subsystem use the generic work offloading
infrastructure, there by decoupling asynchronous threading framework portion
out of posix-aio-compat.c
The patch has been tested with fstress.
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
posix-aio-compat.c | 155 ++--
1 files changed, 29 insertions(+), 126 deletions(-)
diff --git a/posix-aio-compat.c b/posix-aio-compat.c
index b43c531..f2e7c6a 100644
--- a/posix-aio-compat.c
+++ b/posix-aio-compat.c
@@ -28,6 +28,7 @@
#include block_int.h
#include block/raw-posix-aio.h
+#include async-work.h
struct qemu_paiocb {
@@ -50,6 +51,7 @@ struct qemu_paiocb {
struct qemu_paiocb *next;
int async_context_id;
+struct work_item *work;
};
typedef struct PosixAioState {
@@ -57,15 +59,8 @@ typedef struct PosixAioState {
struct qemu_paiocb *first_aio;
} PosixAioState;
-
-static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
-static pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
-static pthread_t thread_id;
-static pthread_attr_t attr;
static int max_threads = 64;
-static int cur_threads = 0;
-static int idle_threads = 0;
-static QTAILQ_HEAD(, qemu_paiocb) request_list;
+static struct async_queue aio_request_list;
#ifdef CONFIG_PREADV
static int preadv_present = 1;
@@ -84,39 +79,6 @@ static void die(const char *what)
die2(errno, what);
}
-static void mutex_lock(pthread_mutex_t *mutex)
-{
-int ret = pthread_mutex_lock(mutex);
-if (ret) die2(ret, pthread_mutex_lock);
-}
-
-static void mutex_unlock(pthread_mutex_t *mutex)
-{
-int ret = pthread_mutex_unlock(mutex);
-if (ret) die2(ret, pthread_mutex_unlock);
-}
-
-static int cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex,
- struct timespec *ts)
-{
-int ret = pthread_cond_timedwait(cond, mutex, ts);
-if (ret ret != ETIMEDOUT) die2(ret, pthread_cond_timedwait);
-return ret;
-}
-
-static void cond_signal(pthread_cond_t *cond)
-{
-int ret = pthread_cond_signal(cond);
-if (ret) die2(ret, pthread_cond_signal);
-}
-
-static void thread_create(pthread_t *thread, pthread_attr_t *attr,
- void *(*start_routine)(void*), void *arg)
-{
-int ret = pthread_create(thread, attr, start_routine, arg);
-if (ret) die2(ret, pthread_create);
-}
-
static ssize_t handle_aiocb_ioctl(struct qemu_paiocb *aiocb)
{
int ret;
@@ -300,47 +262,27 @@ static ssize_t handle_aiocb_rw(struct qemu_paiocb *aiocb)
return nbytes;
}
-static void *aio_thread(void *unused)
+static void aio_thread(struct work_item *work)
{
-pid_t pid;
-pid = getpid();
-
-while (1) {
-struct qemu_paiocb *aiocb;
-ssize_t ret = 0;
-qemu_timeval tv;
-struct timespec ts;
-
-qemu_gettimeofday(tv);
-ts.tv_sec = tv.tv_sec + 10;
-ts.tv_nsec = 0;
-
-mutex_lock(lock);
+pid_t pid;
-while (QTAILQ_EMPTY(request_list)
- !(ret == ETIMEDOUT)) {
-ret = cond_timedwait(cond, lock, ts);
-}
+struct qemu_paiocb *aiocb = (struct qemu_paiocb *) work-private;
+ssize_t ret = 0;
-if (QTAILQ_EMPTY(request_list))
-break;
+pid = getpid();
-aiocb = QTAILQ_FIRST(request_list);
-QTAILQ_REMOVE(request_list, aiocb, node);
-aiocb-active = 1;
-idle_threads--;
-mutex_unlock(lock);
+aiocb-active = 1;
-switch (aiocb-aio_type QEMU_AIO_TYPE_MASK) {
-case QEMU_AIO_READ:
-case QEMU_AIO_WRITE:
+switch (aiocb-aio_type QEMU_AIO_TYPE_MASK) {
+case QEMU_AIO_READ:
+case QEMU_AIO_WRITE:
ret = handle_aiocb_rw(aiocb);
break;
-case QEMU_AIO_FLUSH:
-ret = handle_aiocb_flush(aiocb);
-break;
-case QEMU_AIO_IOCTL:
+case QEMU_AIO_FLUSH:
+ret = handle_aiocb_flush(aiocb);
+break;
+case QEMU_AIO_IOCTL:
ret = handle_aiocb_ioctl(aiocb);
break;
default:
@@ -349,57 +291,28 @@ static void *aio_thread(void *unused)
break;
}
-mutex_lock(lock);
-aiocb-ret = ret;
-idle_threads++;
-mutex_unlock(lock);
-
-if (kill(pid, aiocb-ev_signo)) die(kill failed);
-}
-
-idle_threads--;
-cur_threads--;
-mutex_unlock(lock);
+aiocb-ret = ret;
-return NULL;
-}
-
-static void spawn_thread(void)
-{
-sigset_t set, oldset;
-
-cur_threads++;
-idle_threads++;
-
-/* block all signals */
-if (sigfillset(set)) die(sigfillset);
-if (sigprocmask(SIG_SETMASK, set, oldset)) die(sigprocmask);
-
-thread_create(thread_id, attr, aio_thread, NULL);
-
-if (sigprocmask(SIG_SETMASK, oldset, NULL)) die(sigprocmask restore);
+if (kill(pid, aiocb-ev_signo)) die(kill failed);
}
static void qemu_paio_submit(struct qemu_paiocb *aiocb)
{
[Qemu-devel] [RFC/ PATCH 3/4] virtio-9p: Add async helper functions
Add helper functions to enable virtio-9p make use of the generic asynchronous
threading framework for offloading blocking tasks such as making posix calls on
to the asynchronous threads and handle the post_posix_operations() from the
context of the iothread. This frees the vcpu thread to process any other guest
operations while the processing of v9fs_io is in progress.
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
hw/virtio-9p.c | 167
1 files changed, 167 insertions(+), 0 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 82bb663..f8f60d3 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -17,10 +17,147 @@
#include virtio-9p.h
#include fsdev/qemu-fsdev.h
#include virtio-9p-debug.h
+#include async-work.h
int dotu = 1;
int debug_9p_pdu;
+struct v9fs_post_op {
+QTAILQ_ENTRY(v9fs_post_op) node;
+void (*func)(void *arg);
+void *arg;
+};
+
+static struct {
+struct async_queue virtio_9p_aqueue;
+int rfd;
+int wfd;
+pthread_mutex_t lock;
+QTAILQ_HEAD(, v9fs_post_op) post_op_list;
+} v9fs_async_struct;
+
+static void die2(int err, const char *what)
+{
+fprintf(stderr, %s failed: %s\n, what, strerror(err));
+abort();
+}
+
+static void die(const char *what)
+{
+die2(errno, what);
+}
+
+/**
+ * v9fs_signal_handler: Handle the SIGUSR1 signal.
+ * @signum: Is SIGUSR1 in this case.
+ *
+ * This function is used to inform the iothread that a particular
+ * async-operation pertaining to v9fs has been completed and that the io thread
+ * can handle the v9fs_post_posix_operation.
+ *
+ * This is based on the aio_signal_handler
+ */
+static void v9fs_signal_handler(int signum)
+{
+char byte = 0;
+ssize_t ret;
+
+printf(Writing to file descriptor %d\n, v9fs_async_struct.wfd);
+ret = write(v9fs_async_struct.wfd, byte, sizeof(byte));
+
+if (ret 0 errno != EAGAIN)
+die(write() in v9fs);
+
+qemu_service_io();
+}
+
+#define ASYNC_MAX_PROCESS 5
+
+/**
+ * v9fs_process_post_ops: Process any pending v9fs_post_posix_operation
+ * @arg: Not used.
+ *
+ * This function serves as a callback to the iothread to be called into
whenever
+ * the v9fs_async_struct.wfd is written into. This thread goes through the list
+ * of v9fs_post_posix_operations() and executes them. In the process, it might
+ * queue more job on the asynchronous thread pool.
+ */
+static void v9fs_process_post_ops(void *arg)
+{
+int count = 0;
+struct v9fs_post_op *post_op;
+
+pthread_mutex_lock(v9fs_async_struct.lock);
+for (count = 0; count ASYNC_MAX_PROCESS; count++) {
+if (QTAILQ_EMPTY((v9fs_async_struct.post_op_list))) {
+break;
+}
+post_op = QTAILQ_FIRST((v9fs_async_struct.post_op_list));
+QTAILQ_REMOVE((v9fs_async_struct.post_op_list), post_op, node);
+
+pthread_mutex_unlock(v9fs_async_struct.lock);
+post_op-func(post_op-arg);
+qemu_free(post_op);
+pthread_mutex_lock(v9fs_async_struct.lock);
+}
+pthread_mutex_unlock(v9fs_async_struct.lock);
+}
+
+/**
+ * v9fs_async_signal: Send a signal to the iothread.
+ * @func: v9fs_post_posix_func() to be called by the iothread.
+ * @arg: Argument to func.
+ *
+ * This function is called from the context of one of the asynchronous threads
+ * in the thread pool. This is called when the asynchronous thread has finished
+ * executing a v9fs_posix_operation. It's purpose is to initiate the process of
+ * informing the iothread that the v9fs_posix_operation has completed.
+ *
+ * This code follows the suit of the aio_thread() and uses SIGUSR1 to notify
the
+ * iothread.
+ */
+static void v9fs_async_signal(void (*func)(void *arg), void *arg)
+{
+struct v9fs_post_op *post_op;
+pid_t pid = getpid();
+
+post_op = qemu_mallocz(sizeof(*post_op));
+post_op-func = func;
+post_op-arg = arg;
+
+pthread_mutex_lock(v9fs_async_struct.lock);
+QTAILQ_INSERT_TAIL((v9fs_async_struct.post_op_list), post_op, node);
+pthread_mutex_unlock(v9fs_async_struct.lock);
+
+if(kill(pid, SIGUSR1)) die(v9fs kill failed);
+}
+
+/**
+ * v9fs_do_async_posix: Offload v9fs_posix_operation onto async thread.
+ * @vs: V9fsOPState variable for the OP operation.
+ * @posix_fn: The posix function which has to be offloaded onto async thread.
+ * @post_fn_ptr: Address of the location to hold the post_fn corresponding to
+ * the posix_fn
+ * @post_fn: The post_fn corresponding to the posix_fn.
+ *
+ * This function is a helper to offload posix_operation on to the asynchronous
+ * thread pool. It sets up the associations with the post_function that needs
to
+ * be invoked by from the context of the iothread once the posix_fn has been
+ * executed.
+ */
+static void v9fs_do_async_posix(void *vs ,
+void (*posix_fn)(struct work_item *work),
+void (**post_fn_ptr)(void *arg),
+
[Qemu-devel] [RFC/ PATCH 4/4] virtio-9p: convert lstat to use async infrastructure.
This patch converts v9fs_stat() to make use of the async infrastructure.
Every call to v9fs_stat() is processed in the context of the vcpu thread before
offloading the actual stat operation onto an async-thread. The post operation is
handled in the context of the io-thread which in turn does the complete()
operation for this particular v9fs_stat() operation.
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
hw/virtio-9p.c | 34 ++
hw/virtio-9p.h |4
2 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index f8f60d3..a57fffc 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -1218,26 +1218,38 @@ out:
v9fs_string_free(aname);
}
-static void v9fs_stat_post_lstat(V9fsState *s, V9fsStatState *vs, int err)
+static void v9fs_stat_post_lstat(void *opaque)
{
-if (err == -1) {
-err = -errno;
+V9fsStatState *vs = (V9fsStatState *)opaque;
+
+if (vs-err == -1) {
+vs-err = -(vs-v9fs_errno);
goto out;
}
-err = stat_to_v9stat(s, vs-fidp-path, vs-stbuf, vs-v9stat);
-if (err) {
+vs-err = stat_to_v9stat(vs-s, vs-fidp-path, vs-stbuf, vs-v9stat);
+if (vs-err) {
goto out;
}
vs-offset += pdu_marshal(vs-pdu, vs-offset, wS, 0, vs-v9stat);
-err = vs-offset;
+vs-err = vs-offset;
out:
-complete_pdu(s, vs-pdu, err);
+complete_pdu(vs-s, vs-pdu, vs-err);
v9fs_stat_free(vs-v9stat);
qemu_free(vs);
}
+static void v9fs_stat_do_lstat(struct work_item *work)
+{
+V9fsStatState *vs = (V9fsStatState *)work-private;
+
+vs-err = v9fs_do_lstat(vs-s, vs-fidp-path, vs-stbuf);
+vs-v9fs_errno = errno;
+
+v9fs_async_signal(vs-post_fn, vs);
+}
+
static void v9fs_stat(V9fsState *s, V9fsPDU *pdu)
{
int32_t fid;
@@ -1247,6 +1259,7 @@ static void v9fs_stat(V9fsState *s, V9fsPDU *pdu)
vs = qemu_malloc(sizeof(*vs));
vs-pdu = pdu;
vs-offset = 7;
+vs-s = s;
memset(vs-v9stat, 0, sizeof(vs-v9stat));
@@ -1258,8 +1271,8 @@ static void v9fs_stat(V9fsState *s, V9fsPDU *pdu)
goto out;
}
-err = v9fs_do_lstat(s, vs-fidp-path, vs-stbuf);
-v9fs_stat_post_lstat(s, vs, err);
+v9fs_do_async_posix(vs, v9fs_stat_do_lstat, vs-post_fn,
+v9fs_stat_post_lstat);
return;
out:
@@ -2559,8 +2572,5 @@ VirtIODevice *virtio_9p_init(DeviceState *dev, V9fsConf
*conf)
/* Create async queue. */
async_queue_init(v9fs_async_struct.virtio_9p_aqueue, 10, 3);
-(void)v9fs_do_async_posix;
-(void)v9fs_async_signal;
-
return s-vdev;
}
diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h
index 992c765..b4a1d46 100644
--- a/hw/virtio-9p.h
+++ b/hw/virtio-9p.h
@@ -173,6 +173,10 @@ typedef struct V9fsStatState {
V9fsStat v9stat;
V9fsFidState *fidp;
struct stat stbuf;
+V9fsState *s;
+int err;
+int v9fs_errno;
+void (*post_fn)(void *arg);
} V9fsStatState;
typedef struct V9fsWalkState {
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
At Mon, 24 May 2010 14:56:29 +0300, Avi Kivity wrote: On 05/24/2010 02:42 PM, MORITA Kazutaka wrote: The server would be local and talk over a unix domain socket, perhaps anonymous. nbd has other issues though, such as requiring a copy and no support for metadata operations such as snapshot and file size extension. Sorry, my explanation was unclear. I'm not sure how running servers on localhost can solve the problem. The local server can convert from the local (nbd) protocol to the remote (sheepdog, ceph) protocol. What I wanted to say was that we cannot specify the image of VM. With nbd protocol, command line arguments are as follows: $ qemu nbd:hostname:port As this syntax shows, with nbd protocol the client cannot pass the VM image name to the server. We would extend it to allow it to connect to a unix domain socket: qemu nbd:unix:/path/to/socket The server at the other end would associate the socket with a filename and forward it to the server using the remote protocol. Thank you for the explanation. Sheepdog could achieve desired behavior by creating socket files for all the VM images when the daemon starts up. However, I don't think nbd would be a good protocol. My preference would be for a plugin API, or for a new local protocol that uses splice() to avoid copies. Both would be okay for Sheepdog. I want to take a suitable approach for qemu. Thanks, Kazutaka
Re: [Qemu-devel] [RFC/ PATCH 1/4] qemu: Generic asynchronous threading framework to offload tasks
On Mon, 24 May 2010, Gautham R Shenoy wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com This patch creates a generic asynchronous-task-offloading infrastructure. It's extracted out of the threading framework that is being used by paio. The reason for extracting out this generic infrastructure of the posix-aio-compat.c is so that other subsystems, such as virtio-9p could make use of it for offloading tasks that could block. [...@in.ibm.com: work_item_pool, async_work_init, async_work_release, async_cancel_work] Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Signed-off-by: Gautham R Shenoy e...@in.ibm.com This patch is rather inconsistent w.r.t. error checking. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [RFC/ PATCH 1/4] qemu: Generic asynchronous threading framework to offload tasks
On Mon, May 24, 2010 at 2:53 PM, Gautham R Shenoy e...@in.ibm.com wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com This patch creates a generic asynchronous-task-offloading infrastructure. It's extracted out of the threading framework that is being used by paio. The reason for extracting out this generic infrastructure of the posix-aio-compat.c is so that other subsystems, such as virtio-9p could make use of it for offloading tasks that could block. Hi, I'm currently working asynchronous-encoding for the VNC server and using that kind of approach (a queue of jobs, with a worker thread). I'll post a RFC patch soon, but I would be happy to move to a generic solution instead of managing my own queue of job. I noticed that you were using directly pthread_* functions. Maybe you should use (and extend) qemu-thread.h to provide some kind of thread abstraction (even if currently qemu-thread is a direct wrapper to pthread). Thanks, -- Corentin Chary http://xf.iksaif.net
[Qemu-devel] [Bug 584143] Re: qemu fails to set hdd serial number
Marking Triaged/Medium. Debian has accepted the patch, and a new
(patched) package is in Unstable. May be considered for SRU-ing into
10.04 LTS, so nominating.
** Changed in: qemu-kvm (Ubuntu)
Importance: Undecided = Medium
** Changed in: qemu-kvm (Ubuntu)
Status: New = Triaged
** Also affects: qemu-kvm (Ubuntu Lucid)
Importance: Undecided
Status: New
--
qemu fails to set hdd serial number
https://bugs.launchpad.net/bugs/584143
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Status in “qemu-kvm” package in Ubuntu: Triaged
Status in “qemu-kvm” source package in Lucid: New
Status in “qemu-kvm” package in Debian: Unknown
Bug description:
The -drive ...,serial=xyz option is broken, at least in 0.12. See Debian
bug#573439, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573439 for details.
The proposed fix from the original reporter:
--- qemu-kvm-0.12.3+dfsg/vl.c 2010-02-26 11:34:00.0 +0900
+++ qemu-kvm-0.12.3+dfsg.old/vl.c 2010-03-11 02:26:00.134217787 +0900
@@ -2397,7 +2397,7 @@
dinfo-on_write_error = on_write_error;
dinfo-opts = opts;
if (serial)
-strncpy(dinfo-serial, serial, sizeof(serial));
+strncpy(dinfo-serial, serial, sizeof(dinfo-serial));
QTAILQ_INSERT_TAIL(drives, dinfo, next);
if (is_extboot) {
extboot_drive = dinfo;
[Qemu-devel] [PATCH 1/6] Create again config-device.h and config.devices.h
This were disabled in (it is reverted by hand because lot of code has
changed since then).
commit a992fe3d0fc185112677286f7a02204d8245b61e
Author: Paul Brook p...@codesourcery.com
Date: Sun Nov 22 16:25:30 2009 +
Makefile dependencies for device configs
Signed-off-by: Juan Quintela quint...@redhat.com
---
Makefile|7 +--
Makefile.target |5 -
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 7986bf6..2501154 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
# Makefile for QEMU.
-GENERATED_HEADERS = config-host.h
+GENERATED_HEADERS = config-host.h config-all-devices.h
ifneq ($(wildcard config-host.mak),)
# Put the all: rule here so that config-host.mak can contain dependencies.
@@ -70,6 +70,9 @@ build-all: $(DOCS) $(TOOLS) recurse-all
config-host.h: config-host.h-timestamp
config-host.h-timestamp: config-host.mak
+config-all-devices.h: config-all-devices.h-timestamp
+config-all-devices.h-timestamp: config-all-devices.mak
+
SUBDIR_RULES=$(patsubst %,subdir-%, $(TARGET_DIRS))
subdir-%: $(GENERATED_HEADERS)
@@ -164,7 +167,7 @@ clean:
distclean: clean
rm -f config-host.mak config-host.h* config-host.ld $(DOCS)
qemu-options.texi qemu-img-cmds.texi qemu-monitor.texi
- rm -f config-all-devices.mak
+ rm -f config-all-devices.mak config-all-devices.h*
rm -f roms/seabios/config.mak roms/vgabios/config.mak
rm -f qemu-{doc,tech}.{info,aux,cp,dvi,fn,info,ky,log,pdf,pg,toc,tp,vr}
for d in $(TARGET_DIRS) libhw32 libhw64 libuser libdis libdis-user; do \
diff --git a/Makefile.target b/Makefile.target
index fda5bf3..3859dd5 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -1,6 +1,6 @@
# -*- Mode: makefile -*-
-GENERATED_HEADERS = config-target.h
+GENERATED_HEADERS = config-target.h config-devices.h
CONFIG_NO_KVM = $(if $(subst n,,$(CONFIG_KVM)),n,y)
include ../config-host.mak
@@ -38,6 +38,9 @@ kvm.o kvm-all.o vhost.o vhost_net.o:
QEMU_CFLAGS+=$(KVM_CFLAGS)
config-target.h: config-target.h-timestamp
config-target.h-timestamp: config-target.mak
+config-devices.h: config-devices.h-timestamp
+config-devices.h-timestamp: config-devices.mak
+
all: $(PROGS)
# Dummy command so that make thinks it has done something
--
1.6.6.1
[Qemu-devel] [PATCH 6/6] Create CONFIG_HPET
Compile hpet.o depending of CONFIG_HPET. Simplify testing for using
this functions once there. Create inline stabs for the exported functions.
Signed-off-by: Juan Quintela quint...@redhat.com
---
Makefile.target|3 ++-
config.h | 10 ++
default-configs/i386-softmmu.mak |1 +
default-configs/x86_64-softmmu.mak |1 +
hw/hpet_emul.h |8 ++--
monitor.c |4 +++-
6 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/Makefile.target b/Makefile.target
index 3859dd5..533327e 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -194,7 +194,8 @@ obj-y += e1000.o
obj-i386-y += vga.o
obj-i386-y += mc146818rtc.o i8259.o pc.o
obj-i386-y += cirrus_vga.o apic.o ioapic.o piix_pci.o
-obj-i386-y += vmmouse.o vmport.o hpet.o
+obj-i386-y += vmmouse.o vmport.o
+obj-i386-$(CONFIG_HPET) += hpet.o
obj-i386-y += device-hotplug.o pci-hotplug.o smbios.o wdt_ib700.o
obj-i386-y += debugcon.o multiboot.o
obj-i386-y += pc_piix.o
diff --git a/config.h b/config.h
index e20f786..7d92cfc 100644
--- a/config.h
+++ b/config.h
@@ -1,2 +1,12 @@
#include config-host.h
#include config-target.h
+
+/* We want to include different config files for specific targets
+ And for the common library. They need a different name because
+ we don't want to rely in paths */
+
+#if defined(NEED_CPU_H)
+#include config-devices.h
+#else
+#include config-all-devices.h
+#endif
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index ed00471..6341ede 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -23,3 +23,4 @@ CONFIG_NE2000_ISA=y
CONFIG_PIIX_PCI=y
CONFIG_SOUND=y
CONFIG_VIRTIO_PCI=y
+CONFIG_HPET=y
diff --git a/default-configs/x86_64-softmmu.mak
b/default-configs/x86_64-softmmu.mak
index 5183203..e1ca587 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -23,3 +23,4 @@ CONFIG_NE2000_ISA=y
CONFIG_PIIX_PCI=y
CONFIG_SOUND=y
CONFIG_VIRTIO_PCI=y
+CONFIG_HPET=y
diff --git a/hw/hpet_emul.h b/hw/hpet_emul.h
index 4f90faa..898364b 100644
--- a/hw/hpet_emul.h
+++ b/hw/hpet_emul.h
@@ -15,13 +15,17 @@
extern int no_hpet;
-#if !defined(TARGET_I386)
+#if !defined(CONFIG_HPET)
static inline bool hpet_in_legacy_mode(void)
{
return false;
}
+static inline void hpet_init(qemu_irq *irq)
+{
+}
+
#else
#define HPET_BASE 0xfed0
@@ -87,6 +91,6 @@ typedef struct HPETState {
extern bool hpet_in_legacy_mode(void);
extern void hpet_init(qemu_irq *irq);
-#endif /* TARGET_I386 */
+#endif /* CONFIG_HPET */
#endif
diff --git a/monitor.c b/monitor.c
index 5975f40..a81de0c 100644
--- a/monitor.c
+++ b/monitor.c
@@ -778,7 +778,7 @@ static void do_info_commands(Monitor *mon, QObject
**ret_data)
*ret_data = QOBJECT(cmd_list);
}
-#if defined(TARGET_I386)
+#if defined(CONFIG_HPET)
static void do_info_hpet_print(Monitor *mon, const QObject *data)
{
monitor_printf(mon, HPET is %s by QEMU\n,
@@ -2610,6 +2610,8 @@ static const mon_cmd_t info_cmds[] = {
.help = show the active virtual memory mappings,
.mhandler.info = mem_info,
},
+#endif
+#if defined(CONFIG_HPET)
{
.name = hpet,
.args_type = ,
--
1.6.6.1
[Qemu-devel] [PATCH 4/6] Make hpet_in_legacy_mode() return 0 for !TARGET_I386
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/hpet_emul.h | 12 ++--
hw/mc146818rtc.c |6 --
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/hw/hpet_emul.h b/hw/hpet_emul.h
index 7e9b610..b6fae0a 100644
--- a/hw/hpet_emul.h
+++ b/hw/hpet_emul.h
@@ -15,6 +15,15 @@
extern int no_hpet;
+#if !defined(TARGET_I386)
+
+static inline uint32_t hpet_in_legacy_mode(void)
+{
+return 0;
+}
+
+#else
+
#define HPET_BASE 0xfed0
#define HPET_CLK_PERIOD 1000ULL /* 1000 femtoseconds == 10ns*/
@@ -76,9 +85,8 @@ typedef struct HPETState {
uint64_t hpet_counter; /* main counter */
} HPETState;
-#if defined TARGET_I386
extern uint32_t hpet_in_legacy_mode(void);
extern void hpet_init(qemu_irq *irq);
-#endif
+#endif /* TARGET_I386 */
#endif
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 571c593..b2af5de 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -101,9 +101,7 @@ static void rtc_irq_raise(qemu_irq irq)
* mode is established while interrupt is raised. We want it to
* be lowered in any case
*/
-#if defined TARGET_I386
if (!hpet_in_legacy_mode())
-#endif
qemu_irq_raise(irq);
}
@@ -148,14 +146,10 @@ static void rtc_timer_update(RTCState *s, int64_t
current_time)
int enable_pie;
period_code = s-cmos_data[RTC_REG_A] 0x0f;
-#if defined TARGET_I386
/* disable periodic timer if hpet is in legacy mode, since interrupts are
* disabled anyway.
*/
enable_pie = !hpet_in_legacy_mode();
-#else
-enable_pie = 1;
-#endif
if (period_code != 0
(((s-cmos_data[RTC_REG_B] REG_B_PIE) enable_pie)
|| ((s-cmos_data[RTC_REG_B] REG_B_SQWE) s-sqw_irq))) {
--
1.6.6.1
[Qemu-devel] Re: [PATCH, RFC 4/4] Compile mc146818 only once
Blue Swirl wrote: 8 compilations less for the full build. Signed-off-by: Blue Swirl blauwir...@gmail.com ... diff --git a/default-configs/sparc64-softmmu.mak b/default-configs/sparc64-softmmu.mak index 1cc3f13..6ab0cf4 100644 --- a/default-configs/sparc64-softmmu.mak +++ b/default-configs/sparc64-softmmu.mak @@ -6,6 +6,7 @@ CONFIG_PTIMER=y CONFIG_VGA_PCI=y CONFIG_SERIAL=y CONFIG_PARALLEL=y +CONFIG_MC146818=y CONFIG_PCKBD=y CONFIG_FDC=y CONFIG_IDE_CORE=y Can be dropped at this chance, sparc64 makes no use of it. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Re: [RFC PATCH] AMD IOMMU emulation
Hi Eduard, On Thu, May 20, 2010 at 04:50:07PM +0300, Eduard - Gabriel Munteanu wrote: + --enable-amd-iommu-emul) amd_iommu=yes + ;; A compile-time option is a good idea. +/* MMIO registers */ +#define MMIO_DEVICE_TABLE 0x +#define MMIO_COMMAND_BASE 0x0008 +#define MMIO_EVENT_BASE 0x0010 +#define MMIO_CONTROL0x0018 +#define MMIO_EXCL_BASE 0x0020 +#define MMIO_EXCL_LIMIT 0x0028 +#define MMIO_COMMAND_HEAD 0x2000 +#define MMIO_COMMAND_TAIL 0x2008 +#define MMIO_EVENT_HEAD 0x2010 +#define MMIO_EVENT_TAIL 0x2018 +#define MMIO_STATUS 0x2020 + +#define MMIO_SIZE 0x2028 This size should be a power-of-two value. In this case probably 0x4000. +#define MMIO_DEVTAB_SIZE_MASK ((1UL 12) - 1) +#define MMIO_DEVTAB_BASE_MASK (((1UL 52) - 1) ~MMIO_DEVTAB_SIZE_MASK) You must use ULL to be 32bit safe. This is also true for the defines below. [...] Otherwise the code looks good so far. Seems like the next step should be some work on a qemu dma-layer where you can hook the translation into. Joerg
[Qemu-devel] Re: [PATCH, RFC 1/4] mc146818: move hpet handling to pc.c
Blue Swirl wrote:
On Sun, May 23, 2010 at 3:40 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
Move hpet_in_legacy_mode check from mc146818.c to pc.c. Remove
the optimization where the periodic timer is disabled if
hpet is in legacy mode.
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
hw/mc146818rtc.c | 37 +++--
hw/mc146818rtc.h |2 ++
hw/pc.c | 32 +++-
3 files changed, 36 insertions(+), 35 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 571c593..e0c33c5 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -27,7 +27,6 @@
#include pc.h
#include apic.h
#include isa.h
-#include hpet_emul.h
#include mc146818rtc.h
//#define DEBUG_CMOS
@@ -94,19 +93,6 @@ typedef struct RTCState {
QEMUTimer *second_timer2;
} RTCState;
-static void rtc_irq_raise(qemu_irq irq)
-{
-/* When HPET is operating in legacy mode, RTC interrupts are disabled
- * We block qemu_irq_raise, but not qemu_irq_lower, in case legacy
- * mode is established while interrupt is raised. We want it to
- * be lowered in any case
- */
-#if defined TARGET_I386
-if (!hpet_in_legacy_mode())
-#endif
-qemu_irq_raise(irq);
-}
-
static void rtc_set_time(RTCState *s);
static void rtc_copy_date(RTCState *s);
@@ -131,7 +117,7 @@ static void rtc_coalesced_timer(void *opaque)
if (s-irq_coalesced != 0) {
apic_reset_irq_delivered();
s-cmos_data[RTC_REG_C] |= 0xc0;
-rtc_irq_raise(s-irq);
+qemu_irq_raise(s-irq);
if (apic_get_irq_delivered()) {
s-irq_coalesced--;
}
@@ -145,19 +131,10 @@ static void rtc_timer_update(RTCState *s,
int64_t current_time)
{
int period_code, period;
int64_t cur_clock, next_irq_clock;
-int enable_pie;
period_code = s-cmos_data[RTC_REG_A] 0x0f;
-#if defined TARGET_I386
-/* disable periodic timer if hpet is in legacy mode, since interrupts
are
- * disabled anyway.
- */
Does some dumb OS we care about (specifically in KVM mode) first enable
the periodic RTC, then discovers the HPET, switches over, forgetting
about the RTC? Otherwise: the guest will get what it deserves (degraded
performance).
No idea. The performance penalty also depends on the trigger frequency.
I think now it is OK to leave it ticking.
We are currently lacking proper RTC routing through ACPI to SCI [1,
Figure 11]. Adding this will add a parallel user of the RTC IRQ line. I
briefly thought about some user registration API for the RTC, but that
appears over-engineered on second thought. Let's go the simple path.
-enable_pie = !hpet_in_legacy_mode();
-#else
-enable_pie = 1;
-#endif
if (period_code != 0
- (((s-cmos_data[RTC_REG_B] REG_B_PIE) enable_pie)
+ ((s-cmos_data[RTC_REG_B] REG_B_PIE)
|| ((s-cmos_data[RTC_REG_B] REG_B_SQWE) s-sqw_irq))) {
if (period_code = 2)
period_code += 7;
@@ -194,14 +171,14 @@ static void rtc_periodic_timer(void *opaque)
if (s-irq_reinject_on_ack_count = RTC_REINJECT_ON_ACK_COUNT)
s-irq_reinject_on_ack_count = 0;
apic_reset_irq_delivered();
-rtc_irq_raise(s-irq);
+qemu_irq_raise(s-irq);
if (!apic_get_irq_delivered()) {
s-irq_coalesced++;
rtc_coalesced_timer_update(s);
}
} else
#endif
-rtc_irq_raise(s-irq);
+qemu_irq_raise(s-irq);
}
if (s-cmos_data[RTC_REG_B] REG_B_SQWE) {
/* Not square wave at all but we don't want 2048Hz interrupts!
@@ -430,7 +407,7 @@ static void rtc_update_second2(void *opaque)
s-cmos_data[RTC_HOURS_ALARM] == s-current_tm.tm_hour)) {
s-cmos_data[RTC_REG_C] |= 0xa0;
-rtc_irq_raise(s-irq);
+qemu_irq_raise(s-irq);
}
}
@@ -438,7 +415,7 @@ static void rtc_update_second2(void *opaque)
s-cmos_data[RTC_REG_C] |= REG_C_UF;
if (s-cmos_data[RTC_REG_B] REG_B_UIE) {
s-cmos_data[RTC_REG_C] |= REG_C_IRQF;
- rtc_irq_raise(s-irq);
+ qemu_irq_raise(s-irq);
}
/* clear update in progress bit */
@@ -588,7 +565,7 @@ static int rtc_initfn(ISADevice *dev)
{
RTCState *s = DO_UPCAST(RTCState, dev, dev);
int base = 0x70;
-int isairq = 8;
+int isairq = RTC_ISA_IRQ;
isa_init_irq(dev, s-irq, isairq);
diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
index 6f46a68..d630485 100644
--- a/hw/mc146818rtc.h
+++ b/hw/mc146818rtc.h
@@ -7,4 +7,6 @@ ISADevice *rtc_init(int base_year);
void rtc_set_memory(ISADevice *dev, int addr, int val);
void rtc_set_date(ISADevice *dev, const struct tm *tm);
+#define RTC_ISA_IRQ 8
+
#endif /* !MC146818RTC_H */
diff --git a/hw/pc.c b/hw/pc.c
index e7f31d3..5a703e1 100644
[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Juan Quintela wrote: Hi This series: a- bring back the support for config-devices.h Paul was the one that removed my previous submission. You can see on the last patch why I want config-devices.h b- move all hpet code to hpet.c/hpet_emul.h In the last patch, I add CONFIG_HPET define, and made everything depending on that define. When we have !CONFIG_HPET we just create stub functions. This was my idea to create config-devices.h in the first place. Paul, if you don't like it, I am open to alternatives. Problem here is that there are devices that we don't want to ship in RHEL for one reason or another. Solutions so far: - use Makefile/ifdefs in calling files trickery: this is ugly as hell and was refused (I sent patches to do that ~1 year ago). I was told to use CONFIG_FOO to disable the full compilation and a config file, like the kernel. Here we go, then Paul removed the config-device.h part, because: Also remove config-devices.h. Code does not and should not care which devices are being built. This is ok, when device is only called through qdev, and then it is trivial to compile out. Notice that that there are another cases where we have to do Makefile tricks just because we don't have config-devices.mak symbols in C-land. See for example Makefile.target CONFIG_NO_KVM = $(if $(subst n,,$(CONFIG_KVM)),n,y) obj-$(CONFIG_KVM) += kvm.o kvm-all.o obj-$(CONFIG_NO_KVM) += kvm-stub.o In this case makes sense to have an stub because there are lots of functions, but in the hpet case there are only two functions that are exported. My problem with the stub file way is that we are going to end with three files by device (foo.c, foo-stub.c, foo.h). Where foo-stub.c is basically trivial. I also removed the info hpet command. I can be convinced that it is better to change its output to HPET is disabled by QEMU or HPET is not present or any other stirng. Comments? Any better suggestion? Unless this is deadly urgent, please hold it back until we sorted out some more fundamental issues with the HPET, specifically ported it to qdev. But I'm also not convinced about the general approach. Except for RHEL packagers, no one seems to gain any benefit from having CONFIG_HPET. The HPET model is still incomplete in has some remaining quicks (hold on for improvements), but that doesn't qualify it for !CONFIG_HPET, specifically as it is deeply hooked into every modern PC. If I was asked, I guess I would nack this switch. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] linux-user mmap bug
On 05/24/2010 07:57 AM, Edgar E. Iglesias wrote: I took a look at the code again and I dont really understand how the particular case when we get a high address from the kernel while mmap_min_addr is busy case is supposed to work :/ In fact, for CRIS it never works on my host. Indeed, there are many cases for which it doesn't work for the Alpha target either. I changed it locally to keep scanning after a wrap until we succeed to allocate a chunk or rewrap (SLOW) but at least I can run dynamically linked CRIS programs again. Yep. My hack had been similar, except that I used the PageDesc tree to help speed things up. But PageDesc is hardly an ideal data structure in which to search, since it quickly devolves into a linear search of the address space. Probably the easiest real fix is to re-read /proc/self/maps each time the mmap_next_start guess fails and the kernel's returned address is out of range. Another is using the MMAP_32BIT flag on x86-64 host whenever a 31-bit address is appropriate for the guest. E.g. mips32, where architecturally the high half of the address space is reserved for kernel mode. See http://www.mail-archive.com/qemu-devel@nongnu.org/msg28924.html for more ideas on the subject. r~
[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Jan Kiszka jan.kis...@web.de wrote: Juan Quintela wrote: Unless this is deadly urgent, please hold it back until we sorted out some more fundamental issues with the HPET, specifically ported it to qdev. This series are independent of the qdev change (it almost don't change hpet code at all). It is basically independent of almost everything else. But I'm also not convinced about the general approach. Except for RHEL packagers, no one seems to gain any benefit from having CONFIG_HPET. This happens to us all the time for lots of devices. And the big problem is that there is no sane way to disable them :( If we can agree in a mechanism to disable them (like this one) or something similar, we could remove it. Our biggest problem with shipping a device is that we are going to support it for 7 years, you can guess why we want to be conservative. The HPET model is still incomplete in has some remaining quicks (hold on for improvements), but that doesn't qualify it for !CONFIG_HPET, specifically as it is deeply hooked into every modern PC. If I was asked, I guess I would nack this switch. Then, what should we do? We already have to disable hpet for 5.4 (1 year ago). It was done with a local hack because it was supposed that for next big release it would have been fixed. Here we are, and device is still not fixed, what to do? Another local patch? Just get upstream to integrate a sane way to disable it and let in enable by default? Notice that this patch was sent against hpet as one example, if we agree that this way of disabling devices is ok, we could disable more devices/have more flexibility. Notice that in general, we (RHEL/KVM) are interested in a small subset of qemu devices. Later, Juan.
[Qemu-devel] Final Notice: Please Review
Hello Candidate, As you know, you have been considered for inclusion in the upcoming 2010 Edition of Who's Who for Executives and Professionals, which is scheduled for publication in late 2010. Despite our efforts to contact you, we have still not received your contact information. Who's Who, publisher of over 350,000 biographies, continues to uphold its reputation as the world's foremost source for biographical reference, with an unmatched dedication to accurate biographical reporting. The publication's editors are now assembling the biographical profiles of today's leaders from a wide range of professional fields into one comprehensive collection. Thousands of researchers at medical, academic, public and corporate libraries, as well as journalists and media professionals, rely upon Who's Who as a daily reference tool for obtaining information about the world's most experienced men and women. Inclusion in the Who's Who directory is considered by many as a signal mark of achievement. To be considered for inclusion in this prestigious registry, you need only provide the requested information by completing our online biographical data form. Please Click Here: (http://ct.ymdirect1.com/rd/cts?d=10007-72952-36324-23676-44798-3045591-0-0-0-1-9971-153) to access your form. You have already been selected based on your current professional standing. The information you provide will be evaluated according to the selection criteria the Who's Who has developed over many years as the world's premier biographical publisher. If your data passes our initial screening, we will prepare your biography. I congratulate you on the achievements that have brought your name to the attention of our editorial committee. We look forward to hearing from you. Please remember: Inclusion of your biography in Who's Who of course carries neither cost nor commitment to you of any sort. Our goal with each new edition is to prepare a biographies spanning the spectrum of noteworthy and accomplished men and women across all areas of the professional world. Sincerely, Brandon Morgan Editor-in-Chief Empire Executive Registries | 34-01 Broadway | Astoria | New York | 11101 | USA Unsubscribe: http://ct.ymdirect1.com/rd/cts?d=10007-72952-36324-23676-44798-3045592-0-0-0-1-9971-153list_id=36324email=qemu-de...@nongnu.orgmessage_id=72952 Privacy Policy: http://ct.ymdirect1.com/rd/cts?d=10007-72952-36324-23676-44798-3045593-0-0-0-1-9971-153 Powered by Yesmail Direct.
[Qemu-devel] [RFC 0/3] Tracing framework for QEMU
Hi all, The following patchset includes a simple implementation for qemu tracing. This introduces a framework for : i) Internal buffers for QEMU, and API for logging traces therein. ii) Tracepoint framework that logs traces to the buffer and also interprets already logged traces. iii) Monitor commands to display logged traces in tracepoint-specific formats, and also for enabling/disabling tracepoints individually. This is *work in progress*. There are known issues that I'm chasing, which includes segfault that happens while transitioning from monitor to guest with tracing enabled. (Will appreciate any pointers if I'm missing the obvious somewhere :-)) Stefan, Thanks for your ideas on tracing ! I'm just posting out a rough cut of whatever I have ready ; We can take the best from both your patches and mine and have something running for qemu tracing. I'll take care of merging pieces together. Looking forward to suggestions.. -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India
[Qemu-devel] [PATCH 1/3]make tdb_hash available
This function is used for hash table lookups by tracepoint framework.
The patch adds trivial changes to reuse it.
Regards,
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
Signed-off by : Prerna (pre...@linux.vnet.ibm.com)
Index: qemu/qdict.c
===
--- qemu.orig/qdict.c
+++ qemu/qdict.c
@@ -56,7 +56,7 @@ QDict *qobject_to_qdict(const QObject *o
* tdb_hash(): based on the hash agorithm from gdbm, via tdb
* (from module-init-tools)
*/
-static unsigned int tdb_hash(const char *name)
+unsigned int tdb_hash(const char *name)
{
unsigned value; /* Used to compute the hash value. */
unsigned i; /* Used to cycle through random values. */
Index: qemu/qdict.h
===
--- qemu.orig/qdict.h
+++ qemu/qdict.h
@@ -46,5 +46,7 @@ const char *qdict_get_str(const QDict *q
int64_t qdict_get_try_int(const QDict *qdict, const char *key,
int64_t err_value);
const char *qdict_get_try_str(const QDict *qdict, const char *key);
+/* Export tdb_hash() for use by trace-framework */
+unsigned int tdb_hash(const char *name);
#endif /* QDICT_H */
[Qemu-devel] [PATCH 2/3] Tracepoint, buffer monitor framework
Patch that implements tracepoint framework + trace buffer + monitor support.
tracing can be enabled at compile time using --enable-trace switch,
which compiles tracing support(all of these).
Monitor commands introduced :
1. info trace : to see contents of trace buffer.
2. info tracepoints : to see available tracepoints and their status.
3. trace [on|off] : to enable / disable trace data collection.
4. tracepoint ABC [on|off] : to enable / disable traces from a specific
tracepoint, eg ABC
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
Signed-off by : Prerna (pre...@linux.vnet.ibm.com)
Index: qemu/monitor.c
===
--- qemu.orig/monitor.c
+++ qemu/monitor.c
@@ -55,7 +55,9 @@
#include json-streamer.h
#include json-parser.h
#include osdep.h
-
+#ifdef CONFIG_QEMU_TRACE
+#include tracepoint.h
+#endif
//#define DEBUG
//#define DEBUG_COMPLETION
@@ -145,6 +147,10 @@ struct Monitor {
#ifdef CONFIG_DEBUG_MONITOR
int print_calls_nr;
#endif
+#ifdef CONFIG_QEMU_TRACE
+struct DebugBuffer *qemu_buf_ptr;
+#endif
+
QError *error;
QLIST_HEAD(,mon_fd_t) fds;
QLIST_ENTRY(Monitor) entry;
@@ -1198,6 +1204,63 @@ static void do_log(Monitor *mon, const Q
cpu_set_log(mask);
}
+#ifdef CONFIG_QEMU_TRACE
+static void do_trace(Monitor *mon, const QDict *qdict)
+{
+const char *option = qdict_get_try_str(qdict, option);
+if (!option || !strncmp(option, on, 3)) {
+ mon-qemu_buf_ptr = qemu_buf;
+initialize_buffer(mon-qemu_buf_ptr);
+} else if (!strncmp(option, off, 4)) {
+ mon-qemu_buf_ptr-enabled = 0;
+} else {
+monitor_printf(mon, Invalid option %s\n, option);
+}
+}
+
+static void do_tracepoint_status(Monitor *mon, const QDict *qdict)
+{
+uint8_t status_num;
+struct tracepoint *t;
+const char *tp_name = qdict_get_str(qdict, name);
+const char *tp_state = qdict_get_str(qdict, option);
+
+if(!mon-qemu_buf_ptr || !mon-qemu_buf_ptr-enabled) {
+monitor_printf(mon, Tracing disabled. Use \trace on\ before this\n);
+ return;
+}
+if(!strncmp(tp_state, on, 3))
+ status_num = 1;
+else {
+ if(!strncmp(tp_state, off, 4))
+ status_num = 0;
+ else {
+ monitor_printf(mon, Invalid option : %s. Use [on|off]\n,
+tp_state);
+ return;
+ }
+ }
+t = find_tracepoint_by_name(tp_name);
+if(t == NULL) {
+monitor_printf(mon, Tracepoint %s does not exist\n, tp_name);
+ return;
+ }
+if(t-state == status_num) {
+monitor_printf(mon, State of Tracepoint %s is already %s\n,
+ tp_name, tp_state);
+ return;
+ }
+/* Do I need a spin_lock here ? */
+t-state = status_num;
+return;
+}
+#else /* CONFIG_QEMU_TRACE */
+static void do_tracepoint_status(Monitor *mon, const QDict *qdict)
+{
+monitor_printf(mon, Internal tracing not compiled\n);
+}
+#endif
+
static void do_singlestep(Monitor *mon, const QDict *qdict)
{
const char *option = qdict_get_try_str(qdict, option);
@@ -2170,6 +2233,42 @@ static void do_info_profile(Monitor *mon
}
#endif
+#ifdef CONFIG_QEMU_TRACE
+
+static void qemu_dump_trace(Monitor *mon, struct DebugEntry *data)
+{
+int i;
+
+char *iter = (char *)data;
+for (i=0; iSLOT_SIZE/sizeof(int); i++)
+ monitor_printf(mon, %c,iter[i]);
+monitor_printf(mon, \n);
+return;
+}
+
+static void do_info_trace(Monitor *mon)
+{
+struct DebugEntry data;
+/* TODO : change def of read to have null return*/
+if(!mon-qemu_buf_ptr || !mon-qemu_buf_ptr-enabled)
+ return;
+
+while(1) {
+ if(!read_trace_from_buffer(mon-qemu_buf_ptr, data))
+ break ;
+ /* qemu_dump_trace() is a simple hex dump */
+// qemu_dump_trace(mon, data);
+ print_trace(data, mon);
+};
+return;
+}
+#else /* CONFIG_QEMU_TRACE */
+static void do_info_trace(Monitor *mon)
+{
+monitor_printf(mon, Internal tracing not compiled\n);
+}
+#endif
+
/* Capture support */
static QLIST_HEAD (capture_list_head, CaptureState) capture_head;
@@ -2779,6 +2878,20 @@ static const mon_cmd_t info_cmds[] = {
.mhandler.info = do_info_roms,
},
{
+.name = trace,
+.args_type = ,
+.params = ,
+.help = show contents of trace buffer,
+.mhandler.info = do_info_trace,
+},
+{
+.name = tracepoint,
+.args_type = ,
+.params = ,
+.help = show contents of trace buffer,
+.mhandler.info = do_info_tracepoint,
+},
+{
.name = NULL,
},
};
@@ -4633,6 +4746,9 @@ void monitor_init(CharDriverState *chr,
QLIST_INSERT_HEAD(mon_list, mon, entry);
if (!default_mon || (flags MONITOR_IS_DEFAULT))
default_mon = mon;
+
+/* Disable trace buffer unless enabled */
+mon-qemu_buf_ptr = NULL;
}
static void bdrv_password_cb(Monitor *mon, const char *password, void *opaque)
Index: qemu/trace-buffer.c
[Qemu-devel] [PATCH 02/10] target-mips: add microMIPS-specific bits to mips-defs.h
There's a new ASE_MICROMIPS instruction flag, and some extra CP0_Config3
fields. The ISA and ISA_ON_EXC fields are specific to microMIPS. The
DSP2P is for version 2 of the DSP ASE.
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/cpu.h |3 +++
target-mips/mips-defs.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 7285636..986d938 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -363,6 +363,9 @@ struct CPUMIPSState {
#define CP0C2_SA 0
int32_t CP0_Config3;
#define CP0C3_M31
+#define CP0C3_ISA_ON_EXC 16
+#define CP0C3_ISA 14
+#define CP0C3_DSP2P 11
#define CP0C3_DSPP 10
#define CP0C3_LPA 7
#define CP0C3_VEIC 6
diff --git a/target-mips/mips-defs.h b/target-mips/mips-defs.h
index c57de02..a7f4697 100644
--- a/target-mips/mips-defs.h
+++ b/target-mips/mips-defs.h
@@ -38,6 +38,7 @@
#defineASE_DSPR2 0x0001
#defineASE_MT 0x0002
#defineASE_SMARTMIPS 0x0004
+#defineASE_MICROMIPS 0x0008
/* Chip specific instructions. */
#defineINSN_VR54XX 0x8000
--
1.6.3.2
[Qemu-devel] [PATCH 03/10] target-mips: add enum constants for various invocations of FOP
Tweak gen_farith and its caller to use them.
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/translate.c | 266 ---
1 files changed, 180 insertions(+), 86 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 2075d09..2568e16 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -5714,6 +5714,100 @@ static void gen_compute_branch1 (CPUState *env,
DisasContext *ctx, uint32_t op,
#define FOP(func, fmt) (((fmt) 21) | (func))
+enum {
+OPC_ADD_S = FOP(0, FMT_S),
+OPC_SUB_S = FOP(1, FMT_S),
+OPC_MUL_S = FOP(2, FMT_S),
+OPC_DIV_S = FOP(3, FMT_S),
+OPC_SQRT_S = FOP(4, FMT_S),
+OPC_ABS_S = FOP(5, FMT_S),
+OPC_MOV_S = FOP(6, FMT_S),
+OPC_NEG_S = FOP(7, FMT_S),
+OPC_ROUND_L_S = FOP(8, FMT_S),
+OPC_TRUNC_L_S = FOP(9, FMT_S),
+OPC_CEIL_L_S = FOP(10, FMT_S),
+OPC_FLOOR_L_S = FOP(11, FMT_S),
+OPC_ROUND_W_S = FOP(12, FMT_S),
+OPC_TRUNC_W_S = FOP(13, FMT_S),
+OPC_CEIL_W_S = FOP(14, FMT_S),
+OPC_FLOOR_W_S = FOP(15, FMT_S),
+OPC_MOVCF_S = FOP(17, FMT_S),
+OPC_MOVZ_S = FOP(18, FMT_S),
+OPC_MOVN_S = FOP(19, FMT_S),
+OPC_RECIP_S = FOP(21, FMT_S),
+OPC_RSQRT_S = FOP(22, FMT_S),
+OPC_RECIP2_S = FOP(28, FMT_S),
+OPC_RECIP1_S = FOP(29, FMT_S),
+OPC_RSQRT1_S = FOP(30, FMT_S),
+OPC_RSQRT2_S = FOP(31, FMT_S),
+OPC_CVT_D_S = FOP(33, FMT_S),
+OPC_CVT_W_S = FOP(36, FMT_S),
+OPC_CVT_L_S = FOP(37, FMT_S),
+OPC_CVT_PS_S = FOP(38, FMT_S),
+/* FOP(48..63, FMT_S) used for comparisons */
+OPC_ADD_D = FOP(0, FMT_D),
+OPC_SUB_D = FOP(1, FMT_D),
+OPC_MUL_D = FOP(2, FMT_D),
+OPC_DIV_D = FOP(3, FMT_D),
+OPC_SQRT_D = FOP(4, FMT_D),
+OPC_ABS_D = FOP(5, FMT_D),
+OPC_MOV_D = FOP(6, FMT_D),
+OPC_NEG_D = FOP(7, FMT_D),
+OPC_ROUND_L_D = FOP(8, FMT_D),
+OPC_TRUNC_L_D = FOP(9, FMT_D),
+OPC_CEIL_L_D = FOP(10, FMT_D),
+OPC_FLOOR_L_D = FOP(11, FMT_D),
+OPC_ROUND_W_D = FOP(12, FMT_D),
+OPC_TRUNC_W_D = FOP(13, FMT_D),
+OPC_CEIL_W_D = FOP(14, FMT_D),
+OPC_FLOOR_W_D = FOP(15, FMT_D),
+OPC_MOVCF_D = FOP(17, FMT_D),
+OPC_MOVZ_D = FOP(18, FMT_D),
+OPC_MOVN_D = FOP(19, FMT_D),
+OPC_RECIP_D = FOP(21, FMT_D),
+OPC_RSQRT_D = FOP(22, FMT_D),
+OPC_RECIP2_D = FOP(28, FMT_D),
+OPC_RECIP1_D = FOP(29, FMT_D),
+OPC_RSQRT1_D = FOP(30, FMT_D),
+OPC_RSQRT2_D = FOP(31, FMT_D),
+OPC_CVT_S_D = FOP(32, FMT_D),
+OPC_CVT_W_D = FOP(36, FMT_D),
+OPC_CVT_L_D = FOP(37, FMT_D),
+/* FOP(48..63, FMT_D) used for comparisons */
+
+OPC_CVT_S_W = FOP(32, FMT_W),
+OPC_CVT_D_W = FOP(33, FMT_W),
+OPC_CVT_S_L = FOP(32, FMT_L),
+OPC_CVT_D_L = FOP(33, FMT_L),
+OPC_CVT_PS_PW = FOP(38, FMT_W),
+
+OPC_ADD_PS = FOP(0, FMT_PS),
+OPC_SUB_PS = FOP(1, FMT_PS),
+OPC_MUL_PS = FOP(2, FMT_PS),
+OPC_DIV_PS = FOP(3, FMT_PS),
+OPC_ABS_PS = FOP(5, FMT_PS),
+OPC_MOV_PS = FOP(6, FMT_PS),
+OPC_NEG_PS = FOP(7, FMT_PS),
+OPC_MOVCF_PS = FOP(17, FMT_PS),
+OPC_MOVZ_PS = FOP(18, FMT_PS),
+OPC_MOVN_PS = FOP(19, FMT_PS),
+OPC_ADDR_PS = FOP(24, FMT_PS),
+OPC_MULR_PS = FOP(26, FMT_PS),
+OPC_RECIP2_PS = FOP(28, FMT_PS),
+OPC_RECIP1_PS = FOP(29, FMT_PS),
+OPC_RSQRT1_PS = FOP(30, FMT_PS),
+OPC_RSQRT2_PS = FOP(31, FMT_PS),
+
+OPC_CVT_S_PU = FOP(32, FMT_PS),
+OPC_CVT_PW_PS = FOP(36, FMT_PS),
+OPC_CVT_S_PL = FOP(40, FMT_PS),
+OPC_PLL_PS = FOP(44, FMT_PS),
+OPC_PLU_PS = FOP(45, FMT_PS),
+OPC_PUL_PS = FOP(46, FMT_PS),
+OPC_PUU_PS = FOP(47, FMT_PS),
+/* FOP(48..63, FMT_PS) used for comparisons */
+};
+
static void gen_cp1 (DisasContext *ctx, uint32_t opc, int rt, int fs)
{
const char *opn = cp1 move;
@@ -5937,8 +6031,8 @@ static void gen_farith (DisasContext *ctx, uint32_t op1,
enum { BINOP, CMPOP, OTHEROP } optype = OTHEROP;
uint32_t func = ctx-opcode 0x3f;
-switch (ctx-opcode FOP(0x3f, 0x1f)) {
-case FOP(0, 16):
+switch (opc) {
+case OPC_ADD_S:
{
TCGv_i32 fp0 = tcg_temp_new_i32();
TCGv_i32 fp1 = tcg_temp_new_i32();
@@ -5953,7 +6047,7 @@ static void gen_farith (DisasContext *ctx, uint32_t op1,
opn = add.s;
optype = BINOP;
break;
-case FOP(1, 16):
+case OPC_SUB_S:
{
TCGv_i32 fp0 = tcg_temp_new_i32();
TCGv_i32 fp1 = tcg_temp_new_i32();
@@ -5968,7 +6062,7 @@ static void gen_farith (DisasContext *ctx, uint32_t op1,
opn = sub.s;
optype = BINOP;
break;
-case FOP(2, 16):
+case OPC_MUL_S:
{
TCGv_i32 fp0 = tcg_temp_new_i32();
TCGv_i32 fp1 = tcg_temp_new_i32();
@@ -5983,7 +6077,7 @@ static void gen_farith (DisasContext *ctx, uint32_t op1,
opn = mul.s;
optype = BINOP;
break;
-case FOP(3, 16):
+case OPC_DIV_S:
{
TCGv_i32 fp0
[Qemu-devel] [PATCH 01/10] target-mips: break out [ls][wd]c1 and rdhwr insn generation
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/translate.c | 106 ++-
1 files changed, 59 insertions(+), 47 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index c95ecb1..2075d09 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -1220,6 +1220,17 @@ static void gen_flt_ldst (DisasContext *ctx, uint32_t
opc, int ft,
tcg_temp_free(t0);
}
+static void gen_cop1_ldst(CPUState *env, DisasContext *ctx,
+ uint32_t op, int rt, int rs, int16_t imm)
+{
+if (env-CP0_Config1 (1 CP0C1_FP)) {
+check_cp1_enabled(ctx);
+gen_flt_ldst(ctx, op, rt, rs, imm);
+} else {
+generate_exception_err(ctx, EXCP_CpU, 1);
+}
+}
+
/* Arithmetic with immediate operand */
static void gen_arith_imm (CPUState *env, DisasContext *ctx, uint32_t opc,
int rt, int rs, int16_t imm)
@@ -7528,6 +7539,52 @@ static void gen_flt3_arith (DisasContext *ctx, uint32_t
opc,
fregnames[fs], fregnames[ft]);
}
+static void
+gen_rdhwr (CPUState *env, DisasContext *ctx, int rt, int rd)
+{
+TCGv t0;
+
+check_insn(env, ctx, ISA_MIPS32R2);
+t0 = tcg_temp_new();
+
+switch (rd) {
+case 0:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_cpunum(t0);
+gen_store_gpr(t0, rt);
+break;
+case 1:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_synci_step(t0);
+gen_store_gpr(t0, rt);
+break;
+case 2:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_cc(t0);
+gen_store_gpr(t0, rt);
+break;
+case 3:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_ccres(t0);
+gen_store_gpr(t0, rt);
+break;
+case 29:
+#if defined(CONFIG_USER_ONLY)
+tcg_gen_ld_tl(t0, cpu_env, offsetof(CPUState, tls_value));
+gen_store_gpr(t0, rt);
+break;
+#else
+/* XXX: Some CPUs implement this in hardware.
+ Not supported yet. */
+#endif
+default:/* Invalid */
+MIPS_INVAL(rdhwr);
+generate_exception(ctx, EXCP_RI);
+break;
+}
+tcg_temp_free(t0);
+}
+
static void handle_delay_slot (CPUState *env, DisasContext *ctx,
int insn_bytes)
{
@@ -8999,47 +9056,7 @@ static void decode_opc (CPUState *env, DisasContext
*ctx, int *is_branch)
gen_bshfl(ctx, op2, rt, rd);
break;
case OPC_RDHWR:
-check_insn(env, ctx, ISA_MIPS32R2);
-{
-TCGv t0 = tcg_temp_new();
-
-switch (rd) {
-case 0:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_cpunum(t0);
-gen_store_gpr(t0, rt);
-break;
-case 1:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_synci_step(t0);
-gen_store_gpr(t0, rt);
-break;
-case 2:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_cc(t0);
-gen_store_gpr(t0, rt);
-break;
-case 3:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_ccres(t0);
-gen_store_gpr(t0, rt);
-break;
-case 29:
-#if defined(CONFIG_USER_ONLY)
-tcg_gen_ld_tl(t0, cpu_env, offsetof(CPUState, tls_value));
-gen_store_gpr(t0, rt);
-break;
-#else
-/* XXX: Some CPUs implement this in hardware.
- Not supported yet. */
-#endif
-default:/* Invalid */
-MIPS_INVAL(rdhwr);
-generate_exception(ctx, EXCP_RI);
-break;
-}
-tcg_temp_free(t0);
-}
+gen_rdhwr(env, ctx, rt, rd);
break;
case OPC_FORK:
check_insn(env, ctx, ASE_MT);
@@ -9242,12 +9259,7 @@ static void decode_opc (CPUState *env, DisasContext
*ctx, int *is_branch)
case OPC_LDC1:
case OPC_SWC1:
case OPC_SDC1:
-if (env-CP0_Config1 (1 CP0C1_FP)) {
-check_cp1_enabled(ctx);
-gen_flt_ldst(ctx, op, rt, rs, imm);
-} else {
-generate_exception_err(ctx, EXCP_CpU, 1);
-}
+gen_cop1_ldst(env, ctx, op, rt, rs, imm);
break;
case OPC_CP1:
--
1.6.3.2
[Qemu-devel] [PATCH 05/10] target-mips: small changes to use new FMT_ enums
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/translate.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 63844b8..cc445fb 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -359,7 +359,8 @@ enum {
/* 0 - 15 are reserved */
FMT_S = 16,
FMT_D = 17,
-/* 18 - 19 are reserved */
+FMT_E = 18,
+FMT_Q = 19,
FMT_W = 20,
FMT_L = 21,
FMT_PS = 22,
@@ -378,13 +379,13 @@ enum {
OPC_BC1 = (0x08 21) | OPC_CP1, /* bc */
OPC_BC1ANY2 = (0x09 21) | OPC_CP1,
OPC_BC1ANY4 = (0x0A 21) | OPC_CP1,
-OPC_S_FMT= (0x10 21) | OPC_CP1, /* 16: fmt=single fp */
-OPC_D_FMT= (0x11 21) | OPC_CP1, /* 17: fmt=double fp */
-OPC_E_FMT= (0x12 21) | OPC_CP1, /* 18: fmt=extended fp */
-OPC_Q_FMT= (0x13 21) | OPC_CP1, /* 19: fmt=quad fp */
-OPC_W_FMT= (0x14 21) | OPC_CP1, /* 20: fmt=32bit fixed */
-OPC_L_FMT= (0x15 21) | OPC_CP1, /* 21: fmt=64bit fixed */
-OPC_PS_FMT = (0x16 21) | OPC_CP1, /* 22: fmt=paired single fp */
+OPC_S_FMT= (FMT_S 21) | OPC_CP1, /* 16: fmt=single fp */
+OPC_D_FMT= (FMT_D 21) | OPC_CP1, /* 17: fmt=double fp */
+OPC_E_FMT= (FMT_E 21) | OPC_CP1, /* 18: fmt=extended fp */
+OPC_Q_FMT= (FMT_Q 21) | OPC_CP1, /* 19: fmt=quad fp */
+OPC_W_FMT= (FMT_W 21) | OPC_CP1, /* 20: fmt=32bit fixed */
+OPC_L_FMT= (FMT_L 21) | OPC_CP1, /* 21: fmt=64bit fixed */
+OPC_PS_FMT = (FMT_PS 21) | OPC_CP1, /* 22: fmt=paired single fp */
};
#define MASK_CP1_FUNC(op) MASK_CP1(op) | (op 0x3F)
--
1.6.3.2
[Qemu-devel] [PATCH 04/10] target-mips: refactor {c, abs}.cond.fmt insns
Move all knowledge about coprocessor-checking and register numbering
into the gen_cmp* helper functions.
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/translate.c | 174 --
1 files changed, 91 insertions(+), 83 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 2568e16..63844b8 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -354,6 +354,18 @@ enum {
/* Coprocessor 1 (rs field) */
#define MASK_CP1(op) MASK_OP_MAJOR(op) | (op (0x1F 21))
+/* Values for the fmt field in FP instructions */
+enum {
+/* 0 - 15 are reserved */
+FMT_S = 16,
+FMT_D = 17,
+/* 18 - 19 are reserved */
+FMT_W = 20,
+FMT_L = 21,
+FMT_PS = 22,
+/* 23 - 31 are reserved */
+};
+
enum {
OPC_MFC1 = (0x00 21) | OPC_CP1,
OPC_DMFC1= (0x01 21) | OPC_CP1,
@@ -663,39 +675,6 @@ static inline int get_fp_bit (int cc)
return 23;
}
-#define FOP_CONDS(type, fmt, bits)\
-static inline void gen_cmp ## type ## _ ## fmt(int n, TCGv_i##bits a, \
- TCGv_i##bits b, int cc)\
-{ \
-switch (n) { \
-case 0: gen_helper_2i(cmp ## type ## _ ## fmt ## _f, a, b, cc);break;\
-case 1: gen_helper_2i(cmp ## type ## _ ## fmt ## _un, a, b, cc); break;\
-case 2: gen_helper_2i(cmp ## type ## _ ## fmt ## _eq, a, b, cc); break;\
-case 3: gen_helper_2i(cmp ## type ## _ ## fmt ## _ueq, a, b, cc); break;\
-case 4: gen_helper_2i(cmp ## type ## _ ## fmt ## _olt, a, b, cc); break;\
-case 5: gen_helper_2i(cmp ## type ## _ ## fmt ## _ult, a, b, cc); break;\
-case 6: gen_helper_2i(cmp ## type ## _ ## fmt ## _ole, a, b, cc); break;\
-case 7: gen_helper_2i(cmp ## type ## _ ## fmt ## _ule, a, b, cc); break;\
-case 8: gen_helper_2i(cmp ## type ## _ ## fmt ## _sf, a, b, cc); break;\
-case 9: gen_helper_2i(cmp ## type ## _ ## fmt ## _ngle, a, b, cc); break;\
-case 10: gen_helper_2i(cmp ## type ## _ ## fmt ## _seq, a, b, cc); break;\
-case 11: gen_helper_2i(cmp ## type ## _ ## fmt ## _ngl, a, b, cc); break;\
-case 12: gen_helper_2i(cmp ## type ## _ ## fmt ## _lt, a, b, cc); break;\
-case 13: gen_helper_2i(cmp ## type ## _ ## fmt ## _nge, a, b, cc); break;\
-case 14: gen_helper_2i(cmp ## type ## _ ## fmt ## _le, a, b, cc); break;\
-case 15: gen_helper_2i(cmp ## type ## _ ## fmt ## _ngt, a, b, cc); break;\
-default: abort(); \
-} \
-}
-
-FOP_CONDS(, d, 64)
-FOP_CONDS(abs, d, 64)
-FOP_CONDS(, s, 32)
-FOP_CONDS(abs, s, 32)
-FOP_CONDS(, ps, 64)
-FOP_CONDS(abs, ps, 64)
-#undef FOP_CONDS
-
/* Tests */
static inline void gen_save_pc(target_ulong pc)
{
@@ -836,6 +815,67 @@ static inline void check_mips_64(DisasContext *ctx)
generate_exception(ctx, EXCP_RI);
}
+/* Define small wrappers for gen_load_fpr* so that we have a uniform
+ calling interface for 32 and 64-bit FPRs. No sense in changing
+ all callers for gen_load_fpr32 when we need the CTX parameter for
+ this one use. */
+#define gen_ldcmp_fpr32(ctx, x, y) gen_load_fpr32(x, y)
+#define gen_ldcmp_fpr64(ctx, x, y) gen_load_fpr64(ctx, x, y)
+#define FOP_CONDS(type, abs, fmt, ifmt, bits) \
+static inline void gen_cmp ## type ## _ ## fmt(DisasContext *ctx, int n, \
+ int ft, int fs, int cc)\
+{ \
+TCGv_i##bits fp0 = tcg_temp_new_i##bits (); \
+TCGv_i##bits fp1 = tcg_temp_new_i##bits (); \
+switch (ifmt) { \
+case FMT_PS: \
+check_cp1_64bitmode(ctx); \
+break;\
+case FMT_D: \
+if (abs) \
+check_cop1x(ctx); \
+check_cp1_registers(ctx, fs | ft);\
+break;\
+case FMT_S: \
+if (abs) \
+check_cop1x(ctx);
[Qemu-devel] [PATCH 00/10] target-mips: add microMIPS ASE support, v2
This patch series adds support for the microMIPS ASE. microMIPS is a
new ASE similar to MIPS16, but re-encodes the entire instruction set
into 16-bit and 32-bit instructions--in contrast to MIPS16, which
re-encodes only integer instructions. The mechanisms for going in and
out of microMIPS mode are identical to those for MIPS16; a given chip
cannot support both ASEs simultaneously.
changes from v1:
fix re-introduction of previously deleted code noted by rth
Nathan Froyd (10):
target-mips: break out [ls][wd]c1 and rdhwr insn generation
target-mips: add microMIPS-specific bits to mips-defs.h
target-mips: add enum constants for various invocations of FOP
target-mips: refactor {c,abs}.cond.fmt insns
target-mips: small changes to use new FMT_ enums
target-mips: add microMIPS ASE support
target-mips: add microMIPS CPUs
target-mips: add microMIPS exception handler support
linux-user: honor low bit of entry PC for MIPS
hw: honor low bit in mipssim machine
hw/mips_mipssim.c|4 +-
linux-user/main.c|4 +-
target-mips/cpu.h|3 +
target-mips/helper.c | 21 +-
target-mips/helper.h |9 +
target-mips/mips-defs.h |1 +
target-mips/op_helper.c | 136 ++
target-mips/translate.c | 3050 ++
target-mips/translate_init.c | 61 +
9 files changed, 3047 insertions(+), 242 deletions(-)
[Qemu-devel] [PATCH 10/10] hw: honor low bit in mipssim machine
Signed-off-by: Nathan Froyd froy...@codesourcery.com --- hw/mips_mipssim.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c index a747de5..cd6c2be 100644 --- a/hw/mips_mipssim.c +++ b/hw/mips_mipssim.c @@ -106,7 +106,9 @@ static void main_cpu_reset(void *opaque) CPUState *env = s-env; cpu_reset(env); -env-active_tc.PC = s-vector; +env-active_tc.PC = s-vector ~(target_ulong)1; +if (s-vector 1) +env-hflags |= MIPS_HFLAG_M16; } static void -- 1.6.3.2
[Qemu-devel] [PATCH 08/10] target-mips: add microMIPS exception handler support
Unlike MIPS16, microMIPS lets you choose the ISA mode for your exception
handlers.
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/helper.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/target-mips/helper.c b/target-mips/helper.c
index 8102f03..90c3b3a 100644
--- a/target-mips/helper.c
+++ b/target-mips/helper.c
@@ -385,6 +385,18 @@ static target_ulong exception_resume_pc (CPUState *env)
return bad_pc;
}
+static void set_hflags_for_handler (CPUState *env)
+{
+/* Exception handlers are entered in 32-bit mode. */
+env-hflags = ~(MIPS_HFLAG_M16);
+/* ...except that microMIPS lets you choose. */
+if (env-insn_flags ASE_MICROMIPS) {
+env-hflags |= (!!(env-CP0_Config3
+(1 CP0C3_ISA_ON_EXC))
+ MIPS_HFLAG_M16_SHIFT);
+}
+}
+
#endif
void do_interrupt (CPUState *env)
@@ -440,8 +452,7 @@ void do_interrupt (CPUState *env)
if (!(env-CP0_Status (1 CP0St_EXL)))
env-CP0_Cause = ~(1 CP0Ca_BD);
env-active_tc.PC = (int32_t)0xBFC00480;
-/* Exception handlers are entered in 32-bit mode. */
-env-hflags = ~(MIPS_HFLAG_M16);
+set_hflags_for_handler(env);
break;
case EXCP_RESET:
cpu_reset(env);
@@ -461,8 +472,7 @@ void do_interrupt (CPUState *env)
if (!(env-CP0_Status (1 CP0St_EXL)))
env-CP0_Cause = ~(1 CP0Ca_BD);
env-active_tc.PC = (int32_t)0xBFC0;
-/* Exception handlers are entered in 32-bit mode. */
-env-hflags = ~(MIPS_HFLAG_M16);
+set_hflags_for_handler(env);
break;
case EXCP_EXT_INTERRUPT:
cause = 0;
@@ -581,8 +591,7 @@ void do_interrupt (CPUState *env)
env-active_tc.PC = (int32_t)(env-CP0_EBase ~0x3ff);
}
env-active_tc.PC += offset;
-/* Exception handlers are entered in 32-bit mode. */
-env-hflags = ~(MIPS_HFLAG_M16);
+set_hflags_for_handler(env);
env-CP0_Cause = (env-CP0_Cause ~(0x1f CP0Ca_EC)) | (cause
CP0Ca_EC);
break;
default:
--
1.6.3.2
[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Notice that this patch was sent against hpet as one example, if we agree that this way of disabling devices is ok, we could disable more devices/have more flexibility. Notice that in general, we (RHEL/KVM) are interested in a small subset of qemu devices. IMO this patch is a backwards step. The device models should be cleaned up so that you don't need to make a compile time decision. You'll notice that a fair amount of effort has been put into making the device/system code less tightly coupled and less machine specific. All inter-device interaction and links should be explicit. Changing from PC with HPET and PC without HPET should not require recompiling anything, and devices shouldn't need to know or care which they're part of. Paul
[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Juan Quintela wrote: Jan Kiszka jan.kis...@web.de wrote: Juan Quintela wrote: Unless this is deadly urgent, please hold it back until we sorted out some more fundamental issues with the HPET, specifically ported it to qdev. This series are independent of the qdev change (it almost don't change hpet code at all). It is basically independent of almost everything else. It causes mechanical breakage to the qdev change (and the one I'm hacking on ATM). But I'm also not convinced about the general approach. Except for RHEL packagers, no one seems to gain any benefit from having CONFIG_HPET. This happens to us all the time for lots of devices. And the big problem is that there is no sane way to disable them :( If we can agree in a mechanism to disable them (like this one) or something similar, we could remove it. Our biggest problem with shipping a device is that we are going to support it for 7 years, you can guess why we want to be conservative. In this particular case, it is a one line patch: no_hpet = 1;, hardwired. The HPET model is still incomplete in has some remaining quicks (hold on for improvements), but that doesn't qualify it for !CONFIG_HPET, specifically as it is deeply hooked into every modern PC. If I was asked, I guess I would nack this switch. Then, what should we do? Help fixing it (e.g. testers will soon be welcome). We already have to disable hpet for 5.4 (1 year ago). It was done with a local hack because it was supposed that for next big release it would have been fixed. But this remains a RHEL issue. Redhat decided to compile out features that are unsupported, others seem to handle this differently. Here we are, and device is still not fixed, what to do? Another local patch? Just get upstream to integrate a sane way to disable it and let in enable by default? Let's start with listing your requirements to no longer disable HPET. That would already help us to asses how long !CONFIG_HPET would actually be of any use at all. I'm yet optimistic that we can resolve most if not all remaining concerns for 0.13 - and CONFIG_HPET would at best be 0.13 material anyway. Notice that this patch was sent against hpet as one example, if we agree that this way of disabling devices is ok, we could disable more devices/have more flexibility. Notice that in general, we (RHEL/KVM) are interested in a small subset of qemu devices. At least HPET is IMHO a bad example as it is, just like e.g. the IOAPIC, an essential part of today's x86 systems. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH 07/10] target-mips: add microMIPS CPUs
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
target-mips/translate_init.c | 61 ++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
index b79ed56..8e17f4b 100644
--- a/target-mips/translate_init.c
+++ b/target-mips/translate_init.c
@@ -141,6 +141,25 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_FMT,
},
{
+.name = 4Km-micromips,
+.CP0_PRid = 0x00018300,
+/* Config1 implemented, fixed mapping MMU,
+ no virtual icache, uncached coherency. */
+.CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_FMT CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 |
+ (0 CP0C1_IS) | (3 CP0C1_IL) | (1 CP0C1_IA) |
+ (0 CP0C1_DS) | (3 CP0C1_DL) | (1 CP0C1_DA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3,
+.SYNCI_Step = 32,
+.CCRes = 2,
+.CP0_Status_rw_bitmask = 0x1258FF17,
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
+.mmu_type = MMU_TYPE_FMT,
+},
+{
.name = 4KEcR1,
.CP0_PRid = 0x00018400,
.CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_R4000 CP0C0_MT),
@@ -245,6 +264,25 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_R4000,
},
{
+.name = 24Kc-micromips,
+.CP0_PRid = 0x00019300,
+.CP0_Config0 = MIPS_CONFIG0 | (0x1 CP0C0_AR) |
+(MMU_TYPE_R4000 CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 | (15 CP0C1_MMU) |
+ (0 CP0C1_IS) | (3 CP0C1_IL) | (1 CP0C1_IA) |
+ (0 CP0C1_DS) | (3 CP0C1_DL) | (1 CP0C1_DA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3 | (0 CP0C3_VInt),
+.SYNCI_Step = 32,
+.CCRes = 2,
+/* No DSP implemented. */
+.CP0_Status_rw_bitmask = 0x1278FF1F,
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
+.mmu_type = MMU_TYPE_R4000,
+},
+{
.name = 24Kf,
.CP0_PRid = 0x00019300,
.CP0_Config0 = MIPS_CONFIG0 | (0x1 CP0C0_AR) |
@@ -269,6 +307,29 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_R4000,
},
{
+.name = 24Kf-micromips,
+.CP0_PRid = 0x00019300,
+.CP0_Config0 = MIPS_CONFIG0 | (0x1 CP0C0_AR) |
+(MMU_TYPE_R4000 CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 | (1 CP0C1_FP) | (15 CP0C1_MMU) |
+ (0 CP0C1_IS) | (3 CP0C1_IL) | (1 CP0C1_IA) |
+ (0 CP0C1_DS) | (3 CP0C1_DL) | (1 CP0C1_DA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3 | (0 CP0C3_VInt),
+.CP0_LLAddr_rw_bitmask = 0,
+.CP0_LLAddr_shift = 4,
+.SYNCI_Step = 32,
+.CCRes = 2,
+/* No DSP implemented. */
+.CP0_Status_rw_bitmask = 0x3678FF1F,
+.CP1_fcr0 = (1 FCR0_F64) | (1 FCR0_L) | (1 FCR0_W) |
+(1 FCR0_D) | (1 FCR0_S) | (0x93 FCR0_PRID),
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
+.mmu_type = MMU_TYPE_R4000,
+},
+{
.name = 34Kf,
.CP0_PRid = 0x00019500,
.CP0_Config0 = MIPS_CONFIG0 | (0x1 CP0C0_AR) |
--
1.6.3.2
[Qemu-devel] [PATCH 3/3] Samples to add a tracepoint.
Steps for adding a tracepoint :
1. In trace-entries.h, add a DECLARE_TRACE() in the said format.
2. In trace-entries.c:
i) add a DEFINE_TRACE() for the tracepoint in the said format.
ii) add an INIT_TRACE(name) for the tracepoint in the function
init_tracepoints(void)
3. The call site should have a 'trace_name(args..)'
(Remember to include trace-entries.h in the file where the tracepoint
is logged)
This patch adds tracepoints to virtio_blk_rw_complete() and paio_submit()
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
Signed-off by : Prerna (pre...@linux.vnet.ibm.com)
Index: qemu/hw/virtio-blk.c
===
--- qemu.orig/hw/virtio-blk.c
+++ qemu/hw/virtio-blk.c
@@ -19,6 +19,10 @@
# include scsi/sg.h
#endif
+#ifdef CONFIG_QEMU_TRACE
+#include trace-entries.h
+#endif
+
typedef struct VirtIOBlock
{
VirtIODevice vdev;
@@ -87,6 +91,8 @@ static void virtio_blk_rw_complete(void
{
VirtIOBlockReq *req = opaque;
+trace_virtio_blk_rw_complete(req, ret);
+
if (ret) {
int is_read = !(req-out-type VIRTIO_BLK_T_OUT);
if (virtio_blk_handle_rw_error(req, -ret, is_read))
Index: qemu/posix-aio-compat.c
===
--- qemu.orig/posix-aio-compat.c
+++ qemu/posix-aio-compat.c
@@ -29,6 +29,9 @@
#include block/raw-posix-aio.h
+#ifdef CONFIG_QEMU_TRACE
+#include trace-entries.h
+#endif
struct qemu_paiocb {
BlockDriverAIOCB common;
@@ -565,6 +568,7 @@ BlockDriverAIOCB *paio_submit(BlockDrive
{
struct qemu_paiocb *acb;
+trace_paio_submit(fd, sector_num);
acb = qemu_aio_get(raw_aio_pool, bs, cb, opaque);
if (!acb)
return NULL;
Index: qemu/trace-entries.h
===
--- qemu.orig/trace-entries.h
+++ qemu/trace-entries.h
@@ -29,5 +29,20 @@ void init_tracepoints(void);
* ),
* )
*/
+DECLARE_TRACE(virtio_blk_rw_complete,
+ TP_PROTO(void* req, int ret),
+ TP_STRUCT__entry(
+ __field(void*, req);
+ __field(int, ret);
+ )
+)
+
+DECLARE_TRACE(paio_submit,
+ TP_PROTO(int fd, int64_t sector_num),
+ TP_STRUCT__entry(
+ __field(int, fd);
+ __field(int64_t, sector_num);
+ )
+)
#endif /*__TRACE_ENTRIES_H__ */
Index: qemu/trace-entries.c
===
--- qemu.orig/trace-entries.c
+++ qemu/trace-entries.c
@@ -20,7 +20,8 @@
void init_tracepoints(void)
{
// INIT_TRACE(foo);
-
+ INIT_TRACE(virtio_blk_rw_complete);
+ INIT_TRACE(paio_submit);
return;
}
@@ -37,4 +38,23 @@ void init_tracepoints(void)
* )
*
*/
+DEFINE_TRACE( virtio_blk_rw_complete,
+ TP_PROTO(void* req, int ret),
+ TP_fast_assign(
+ __entry-req = req;
+ __entry-ret = ret;
+ ),
+ TP_printk(virtio_blk_rw_complete: req %p ret %d\n,__entry-req,
+ __entry-ret)
+)
+
+DEFINE_TRACE( paio_submit,
+ TP_PROTO(int fd, int64_t sector_num),
+ TP_fast_assign(
+ __entry-fd = fd;
+ __entry-sector_num = sector_num;
+ ),
+ TP_printk(paio_submit: fd %d sector_num %ld\n,__entry-fd,
+ __entry-sector_num)
+)
[Qemu-devel] [PATCH 09/10] linux-user: honor low bit of entry PC for MIPS
Signed-off-by: Nathan Froyd froy...@codesourcery.com
---
linux-user/main.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 18b52c0..76d443b 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3192,7 +3192,9 @@ int main(int argc, char **argv, char **envp)
for(i = 0; i 32; i++) {
env-active_tc.gpr[i] = regs-regs[i];
}
-env-active_tc.PC = regs-cp0_epc;
+env-active_tc.PC = regs-cp0_epc ~(target_ulong)1;
+if (regs-cp0_epc 1)
+env-hflags |= MIPS_HFLAG_M16;
}
#elif defined(TARGET_SH4)
{
--
1.6.3.2
Re: [Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
On 05/24/2010 11:32 AM, Paul Brook wrote: Notice that this patch was sent against hpet as one example, if we agree that this way of disabling devices is ok, we could disable more devices/have more flexibility. Notice that in general, we (RHEL/KVM) are interested in a small subset of qemu devices. IMO this patch is a backwards step. The device models should be cleaned up so that you don't need to make a compile time decision. I disagree. I think the device model should be cleaned up so that no CONFIG_HPET is required in code but I think it's still useful to be able to exclude device models from the build. That should just be a matter of not building the object though (that's the point of device_init()). Regards, Anthony LIguori You'll notice that a fair amount of effort has been put into making the device/system code less tightly coupled and less machine specific. All inter-device interaction and links should be explicit. Changing from PC with HPET and PC without HPET should not require recompiling anything, and devices shouldn't need to know or care which they're part of. Paul
Re: [Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
On 05/24/2010 11:32 AM, Paul Brook wrote: Notice that this patch was sent against hpet as one example, if we agree that this way of disabling devices is ok, we could disable more devices/have more flexibility. Notice that in general, we (RHEL/KVM) are interested in a small subset of qemu devices. IMO this patch is a backwards step. The device models should be cleaned up so that you don't need to make a compile time decision. I disagree. I think the device model should be cleaned up so that no CONFIG_HPET is required in code but I think it's still useful to be able to exclude device models from the build. That should just be a matter of not building the object though (that's the point of device_init()). I think we're saying the same thing. We already have a mechanism for avoiding things at build time - specifically config-devices.mak. We don't have a nice UI for it, but it's there. At worst your distro specific patch is a 1-line change to default- configs/i386-softmmu.mak. I have no objection to moving hpet.c into Makefile.objs, conditional on CONFIG_HPET (like e.g. CONFIG_SERIAL/serial.o). However a necessary prerequisite is that you fix the device model and machine initialisation so that it's possible to omit hpet.o without rebuilding anything else. Paul
Re: [Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
On 05/24/2010 12:11 PM, Paul Brook wrote: I think we're saying the same thing. We already have a mechanism for avoiding things at build time - specifically config-devices.mak. We don't have a nice UI for it, but it's there. At worst your distro specific patch is a 1-line change to default- configs/i386-softmmu.mak. I have no objection to moving hpet.c into Makefile.objs, conditional on CONFIG_HPET (like e.g. CONFIG_SERIAL/serial.o). However a necessary prerequisite is that you fix the device model and machine initialisation so that it's possible to omit hpet.o without rebuilding anything else. Yes, I fully agree. Regards, Anthony Liguori Paul
[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Paul Brook p...@codesourcery.com wrote:
On 05/24/2010 11:32 AM, Paul Brook wrote:
Notice that this patch was sent against hpet as one example, if we agree
that this way of disabling devices is ok, we could disable more
devices/have more flexibility. Notice that in general, we (RHEL/KVM)
are interested in a small subset of qemu devices.
IMO this patch is a backwards step. The device models should be cleaned
up so that you don't need to make a compile time decision.
I disagree. I think the device model should be cleaned up so that no
CONFIG_HPET is required in code but I think it's still useful to be able
to exclude device models from the build. That should just be a matter
of not building the object though (that's the point of device_init()).
I think we're saying the same thing.
We already have a mechanism for avoiding things at build time - specifically
config-devices.mak. We don't have a nice UI for it, but it's there.
At worst your distro specific patch is a 1-line change to default-
configs/i386-softmmu.mak.
I have no objection to moving hpet.c into Makefile.objs, conditional on
CONFIG_HPET (like e.g. CONFIG_SERIAL/serial.o). However a necessary
prerequisite is that you fix the device model and machine initialisation so
that it's possible to omit hpet.o without rebuilding anything else.
We have two exported functions:
void hpet_init(qemu_irq *irq);
uint32_t hpet_in_legacy_mode(void);
This is how one is used in mc14818rtc:
#if defined TARGET_I386
if (!hpet_in_legacy_mode())
#endif
how the other one is used on pc.c
if (!no_hpet) {
hpet_init(isa_irq);
}
I agree that I could probably came with some trick with qdev_create() to
substitute the hpet_init() (my understanding is that jan already have it
or something like that).
But for the other call, what do you propose?
My best try was to hide the availability of hpet inside hpet_emul.h
with:
#ifdef CONFIG_HPET
uint32_t hpet_in_legacy_mode(void);
else
uint32_t hpet_in_legacy_mode(void) { return 0;}
#endif
I can't see any obvious way to change the hpet_in_legacy_mode() that is
cleaner than this.
Thanks, Juan.
Paul
[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
On 05/24/2010 12:54 PM, Juan Quintela wrote:
Paul Brookp...@codesourcery.com wrote:
On 05/24/2010 11:32 AM, Paul Brook wrote:
Notice that this patch was sent against hpet as one example, if we agree
that this way of disabling devices is ok, we could disable more
devices/have more flexibility. Notice that in general, we (RHEL/KVM)
are interested in a small subset of qemu devices.
IMO this patch is a backwards step. The device models should be cleaned
up so that you don't need to make a compile time decision.
I disagree. I think the device model should be cleaned up so that no
CONFIG_HPET is required in code but I think it's still useful to be able
to exclude device models from the build. That should just be a matter
of not building the object though (that's the point of device_init()).
I think we're saying the same thing.
We already have a mechanism for avoiding things at build time - specifically
config-devices.mak. We don't have a nice UI for it, but it's there.
At worst your distro specific patch is a 1-line change to default-
configs/i386-softmmu.mak.
I have no objection to moving hpet.c into Makefile.objs, conditional on
CONFIG_HPET (like e.g. CONFIG_SERIAL/serial.o). However a necessary
prerequisite is that you fix the device model and machine initialisation so
that it's possible to omit hpet.o without rebuilding anything else.
We have two exported functions:
void hpet_init(qemu_irq *irq);
uint32_t hpet_in_legacy_mode(void);
This is how one is used in mc14818rtc:
#if defined TARGET_I386
if (!hpet_in_legacy_mode())
#endif
In real hardware, and HPET would normally emulate an RTC. The
interaction problem here is that we aren't modelling that correctly in
qemu as we're treating the rtc as a separate device.
What could probably work at a hand wave level, is to make the rtc init
function take a qemu_irq instead of directly grabbing the isa irq. When
an HPET is in use, the rtc no longer is directly initiated but instead
is indirectly initiated by the HPET passing a special qemu_irq to the
device that masks the actual interrupt line when legacy mode isn't
enabled. When the HPET isn't in use, the rtc would be created with an
isa allocated qemu_irq.
Regards,
Anthony Liguori
how the other one is used on pc.c
if (!no_hpet) {
hpet_init(isa_irq);
}
I agree that I could probably came with some trick with qdev_create() to
substitute the hpet_init() (my understanding is that jan already have it
or something like that).
But for the other call, what do you propose?
My best try was to hide the availability of hpet inside hpet_emul.h
with:
#ifdef CONFIG_HPET
uint32_t hpet_in_legacy_mode(void);
else
uint32_t hpet_in_legacy_mode(void) { return 0;}
#endif
I can't see any obvious way to change the hpet_in_legacy_mode() that is
cleaner than this.
Thanks, Juan.
Paul
[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Jan Kiszka jan.kis...@web.de wrote: This happens to us all the time for lots of devices. And the big problem is that there is no sane way to disable them :( If we can agree in a mechanism to disable them (like this one) or something similar, we could remove it. Our biggest problem with shipping a device is that we are going to support it for 7 years, you can guess why we want to be conservative. In this particular case, it is a one line patch: no_hpet = 1;, hardwired. Yeap, but then I end having lots of things patches in RHEL that are not upstream, and each new version/rebase I have to redo all of them. The HPET model is still incomplete in has some remaining quicks (hold on for improvements), but that doesn't qualify it for !CONFIG_HPET, specifically as it is deeply hooked into every modern PC. If I was asked, I guess I would nack this switch. Then, what should we do? Help fixing it (e.g. testers will soon be welcome). Sorry, no donut :-) We try to help/fix everything that we can (we == Red Hat in this case), but we are not going to ship will all drivers any time soon, so it needs to be a way to disable them IMHO. If we need to wait for _all_ devices to be stable and bug free we could ship for next millenium (take or put a couple century's). We already have to disable hpet for 5.4 (1 year ago). It was done with a local hack because it was supposed that for next big release it would have been fixed. But this remains a RHEL issue. Redhat decided to compile out features that are unsupported, others seem to handle this differently. And then, everybody has a different hack to disable the features that they don't need. Instead of doing a local hack, we do a patch that allows anyone to disable HPET if it sees fit. Here we are, and device is still not fixed, what to do? Another local patch? Just get upstream to integrate a sane way to disable it and let in enable by default? Let's start with listing your requirements to no longer disable HPET. It is not stable at this point in time :-( Running with --no-hpet is better than without it in all our testing. If we have to ask/modify everything to use --no-hpet, we can also compile-out it. That would already help us to asses how long !CONFIG_HPET would actually be of any use at all. I'm yet optimistic that we can resolve most if not all remaining concerns for 0.13 - and CONFIG_HPET would at best be 0.13 material anyway. At this very point in time: - it is not stable - lack irq-reinjection when missing ticks (I was not the one debugging/testing this so I don't have more details, but can ask for them). So, it is not stable enough yet. Notice that this patch was sent against hpet as one example, if we agree that this way of disabling devices is ok, we could disable more devices/have more flexibility. Notice that in general, we (RHEL/KVM) are interested in a small subset of qemu devices. At least HPET is IMHO a bad example as it is, just like e.g. the IOAPIC, an essential part of today's x86 systems. Humm, we run normally without hpet enabled and all normal guests work. And yes, I would also preffer it to work. Later, Juan.
[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Anthony Liguori wrote: On 05/24/2010 12:54 PM, Juan Quintela wrote: Paul Brookp...@codesourcery.com wrote: On 05/24/2010 11:32 AM, Paul Brook wrote: Notice that this patch was sent against hpet as one example, if we agree that this way of disabling devices is ok, we could disable more devices/have more flexibility. Notice that in general, we (RHEL/KVM) are interested in a small subset of qemu devices. IMO this patch is a backwards step. The device models should be cleaned up so that you don't need to make a compile time decision. I disagree. I think the device model should be cleaned up so that no CONFIG_HPET is required in code but I think it's still useful to be able to exclude device models from the build. That should just be a matter of not building the object though (that's the point of device_init()). I think we're saying the same thing. We already have a mechanism for avoiding things at build time - specifically config-devices.mak. We don't have a nice UI for it, but it's there. At worst your distro specific patch is a 1-line change to default- configs/i386-softmmu.mak. I have no objection to moving hpet.c into Makefile.objs, conditional on CONFIG_HPET (like e.g. CONFIG_SERIAL/serial.o). However a necessary prerequisite is that you fix the device model and machine initialisation so that it's possible to omit hpet.o without rebuilding anything else. We have two exported functions: void hpet_init(qemu_irq *irq); uint32_t hpet_in_legacy_mode(void); This is how one is used in mc14818rtc: #if defined TARGET_I386 if (!hpet_in_legacy_mode()) #endif In real hardware, and HPET would normally emulate an RTC. The interaction problem here is that we aren't modelling that correctly in qemu as we're treating the rtc as a separate device. Not exactly: The HPET can only take over the periodic timer service of the RTC. But the RTC can still deliver that one as well as all its other IRQs via the SCI (part of ACPI). We don't implement the latter yet, though. What could probably work at a hand wave level, is to make the rtc init function take a qemu_irq instead of directly grabbing the isa irq. When an HPET is in use, the rtc no longer is directly initiated but instead is indirectly initiated by the HPET passing a special qemu_irq to the device that masks the actual interrupt line when legacy mode isn't enabled. When the HPET isn't in use, the rtc would be created with an isa allocated qemu_irq. I'm on this. But, as already indicated, the current beautifulness of the RTC IRQ coalescing workaround kept me more busy than I expected. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Juan Quintela wrote: Paul Brook p...@codesourcery.com wrote: On 05/24/2010 11:32 AM, Paul Brook wrote: Notice that this patch was sent against hpet as one example, if we agree that this way of disabling devices is ok, we could disable more devices/have more flexibility. Notice that in general, we (RHEL/KVM) are interested in a small subset of qemu devices. IMO this patch is a backwards step. The device models should be cleaned up so that you don't need to make a compile time decision. I disagree. I think the device model should be cleaned up so that no CONFIG_HPET is required in code but I think it's still useful to be able to exclude device models from the build. That should just be a matter of not building the object though (that's the point of device_init()). I think we're saying the same thing. We already have a mechanism for avoiding things at build time - specifically config-devices.mak. We don't have a nice UI for it, but it's there. At worst your distro specific patch is a 1-line change to default- configs/i386-softmmu.mak. I have no objection to moving hpet.c into Makefile.objs, conditional on CONFIG_HPET (like e.g. CONFIG_SERIAL/serial.o). However a necessary prerequisite is that you fix the device model and machine initialisation so that it's possible to omit hpet.o without rebuilding anything else. We have two exported functions: void hpet_init(qemu_irq *irq); uint32_t hpet_in_legacy_mode(void); One, hpet_in_legacy_mode will become hpet-private. Once done, I will have a look if we can cleanly push more x86 platform logic related to the HPET IRQ routing into hpet_init. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Windows guest debugging on KVM/Qemu
hi, I am using KVM/Qemu to debug my Windows guest according to KVM wiki page (http://www.linux-kvm.org/page/WindowsGuestDrivers/GuestDebugging). It works for me and also I can only use one Windows guest and bind its serial port to a TCP port and run Virtual Serial Ports Emulator on my Windows dev machine. The problem is that these kind of connection is really slow. Is there any known issue with KVM serial port driver? There is a good discussion about the same issue one year ago. Not sure if there is any improvement or not after that. (http://www.mail-archive.com/k...@vger.kernel.org/msg21145.html). Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
2010/5/24 MORITA Kazutaka morita.kazut...@lab.ntt.co.jp: However, I don't think nbd would be a good protocol. My preference would be for a plugin API, or for a new local protocol that uses splice() to avoid copies. Both would be okay for Sheepdog. I want to take a suitable approach for qemu. I think both should be possible: - Using splice() we would need a daemon that is listening on a control socket for requests from qemu-processes or admin commands. When a qemu-process wants to open an image it could call open_image(protocol:imagename) on the controll socket and the daemon has to create a pipe to which the image is mapped. (What I'm unsure about, are the security implications. Do we need some kind of authentication for the sockets? What about sVirt? - Building a plugin API seems a bit simpler to me, although I'm to sure if I'd get the idea correctly: The block layer has already some kind of api (.bdrv_file_open, .bdrv_read). We could simply compile the block-drivers as shared objects and create a method for loading the necessary modules at runtime. Are you planing to use this for all block drivers? Regards, Christian
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On 05/24/2010 06:56 AM, Avi Kivity wrote: On 05/24/2010 02:42 PM, MORITA Kazutaka wrote: The server would be local and talk over a unix domain socket, perhaps anonymous. nbd has other issues though, such as requiring a copy and no support for metadata operations such as snapshot and file size extension. Sorry, my explanation was unclear. I'm not sure how running servers on localhost can solve the problem. The local server can convert from the local (nbd) protocol to the remote (sheepdog, ceph) protocol. What I wanted to say was that we cannot specify the image of VM. With nbd protocol, command line arguments are as follows: $ qemu nbd:hostname:port As this syntax shows, with nbd protocol the client cannot pass the VM image name to the server. We would extend it to allow it to connect to a unix domain socket: qemu nbd:unix:/path/to/socket nbd is a no-go because it only supports a single, synchronous I/O operation at a time and has no mechanism for extensibility. If we go this route, I think two options are worth considering. The first would be a purely socket based approach where we just accepted the extra copy. The other potential approach would be shared memory based. We export all guest ram as shared memory along with a small bounce buffer pool. We would then use a ring queue (potentially even using virtio-blk) and an eventfd for notification. The server at the other end would associate the socket with a filename and forward it to the server using the remote protocol. However, I don't think nbd would be a good protocol. My preference would be for a plugin API, or for a new local protocol that uses splice() to avoid copies. I think a good shared memory implementation would be preferable to plugins. I think it's worth attempting to do a plugin interface for the block layer but I strongly suspect it would not be sufficient. I would not want to see plugins that interacted with BlockDriverState directly, for instance. We change it far too often. Our main loop functions are also not terribly stable so I'm not sure how we would handle that (unless we forced all block plugins to be in a separate thread). Regards, Anthony Liguori
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On 05/24/2010 06:03 AM, Avi Kivity wrote: On 05/24/2010 11:27 AM, Stefan Hajnoczi wrote: On Sun, May 23, 2010 at 1:01 PM, Avi Kivitya...@redhat.com wrote: On 05/21/2010 12:29 AM, Anthony Liguori wrote: I'd be more interested in enabling people to build these types of storage systems without touching qemu. Both sheepdog and ceph ultimately transmit I/O over a socket to a central daemon, right? That incurs an extra copy. Besides a shared memory approach, I wonder if the splice() family of syscalls could be used to send/receive data through a storage daemon without the daemon looking at or copying the data? Excellent idea. splice() eventually requires a copy. You cannot splice() to linux-aio so you'd have to splice() to a temporary buffer and then call into linux-aio. With shared memory, you can avoid ever bringing the data into memory via O_DIRECT and linux-aio. Regards, Anthony Liguori
Re: [Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On 05/20/2010 02:22 PM, Luiz Capitulino wrote: On Thu, 20 May 2010 13:52:08 -0500 Anthony Liguorianth...@codemonkey.ws wrote: On 05/20/2010 01:47 PM, Luiz Capitulino wrote: On Thu, 20 May 2010 11:55:00 -0500 Anthony Liguorianth...@codemonkey.ws wrote: On 05/20/2010 11:27 AM, Luiz Capitulino wrote: On Thu, 20 May 2010 10:50:41 -0500 Anthony Liguorianth...@codemonkey.wswrote: On 05/20/2010 10:16 AM, Paolo Bonzini wrote: On 05/20/2010 03:44 PM, Luiz Capitulino wrote: I think there's another issue in the handling of strings. The spec says that valid unescaped chars are in the following range: unescaped = %x20-21 / %x23-5B / %x5D-10 That's a spec bug IMHO. Tab is %x09. Surely you can include tabs in strings. Any parser that didn't accept that would be broken. Honestly, I had the impression this should be encoded as: %x5C %x74, but if you're right, wouldn't this be true for other sequences as well? I don't think most reasonable clients are going to quote tabs as '\t'. That would be a bug, wouldn't it? Tabs are valid in JavaScript strings and I don't think it's reasonable to expect that a valid JavaScript string is not a valid JSON string. IMO, we should do what the spec says and what bug free clients expect, what we consider reasonable or unreasonable is a different matter. How we encode strings is one thing, what we accept is something else. Why shouldn't we be liberal in what we accept? It doesn't violate the spec to accept more than it requires so why shouldn't we? Regards, Anthony Liguori I would be with you if the spec was proved wrong, specially if reference implementations out there didn't follow it either, but everything I found so far shows this is not the case. Another example: http://www.json.org/json2.js Search for 'character substitutions'.
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On 05/24/2010 02:07 PM, Christian Brunner wrote:
2010/5/24 MORITA Kazutakamorita.kazut...@lab.ntt.co.jp:
However, I don't think nbd would be a good protocol. My preference
would be for a plugin API, or for a new local protocol that uses
splice() to avoid copies.
Both would be okay for Sheepdog. I want to take a suitable approach
for qemu.
I think both should be possible:
- Using splice() we would need a daemon that is listening on a control
socket for
requests from qemu-processes or admin commands. When a qemu-process
wants to open an image it could call open_image(protocol:imagename) on the
controll socket and the daemon has to create a pipe to which the
image is mapped.
(What I'm unsure about, are the security implications. Do we need some kind
of
authentication for the sockets? What about sVirt?
This is a fairly old patch that I dug out of a backup. It uses the 9p
protocol and does proper support for AIO.
At one point in time, I actually implemented splice() support but it
didn't result in a significant improvement in benchmarks.
- Building a plugin API seems a bit simpler to me, although I'm to
sure if I'd get the
idea correctly:
The block layer has already some kind of api (.bdrv_file_open, .bdrv_read).
We
could simply compile the block-drivers as shared objects and create a method
for loading the necessary modules at runtime.
That approach would be a recipe for disaster. We would have to
introduce a new, reduced functionality block API that was supported for
plugins. Otherwise, the only way a plugin could keep up with our API
changes would be if it was in tree which defeats the purpose of having
plugins.
Regards,
Anthony Liguori
Are you planing to use this for all block drivers?
Regards,
Christian
diff --git a/Makefile b/Makefile
index 4f7a55a..541b26a 100644
--- a/Makefile
+++ b/Makefile
@@ -53,7 +53,7 @@ BLOCK_OBJS=cutils.o qemu-malloc.o
BLOCK_OBJS+=block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o
BLOCK_OBJS+=block-dmg.o block-bochs.o block-vpc.o block-vvfat.o
BLOCK_OBJS+=block-qcow2.o block-parallels.o block-nbd.o
-BLOCK_OBJS+=nbd.o block.o aio.o
+BLOCK_OBJS+=nbd.o block.o aio.o block-9p.o p9.o p9c.o
ifdef CONFIG_WIN32
BLOCK_OBJS += block-raw-win32.o
diff --git a/block-9p.c b/block-9p.c
new file mode 100644
index 000..5570f37
--- /dev/null
+++ b/block-9p.c
@@ -0,0 +1,573 @@
+/*
+ * 9p based block driver for QEMU
+ *
+ * Copyright IBM, Corp. 2008
+ *
+ * Authors:
+ * Anthony Liguori aligu...@us.ibm.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include qemu-common.h
+#include block_int.h
+#include p9c.h
+#include qemu_socket.h
+
+#include string.h
+#include stdlib.h
+#include errno.h
+
+//#define DEBUG_BLOCK_9P
+
+#ifdef DEBUG_BLOCK_9P
+#define dprintf(fmt, ...) \
+do { printf(block-9p: fmt, ## __VA_ARGS__); } while (0)
+#define _dprintf(fmt, ...) \
+do { printf(fmt, ## __VA_ARGS__); } while (0)
+#else
+#define dprintf(fmt, ...) \
+do { } while (0)
+#define _dprintf(fmt, ...) \
+do { } while (0)
+#endif
+
+typedef struct BDRV9pState {
+P9IOState iops;
+BlockDriverState *bs;
+P9ClientState *client_state;
+int fd;
+char filename[1024];
+int nwnames;
+const char *wnames[256];
+int do_loop;
+int64_t length;
+int32_t msize;
+int count;
+} BDRV9pState;
+
+typedef struct P9AIOCB {
+BlockDriverAIOCB common;
+BDRV9pState *s;
+int64_t offset;
+size_t size;
+void *buf;
+} P9AIOCB;
+
+static void p9_recv_notify(void *opaque)
+{
+BDRV9pState *s = opaque;
+p9c_notify_can_recv(s-client_state);
+}
+
+static void p9_send_notify(void *opaque)
+{
+BDRV9pState *s = opaque;
+p9c_notify_can_send(s-client_state);
+}
+
+static BDRV9pState *to_bs(P9IOState *iops)
+{
+return container_of(iops, BDRV9pState, iops);
+}
+
+static ssize_t p9_send(P9IOState *iops, const void *data, size_t size)
+{
+BDRV9pState *s = to_bs(iops);
+ssize_t len;
+len = send(s-fd, data, size, 0);
+if (len == -1)
+errno = socket_error();
+return len;
+}
+
+static ssize_t p9_recv(P9IOState *iops, void *data, size_t size)
+{
+BDRV9pState *s = to_bs(iops);
+ssize_t len;
+len = recv(s-fd, data, size, 0);
+if (len == -1)
+errno = socket_error();
+return len;
+}
+
+static int p9_flush(void *opaque)
+{
+BDRV9pState *s = opaque;
+return !!s-count || s-do_loop;
+}
+
+static void p9_set_send_notify(P9IOState *iops, int enable)
+{
+BDRV9pState *s = to_bs(iops);
+
+if (enable)
+qemu_aio_set_fd_handler(s-fd, p9_recv_notify, p9_send_notify,
p9_flush, s);
+else
+qemu_aio_set_fd_handler(s-fd, p9_recv_notify, NULL, p9_flush, s);
+}
+
+static int p9_open_cb(void *opaque, int ret, const P9QID *qid, int32_t iounit)
+{
+BDRV9pState *s = opaque;
+
+if (ret) {
+
Re: [Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On Mon, 24 May 2010 14:29:58 -0500 Anthony Liguori anth...@codemonkey.ws wrote: On 05/20/2010 02:22 PM, Luiz Capitulino wrote: On Thu, 20 May 2010 13:52:08 -0500 Anthony Liguorianth...@codemonkey.ws wrote: On 05/20/2010 01:47 PM, Luiz Capitulino wrote: On Thu, 20 May 2010 11:55:00 -0500 Anthony Liguorianth...@codemonkey.ws wrote: On 05/20/2010 11:27 AM, Luiz Capitulino wrote: On Thu, 20 May 2010 10:50:41 -0500 Anthony Liguorianth...@codemonkey.wswrote: On 05/20/2010 10:16 AM, Paolo Bonzini wrote: On 05/20/2010 03:44 PM, Luiz Capitulino wrote: I think there's another issue in the handling of strings. The spec says that valid unescaped chars are in the following range: unescaped = %x20-21 / %x23-5B / %x5D-10 That's a spec bug IMHO. Tab is %x09. Surely you can include tabs in strings. Any parser that didn't accept that would be broken. Honestly, I had the impression this should be encoded as: %x5C %x74, but if you're right, wouldn't this be true for other sequences as well? I don't think most reasonable clients are going to quote tabs as '\t'. That would be a bug, wouldn't it? Tabs are valid in JavaScript strings and I don't think it's reasonable to expect that a valid JavaScript string is not a valid JSON string. IMO, we should do what the spec says and what bug free clients expect, what we consider reasonable or unreasonable is a different matter. How we encode strings is one thing, what we accept is something else. True. Why shouldn't we be liberal in what we accept? It doesn't violate the spec to accept more than it requires so why shouldn't we? For the reasons outlined by Avi, not sure how this serious this is though.
[Qemu-devel] [Bug 584510] Re: e1000 irq problems after live migration with qemu-kvm 0.12.4
I did 2 additional tests 1) Stop VM, Live Migrate, Continue - Triggers BUG 2) Stop VM, Continue - Does NOT trigger BUG. My guess it seems that pending interrupts are incorrectly transferred with kernel irqchip. As said earlier userspace irqchip does not trigger the bug. ** Project changed: qemu = qemu-kvm -- e1000 irq problems after live migration with qemu-kvm 0.12.4 https://bugs.launchpad.net/bugs/584510 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in qemu-kvm: New Bug description: After live migrating ubuntu 9.10 server (2.6.31-14-server) and suse linux 10.1 (2.6.16.13-4-smp) it happens sometimes that the guest runs into irq problems. i mention these 2 guest oss since i have seen the error there. there are likely others around with the same problem. on the host i run 2.6.33.3 (kernel+mod) and qemu-kvm 0.12.4. i started a vm with: /usr/bin/qemu-kvm-0.12.4 -net tap,vlan=141,script=no,downscript=no,ifname=tap0 -net nic,vlan=141,model=e1000,macaddr=52:54:00:ff:00:72 -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor tcp:0:4001,server,nowait -vnc :1 -name 'migration-test-9-10' -boot order=dc,menu=on -k de -incoming tcp:172.21.55.22:5001 -pidfile /var/run/qemu/vm-155.pid -mem-path /hugepages -mem-prealloc -rtc base=utc,clock=host -usb -usbdevice tablet for testing i have a clean ubuntu 9.10 server 64-bit install and created a small script with fetches a dvd iso from a local server and checking md5sum in an endless loop. the download performance is approx. 50MB/s on that vm. to trigger the error i did several migrations of the vm throughout the last days. finally I ended up in the following oops in the guest: [64442.298521] irq 10: nobody cared (try booting with the irqpoll option) [64442.299175] Pid: 0, comm: swapper Not tainted 2.6.31-14-server #48-Ubuntu [64442.299179] Call Trace: [64442.299185] IRQ [810b4b96] __report_bad_irq+0x26/0xa0 [64442.299227] [810b4d9c] note_interrupt+0x18c/0x1d0 [64442.299232] [810b5415] handle_fasteoi_irq+0xd5/0x100 [64442.299244] [81014bdd] handle_irq+0x1d/0x30 [64442.299246] [810140b7] do_IRQ+0x67/0xe0 [64442.299249] [810129d3] ret_from_intr+0x0/0x11 [64442.299266] [810b3234] ? handle_IRQ_event+0x24/0x160 [64442.299269] [810b529f] ? handle_edge_irq+0xcf/0x170 [64442.299271] [81014bdd] ? handle_irq+0x1d/0x30 [64442.299273] [810140b7] ? do_IRQ+0x67/0xe0 [64442.299275] [810129d3] ? ret_from_intr+0x0/0x11 [64442.299290] [81526b14] ? _spin_unlock_irqrestore+0x14/0x20 [64442.299302] [8133257c] ? scsi_dispatch_cmd+0x16c/0x2d0 [64442.299307] [8133963a] ? scsi_request_fn+0x3aa/0x500 [64442.299322] [8125fafc] ? __blk_run_queue+0x6c/0x150 [64442.299324] [8125fcbb] ? blk_run_queue+0x2b/0x50 [64442.299327] [8133899f] ? scsi_run_queue+0xcf/0x2a0 [64442.299336] [81339a0d] ? scsi_next_command+0x3d/0x60 [64442.299338] [8133a21b] ? scsi_end_request+0xab/0xb0 [64442.299340] [8133a50e] ? scsi_io_completion+0x9e/0x4d0 [64442.299348] [81036419] ? default_spin_lock_flags+0x9/0x10 [64442.299351] [8133224d] ? scsi_finish_command+0xbd/0x130 [64442.299353] [8133aa95] ? scsi_softirq_done+0x145/0x170 [64442.299356] [81264e6d] ? blk_done_softirq+0x7d/0x90 [64442.299368] [810651fd] ? __do_softirq+0xbd/0x200 [64442.299370] [810131ac] ? call_softirq+0x1c/0x30 [64442.299372] [81014b85] ? do_softirq+0x55/0x90 [64442.299374] [81064f65] ? irq_exit+0x85/0x90 [64442.299376] [810140c0] ? do_IRQ+0x70/0xe0 [64442.299379] [810129d3] ? ret_from_intr+0x0/0x11 [64442.299380] EOI [810356f6] ? native_safe_halt+0x6/0x10 [64442.299390] [8101a20c] ? default_idle+0x4c/0xe0 [64442.299395] [815298f5] ? atomic_notifier_call_chain+0x15/0x20 [64442.299398] [81010e02] ? cpu_idle+0xb2/0x100 [64442.299406] [815123c6] ? rest_init+0x66/0x70 [64442.299424] [81838047] ? start_kernel+0x352/0x35b [64442.299427] [8183759a] ? x86_64_start_reservations+0x125/0x129 [64442.299429] [81837698] ? x86_64_start_kernel+0xfa/0x109 [64442.299433] handlers: [64442.299840] [ab80] (e1000_intr+0x0/0x190 [e1000]) [64442.300046] Disabling IRQ #10 After this the guest is still allive, but download performance is down to approx. 500KB/s This error is definetly not triggerable with option -no-kvm-irqchip. I have seen this error occasionally since my first experiments with qemu-kvm-88 and also without hugetablefs. Help appreciated.
[Qemu-devel] [Bug 585113] [NEW] e1000 irq problems after live migration with qemu-kvm 0.12.4
Public bug reported: sorry for resubmitting. i accidently moved this bug to qemu-kvm at launchpad where it is stuck... After live migrating ubuntu 9.10 server (2.6.31-14-server) and suse linux 10.1 (2.6.16.13-4-smp) it happens sometimes that the guest runs into irq problems. i mention these 2 guest oss since i have seen the error there. there are likely others around with the same problem. on the host i run 2.6.33.3 (kernel+mod) and qemu-kvm 0.12.4. i started a vm with: /usr/bin/qemu-kvm-0.12.4 -net tap,vlan=141,script=no,downscript=no,ifname=tap0 -net nic,vlan=141,model=e1000,macaddr=52:54:00:ff:00:72 -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor tcp:0:4001,server,nowait -vnc :1 -name 'migration-test-9-10' -boot order=dc,menu=on -k de -incoming tcp:172.21.55.22:5001 -pidfile /var/run/qemu/vm-155.pid -mem-path /hugepages -mem-prealloc -rtc base=utc,clock=host -usb -usbdevice tablet for testing i have a clean ubuntu 9.10 server 64-bit install and created a small script with fetches a dvd iso from a local server and checking md5sum in an endless loop. the download performance is approx. 50MB/s on that vm. to trigger the error i did several migrations of the vm throughout the last days. finally I ended up in the following oops in the guest: [64442.298521] irq 10: nobody cared (try booting with the irqpoll option) [64442.299175] Pid: 0, comm: swapper Not tainted 2.6.31-14-server #48-Ubuntu [64442.299179] Call Trace: [64442.299185] IRQ [810b4b96] __report_bad_irq+0x26/0xa0 [64442.299227] [810b4d9c] note_interrupt+0x18c/0x1d0 [64442.299232] [810b5415] handle_fasteoi_irq+0xd5/0x100 [64442.299244] [81014bdd] handle_irq+0x1d/0x30 [64442.299246] [810140b7] do_IRQ+0x67/0xe0 [64442.299249] [810129d3] ret_from_intr+0x0/0x11 [64442.299266] [810b3234] ? handle_IRQ_event+0x24/0x160 [64442.299269] [810b529f] ? handle_edge_irq+0xcf/0x170 [64442.299271] [81014bdd] ? handle_irq+0x1d/0x30 [64442.299273] [810140b7] ? do_IRQ+0x67/0xe0 [64442.299275] [810129d3] ? ret_from_intr+0x0/0x11 [64442.299290] [81526b14] ? _spin_unlock_irqrestore+0x14/0x20 [64442.299302] [8133257c] ? scsi_dispatch_cmd+0x16c/0x2d0 [64442.299307] [8133963a] ? scsi_request_fn+0x3aa/0x500 [64442.299322] [8125fafc] ? __blk_run_queue+0x6c/0x150 [64442.299324] [8125fcbb] ? blk_run_queue+0x2b/0x50 [64442.299327] [8133899f] ? scsi_run_queue+0xcf/0x2a0 [64442.299336] [81339a0d] ? scsi_next_command+0x3d/0x60 [64442.299338] [8133a21b] ? scsi_end_request+0xab/0xb0 [64442.299340] [8133a50e] ? scsi_io_completion+0x9e/0x4d0 [64442.299348] [81036419] ? default_spin_lock_flags+0x9/0x10 [64442.299351] [8133224d] ? scsi_finish_command+0xbd/0x130 [64442.299353] [8133aa95] ? scsi_softirq_done+0x145/0x170 [64442.299356] [81264e6d] ? blk_done_softirq+0x7d/0x90 [64442.299368] [810651fd] ? __do_softirq+0xbd/0x200 [64442.299370] [810131ac] ? call_softirq+0x1c/0x30 [64442.299372] [81014b85] ? do_softirq+0x55/0x90 [64442.299374] [81064f65] ? irq_exit+0x85/0x90 [64442.299376] [810140c0] ? do_IRQ+0x70/0xe0 [64442.299379] [810129d3] ? ret_from_intr+0x0/0x11 [64442.299380] EOI [810356f6] ? native_safe_halt+0x6/0x10 [64442.299390] [8101a20c] ? default_idle+0x4c/0xe0 [64442.299395] [815298f5] ? atomic_notifier_call_chain+0x15/0x20 [64442.299398] [81010e02] ? cpu_idle+0xb2/0x100 [64442.299406] [815123c6] ? rest_init+0x66/0x70 [64442.299424] [81838047] ? start_kernel+0x352/0x35b [64442.299427] [8183759a] ? x86_64_start_reservations+0x125/0x129 [64442.299429] [81837698] ? x86_64_start_kernel+0xfa/0x109 [64442.299433] handlers: [64442.299840] [ab80] (e1000_intr+0x0/0x190 [e1000]) [64442.300046] Disabling IRQ #10 After this the guest is still allive, but download performance is down to approx. 500KB/s This error is definetly not triggerable with option -no-kvm-irqchip. I have seen this error occasionally since my first experiments with qemu-kvm-88 and also without hugetablefs. Help appreciated. ** Affects: qemu Importance: Undecided Status: New -- e1000 irq problems after live migration with qemu-kvm 0.12.4 https://bugs.launchpad.net/bugs/585113 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: sorry for resubmitting. i accidently moved this bug to qemu-kvm at launchpad where it is stuck... After live migrating ubuntu 9.10 server (2.6.31-14-server) and suse linux 10.1 (2.6.16.13-4-smp) it happens sometimes that the guest runs into irq problems. i mention these 2 guest oss since i have seen the
[Qemu-devel] Re: [PATCH, RFC 1/4] mc146818: move hpet handling to pc.c
On Mon, May 24, 2010 at 3:30 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
On Sun, May 23, 2010 at 3:40 PM, Jan Kiszka jan.kis...@web.de wrote:
Blue Swirl wrote:
Move hpet_in_legacy_mode check from mc146818.c to pc.c. Remove
the optimization where the periodic timer is disabled if
hpet is in legacy mode.
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
hw/mc146818rtc.c | 37 +++--
hw/mc146818rtc.h | 2 ++
hw/pc.c | 32 +++-
3 files changed, 36 insertions(+), 35 deletions(-)
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 571c593..e0c33c5 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -27,7 +27,6 @@
#include pc.h
#include apic.h
#include isa.h
-#include hpet_emul.h
#include mc146818rtc.h
//#define DEBUG_CMOS
@@ -94,19 +93,6 @@ typedef struct RTCState {
QEMUTimer *second_timer2;
} RTCState;
-static void rtc_irq_raise(qemu_irq irq)
-{
- /* When HPET is operating in legacy mode, RTC interrupts are disabled
- * We block qemu_irq_raise, but not qemu_irq_lower, in case legacy
- * mode is established while interrupt is raised. We want it to
- * be lowered in any case
- */
-#if defined TARGET_I386
- if (!hpet_in_legacy_mode())
-#endif
- qemu_irq_raise(irq);
-}
-
static void rtc_set_time(RTCState *s);
static void rtc_copy_date(RTCState *s);
@@ -131,7 +117,7 @@ static void rtc_coalesced_timer(void *opaque)
if (s-irq_coalesced != 0) {
apic_reset_irq_delivered();
s-cmos_data[RTC_REG_C] |= 0xc0;
- rtc_irq_raise(s-irq);
+ qemu_irq_raise(s-irq);
if (apic_get_irq_delivered()) {
s-irq_coalesced--;
}
@@ -145,19 +131,10 @@ static void rtc_timer_update(RTCState *s,
int64_t current_time)
{
int period_code, period;
int64_t cur_clock, next_irq_clock;
- int enable_pie;
period_code = s-cmos_data[RTC_REG_A] 0x0f;
-#if defined TARGET_I386
- /* disable periodic timer if hpet is in legacy mode, since interrupts
are
- * disabled anyway.
- */
Does some dumb OS we care about (specifically in KVM mode) first enable
the periodic RTC, then discovers the HPET, switches over, forgetting
about the RTC? Otherwise: the guest will get what it deserves (degraded
performance).
No idea. The performance penalty also depends on the trigger frequency.
I think now it is OK to leave it ticking.
We are currently lacking proper RTC routing through ACPI to SCI [1,
Figure 11]. Adding this will add a parallel user of the RTC IRQ line. I
What a poor picture BTW, even the arrow heads are missing. Would you
have a pointer for the SCI specs?
briefly thought about some user registration API for the RTC, but that
appears over-engineered on second thought. Let's go the simple path.
I think it's easier to add some logic to HPET to route the
RTC/HPET/i8254 irqs. If there is no HPET, the irqs are routed
directly.
- enable_pie = !hpet_in_legacy_mode();
-#else
- enable_pie = 1;
-#endif
if (period_code != 0
- (((s-cmos_data[RTC_REG_B] REG_B_PIE) enable_pie)
+ ((s-cmos_data[RTC_REG_B] REG_B_PIE)
|| ((s-cmos_data[RTC_REG_B] REG_B_SQWE) s-sqw_irq))) {
if (period_code = 2)
period_code += 7;
@@ -194,14 +171,14 @@ static void rtc_periodic_timer(void *opaque)
if (s-irq_reinject_on_ack_count = RTC_REINJECT_ON_ACK_COUNT)
s-irq_reinject_on_ack_count = 0;
apic_reset_irq_delivered();
- rtc_irq_raise(s-irq);
+ qemu_irq_raise(s-irq);
if (!apic_get_irq_delivered()) {
s-irq_coalesced++;
rtc_coalesced_timer_update(s);
}
} else
#endif
- rtc_irq_raise(s-irq);
+ qemu_irq_raise(s-irq);
}
if (s-cmos_data[RTC_REG_B] REG_B_SQWE) {
/* Not square wave at all but we don't want 2048Hz interrupts!
@@ -430,7 +407,7 @@ static void rtc_update_second2(void *opaque)
s-cmos_data[RTC_HOURS_ALARM] == s-current_tm.tm_hour)) {
s-cmos_data[RTC_REG_C] |= 0xa0;
- rtc_irq_raise(s-irq);
+ qemu_irq_raise(s-irq);
}
}
@@ -438,7 +415,7 @@ static void rtc_update_second2(void *opaque)
s-cmos_data[RTC_REG_C] |= REG_C_UF;
if (s-cmos_data[RTC_REG_B] REG_B_UIE) {
s-cmos_data[RTC_REG_C] |= REG_C_IRQF;
- rtc_irq_raise(s-irq);
+ qemu_irq_raise(s-irq);
}
/* clear update in progress bit */
@@ -588,7 +565,7 @@ static int rtc_initfn(ISADevice *dev)
{
RTCState *s = DO_UPCAST(RTCState, dev, dev);
int base = 0x70;
- int isairq = 8;
+ int isairq = RTC_ISA_IRQ;
isa_init_irq(dev, s-irq, isairq);
diff --git a/hw/mc146818rtc.h b/hw/mc146818rtc.h
index 6f46a68..d630485 100644
--- a/hw/mc146818rtc.h
+++
Re: [Qemu-devel] [PATCH, RFC 2/4] Convert PCI devices to use pci_register_memory()
On 05/23/2010 03:34 PM, Blue Swirl wrote: Signed-off-by: Blue Swirlblauwir...@gmail.com --- hw/cirrus_vga.c | 12 ++-- hw/e1000.c|2 +- hw/eepro100.c |2 +- hw/isa.h |1 + hw/isa_mmio.c | 18 -- hw/lsi53c895a.c |4 ++-- hw/macio.c| 24 hw/msix.c |4 ++-- hw/openpic.c |6 +++--- hw/pcnet.c|3 ++- hw/rtl8139.c |2 +- hw/sun4u.c|7 +-- hw/usb-ohci.c |2 +- hw/vga-pci.c |4 ++-- hw/vmware_vga.c |7 +++ hw/wdt_i6300esb.c |2 +- 16 files changed, 59 insertions(+), 41 deletions(-) diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c index ba48289..52e51e0 100644 --- a/hw/cirrus_vga.c +++ b/hw/cirrus_vga.c @@ -3145,10 +3145,10 @@ static void cirrus_pci_lfb_map(PCIDevice *d, int region_num, CirrusVGAState *s =DO_UPCAST(PCICirrusVGAState, dev, d)-cirrus_vga; /* XXX: add byte swapping apertures */ -cpu_register_physical_memory(addr, s-vga.vram_size, -s-cirrus_linear_io_addr); -cpu_register_physical_memory(addr + 0x100, 0x40, -s-cirrus_linear_bitblt_io_addr); +pci_register_memory(d-bus, addr, s-vga.vram_size, +s-cirrus_linear_io_addr); +pci_register_memory(d-bus, addr + 0x100, 0x40, +s-cirrus_linear_bitblt_io_addr); It would probably be better to pass the PCIDevice instead of the bus. That would allow a per-device PCI IOMMU to be used (such as emulated VT-d). Ultimately, I don't think devices should be handling their IO region mappings but I think this could be a reasonable intermediate solution. Regards, Anthony Liguori
[Qemu-devel] [Bug 585113] Re: e1000 irq problems after live migration with qemu-kvm 0.12.4
I did 2 additional tests 1) Stop VM, Live Migrate, Continue - Triggers BUG 2) Stop VM, Continue - Does NOT trigger BUG. My guess it seems that pending interrupts are incorrectly transferred with kernel irqchip. As said earlier userspace irqchip does not trigger the bug. -- e1000 irq problems after live migration with qemu-kvm 0.12.4 https://bugs.launchpad.net/bugs/585113 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: sorry for resubmitting. i accidently moved this bug to qemu-kvm at launchpad where it is stuck... After live migrating ubuntu 9.10 server (2.6.31-14-server) and suse linux 10.1 (2.6.16.13-4-smp) it happens sometimes that the guest runs into irq problems. i mention these 2 guest oss since i have seen the error there. there are likely others around with the same problem. on the host i run 2.6.33.3 (kernel+mod) and qemu-kvm 0.12.4. i started a vm with: /usr/bin/qemu-kvm-0.12.4 -net tap,vlan=141,script=no,downscript=no,ifname=tap0 -net nic,vlan=141,model=e1000,macaddr=52:54:00:ff:00:72 -drive file=/dev/sdb,if=ide,boot=on,cache=none,aio=native -m 1024 -cpu qemu64,model_id='Intel(R) Xeon(R) CPU E5430 @ 2.66GHz' -monitor tcp:0:4001,server,nowait -vnc :1 -name 'migration-test-9-10' -boot order=dc,menu=on -k de -incoming tcp:172.21.55.22:5001 -pidfile /var/run/qemu/vm-155.pid -mem-path /hugepages -mem-prealloc -rtc base=utc,clock=host -usb -usbdevice tablet for testing i have a clean ubuntu 9.10 server 64-bit install and created a small script with fetches a dvd iso from a local server and checking md5sum in an endless loop. the download performance is approx. 50MB/s on that vm. to trigger the error i did several migrations of the vm throughout the last days. finally I ended up in the following oops in the guest: [64442.298521] irq 10: nobody cared (try booting with the irqpoll option) [64442.299175] Pid: 0, comm: swapper Not tainted 2.6.31-14-server #48-Ubuntu [64442.299179] Call Trace: [64442.299185] IRQ [810b4b96] __report_bad_irq+0x26/0xa0 [64442.299227] [810b4d9c] note_interrupt+0x18c/0x1d0 [64442.299232] [810b5415] handle_fasteoi_irq+0xd5/0x100 [64442.299244] [81014bdd] handle_irq+0x1d/0x30 [64442.299246] [810140b7] do_IRQ+0x67/0xe0 [64442.299249] [810129d3] ret_from_intr+0x0/0x11 [64442.299266] [810b3234] ? handle_IRQ_event+0x24/0x160 [64442.299269] [810b529f] ? handle_edge_irq+0xcf/0x170 [64442.299271] [81014bdd] ? handle_irq+0x1d/0x30 [64442.299273] [810140b7] ? do_IRQ+0x67/0xe0 [64442.299275] [810129d3] ? ret_from_intr+0x0/0x11 [64442.299290] [81526b14] ? _spin_unlock_irqrestore+0x14/0x20 [64442.299302] [8133257c] ? scsi_dispatch_cmd+0x16c/0x2d0 [64442.299307] [8133963a] ? scsi_request_fn+0x3aa/0x500 [64442.299322] [8125fafc] ? __blk_run_queue+0x6c/0x150 [64442.299324] [8125fcbb] ? blk_run_queue+0x2b/0x50 [64442.299327] [8133899f] ? scsi_run_queue+0xcf/0x2a0 [64442.299336] [81339a0d] ? scsi_next_command+0x3d/0x60 [64442.299338] [8133a21b] ? scsi_end_request+0xab/0xb0 [64442.299340] [8133a50e] ? scsi_io_completion+0x9e/0x4d0 [64442.299348] [81036419] ? default_spin_lock_flags+0x9/0x10 [64442.299351] [8133224d] ? scsi_finish_command+0xbd/0x130 [64442.299353] [8133aa95] ? scsi_softirq_done+0x145/0x170 [64442.299356] [81264e6d] ? blk_done_softirq+0x7d/0x90 [64442.299368] [810651fd] ? __do_softirq+0xbd/0x200 [64442.299370] [810131ac] ? call_softirq+0x1c/0x30 [64442.299372] [81014b85] ? do_softirq+0x55/0x90 [64442.299374] [81064f65] ? irq_exit+0x85/0x90 [64442.299376] [810140c0] ? do_IRQ+0x70/0xe0 [64442.299379] [810129d3] ? ret_from_intr+0x0/0x11 [64442.299380] EOI [810356f6] ? native_safe_halt+0x6/0x10 [64442.299390] [8101a20c] ? default_idle+0x4c/0xe0 [64442.299395] [815298f5] ? atomic_notifier_call_chain+0x15/0x20 [64442.299398] [81010e02] ? cpu_idle+0xb2/0x100 [64442.299406] [815123c6] ? rest_init+0x66/0x70 [64442.299424] [81838047] ? start_kernel+0x352/0x35b [64442.299427] [8183759a] ? x86_64_start_reservations+0x125/0x129 [64442.299429] [81837698] ? x86_64_start_kernel+0xfa/0x109 [64442.299433] handlers: [64442.299840] [ab80] (e1000_intr+0x0/0x190 [e1000]) [64442.300046] Disabling IRQ #10 After this the guest is still allive, but download performance is down to approx. 500KB/s This error is definetly not triggerable with option -no-kvm-irqchip. I have seen this error occasionally since my first experiments with qemu-kvm-88 and also without hugetablefs. Help appreciated.
[Qemu-devel] Re: [PATCH, RFC 4/4] Compile mc146818 only once
On Mon, May 24, 2010 at 3:31 PM, Jan Kiszka jan.kis...@web.de wrote: Blue Swirl wrote: 8 compilations less for the full build. Signed-off-by: Blue Swirl blauwir...@gmail.com ... diff --git a/default-configs/sparc64-softmmu.mak b/default-configs/sparc64-softmmu.mak index 1cc3f13..6ab0cf4 100644 --- a/default-configs/sparc64-softmmu.mak +++ b/default-configs/sparc64-softmmu.mak @@ -6,6 +6,7 @@ CONFIG_PTIMER=y CONFIG_VGA_PCI=y CONFIG_SERIAL=y CONFIG_PARALLEL=y +CONFIG_MC146818=y CONFIG_PCKBD=y CONFIG_FDC=y CONFIG_IDE_CORE=y Can be dropped at this chance, sparc64 makes no use of it. Right, though there some Blade machines (not emulated) with ds1287 (MC146818 compatible).
[Qemu-devel] Windows guest debugging on KVM/Qemu
hi, I am using KVM/Qemu to debug my Windows guest according to KVM wiki page (http://www.linux-kvm.org/page/WindowsGuestDrivers/GuestDebugging). It works for me and also I can only use one Windows guest and bind its serial port to a TCP port and run Virtual Serial Ports Emulator on my Windows dev machine. The problem is that these kind of connection is really slow. Is there any known issue with KVM serial port driver? There is a good discussion about the same issue one year ago. Not sure if there is any improvement or not after that. (http://www.mail-archive.com/k...@vger.kernel.org/msg21145.html). Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!
Re: [Qemu-devel] Re: [RFC PATCH] AMD IOMMU emulation
On Mon, May 24, 2010 at 3:40 PM, Joerg Roedel j...@8bytes.org wrote: Hi Eduard, On Thu, May 20, 2010 at 04:50:07PM +0300, Eduard - Gabriel Munteanu wrote: + --enable-amd-iommu-emul) amd_iommu=yes + ;; A compile-time option is a good idea. +/* MMIO registers */ +#define MMIO_DEVICE_TABLE 0x +#define MMIO_COMMAND_BASE 0x0008 +#define MMIO_EVENT_BASE 0x0010 +#define MMIO_CONTROL 0x0018 +#define MMIO_EXCL_BASE 0x0020 +#define MMIO_EXCL_LIMIT 0x0028 +#define MMIO_COMMAND_HEAD 0x2000 +#define MMIO_COMMAND_TAIL 0x2008 +#define MMIO_EVENT_HEAD 0x2010 +#define MMIO_EVENT_TAIL 0x2018 +#define MMIO_STATUS 0x2020 + +#define MMIO_SIZE 0x2028 This size should be a power-of-two value. In this case probably 0x4000. Not really, the devices can reserve regions of any size. There were some implementation deficiencies in earlier versions of QEMU, where the whole page would be reserved anyway, but this limitation has been removed long time ago. +#define MMIO_DEVTAB_SIZE_MASK ((1UL 12) - 1) +#define MMIO_DEVTAB_BASE_MASK (((1UL 52) - 1) ~MMIO_DEVTAB_SIZE_MASK) You must use ULL to be 32bit safe. This is also true for the defines below. [...] Otherwise the code looks good so far. Seems like the next step should be some work on a qemu dma-layer where you can hook the translation into. Joerg
Re: [Qemu-devel] [PATCH -V3 1/7] virtio-9p: Introduces an option to specify the security model.
On 05/21/2010 04:26 PM, Venkateswararao Jujjuri (JV) wrote:
The new option is:
-fsdev fstype,id=myid,path=/share_path/,security_model=[mapped|passthrough]
-virtfs fstype,path=/share_path/,security_model=[mapped|passthrough],mnt_tag=tag
In the case of mapped security model, files are created with QEMU user
credentials and the client-user's credentials are saved in extended attributes.
Whereas in the case of passthrough security model, files on the
filesystem are directly created with client-user's credentials.
Signed-off-by: Venkateswararao Jujjurijv...@linux.vnet.ibm.com
---
fsdev/qemu-fsdev.c | 14 +-
fsdev/qemu-fsdev.h |1 +
hw/virtio-9p.c | 14 ++
qemu-config.c | 12 +---
qemu-options.hx| 15 +++
vl.c | 18 +++---
6 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/fsdev/qemu-fsdev.c b/fsdev/qemu-fsdev.c
index 813e1f7..7d7a153 100644
--- a/fsdev/qemu-fsdev.c
+++ b/fsdev/qemu-fsdev.c
@@ -34,7 +34,7 @@ int qemu_fsdev_add(QemuOpts *opts)
return -1;
}
- for (i = 0; i ARRAY_SIZE(FsTypes); i++) {
+for (i = 0; i ARRAY_SIZE(FsTypes); i++) {
if (strcmp(FsTypes[i].name, qemu_opt_get(opts, fstype)) == 0) {
break;
}
@@ -46,10 +46,22 @@ int qemu_fsdev_add(QemuOpts *opts)
return -1;
}
+if (qemu_opt_get(opts, path) == NULL) {
+fprintf(stderr, fsdev: No path specified.\n);
+return -1;
+}
+
+if (qemu_opt_get(opts, security_model) == NULL) {
+fprintf(stderr, fsdev: No security_model specified.\n);
+return -1;
+}
+
fsle = qemu_malloc(sizeof(*fsle));
fsle-fse.fsdev_id = qemu_strdup(qemu_opts_id(opts));
fsle-fse.path = qemu_strdup(qemu_opt_get(opts, path));
+fsle-fse.security_model = qemu_strdup(qemu_opt_get(opts,
+security_model));
fsle-fse.ops = FsTypes[i].ops;
QTAILQ_INSERT_TAIL(fstype_entries, fsle, next);
diff --git a/fsdev/qemu-fsdev.h b/fsdev/qemu-fsdev.h
index b50fbe0..6c27881 100644
--- a/fsdev/qemu-fsdev.h
+++ b/fsdev/qemu-fsdev.h
@@ -40,6 +40,7 @@ typedef struct FsTypeTable {
typedef struct FsTypeEntry {
char *fsdev_id;
char *path;
+char *security_model;
FileOperations *ops;
} FsTypeEntry;
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 687abc0..8ecd39c 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -2413,6 +2413,20 @@ VirtIODevice *virtio_9p_init(DeviceState *dev, V9fsConf
*conf)
exit(1);
}
+if (!strcmp(fse-security_model, passthrough)) {
+/* Files on the Fileserver set to client user credentials */
+} else if (!strcmp(fse-security_model, mapped)) {
+/* Files on the fileserver are set to QEMU credentials.
+ * Client user credentials are saved in extended attributes.
+ */
+} else {
+/* user haven't specified a correct security option */
+fprintf(stderr, one of the following must be specified as the
+security option:\n\t security_model=passthrough \n\t
+security_model=mapped\n);
+exit(1);
+}
error_report and a return NULL would be more appropriate than an exit(1).
Regards,
Anthony Liguori
+
if (lstat(fse-path,stat)) {
fprintf(stderr, share path %s does not exist\n, fse-path);
exit(1);
diff --git a/qemu-config.c b/qemu-config.c
index d500885..e1e3aa1 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -160,9 +160,12 @@ QemuOptsList qemu_fsdev_opts = {
{
.name = fstype,
.type = QEMU_OPT_STRING,
-}, {
+},{
.name = path,
.type = QEMU_OPT_STRING,
+},{
+.name = security_model,
+.type = QEMU_OPT_STRING,
},
{ /*End of list */ }
},
@@ -178,12 +181,15 @@ QemuOptsList qemu_virtfs_opts = {
{
.name = fstype,
.type = QEMU_OPT_STRING,
-}, {
+},{
.name = path,
.type = QEMU_OPT_STRING,
-}, {
+},{
.name = mount_tag,
.type = QEMU_OPT_STRING,
+},{
+.name = security_model,
+.type = QEMU_OPT_STRING,
},
{ /*End of list */ }
diff --git a/qemu-options.hx b/qemu-options.hx
index 12f6b51..d557c92 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -482,7 +482,7 @@ ETEXI
DEFHEADING(File system options:)
DEF(fsdev, HAS_ARG, QEMU_OPTION_fsdev,
--fsdev local,id=id,path=path\n,
+-fsdev local,id=id,path=path,security_model=[mapped|passthrough]\n,
QEMU_ARCH_ALL)
STEXI
@@ -498,7 +498,7 @@ The specific Fstype will determine the applicable options.
Options to each backend are described below.
-...@item -fsdev local ,i...@var{id} ,pa...@var{path}
+...@item -fsdev local ,i...@var{id} ,pa...@var{path}
Re: [Qemu-devel] [PATCH -V3 5/7] virtio-9p: Implemented security model for symlink and link.
On 05/21/2010 04:26 PM, Venkateswararao Jujjuri (JV) wrote:
Signed-off-by: Venkateswararao Jujjurijv...@linux.vnet.ibm.com
---
hw/file-op-9p.h |4 +-
hw/virtio-9p-local.c | 87 +++--
hw/virtio-9p.c | 24 ++
3 files changed, 88 insertions(+), 27 deletions(-)
diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h
index 752fbad..0a9c10a 100644
--- a/hw/file-op-9p.h
+++ b/hw/file-op-9p.h
@@ -54,8 +54,8 @@ typedef struct FileOperations
int (*mknod)(FsContext *, const char *, FsCred *);
int (*utime)(FsContext *, const char *, const struct utimbuf *);
int (*remove)(FsContext *, const char *);
-int (*symlink)(FsContext *, const char *, const char *);
-int (*link)(FsContext *, const char *, const char *);
+int (*symlink)(FsContext *, const char *, const char *, FsCred *);
+int (*link)(FsContext *, const char *, const char *, FsCred *);
int (*setuid)(FsContext *, uid_t);
int (*close)(FsContext *, int);
int (*closedir)(FsContext *, DIR *);
diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c
index bfcd695..ca0f065 100644
--- a/hw/virtio-9p-local.c
+++ b/hw/virtio-9p-local.c
@@ -64,12 +64,25 @@ static int local_set_xattr(const char *path, FsCred *credp)
}
}
return 0;
- }
+}
-static ssize_t local_readlink(FsContext *ctx, const char *path,
-char *buf, size_t bufsz)
+static ssize_t local_readlink(FsContext *fs_ctx, const char *path,
+char *buf, size_t bufsz)
{
-return readlink(rpath(ctx, path), buf, bufsz);
+ssize_t tsize = -1;
+if (fs_ctx-fs_sm == sm_mapped) {
+int fd;
+fd = open(rpath(fs_ctx, path), O_RDONLY);
+if (fd == -1) {
+return -1;
+}
+tsize = read(fd, (void *)buf, bufsz);
+close(fd);
+return tsize;
+} else if (fs_ctx-fs_sm == sm_passthrough) {
+tsize = readlink(rpath(fs_ctx, path), buf, bufsz);
+}
+return tsize;
}
static int local_close(FsContext *ctx, int fd)
@@ -247,32 +260,70 @@ err_end:
return err;
}
-static int local_symlink(FsContext *ctx, const char *oldpath,
-const char *newpath)
+
+static int local_symlink(FsContext *fs_ctx, const char *oldpath,
+const char *newpath, FsCred *credp)
{
-return symlink(oldpath, rpath(ctx, newpath));
+int err = -1;
+/* Determine the security model */
+if (fs_ctx-fs_sm == sm_mapped) {
+int fd;
+ssize_t oldpath_size, write_size;
+fd = open(rpath(fs_ctx, newpath), O_CREAT|O_EXCL|O_RDWR,
+SM_LOCAL_MODE_BITS);
+if (fd == -1) {
+return fd;
+}
+/* Write the oldpath (target) to the file. */
+oldpath_size = strlen(oldpath) + 1;
+write_size = write(fd, (void *)oldpath, oldpath_size);
Signals are pretty frequent in qemu so not handling EINTR is asking for
trouble.
Regards,
Anthony Liguori
+if (write_size != oldpath_size) {
+close(fd);
+err = -1;
+goto err_end;
+}
+close(fd);
+/* Set cleint credentials in symlink's xattr */
+credp-fc_mode = credp-fc_mode|S_IFLNK;
+err = local_set_xattr(rpath(fs_ctx, newpath), credp);
+if (err == -1) {
+goto err_end;
+}
+} else if (fs_ctx-fs_sm == sm_passthrough) {
+err = symlink(oldpath, rpath(fs_ctx, newpath));
+if (err) {
+return err;
+}
+err = chmod(rpath(fs_ctx, newpath), credp-fc_mode 0);
+if (err == -1) {
+goto err_end;
+}
+err = chown(rpath(fs_ctx, newpath), credp-fc_uid, credp-fc_gid);
+if (err == -1) {
+goto err_end;
+}
+}
+return err;
+
+err_end:
+remove(rpath(fs_ctx, newpath));
+return err;
}
-static int local_link(FsContext *ctx, const char *oldpath, const char *newpath)
+static int local_link(FsContext *fs_ctx, const char *oldpath,
+const char *newpath, FsCred *credp)
{
-char *tmp = qemu_strdup(rpath(ctx, oldpath));
-int err, serrno = 0;
+char *tmp = qemu_strdup(rpath(fs_ctx, oldpath));
+int err;
if (tmp == NULL) {
return -ENOMEM;
}
-err = link(tmp, rpath(ctx, newpath));
-if (err == -1) {
-serrno = errno;
-}
+err = link(tmp, rpath(fs_ctx, newpath));
qemu_free(tmp);
-if (err == -1) {
-errno = serrno;
-}
-
return err;
}
diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
index 30f649d..fbc846b 100644
--- a/hw/virtio-9p.c
+++ b/hw/virtio-9p.c
@@ -197,15 +197,25 @@ static int v9fs_do_open2(V9fsState *s, V9fsCreateState
*vs)
return s-ops-open2(s-ctx, vs-fullname.data, flags,cred);
}
-static int v9fs_do_symlink(V9fsState *s, V9fsString *oldpath,
-V9fsString *newpath)
+static int v9fs_do_symlink(V9fsState
[Qemu-devel] [RFT][PATCH 01/15] hpet: Catch out-of-bounds timer access
From: Jan Kiszka jan.kis...@siemens.com
Also prevent out-of-bounds write access to the timers but don't spam the
host console if it triggers.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 8729fb2..1980906 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -294,7 +294,7 @@ static uint32_t hpet_ram_readl(void *opaque,
target_phys_addr_t addr)
if (index = 0x100 index = 0x3ff) {
uint8_t timer_id = (addr - 0x100) / 0x20;
if (timer_id HPET_NUM_TIMERS - 1) {
-printf(qemu: timer id out of range\n);
+DPRINTF(qemu: timer id out of range\n);
return 0;
}
HPETTimer *timer = s-timer[timer_id];
@@ -383,6 +383,10 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
DPRINTF(qemu: hpet_ram_writel timer_id = %#x \n, timer_id);
HPETTimer *timer = s-timer[timer_id];
+if (timer_id HPET_NUM_TIMERS - 1) {
+DPRINTF(qemu: timer id out of range\n);
+return;
+}
switch ((addr - 0x100) % 0x20) {
case HPET_TN_CFG:
DPRINTF(qemu: hpet_ram_writel HPET_TN_CFG\n);
--
1.6.0.2
[Qemu-devel] [RFT][PATCH 04/15] hpet: Move static timer field initialization
From: Jan Kiszka jan.kis...@siemens.com
Properly initialize HPETTimer::tn and HPETTimer::state once during
hpet_init instead of (re-)writing them on every reset.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index bcb160b..fd7a1fd 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -575,12 +575,10 @@ static void hpet_reset(void *opaque)
HPETTimer *timer = s-timer[i];
hpet_del_timer(timer);
-timer-tn = i;
timer-cmp = ~0ULL;
timer-config = HPET_TN_PERIODIC_CAP | HPET_TN_SIZE_CAP;
/* advertise availability of ioapic inti2 */
timer-config |= 0x0004ULL 32;
-timer-state = s;
timer-period = 0ULL;
timer-wrap_flag = 0;
}
@@ -617,6 +615,8 @@ void hpet_init(qemu_irq *irq)
for (i = 0; i HPET_NUM_TIMERS; i++) {
timer = s-timer[i];
timer-qemu_timer = qemu_new_timer(vm_clock, hpet_timer, timer);
+timer-tn = i;
+timer-state = s;
}
vmstate_register(-1, vmstate_hpet, s);
qemu_register_reset(hpet_reset, s);
--
1.6.0.2
[Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option
Juan Quintela wrote: We already have to disable hpet for 5.4 (1 year ago). It was done with a local hack because it was supposed that for next big release it would have been fixed. But this remains a RHEL issue. Redhat decided to compile out features that are unsupported, others seem to handle this differently. And then, everybody has a different hack to disable the features that they don't need. Instead of doing a local hack, we do a patch that allows anyone to disable HPET if it sees fit. So far I only know of precisely one user that wants to disable x86 platform devices at build-time. Here we are, and device is still not fixed, what to do? Another local patch? Just get upstream to integrate a sane way to disable it and let in enable by default? Let's start with listing your requirements to no longer disable HPET. It is not stable at this point in time :-( Running with --no-hpet is better than without it in all our testing. If we have to ask/modify everything to use --no-hpet, we can also compile-out it. That would already help us to asses how long !CONFIG_HPET would actually be of any use at all. I'm yet optimistic that we can resolve most if not all remaining concerns for 0.13 - and CONFIG_HPET would at best be 0.13 material anyway. At this very point in time: - it is not stable Well, that is helpful. - lack irq-reinjection when missing ticks That is more helpful. I just reworked the RTC regarding this, I guess it will be straightforward to address it in the HPET too. (I was not the one debugging/testing this so I don't have more details, but can ask for them). So, it is not stable enough yet. HPET is a fairly small device, a few hundred lines of code, only a few ugly platform dependencies, but that's it already. I bet it could have been fixed by now if someone just started by the time the tests reported it is not stable enough. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] [RFT][PATCH 00/15] HPET cleanups, fixes, enhancements
Not yet for merge (unless I happened to forgot adding bugs), just a Request For Testing (and for review, of course). This series grew beyond my initial plans and my current testing capabilities, Linux and Win7 are apparently still fine, but that's all I can say so far. To summarize contributions to the HPET model: - fixed host memory corruptions by guest (patch 1, likely stable stuff) - coding style cleanup - qdev conversion - detangling of RTC from HPET dependencies, specifically via providing feedback IRQ handlers to easy IRQ coalescing workaround implementations - support for level-triggered HPET IRQs (untested - does anyone know of a user?) - up to 32 comparators (configurable via qdev prop) - MSI support (configurable via qdev prop) - dropped obsolete info hpet and query-hpet Yet missing: - IRQ coalescing workaround - maybe some refactoring to easy compile-time disabling (Juan?) - build once (I leave this to Blue Swirl :) ) - multiple HPET blocks (no urgent need yet) Please give this hell. Jan Kiszka (15): hpet: Catch out-of-bounds timer access hpet: Coding style cleanups and some refactorings hpet: Silence warning on write to running main counter hpet: Move static timer field initialization hpet: Convert to qdev hpet: Start/stop timer when HPET_TN_ENABLE is modified qemu_irq: Add IRQ handlers with delivery feedback x86: Refactor RTC IRQ coalescing workaround hpet/rtc: Rework RTC IRQ replacement by HPET hpet: Drop static state hpet: Add support for level-triggered interrupts vmstate: Add VMSTATE_STRUCT_VARRAY_UINT8 hpet: Make number of timers configurable hpet: Add MSI support monitor/QMP: Drop info hpet / query-hpet QMP/vm-info |2 +- hw/apic.c| 63 +++--- hw/apic.h| 11 +- hw/hpet.c| 582 + hw/hpet_emul.h | 46 + hw/hw.h | 10 + hw/i8259.c | 20 ++- hw/ioapic.c | 34 ++-- hw/irq.c | 38 +++- hw/irq.h | 22 ++- hw/mc146818rtc.c | 60 ++ hw/mc146818rtc.h |4 +- hw/mips_jazz.c |2 +- hw/mips_malta.c |2 +- hw/mips_r4k.c|2 +- hw/pc.c | 33 +++- hw/pc.h |2 +- hw/pc_piix.c |2 +- hw/ppc_prep.c|2 +- monitor.c| 33 --- 20 files changed, 552 insertions(+), 418 deletions(-)
[Qemu-devel] [RFT][PATCH 05/15] hpet: Convert to qdev
From: Jan Kiszka jan.kis...@siemens.com
Register the HPET as a sysbus device and create it that way. As it can
route its IRQs to any ISA IRQ, we need to connect it to all 24 of them.
Once converted to qdev, we can move reset handler and vmstate
registration into its hands as well.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c | 43 ++-
hw/hpet_emul.h |3 ++-
hw/pc.c|7 ++-
3 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index fd7a1fd..6974935 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -29,6 +29,7 @@
#include console.h
#include qemu-timer.h
#include hpet_emul.h
+#include sysbus.h
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -54,8 +55,9 @@ typedef struct HPETTimer { /* timers */
} HPETTimer;
typedef struct HPETState {
+SysBusDevice busdev;
uint64_t hpet_offset;
-qemu_irq *irqs;
+qemu_irq irqs[HPET_NUM_IRQ_ROUTES];
HPETTimer timer[HPET_NUM_TIMERS];
/* Memory-mapped, software visible registers */
@@ -565,9 +567,9 @@ static CPUWriteMemoryFunc * const hpet_ram_write[] = {
hpet_ram_writel,
};
-static void hpet_reset(void *opaque)
+static void hpet_reset(DeviceState *d)
{
-HPETState *s = opaque;
+HPETState *s = FROM_SYSBUS(HPETState, sysbus_from_qdev(d));
int i;
static int count = 0;
@@ -600,28 +602,43 @@ static void hpet_reset(void *opaque)
count = 1;
}
-
-void hpet_init(qemu_irq *irq)
+static int hpet_init(SysBusDevice *dev)
{
+HPETState *s = FROM_SYSBUS(HPETState, dev);
int i, iomemtype;
HPETTimer *timer;
-HPETState *s;
-
-DPRINTF (hpet_init\n);
-s = qemu_mallocz(sizeof(HPETState));
+assert(!hpet_statep);
hpet_statep = s;
-s-irqs = irq;
+for (i = 0; i HPET_NUM_IRQ_ROUTES; i++) {
+sysbus_init_irq(dev, s-irqs[i]);
+}
for (i = 0; i HPET_NUM_TIMERS; i++) {
timer = s-timer[i];
timer-qemu_timer = qemu_new_timer(vm_clock, hpet_timer, timer);
timer-tn = i;
timer-state = s;
}
-vmstate_register(-1, vmstate_hpet, s);
-qemu_register_reset(hpet_reset, s);
+
/* HPET Area */
iomemtype = cpu_register_io_memory(hpet_ram_read,
hpet_ram_write, s);
-cpu_register_physical_memory(HPET_BASE, 0x400, iomemtype);
+sysbus_init_mmio(dev, 0x400, iomemtype);
+return 0;
}
+
+static SysBusDeviceInfo hpet_device_info = {
+.qdev.name= hpet,
+.qdev.size= sizeof(HPETState),
+.qdev.no_user = 1,
+.qdev.vmsd= vmstate_hpet,
+.qdev.reset = hpet_reset,
+.init = hpet_init,
+};
+
+static void hpet_register_device(void)
+{
+sysbus_register_withprop(hpet_device_info);
+}
+
+device_init(hpet_register_device)
diff --git a/hw/hpet_emul.h b/hw/hpet_emul.h
index 2f5f8ba..785f850 100644
--- a/hw/hpet_emul.h
+++ b/hw/hpet_emul.h
@@ -19,6 +19,8 @@
#define FS_PER_NS 100
#define HPET_NUM_TIMERS 3
+#define HPET_NUM_IRQ_ROUTES 32
+
#define HPET_CFG_ENABLE 0x001
#define HPET_CFG_LEGACY 0x002
@@ -47,7 +49,6 @@
#if defined TARGET_I386
extern uint32_t hpet_in_legacy_mode(void);
-extern void hpet_init(qemu_irq *irq);
#endif
#endif
diff --git a/hw/pc.c b/hw/pc.c
index e7f31d3..631b0ae 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -35,6 +35,7 @@
#include elf.h
#include multiboot.h
#include mc146818rtc.h
+#include sysbus.h
/* output Bochs bios info messages */
//#define DEBUG_BIOS
@@ -945,7 +946,11 @@ void pc_basic_device_init(qemu_irq *isa_irq,
pit = pit_init(0x40, isa_reserve_irq(0));
pcspk_init(pit);
if (!no_hpet) {
-hpet_init(isa_irq);
+DeviceState *hpet = sysbus_create_simple(hpet, HPET_BASE, NULL);
+
+for (i = 0; i 24; i++) {
+sysbus_connect_irq(sysbus_from_qdev(hpet), i, isa_irq[i]);
+}
}
for(i = 0; i MAX_SERIAL_PORTS; i++) {
--
1.6.0.2
[Qemu-devel] [RFT][PATCH 03/15] hpet: Silence warning on write to running main counter
From: Jan Kiszka jan.kis...@siemens.com
Setting the main counter while the HPET is enabled may not be a good
idea of the guest, but it is supported and should, thus, not spam the
host console with warnings.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 2836fb0..bcb160b 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -520,7 +520,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
break;
case HPET_COUNTER:
if (hpet_enabled()) {
-printf(qemu: Writing counter while HPET enabled!\n);
+DPRINTF(qemu: Writing counter while HPET enabled!\n);
}
s-hpet_counter =
(s-hpet_counter 0xULL) | value;
@@ -529,7 +529,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
break;
case HPET_COUNTER + 4:
if (hpet_enabled()) {
-printf(qemu: Writing counter while HPET enabled!\n);
+DPRINTF(qemu: Writing counter while HPET enabled!\n);
}
s-hpet_counter =
(s-hpet_counter 0xULL) | (((uint64_t)value) 32);
--
1.6.0.2
