[Qemu-devel] [PATCH 18/18] Introduce kemari: to enable FT migration mode (Kemari).
When kemari: is set in front of URI of migrate command, it will turn
on ft_mode to start FT migration mode (Kemari). On the receiver side,
the option looks like, -incoming kemari:protocol:address:port
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Acked-by: Paolo Bonzini pbonz...@redhat.com
---
hmp-commands.hx |4 +++-
migration.c | 12
qmp-commands.hx |4 +++-
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 372bef4..4588f38 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -760,7 +760,9 @@ ETEXI
\n\t\t\t -b for migration without shared storage with
full copy of disk\n\t\t\t -i for migration without
shared storage with incremental copy of disk
- (base image shared between src and destination),
+ (base image shared between src and destination)
+ \n\t\t\t put \kemari:\ in front of URI to enable
+ Fault Tolerance mode (Kemari protocol),
.user_print = monitor_user_noop,
.mhandler.cmd_new = do_migrate,
},
diff --git a/migration.c b/migration.c
index cdea459..ee57b0e 100644
--- a/migration.c
+++ b/migration.c
@@ -48,6 +48,12 @@ int qemu_start_incoming_migration(const char *uri)
const char *p;
int ret;
+/* check ft_mode (Kemari protocol) */
+if (strstart(uri, kemari:, p)) {
+ft_mode = FT_INIT;
+uri = p;
+}
+
if (strstart(uri, tcp:, p))
ret = tcp_start_incoming_migration(p);
#if !defined(WIN32)
@@ -99,6 +105,12 @@ int do_migrate(Monitor *mon, const QDict *qdict, QObject
**ret_data)
return -1;
}
+/* check ft_mode (Kemari protocol) */
+if (strstart(uri, kemari:, p)) {
+ft_mode = FT_INIT;
+uri = p;
+}
+
if (strstart(uri, tcp:, p)) {
s = tcp_start_outgoing_migration(mon, p, max_throttle, detach,
blk, inc);
diff --git a/qmp-commands.hx b/qmp-commands.hx
index df40a3d..68ca48a 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -437,7 +437,9 @@ EQMP
\n\t\t\t -b for migration without shared storage with
full copy of disk\n\t\t\t -i for migration without
shared storage with incremental copy of disk
- (base image shared between src and destination),
+ (base image shared between src and destination)
+ \n\t\t\t put \kemari:\ in front of URI to enable
+ Fault Tolerance mode (Kemari protocol),
.user_print = monitor_user_noop,
.mhandler.cmd_new = do_migrate,
},
--
1.7.1.2
[Qemu-devel] [PATCH 15/18] savevm: introduce qemu_savevm_trans_{begin, commit}.
Introduce qemu_savevm_trans_{begin,commit} to send the memory and
device info together, while avoiding cancelling memory state tracking.
This patch also abstracts common code between
qemu_savevm_state_{begin,iterate,commit}.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
savevm.c | 157 +++---
sysemu.h |2 +
2 files changed, 101 insertions(+), 58 deletions(-)
diff --git a/savevm.c b/savevm.c
index aa760b7..c21b901 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1602,29 +1602,68 @@ bool qemu_savevm_state_blocked(Monitor *mon)
return false;
}
-int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f, int blk_enable,
-int shared)
+/*
+ * section: header to write
+ * inc: if true, forces to pass SECTION_PART instead of SECTION_START
+ * pause: if true, breaks the loop when live handler returned 0
+ */
+static int qemu_savevm_state_live(Monitor *mon, QEMUFile *f, int section,
+ bool inc, bool pause)
{
SaveStateEntry *se;
+int skip = 0, ret;
QTAILQ_FOREACH(se, savevm_handlers, entry) {
-if(se-set_params == NULL) {
+int len, stage;
+
+if (se-save_live_state == NULL) {
continue;
- }
- se-set_params(blk_enable, shared, se-opaque);
+}
+
+/* Section type */
+qemu_put_byte(f, section);
+qemu_put_be32(f, se-section_id);
+
+if (section == QEMU_VM_SECTION_START) {
+/* ID string */
+len = strlen(se-idstr);
+qemu_put_byte(f, len);
+qemu_put_buffer(f, (uint8_t *)se-idstr, len);
+
+qemu_put_be32(f, se-instance_id);
+qemu_put_be32(f, se-version_id);
+
+stage = inc ? QEMU_VM_SECTION_PART : QEMU_VM_SECTION_START;
+} else {
+assert(inc);
+stage = section;
+}
+
+ret = se-save_live_state(mon, f, stage, se-opaque);
+if (!ret) {
+skip++;
+if (pause) {
+break;
+}
+}
}
-
-qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
-qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+
+return skip;
+}
+
+static void qemu_savevm_state_full(QEMUFile *f)
+{
+SaveStateEntry *se;
QTAILQ_FOREACH(se, savevm_handlers, entry) {
int len;
-if (se-save_live_state == NULL)
+if (se-save_state == NULL se-vmsd == NULL) {
continue;
+}
/* Section type */
-qemu_put_byte(f, QEMU_VM_SECTION_START);
+qemu_put_byte(f, QEMU_VM_SECTION_FULL);
qemu_put_be32(f, se-section_id);
/* ID string */
@@ -1635,9 +1674,29 @@ int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f,
int blk_enable,
qemu_put_be32(f, se-instance_id);
qemu_put_be32(f, se-version_id);
-se-save_live_state(mon, f, QEMU_VM_SECTION_START, se-opaque);
+vmstate_save(f, se);
+}
+
+qemu_put_byte(f, QEMU_VM_EOF);
+}
+
+int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f, int blk_enable,
+int shared)
+{
+SaveStateEntry *se;
+
+QTAILQ_FOREACH(se, savevm_handlers, entry) {
+if (se-set_params == NULL) {
+continue;
+}
+se-set_params(blk_enable, shared, se-opaque);
}
+qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
+qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+
+qemu_savevm_state_live(mon, f, QEMU_VM_SECTION_START, 0, 0);
+
if (qemu_file_has_error(f)) {
qemu_savevm_state_cancel(mon, f);
return -EIO;
@@ -1648,29 +1707,16 @@ int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f,
int blk_enable,
int qemu_savevm_state_iterate(Monitor *mon, QEMUFile *f)
{
-SaveStateEntry *se;
int ret = 1;
-QTAILQ_FOREACH(se, savevm_handlers, entry) {
-if (se-save_live_state == NULL)
-continue;
-
-/* Section type */
-qemu_put_byte(f, QEMU_VM_SECTION_PART);
-qemu_put_be32(f, se-section_id);
-
-ret = se-save_live_state(mon, f, QEMU_VM_SECTION_PART, se-opaque);
-if (!ret) {
-/* Do not proceed to the next vmstate before this one reported
- completion of the current stage. This serializes the migration
- and reduces the probability that a faster changing state is
- synchronized over and over again. */
-break;
-}
-}
-
-if (ret)
+/* Do not proceed to the next vmstate before this one reported
+ completion of the current stage. This serializes the migration
+ and reduces the probability that a faster changing state is
+ synchronized over and over again. */
+ret = qemu_savevm_state_live(mon, f, QEMU_VM_SECTION_PART, 1, 1);
+if (!ret) {
return 1;
+}
if (qemu_file_has_error(f)) {
qemu_savevm_state_cancel(mon, f);
@@ -1682,46 +1728,41 @@ int
[Qemu-devel] [PATCH 16/18] migration: introduce migrate_ft_trans_{put, get}_ready(), and modify migrate_fd_put_ready() when ft_mode is on.
Introduce migrate_ft_trans_put_ready() which kicks the FT transaction
cycle. When ft_mode is on, migrate_fd_put_ready() would open
ft_trans_file and turn on event_tap. To end or cancel FT transaction,
ft_mode and event_tap is turned off. migrate_ft_trans_get_ready() is
called to receive ack from the receiver.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
migration.c | 261 ++-
1 files changed, 260 insertions(+), 1 deletions(-)
diff --git a/migration.c b/migration.c
index 1c2d956..cdea459 100644
--- a/migration.c
+++ b/migration.c
@@ -21,6 +21,7 @@
#include qemu_socket.h
#include block-migration.h
#include qemu-objects.h
+#include event-tap.h
//#define DEBUG_MIGRATION
@@ -283,6 +284,14 @@ void migrate_fd_error(FdMigrationState *s)
migrate_fd_cleanup(s);
}
+static void migrate_ft_trans_error(FdMigrationState *s)
+{
+ft_mode = FT_ERROR;
+qemu_savevm_state_cancel(s-mon, s-file);
+migrate_fd_error(s);
+event_tap_unregister();
+}
+
int migrate_fd_cleanup(FdMigrationState *s)
{
int ret = 0;
@@ -318,6 +327,17 @@ void migrate_fd_put_notify(void *opaque)
qemu_file_put_notify(s-file);
}
+static void migrate_fd_get_notify(void *opaque)
+{
+FdMigrationState *s = opaque;
+
+qemu_set_fd_handler2(s-fd, NULL, NULL, NULL, NULL);
+qemu_file_get_notify(s-file);
+if (qemu_file_has_error(s-file)) {
+migrate_ft_trans_error(s);
+}
+}
+
ssize_t migrate_fd_put_buffer(void *opaque, const void *data, size_t size)
{
FdMigrationState *s = opaque;
@@ -353,6 +373,10 @@ int migrate_fd_get_buffer(void *opaque, uint8_t *data,
int64_t pos, size_t size)
ret = -(s-get_error(s));
}
+if (ret == -EAGAIN) {
+qemu_set_fd_handler2(s-fd, NULL, migrate_fd_get_notify, NULL, s);
+}
+
return ret;
}
@@ -379,6 +403,230 @@ void migrate_fd_connect(FdMigrationState *s)
migrate_fd_put_ready(s);
}
+static int migrate_ft_trans_commit(void *opaque)
+{
+FdMigrationState *s = opaque;
+int ret = -1;
+
+if (ft_mode != FT_TRANSACTION_COMMIT ft_mode != FT_TRANSACTION_ATOMIC) {
+fprintf(stderr,
+migrate_ft_trans_commit: invalid ft_mode %d\n, ft_mode);
+goto out;
+}
+
+do {
+if (ft_mode == FT_TRANSACTION_ATOMIC) {
+if (qemu_ft_trans_begin(s-file) 0) {
+fprintf(stderr, qemu_ft_trans_begin failed\n);
+goto out;
+}
+
+ret = qemu_savevm_trans_begin(s-mon, s-file, 0);
+if (ret 0) {
+fprintf(stderr, qemu_savevm_trans_begin failed\n);
+goto out;
+}
+
+ft_mode = FT_TRANSACTION_COMMIT;
+if (ret) {
+/* don't proceed until if fd isn't ready */
+goto out;
+}
+}
+
+/* make the VM state consistent by flushing outstanding events */
+vm_stop(0);
+
+/* send at full speed */
+qemu_file_set_rate_limit(s-file, 0);
+
+ret = qemu_savevm_trans_complete(s-mon, s-file);
+if (ret 0) {
+fprintf(stderr, qemu_savevm_trans_complete failed\n);
+goto out;
+}
+
+ret = qemu_ft_trans_commit(s-file);
+if (ret 0) {
+fprintf(stderr, qemu_ft_trans_commit failed\n);
+goto out;
+}
+
+if (ret) {
+ft_mode = FT_TRANSACTION_RECV;
+ret = 1;
+goto out;
+}
+
+/* flush and check if events are remaining */
+vm_start();
+ret = event_tap_flush_one();
+if (ret 0) {
+fprintf(stderr, event_tap_flush_one failed\n);
+goto out;
+}
+
+ft_mode = ret ? FT_TRANSACTION_BEGIN : FT_TRANSACTION_ATOMIC;
+} while (ft_mode != FT_TRANSACTION_BEGIN);
+
+vm_start();
+ret = 0;
+
+out:
+return ret;
+}
+
+static int migrate_ft_trans_get_ready(void *opaque)
+{
+FdMigrationState *s = opaque;
+int ret = -1;
+
+if (ft_mode != FT_TRANSACTION_RECV) {
+fprintf(stderr,
+migrate_ft_trans_get_ready: invalid ft_mode %d\n, ft_mode);
+goto error_out;
+}
+
+/* flush and check if events are remaining */
+vm_start();
+ret = event_tap_flush_one();
+if (ret 0) {
+fprintf(stderr, event_tap_flush_one failed\n);
+goto error_out;
+}
+
+if (ret) {
+ft_mode = FT_TRANSACTION_BEGIN;
+} else {
+ft_mode = FT_TRANSACTION_ATOMIC;
+
+ret = migrate_ft_trans_commit(s);
+if (ret 0) {
+goto error_out;
+}
+if (ret) {
+goto out;
+}
+}
+
+vm_start();
+ret = 0;
+goto out;
+
+error_out:
+migrate_ft_trans_error(s);
+
+out:
+return ret;
+}
+
+static int migrate_ft_trans_put_ready(void)
+{
+FdMigrationState *s = migrate_to_fms(current_migration);
+
Re: [Qemu-devel] Re: [PATCH V6 1/4 resend] nmi: convert cpu_index to cpu-index
Luiz Capitulino lcapitul...@redhat.com writes: On Mon, 21 Feb 2011 09:37:57 +0800 Lai Jiangshan la...@cn.fujitsu.com wrote: Hi, Luiz Capitulino Any problem? Sorry for the delay. Looks good in general to me know, there's only one small problem and it's the error message: (qemu) nmi 100 Parameter 'cpu-index' expects a CPU number (qemu) I would expect that kind of error message when no CPU number is provided, but in the case above the CPU number is provided but it happens to be invalid. Why? This is not Lai Jiangshan's fault. It's what QERR_INVALID_PARAMETER_VALUE reports. The current design of QError makes it hard to do better. expects a valid CPU number could be done, if you think that's better. By the way, please add an introductory email with proper changelog when submitting series/patches, so that it's easier to review. Also make sure the parts are threaded together properly with In-Reply-To and References headers, because that helps e-mail readers to keep the parts together. Lack of threading is annoying, and annoying reviewers intentionally would be rude :) Suggested workflow: git-format-patch --cover-letter -ns ... look over patch files, edit the cover letter to taste git-send-email --to qemu-devel@nongnu.org 0*.patch
Re: [Qemu-devel] Re: Network bridging without adding bridge with brctl, possible?
On 2011-02-24 07:49, Gerhard Wiesinger wrote: On Wed, 23 Feb 2011, Jan Kiszka wrote: Right, but if I set IP(eth0) == IP(macvlan0), I'm able to communicate between macvlan0 and mactapX, thus between guest and host. Just re-checked here, still works (after resolving the usual MAC address mess I caused by configuring manually). Thnx for the tipp. Did you use MAC(eth0) == MAC(macvlan0) or MAC(eth0) MAC(macvlan0) to get it to work? The latter (I just let macvlan/tap choose their MACs). OK, that should be possible because of the layer2 split brain implementation of macvlan/macvtap between lower interface (e.g. eth0) and mavlan*/macvtap*. Therefore the macvlan*/macvtap* interfaces see only each other and the outer world/eth0 is another distinct layer2 domain. My only concern is about layer3 (IP) and same IP address on the same host. Because of the split brain there shouldn't be any problem from the macvlan*/macvtap* point of view and also from the eth0 outside world view. But from the view of localhost/iptables/routing the kernel sees 2 identical IP addresses. Which one is used on a local ping or local connect? None of both, rather the lookback interface. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v6 0/5] ARM: fix Neon VRECPE and VRSQRTE instructions.
On Mon, Feb 21, 2011 at 05:38:43PM +0100, Christophe Lyon wrote: These 5 patches fix the ARM Neon VRECPE and VRSQRTE instructions by matching the algorithms descibed in the ARM ARM. Patches #1 to #3 are unchanged compared to v4 Patches #4 and #5 should address Peter's comments. Christophe Lyon (5): softfloat: move all default NaN definitions to softfloat.h. softfloat: add _set_sign(), _infinity and _half for 32 and 64 bits floats. target-arm: Introduce float64_256 and float64_512 constants. target-arm: fix support for VRECPE. target-arm: fix support for VRSQRTE. fpu/softfloat-specialize.h | 68 -- fpu/softfloat.h| 84 + target-arm/helper.c| 211 +++- 3 files changed, 273 insertions(+), 90 deletions(-) Thanks, whole series applied. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: [PATCH 16/28] migration: use global variable directly
On 02/24/2011 08:09 AM, Markus Armbruster wrote: For completeness: a local variable may be necessary to convince the optimizer that the value doesn't change. Cases where this matters exist, but they're rare. In particular, for non-pointers they're nonexistent if the variable is static and you never use current_migration, i.e. if the variable doesn't escape. If the above conditions are satisfied and you have a loop that never leaves the C file, you could even see the compiler keep the variable in a register for the whole duration of the loop and store the modified change after the loop. Paolo
[Qemu-devel] [PATCH 09/18] Introduce event-tap.
event-tap controls when to start FT transaction, and provides proxy
functions to called from net/block devices. While FT transaction, it
queues up net/block requests, and flush them when the transaction gets
completed.
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
Signed-off-by: OHMURA Kei ohmura@lab.ntt.co.jp
---
Makefile.target |1 +
event-tap.c | 940 +++
event-tap.h | 44 +++
qemu-tool.c | 28 ++
trace-events| 10 +
5 files changed, 1023 insertions(+), 0 deletions(-)
create mode 100644 event-tap.c
create mode 100644 event-tap.h
diff --git a/Makefile.target b/Makefile.target
index 220589e..da57efe 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -199,6 +199,7 @@ obj-y += rwhandler.o
obj-$(CONFIG_KVM) += kvm.o kvm-all.o
obj-$(CONFIG_NO_KVM) += kvm-stub.o
LIBS+=-lz
+obj-y += event-tap.o
QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
diff --git a/event-tap.c b/event-tap.c
new file mode 100644
index 000..95c147a
--- /dev/null
+++ b/event-tap.c
@@ -0,0 +1,940 @@
+/*
+ * Event Tap functions for QEMU
+ *
+ * Copyright (c) 2010 Nippon Telegraph and Telephone Corporation.
+ *
+ * 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 qemu-error.h
+#include block.h
+#include block_int.h
+#include ioport.h
+#include osdep.h
+#include sysemu.h
+#include hw/hw.h
+#include net.h
+#include event-tap.h
+#include trace.h
+
+enum EVENT_TAP_STATE {
+EVENT_TAP_OFF,
+EVENT_TAP_ON,
+EVENT_TAP_SUSPEND,
+EVENT_TAP_FLUSH,
+EVENT_TAP_LOAD,
+EVENT_TAP_REPLAY,
+};
+
+static enum EVENT_TAP_STATE event_tap_state = EVENT_TAP_OFF;
+
+typedef struct EventTapIOport {
+uint32_t address;
+uint32_t data;
+int index;
+} EventTapIOport;
+
+#define MMIO_BUF_SIZE 8
+
+typedef struct EventTapMMIO {
+uint64_t address;
+uint8_t buf[MMIO_BUF_SIZE];
+int len;
+} EventTapMMIO;
+
+typedef struct EventTapNetReq {
+char *device_name;
+int iovcnt;
+int vlan_id;
+bool vlan_needed;
+bool async;
+struct iovec *iov;
+NetPacketSent *sent_cb;
+} EventTapNetReq;
+
+#define MAX_BLOCK_REQUEST 32
+
+typedef struct EventTapAIOCB EventTapAIOCB;
+
+typedef struct EventTapBlkReq {
+char *device_name;
+int num_reqs;
+int num_cbs;
+bool is_flush;
+BlockRequest reqs[MAX_BLOCK_REQUEST];
+EventTapAIOCB *acb[MAX_BLOCK_REQUEST];
+} EventTapBlkReq;
+
+#define EVENT_TAP_IOPORT (1 0)
+#define EVENT_TAP_MMIO (1 1)
+#define EVENT_TAP_NET(1 2)
+#define EVENT_TAP_BLK(1 3)
+
+#define EVENT_TAP_TYPE_MASK (EVENT_TAP_NET - 1)
+
+typedef struct EventTapLog {
+int mode;
+union {
+EventTapIOport ioport;
+EventTapMMIO mmio;
+};
+union {
+EventTapNetReq net_req;
+EventTapBlkReq blk_req;
+};
+QTAILQ_ENTRY(EventTapLog) node;
+} EventTapLog;
+
+struct EventTapAIOCB {
+BlockDriverAIOCB common;
+BlockDriverAIOCB *acb;
+bool is_canceled;
+};
+
+static EventTapLog *last_event_tap;
+
+static QTAILQ_HEAD(, EventTapLog) event_list;
+static QTAILQ_HEAD(, EventTapLog) event_pool;
+
+static int (*event_tap_cb)(void);
+static QEMUBH *event_tap_bh;
+static VMChangeStateEntry *vmstate;
+
+static void event_tap_bh_cb(void *p)
+{
+if (event_tap_cb) {
+event_tap_cb();
+}
+
+qemu_bh_delete(event_tap_bh);
+event_tap_bh = NULL;
+}
+
+static void event_tap_schedule_bh(void)
+{
+trace_event_tap_ignore_bh(!!event_tap_bh);
+
+/* if bh is already set, we ignore it for now */
+if (event_tap_bh) {
+return;
+}
+
+event_tap_bh = qemu_bh_new(event_tap_bh_cb, NULL);
+qemu_bh_schedule(event_tap_bh);
+
+return;
+}
+
+static void *event_tap_alloc_log(void)
+{
+EventTapLog *log;
+
+if (QTAILQ_EMPTY(event_pool)) {
+log = qemu_mallocz(sizeof(EventTapLog));
+} else {
+log = QTAILQ_FIRST(event_pool);
+QTAILQ_REMOVE(event_pool, log, node);
+}
+
+return log;
+}
+
+static void event_tap_free_net_req(EventTapNetReq *net_req);
+static void event_tap_free_blk_req(EventTapBlkReq *blk_req);
+
+static void event_tap_free_log(EventTapLog *log)
+{
+int mode = log-mode ~EVENT_TAP_TYPE_MASK;
+
+if (mode == EVENT_TAP_NET) {
+event_tap_free_net_req(log-net_req);
+} else if (mode == EVENT_TAP_BLK) {
+event_tap_free_blk_req(log-blk_req);
+}
+
+log-mode = 0;
+
+/* return the log to event_pool */
+QTAILQ_INSERT_HEAD(event_pool, log, node);
+}
+
+static void event_tap_free_pool(void)
+{
+EventTapLog *log, *next;
+
+QTAILQ_FOREACH_SAFE(log, event_pool, node, next) {
+QTAILQ_REMOVE(event_pool, log, node);
+qemu_free(log);
+}
+}
+
+static void event_tap_free_net_req(EventTapNetReq *net_req)
+{
+int i;
+
+if (!net_req-async) {
+for
Re: [Qemu-devel] Re: Network bridging without adding bridge with brctl, possible?
On Thursday 24 February 2011, Jan Kiszka wrote:
On 2011-02-24 07:49, Gerhard Wiesinger wrote:
On Wed, 23 Feb 2011, Jan Kiszka wrote:
Right, but if I set IP(eth0) == IP(macvlan0), I'm able to communicate
between macvlan0 and mactapX, thus between guest and host. Just
re-checked here, still works (after resolving the usual MAC address mess
I caused by configuring manually).
Thnx for the tipp.
Did you use MAC(eth0) == MAC(macvlan0) or MAC(eth0) MAC(macvlan0) to
get it to work?
The latter (I just let macvlan/tap choose their MACs).
You cannot set the two to the same MAC address while they are up, but I think
you can do
ip link set eth0 down
ip link set macvlan0 ${MAC_ETH0}
ip link set macvlan0 up
Doing that is a bit tricky if eth0 is your only connection to the machine...
Arnd
Re: [Qemu-devel] [PATCH V6 3/4] qmp, nmi: convert do_inject_nmi() to QObject
Anthony Liguori anth...@codemonkey.ws writes:
On 01/27/2011 02:20 AM, Lai Jiangshan wrote:
Make we can inject NMI via qemu-monitor-protocol.
We use inject-nmi for the qmp command name, the meaning is clearer.
Signed-off-by: Lai Jiangshanla...@cn.fujitsu.com
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index ec1a4db..e763bf9 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -725,7 +725,8 @@ ETEXI
.params = [cpu],
.help = Inject an NMI on all CPUs if no argument is given,
otherwise inject it on the specified CPU,
-.mhandler.cmd = do_inject_nmi,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
},
#endif
STEXI
diff --git a/monitor.c b/monitor.c
index 387b020..1b1c0ba 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2542,7 +2542,7 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
#endif
#if defined(TARGET_I386)
-static void do_inject_nmi(Monitor *mon, const QDict *qdict)
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject
**ret_data)
{
CPUState *env;
int cpu_index;
@@ -2550,7 +2550,7 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
if (!qdict_haskey(qdict, cpu-index)) {
for (env = first_cpu; env != NULL; env = env-next_cpu)
cpu_interrupt(env, CPU_INTERRUPT_NMI);
-return;
+return 0;
}
cpu_index = qdict_get_int(qdict, cpu-index);
@@ -2560,8 +2560,10 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
kvm_inject_interrupt(env, CPU_INTERRUPT_NMI);
else
cpu_interrupt(env, CPU_INTERRUPT_NMI);
-break;
+return 0;
}
+
+return -1;
}
#endif
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 56c4d8b..a887dd5 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -429,6 +429,34 @@ Example:
EQMP
+#if defined(TARGET_I386)
+{
+.name = inject-nmi,
+.args_type = cpu-index:i?,
+.params = [cpu],
+.help = Inject an NMI on all CPUs if no argument is given,
+ otherwise inject it on the specified CPU,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
+},
+#endif
+SQMP
+inject-nmi
+--
+
+Inject an NMI on all CPUs or the given CPU (x86 only).
+
+Arguments:
+
+- cpu-index: the index of the CPU to be injected NMI (json-int, optional)
+
+Example:
+
+- { execute: inject-nmi, arguments: { cpu-index: 0 } }
+- { return: {} }
Please describe all expected errors.
Quoting qmp-commands.hx:
3. Errors, in special, are not documented. Applications should NOT check
for specific errors classes or data (it's strongly recommended to only
check for the error key)
Indeed, not a single error is documented there. This is intentional.
Once we have an error design in place that has a reasonable hope to
stand the test of time, and have errors documented for at least some of
the commands here, we can start to require proper error documentation
for new commands. But not now.
Don't hide this command for
!defined(TARGET_I386), instead have it throw an error in the
implementation.
Works for me.
Don't have commands that multiple behavior based on the presence or
absence of arguments. Make it take a list of cpus if you want the
ability to inject the NMI to more than one CPU.
Having optional arguments is fine. It's good taste to give them
default semantics, i.e. no argument is shorthand for one specific
argument value.
Luiz already pointed to the thread where we discussed this command
before. Executive summary:
* Real hardware's NMI button injects all CPUs. This is the primary use
case.
* Lai said injecting a single CPU can be useful for debugging. Was
deemed acceptable as secondary use case.
Lai also pointed out that the human monitor's nmi command injects a
single CPU. That was dismissed as irrelevant for QMP.
* No other use cases have been presented.
Therefore, the list of CPUs idea was shot down as overly general.
Re: [Qemu-devel] [PATCH] hw/sd.c: Add missing state change for SD_STATUS, SEND_NUM_WR_BLOCKS
On Fri, Feb 18, 2011 at 01:39:00PM +, Peter Maydell wrote:
The SD_STATUS and SEND_NUM_WR_BLOCKS commands are supposed to cause
the card to send data back to the host. However sd.c was missing the
state change to sd_sendingdata_state for these commands, with the effect
that the Linux driver would either hang indefinitely waiting for
nonexistent data (pl181) or read zeroes and provoke a qemu warning
message (omap).
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
hw/sd.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Thanks, applied.
diff --git a/hw/sd.c b/hw/sd.c
index 789ca84..5e29752 100644
--- a/hw/sd.c
+++ b/hw/sd.c
@@ -1168,6 +1168,7 @@ static sd_rsp_type_t sd_app_command(SDState *sd,
case 13: /* ACMD13: SD_STATUS */
switch (sd-state) {
case sd_transfer_state:
+sd-state = sd_sendingdata_state;
sd-data_start = 0;
sd-data_offset = 0;
return sd_r1;
@@ -1182,6 +1183,7 @@ static sd_rsp_type_t sd_app_command(SDState *sd,
case sd_transfer_state:
*(uint32_t *) sd-data = sd-blk_written;
+sd-state = sd_sendingdata_state;
sd-data_start = 0;
sd-data_offset = 0;
return sd_r1;
--
1.7.1
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On 02/23/2011 10:18 PM, Anthony Liguori wrote:
Then the management stack has to worry about yet another way of
interacting via qemu.
{ 'StateItem': { 'key': 'str', 'value': 'str' } }
{ 'StateSection': { 'kind': 'str', 'name': 'str', 'items': [
'StateItem' ] } }
{ 'StateInfo': { 'sections': [ 'StateSection' ] } }
{ 'query-state', {}, {}, 'StateInfo' }
A management tool never need to worry about anything other than this
command if it so chooses. If we have the pre-machine init mode for
0.16, then this can even be used to inspect state without running a
guest.
So we have yet another information tree. If we store the cd-rom eject
state here, then we need to make an association between the device path
of the cd-rom, and the StateItem key.
Far better to store it in the device itself. For example, we could make
a layered block format driver that stores the eject state and a backing
file containing the actual media. Eject and media change would be
recorded in the block format driver's state. You could then hot-unplug
a USB cd-writer and hot-plug it back into a different guest,
implementing a virtual sneakernet.
The fact that the state is visible in the filesystem is an
implementation detail.
A detail that has to be catered for by the management stack - it has to
provide a safe place for it, back it up, etc.
I'd like to limit it to the monitor.
Doesn't the stateful non-config file becomes a failure point? It
has to be on shared and redundant storage?
It depends on what your availability model is and how frequently
your management tool backs up the config. As of right now, we have
a pretty glaring reliability hole here so adding a stateful
non-config can only improve things.
I think the solutions I pointed out close the hole with the existing
interfaces.
It doesn't work for eject unless you interpose an acknowledged event.
Ultimately, this is a simple problem. If you want reliability, we
either need symmetric RPCs so that the device model can call (and
wait) to the management layer to acknowledge a change or QEMU can post
an event to the management layer, and maintain the state in a reliable
fashion.
I don't see why it doesn't work. Please explain.
You still have the race condition around guest initiated events like
eject. Unless you have an acknowledged event from a management tool
(which we can't do in QMP today) whereas you don't complete the
guest initiated eject operation until management ack's it, we need
to store that state ourself.
I don't see why.
If management crashes, it queries the eject state when it reconnects
to qemu.
If qemu crashes, the eject state is lost, but that is fine. My
CD-ROM drive tray pulls itself in when the machine is started.
Pick any of a number of possible events that change the machine's
state. We can wave our hands at some things saying they don't matter
and do one off solutions for others, or we can just have a robust way
of handling this consistently.
Both block live copy and cd-rom eject state can be solved with layered
block format drivers. I don't think a central place for random data
makes sense. State belongs near the device that maintains it, esp. if
the device is hot-pluggable, so it's easy to associate the state with
the device.
You're introducing the need for additional code in the management
layer, the care and feeding for the stateful non-config file.
If a management layer ignores the stateful non-config file, as you
like to call it, it'll get the same semantics it has today. I think
managing a single thing is a whole lot easier than managing an NVRAM
file, a block migration layering file, and all of the future things
we're going to add once we decide they are important too.
I disagree. Storing NVRAM as a disk image is a simple extension of
existing management tools. Block live-copy and cd-rom eject state also
make sense as per-image state if you take hotunplug and hotplug into
account.
If qemu crashes, these events are meaningless. If management
crashes, it has to query qemu for all state that it wants to keep
track of via events.
Think power failure, not qemu crash. In the event of a power
failure, any hardware change initiated by the guest ought to be
consistent with when the guest has restarted. If you eject the
CDROM tray and then lose power, its still ejected after the power
comes back on.
Not on all machines.
Let's list guest state which is independent of power. That would be
wither NVRAM of various types, or physical alterations. CD-ROM eject
is one. Are there others?
Any indirect qemu state. Block migration is an example, but other
examples would be VNC server information (like current password), WCE
setting (depending on whether we modelled eeprom for the drivers), and
persisted device settings (lots of devices have eeprom these days).
Device settings should be stored with the devices, not with qemu.
Suppose we
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On 02/23/2011 07:49 PM, Marcelo Tosatti wrote: On Wed, Feb 23, 2011 at 03:01:14PM +0200, Avi Kivity wrote: On 02/23/2011 01:14 AM, Anthony Liguori wrote: -drive already ties into the qemuopts infrastructure and we have readconfig and writeconfig. I don't think we're missing any major pieces to do this in a more proper fashion. The problem with qemu config files is that it splits the authoritative source of where images are stored into two. Is it in the management tool's database or is it in qemu's config file? For the problem at hand, one solution is to make qemu stop after the copy, and then management can issue an additional command to rearrange the disk and resume the guest. A drawback here is that if management dies, the guest is stopped until it restarts. We also make management latency guest visible, even if it doesn't die at an inconvenient place. An alternative approach is to have the copy be performed by a new layered block format driver: - create a new image, type = live-copy, containing three pieces of information - source image - destination image - copy state (initially nothing is copied) - tell qemu switch to the new image - qemu starts copying, updates copy state as needed - copy finishes, event is emitted; reads and writes still serviced - management receives event, switches qemu to destination image - management removes live-copy image If management dies while this is happening, it can simply query the state of the copy. Similarly, if qemu dies, the copy state is persistent (could be 0/1 or real range of blocks). You don't know if a given block is uptodate or not without the dirty bitmap. So unless you also keep track of dirty log somehow, this is meaningless. First, you no longer need the dirty bitmap. Since all writes go through the layered block format driver, you know first-hand what is dirty and what isn't. So a commit file as proposed indicates copy state (in 0/1 fashion). The difference in your proposal is that such information is stored inside a special purpose image format? It could also store the already synced range. The difference is that the file is self contained. You could hot-unplug the image and hot-plug it later (continuing the copy with qemu-img), or live migrate it. In fact I think a qemu RAID-1 driver removes the restriction that you can't live-migrate and live-copy simultaneously. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH 21/28] migration: Make state definitions local
Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp wrote:
2011/2/24 Juan Quintela quint...@redhat.com:
Signed-off-by: Juan Quintela quint...@redhat.com
---
migration.c | 8
migration.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/migration.c b/migration.c
index 493c2d7..697c74f 100644
--- a/migration.c
+++ b/migration.c
@@ -31,6 +31,14 @@
do { } while (0)
#endif
+enum migration_state {
+ MIG_STATE_ERROR,
Would be better to say:
MIG_STATE_ERROR = -1,
I thought about it, but basically it shouldn't matter, no?
Later, Juan.
[Qemu-devel] Memory Map
Hi,
This is what my board do
cpu_register_physical_memory(0, 128*1024*1024, ...)
cpu_register_physical_memory(0xFF80, 8*1024*1024, ...)
and this layout does not change over the entire live (virtual) of the board.
For the following offset (1st column) and size in bytes (2nd column)
{0x00, 512},
{0x000200, 16},
{0x000300, 32},
{0x000400, 32},
{0x000500, 64},
{0x000600, 64},
{0x000700, 128},
{0x000800, 30},
{0x000900, 256},
{0x000A00, 44},
{0x000B00, 256},
{0x000C00, 24},
{0x000F00, 20},
{0x001000, 20},
{0x001100, 20},
{0x001400, 168},
{0x001800, 24},
{0x002000, 4096},
{0x003000, 24},
{0x003100, 24},
{0x004500, 36},
{0x005000, 224},
{0x008000, 768},
{0x008300, 16},
i do, for each item,
a = cpu_register_io_memory(r, w, o, DEVICE_NATIVE_ENDIAN)
cpu_register_physical_memory(_base+offset, len, a)
And _base could be reprogrammed at any time. So before to change _base i:
cpu_unregister_io_memory(a)
What i see is that accessing to _base+
_base+0x005000 = Wake up r/w with offset 0
_base+0x000204 = Wake up r/w with offset 0x204
So the question
- Am i wrong something?
- Is possible to map address with last TARGET_PAGE_BITS (es 0x200) bits set?
Have a good day
[Qemu-devel] Missing op on SPARC
Hi, all I have a Linux/SPARC machine and want to run QEMU on it. Here is the system information. -- $ uname -a Linux sparc 2.6.37-rc5-git #1 SMP Tue Dec 21 17:03:53 CST 2010 sparc64 sun4v UltraSparc T2 (Niagara2) GNU/Linux $ gcc --version gcc (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4 -- QEMU is configured with --sparc_cpu=v8plus. QEMU report there are some missing op definitions. See below, -- $ qemu-sparc hello Missing op definition for qemu_ld64 Missing op definition for qemu_st64 /tmp/chenwj/qemu-0.14.0/tcg/tcg.c:1116: tcg fatal error Aborted -- Is it possible to fix it? If so, how? Any sugguestions appreciated. Regards, chenwj -- Wei-Ren Chen (陳韋任) Parallel Processing Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
[Qemu-devel] Re: [PATCH] Fix conversions from pointer to int and vice versa
On 02/24/2011 08:21 AM, Markus Armbruster wrote: Why can't you cast straight to void *? warning: cast from pointer to integer of different size, and similarly in the other direction.
Re: [Qemu-devel] [PATCH] Fix conversions from pointer to int and vice versa
Am 24.02.2011 08:21, schrieb Markus Armbruster:
Stefan Weil w...@mail.berlios.de writes:
Here the int values fds[0], sigfd, s, sock and fd are converted
to void pointers which are later converted back to an int value.
These conversions should always use intptr_t instead of unsigned long.
They are needed for environments where sizeof(long) != sizeof(void *).
To be precise: when you want to cast a pointer to a signed integer type
and back without loss, intptr_t is the signed integer type to use.
But here we're dealing with the opposite case: cast int to pointer and
back.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
cpus.c |8
migration-tcp.c |4 ++--
migration-unix.c |4 ++--
qemu-char.c |4 ++--
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/cpus.c b/cpus.c
index 0f33945..3c4e1b8 100644
--- a/cpus.c
+++ b/cpus.c
@@ -267,7 +267,7 @@ static void qemu_event_increment(void)
static void qemu_event_read(void *opaque)
{
-int fd = (unsigned long)opaque;
+int fd = (intptr_t)opaque;
ssize_t len;
char buffer[512];
Why can't you cast straight to int?
You would get warnings about a pointer being cast to an integer of
different size (the behaviour is undefined if the integer is too small).
I think you might also get a warning for the opposite direction.
Kevin
[Qemu-devel] Re: [PATCH] Add TAGS and *~ to .gitignore
David Gibson da...@gibson.dropbear.id.au wrote: Add the etags output generated by make TAGS and editor backup files to .gitignore. This patch has previously appeared in my series of patches to add pSeries emulation support. However, it obviously has no real connection to that, and can be applied seperately. Please apply. Signed-off-by: David Gibson da...@gibson.dropbear.id.au Reviewed-by: Juan Quintela quint...@redhat.com O:-) --- .gitignore |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 26703e1..1d79680 100644 --- a/.gitignore +++ b/.gitignore @@ -63,3 +63,5 @@ pc-bios/optionrom/multiboot.raw .stgit-* cscope.* tags +TAGS +*~ -- 1.7.1
[Qemu-devel] Re: [PATCH 21/28] migration: Make state definitions local
Juan Quintela wrote:
Yoshiaki Tamuratamura.yoshi...@lab.ntt.co.jp wrote:
2011/2/24 Juan Quintelaquint...@redhat.com:
Signed-off-by: Juan Quintelaquint...@redhat.com
---
migration.c |8
migration.h |8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/migration.c b/migration.c
index 493c2d7..697c74f 100644
--- a/migration.c
+++ b/migration.c
@@ -31,6 +31,14 @@
do { } while (0)
#endif
+enum migration_state {
+MIG_STATE_ERROR,
Would be better to say:
MIG_STATE_ERROR = -1,
I thought about it, but basically it shouldn't matter, no?
It shouldn't. Just gives clear impression :)
Yoshi
Later, Juan.
[Qemu-devel] Re: [PATCH 07/18] Introduce fault tolerant VM transaction QEMUFile and ft_mode.
[ trimming cc to kvm qemu lists] Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp wrote: Juan Quintela wrote: Yoshiaki Tamuratamura.yoshi...@lab.ntt.co.jp wrote: This code implements VM transaction protocol. Like buffered_file, it sits between savevm and migration layer. With this architecture, VM transaction protocol is implemented mostly independent from other existing code. Could you explain what is the difference with buffered_file.c? I am fixing problems on buffered_file, and having something that copies lot of code from there makes me nervous. The objective is different: buffered_file buffers data for transmission control. ft_trans_file adds headers to the stream, and controls the transaction between sender and receiver. Although ft_trans_file sometimes buffers date, but it's not the main objective. If you're fixing the problems on buffered_file, I'll keep eyes on them. +typedef ssize_t (FtTransPutBufferFunc)(void *opaque, const void *data, size_t size); Can we get some sharing here? typedef ssize_t (BufferedPutFunc)(void *opaque, const void *data, size_t size); There are not so much types for a write function that the 1st element is one opaque :p You're right, but I want to keep ft_trans_file independent of buffered_file at this point. Once Kemari gets merged, I'm happy to work with you to fix the problems on buffered_file and ft_trans_file, and refactoring them. My goal is getting its own thread for migration on 0.15, that basically means that we can do rm buffered_file.c. I guess that something similar could happen for kemari. But for now, this is just the start + handwaving, once I start doing the work I will told you. Later, Juan.
[Qemu-devel] Re: [PATCH 07/18] Introduce fault tolerant VM transaction QEMUFile and ft_mode.
2011/2/24 Juan Quintela quint...@redhat.com: [ trimming cc to kvm qemu lists] Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp wrote: Juan Quintela wrote: Yoshiaki Tamuratamura.yoshi...@lab.ntt.co.jp wrote: This code implements VM transaction protocol. Like buffered_file, it sits between savevm and migration layer. With this architecture, VM transaction protocol is implemented mostly independent from other existing code. Could you explain what is the difference with buffered_file.c? I am fixing problems on buffered_file, and having something that copies lot of code from there makes me nervous. The objective is different: buffered_file buffers data for transmission control. ft_trans_file adds headers to the stream, and controls the transaction between sender and receiver. Although ft_trans_file sometimes buffers date, but it's not the main objective. If you're fixing the problems on buffered_file, I'll keep eyes on them. +typedef ssize_t (FtTransPutBufferFunc)(void *opaque, const void *data, size_t size); Can we get some sharing here? typedef ssize_t (BufferedPutFunc)(void *opaque, const void *data, size_t size); There are not so much types for a write function that the 1st element is one opaque :p You're right, but I want to keep ft_trans_file independent of buffered_file at this point. Once Kemari gets merged, I'm happy to work with you to fix the problems on buffered_file and ft_trans_file, and refactoring them. My goal is getting its own thread for migration on 0.15, that basically means that we can do rm buffered_file.c. I guess that something similar could happen for kemari. That means both gets initiated by it's own thread, not like current poll based. I'm still skeptical whether Anthony agrees, but I'll keep it in my mind. But for now, this is just the start + handwaving, once I start doing the work I will told you. Yes, please. Yoshi Later, Juan. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] [PATCH] migration: allow setting MIG_STATE_CANCEL even if s-state != MIG_STATE_ACTIVE.
After migration failure, even a user commands migrate_cancel, it keeps
saying:
Migration status: failed
Move checking s-state is MIG_STATE_ACTIVE, to allow setting
MIG_STATE_CANCEL even if s-state != MIG_STATE_ACTIVE. With this
patch the message above would be:
Migration status: cancelled
Signed-off-by: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
---
migration.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/migration.c b/migration.c
index af3a1f2..098885f 100644
--- a/migration.c
+++ b/migration.c
@@ -409,15 +409,16 @@ void migrate_fd_cancel(MigrationState *mig_state)
{
FdMigrationState *s = migrate_to_fms(mig_state);
-if (s-state != MIG_STATE_ACTIVE)
-return;
-
DPRINTF(cancelling migration\n);
s-state = MIG_STATE_CANCELLED;
notifier_list_notify(migration_state_notifiers);
-qemu_savevm_state_cancel(s-mon, s-file);
+if (s-state != MIG_STATE_ACTIVE) {
+return;
+}
+
+qemu_savevm_state_cancel(s-mon, s-file);
migrate_fd_cleanup(s);
}
--
1.7.1.2
Re: [Qemu-devel] Unsubsribing
On Thu, Feb 24, 2011 at 5:41 AM, James Brown jbrownfi...@gmail.com wrote: Who I can do it? Please see http://lists.nongnu.org/mailman/listinfo/qemu-devel for info on how to unsubscribe. Stefan
Re: [Qemu-devel] [PATCH] net: Use iov helper functions
On Thu, Feb 24, 2011 at 12:57 AM, Benjamin Poirier benjamin.poir...@gmail.com wrote: Signed-off-by: Benjamin Poirier benjamin.poir...@gmail.com --- net.c | 28 ++-- 1 files changed, 6 insertions(+), 22 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Re: [Qemu-devel] [PATCH] Fix conversions from pointer to int and vice versa
Kevin Wolf kw...@redhat.com writes:
Am 24.02.2011 08:21, schrieb Markus Armbruster:
Stefan Weil w...@mail.berlios.de writes:
Here the int values fds[0], sigfd, s, sock and fd are converted
to void pointers which are later converted back to an int value.
These conversions should always use intptr_t instead of unsigned long.
They are needed for environments where sizeof(long) != sizeof(void *).
To be precise: when you want to cast a pointer to a signed integer type
and back without loss, intptr_t is the signed integer type to use.
But here we're dealing with the opposite case: cast int to pointer and
back.
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
cpus.c |8
migration-tcp.c |4 ++--
migration-unix.c |4 ++--
qemu-char.c |4 ++--
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/cpus.c b/cpus.c
index 0f33945..3c4e1b8 100644
--- a/cpus.c
+++ b/cpus.c
@@ -267,7 +267,7 @@ static void qemu_event_increment(void)
static void qemu_event_read(void *opaque)
{
-int fd = (unsigned long)opaque;
+int fd = (intptr_t)opaque;
ssize_t len;
char buffer[512];
Why can't you cast straight to int?
You would get warnings about a pointer being cast to an integer of
different size
Fair enough. Stop reading here unless you like language-lawyering ;)
(the behaviour is undefined if the integer is too small).
Correct (I looked it up). The detour via intptr_t makes it
implementation-defined.
I think you might also get a warning for the opposite direction.
Implementation-defined.
The standard defines semantics of valid void * - intptr_t, uintptr_t -
void *: you get your original pointer back (will compare equal).
The standard is silent on converting integer type to pointer type and
back. Doesn't matter. No sane implementation screws that up.
Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop
On Thu, Feb 24, 2011 at 12:36 AM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/23/2011 05:38 PM, Juan Quintela wrote: Anthony Liguorianth...@codemonkey.ws wrote: On 02/23/2011 05:00 PM, Juan Quintela wrote: Anthony Liguorialigu...@us.ibm.com wrote: The goal is to enable the monitor to run independently of whether the machine has been created such that the monitor can be used to specify all of the parameters for machine initialization. Signed-off-by: Anthony Liguorialigu...@us.ibm.com I agree that it is one step in the right direction, but we are still calling qemu_machine_init() before calling the main_loop(). What is the plan from here? 1) Decouple QMP from qemu_machine_init(). This really requires the introduction of the new QAPI server that exists outside of the chardev infrastructure since chardevs are currently initialized in qemu_machine_init(). 2) Make qemu_machine_init() take no parameters and just reference global state. Any good idea how that global state is going to be stored? I just want to be able to launch a qemu on a different machine and migrate the configuration to it, for doing that, I really need what values are different from default or anything like that. So as you can see, I am very interested on that work. First step is to have everything go through QMP. If everything flows through QMP, we have a gateway that we can focus on. What I'd like to do next is introduce the notion of a stateful config file. Any chance of reusing info qtree, QemuOpts, or other existing infrastructure for the config file? Config file set/get/format code tends to be just toggling variables and manipulating strings. There is similarity here with the option parsing and qdev properties. Stefan
[Qemu-devel] realview isp1761 support in qemu
Hi, Currently Iam trying to emulate USB in qemu for realview board.so on board isp1761 controller is connected thru smc911 controller for which there is support in qemu.but I dont see isp1761support. Iam using qemu 0.13.0.Plz let me know as soon as possible. --Thanx AK
[Qemu-devel] [PATCH 2/2] build: create shared-obj-y for tools/qemu-softmmu
There are objects that need to be in both places, just make it explicit in a single place. Signed-off-by: Juan Quintela quint...@redhat.com --- Makefile |4 +--- Makefile.objs | 14 +- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 9e090cb..1902f96 100644 --- a/Makefile +++ b/Makefile @@ -150,9 +150,7 @@ version.o: $(SRC_PATH)/version.rc config-host.mak version-obj-$(CONFIG_WIN32) += version.o ## -tools-obj-y=qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) -tools-obj-y+=$(block-obj-y) $(qobject-obj-y) $(version-obj-y) -tools-obj-y+=qemu-timer-common.o +tools-obj-y = qemu-tool.o $(shared-obj-y) $(trace-obj-y) $(version-obj-y) qemu-img.o: qemu-img-cmds.h qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o cmd.o: $(GENERATED_HEADERS) diff --git a/Makefile.objs b/Makefile.objs index 9e98a66..5849487 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -54,17 +54,21 @@ fsdev-nested-$(CONFIG_VIRTFS) = qemu-fsdev.o fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) ## +# shared-obj-y has the object that are shared by qemu binary and tools + +shared-obj-y = qemu-error.o $(block-obj-y) $(qobject-obj-y) $(oslib-obj-y) +shared-obj-y += qemu-timer-common.o + +## # libqemu_common.a: Target independent part of system emulation. The # long term path is to suppress *all* target specific code in case of # system emulation, i.e. a single QEMU executable should support all # CPUs and machines. -common-obj-y = $(block-obj-y) blockdev.o +common-obj-y = $(shared-obj-y) blockdev.o common-obj-y += $(net-obj-y) -common-obj-y += $(qobject-obj-y) common-obj-$(CONFIG_LINUX) += $(fsdev-obj-$(CONFIG_LINUX)) -common-obj-y += readline.o console.o cursor.o async.o qemu-error.o -common-obj-y += $(oslib-obj-y) +common-obj-y += readline.o console.o cursor.o async.o common-obj-$(CONFIG_WIN32) += os-win32.o common-obj-$(CONFIG_POSIX) += os-posix.o @@ -145,7 +149,7 @@ common-obj-y += iov.o acl.o common-obj-$(CONFIG_THREAD) += qemu-thread.o common-obj-$(CONFIG_POSIX) += compatfd.o common-obj-y += notify.o event_notifier.o -common-obj-y += qemu-timer.o qemu-timer-common.o +common-obj-y += qemu-timer.o slirp-obj-y = cksum.o if.o ip_icmp.o ip_input.o ip_output.o slirp-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o tcp_input.o tcp_output.o -- 1.7.4
[Qemu-devel] [PATCH 0/2] build: make sharing of objects explicit
Hi - all tools shared the same list of object files, create a variable instead or repeating them (tools-obj-y). - tools and softmmu targets share lots of objects, just make that explicit with shared-obj-y. Please review, Juan. Juan Quintela (2): build: Create tools-obj-y variable build: create shared-obj-y for tools/qemu-softmmu Makefile |8 +--- Makefile.objs | 14 +- 2 files changed, 14 insertions(+), 8 deletions(-) -- 1.7.4
[Qemu-devel] [PATCH 1/2] build: Create tools-obj-y variable
All our tools have to have exactly all this objects, just share them. Signed-off-by: Juan Quintela quint...@redhat.com --- Makefile | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index eca4c76..9e090cb 100644 --- a/Makefile +++ b/Makefile @@ -150,14 +150,18 @@ version.o: $(SRC_PATH)/version.rc config-host.mak version-obj-$(CONFIG_WIN32) += version.o ## +tools-obj-y=qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) +tools-obj-y+=$(block-obj-y) $(qobject-obj-y) $(version-obj-y) +tools-obj-y+=qemu-timer-common.o + qemu-img.o: qemu-img-cmds.h qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o cmd.o: $(GENERATED_HEADERS) -qemu-img$(EXESUF): qemu-img.o qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o +qemu-img$(EXESUF): qemu-img.o $(tools-obj-y) -qemu-nbd$(EXESUF): qemu-nbd.o qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o +qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y) -qemu-io$(EXESUF): qemu-io.o cmd.o qemu-tool.o qemu-error.o $(oslib-obj-y) $(trace-obj-y) $(block-obj-y) $(qobject-obj-y) $(version-obj-y) qemu-timer-common.o +qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y) qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h $ $@, GEN $@) -- 1.7.4
[Qemu-devel] PCI virtual address
Hi,
Iam trying to emulate USB for realview board in QEMU.
trying to access it thru the PCI bus.for realview board Idont see PCI
support in QEMU although it is there for versatile boad.so I googled and
found realview PCIX support.I applied the patch. but then in
arch/arm/mach-realview/pcix.c inside function
realview_pb_pcix_unit_init(void)
u32 data = readl(PCIX_UNIT_BASE + PCI_UNITCNT);
the data value it is printing is zero.
#define PCIX_UNIT_BASE 0xF800 which seems to be virtual
adress
realview spec PCI memory map:
AXI2PCI 0x9004
PCI IO window 0x9005
PCI Memory Window 0xA000-0XBFFF
and in qemu realview.c
if (is_pb) {
dev = sysbus_create_varargs(realview_pci,
0x9004,/*0x6000*/
pic[48], pic[49], pic[50], pic[51],
NULL);
pci_bus = (PCIBus *)qdev_get_child_bus(dev, pci);
if (usb_enabled) {
fprintf(stderr, USB ENABLED\n);
usb_ohci_init_pci(pci_bus, -1);
}
but it seems the virtual adress are not proper for above physical address as
Iam getting error
Error: PCI-X unit not in PCI-X mode.
pci_bus :00: scanning bus
pci_bus :00: fixups for bus
the macro for vrtual address Iam using is
#define IO_ADDRESS(x) (((x) 0x03ff) + 0xfb00)
//#define IO_ADDRESS(x) ((void __iomem *)(unsigned
long)IO_ADDRESS(x))
#else
#define IO_ADDRESS(x) (x)
#endif
#define __io_address(n) __io(IO_ADDRESS(n))
#endif
Plz help me in that whats going wrong..its bit urgen plz reply as soon as
possible
--thanx in advance
ak
Re: [Qemu-devel] PCI virtual address
On 24 February 2011 10:52, asim khan khan.asim.2...@gmail.com wrote:
Hi,
Iam trying to emulate USB for realview board in QEMU.
trying to access it thru the PCI bus.for realview board Idont see PCI
support in QEMU although it is there for versatile boad.so I googled and
found realview PCIX support.I applied the patch.
QEMU models the PCI controller in versatile boards and
the EB (emulation baseboard). It does not have a model
of the different PCIX controller found in the realview
PB and PBX boards.
(The model of the versatile PCI controller is also buggy
in that it works only with the buggy Linux kernel driver;
there are patches for the kernel which fix it to work
with real versatile PCI hardware, at which point it
doesn't work on qemu any more.)
arch/arm/mach-realview/pcix.c
This is the kernel code for handling the PCIX controller.
QEMU doesn't model that controller, so this won't work.
if (is_pb) {
dev = sysbus_create_varargs(realview_pci,
0x9004,/*0x6000*/
pic[48], pic[49], pic[50], pic[51],
NULL);
The code in git says if (!is_pb) { ... -- this is
for the EB/versatile PCI controller.
Plz help me in that whats going wrong.
You're trying to use something that isn't implemented.
Sorry.
In answer to your other email, QEMU doesn't implement
a model of the ISP1761 USB controller either.
-- PMM
[Qemu-devel] Re: QEMU regression problems - Update FPU
On 02/23/2011 08:04 PM, Aurelien Jarno wrote: Actually that's the reason why i386 doesn't use softfloat, as all the trigonometric use libm, and the bridge between softfloat and libm is not working correctly (plenty of type abuse). Besides, I doubt softfloat would want bug-compatible trig function implementations. fsincos for example is a far cry from the precision of the libm function. Paolo
Re: [Qemu-devel] [PATCH 2/2] build: create shared-obj-y for tools/qemu-softmmu
On 24 February 2011 10:33, Juan Quintela quint...@redhat.com wrote: +# shared-obj-y has the object that are shared by qemu binary and tools + +shared-obj-y = qemu-error.o $(block-obj-y) $(qobject-obj-y) $(oslib-obj-y) +shared-obj-y += qemu-timer-common.o I don't feel very strongly about this, but: It seems a bit odd to have a shared-obj-y variable that isn't actually a list of shared objects (ie .so files, DLLs). Maybe there's a better name? -- PMM
[Qemu-devel] Re: QEMU regression problems - Update FPU
On Thu, Feb 24, 2011 at 12:10 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 02/23/2011 08:04 PM, Aurelien Jarno wrote: Actually that's the reason why i386 doesn't use softfloat, as all the trigonometric use libm, and the bridge between softfloat and libm is not working correctly (plenty of type abuse). Besides, I doubt softfloat would want bug-compatible trig function implementations. fsincos for example is a far cry from the precision of the libm function. I agree, these functions certainly don't belong to SoftFloat. They should be implemented in target-i386/op_helper.c. But bit accuracy might be difficult to achieve, unless Intel/AMD properly documented how they compute all these functions. Laurent
[Qemu-devel] [PATCH] net: remove parse_host_src_port() function
It was deprecated, and it has no users.
Signed-off-by: Juan Quintela quint...@redhat.com
---
net.c | 41 -
qemu_socket.h |3 ---
2 files changed, 0 insertions(+), 44 deletions(-)
diff --git a/net.c b/net.c
index ec4745d..4c3e083 100644
--- a/net.c
+++ b/net.c
@@ -93,47 +93,6 @@ static int get_str_sep(char *buf, int buf_size, const char
**pp, int sep)
return 0;
}
-int parse_host_src_port(struct sockaddr_in *haddr,
-struct sockaddr_in *saddr,
-const char *input_str)
-{
-char *str = qemu_strdup(input_str);
-char *host_str = str;
-char *src_str;
-const char *src_str2;
-char *ptr;
-
-/*
- * Chop off any extra arguments at the end of the string which
- * would start with a comma, then fill in the src port information
- * if it was provided else use the any address and any port.
- */
-if ((ptr = strchr(str,',')))
-*ptr = '\0';
-
-if ((src_str = strchr(input_str,'@'))) {
-*src_str = '\0';
-src_str++;
-}
-
-if (parse_host_port(haddr, host_str) 0)
-goto fail;
-
-src_str2 = src_str;
-if (!src_str || *src_str == '\0')
-src_str2 = :0;
-
-if (parse_host_port(saddr, src_str2) 0)
-goto fail;
-
-free(str);
-return(0);
-
-fail:
-free(str);
-return -1;
-}
-
int parse_host_port(struct sockaddr_in *saddr, const char *str)
{
char buf[512];
diff --git a/qemu_socket.h b/qemu_socket.h
index 897a8ae..180e4db 100644
--- a/qemu_socket.h
+++ b/qemu_socket.h
@@ -54,9 +54,6 @@ int unix_connect(const char *path);
/* Old, ipv4 only bits. Don't use for new code. */
int parse_host_port(struct sockaddr_in *saddr, const char *str);
-int parse_host_src_port(struct sockaddr_in *haddr,
-struct sockaddr_in *saddr,
-const char *str);
int socket_init(void);
#endif /* QEMU_SOCKET_H */
--
1.7.4
[Qemu-devel] usb support in realview pbx board
Hi, Iam using qemu0.13.0. Iam loking for usb support in qemu for realview pbx board. is usb support already there in qemu for realview pbx board?. what things I need to do for giving usb support in realviewpbx boad in qemu plz let me know as soon as possible. --Thanx AK
Re: [Qemu-devel] [PATCH 2/2] build: create shared-obj-y for tools/qemu-softmmu
Peter Maydell peter.mayd...@linaro.org writes: On 24 February 2011 10:33, Juan Quintela quint...@redhat.com wrote: +# shared-obj-y has the object that are shared by qemu binary and tools + +shared-obj-y = qemu-error.o $(block-obj-y) $(qobject-obj-y) $(oslib-obj-y) +shared-obj-y += qemu-timer-common.o I don't feel very strongly about this, but: It seems a bit odd to have a shared-obj-y variable that isn't actually a list of shared objects (ie .so files, DLLs). Maybe there's a better name? common-obj-y?
[Qemu-devel] [PATCH] target-sh4: move intr_at_halt out of cpu_halted()
All targets except SH4 have the same cpu_halted() routine, and it has
only one caller. It is therefore a good candidate for inlining.
The difference is the handling of the intr_at_halt, which is necessary
to ignore SR.BL when sleeping. Move intr_at_halt handling out of it, by
setting this variable while executing the sleep instruction, and
clearing it when the CPU has been woken-up by an interrupt, whatever the
state of SR.BL.
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
target-sh4/exec.h |1 -
target-sh4/helper.c|2 +-
target-sh4/op_helper.c |1 +
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/target-sh4/exec.h b/target-sh4/exec.h
index 2999c02..61bc121 100644
--- a/target-sh4/exec.h
+++ b/target-sh4/exec.h
@@ -37,7 +37,6 @@ static inline int cpu_halted(CPUState *env) {
return 0;
if (cpu_has_work(env)) {
env-halted = 0;
-env-intr_at_halt = 1;
return 0;
}
return EXCP_HALTED;
diff --git a/target-sh4/helper.c b/target-sh4/helper.c
index b9fcba6..1f0d15b 100644
--- a/target-sh4/helper.c
+++ b/target-sh4/helper.c
@@ -93,8 +93,8 @@ void do_interrupt(CPUState * env)
if (do_irq !env-intr_at_halt) {
return; /* masked */
}
-env-intr_at_halt = 0;
}
+env-intr_at_halt = 0;
if (do_irq) {
irq_vector = sh_intc_get_pending_vector(env-intc_handle,
diff --git a/target-sh4/op_helper.c b/target-sh4/op_helper.c
index 30f9842..2cd7fed 100644
--- a/target-sh4/op_helper.c
+++ b/target-sh4/op_helper.c
@@ -119,6 +119,7 @@ void helper_debug(void)
void helper_sleep(uint32_t next_pc)
{
env-halted = 1;
+env-intr_at_halt = 1;
env-exception_index = EXCP_HLT;
env-pc = next_pc;
cpu_loop_exit();
--
1.7.2.3
[Qemu-devel] Re: [PATCH] target-sh4: move intr_at_halt out of cpu_halted()
On 02/24/2011 12:54 PM, Aurelien Jarno wrote: All targets except SH4 have the same cpu_halted() routine, and it has only one caller. It is therefore a good candidate for inlining. The difference is the handling of the intr_at_halt, which is necessary to ignore SR.BL when sleeping. Move intr_at_halt handling out of it, by setting this variable while executing the sleep instruction, and clearing it when the CPU has been woken-up by an interrupt, whatever the state of SR.BL. Cc: Paolo Bonzinipbonz...@redhat.com Signed-off-by: Aurelien Jarnoaurel...@aurel32.net Makes sense, thanks! You may want to rename intr_at_halt to env-in_sleep or something like that. Paolo
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
Anthony Liguori anth...@codemonkey.ws writes: On 02/23/2011 11:26 AM, Markus Armbruster wrote: I don't think it's reasonable to have three different ways to interact with qemu, all needed: the command line, reading and writing the stateful config file, and the monitor. I'd rather push for starting qemu with a blank guest and assembling (cold-plugging) all the hardware via the monitor before starting the guest. Exactly. And qdev has brought his within our reach. Actually, QMP is the star of the show here, not qdev. The way we get here is by incrementally converting the option handling to be qmp calls. For instance, instead of: case QEMU_OPTION_name: qemu_name = optarg; break; We do: case QEMU_OPTION_name: qmp_set_name(optarg, NULL); break; When we can compile vl.c with nothing more than QMP dependencies, we've achieved the goals here. This will mean adding a lot of new QMP commands. There are some command line options that must be handled before the machine is initialized and QMP is normally run. For 0.16, we can introduce a new QMP mode whereas the event loop gets to run before doing machine init and explicit create_machine() command is needed. This is the final bit that will be needed to realize this goal. A lot of good things come out of this. Quite a lot of these new commands don't strictly need to run before machine init (like -name) which means we'll get the ability to change a lot of parameters without rebooting the guest which couldn't be changed before. And this is all incremental stuff that can be done in parallel of the QAPI work. We just need to do the work of adding the function calls (or function call wrappers where appropriate). Well, I wouldn't put let's create a sane separation between option parsing and machine configuration under the QEMU *Monitor* Protocol flag, but I certainly don't mind you hoisting whatever flag pleases you.
[Qemu-devel] Re: [PATCH 2/2] build: create shared-obj-y for tools/qemu-softmmu
Markus Armbruster arm...@redhat.com wrote: Peter Maydell peter.mayd...@linaro.org writes: On 24 February 2011 10:33, Juan Quintela quint...@redhat.com wrote: +# shared-obj-y has the object that are shared by qemu binary and tools + +shared-obj-y = qemu-error.o $(block-obj-y) $(qobject-obj-y) $(oslib-obj-y) +shared-obj-y += qemu-timer-common.o I don't feel very strongly about this, but: It seems a bit odd to have a shared-obj-y variable that isn't actually a list of shared objects (ie .so files, DLLs). Maybe there's a better name? common-obj-y? already taken :-( common-obj-y is the list of files that are shared by all qemu-softmmu ## # libqemu_common.a: Target independent part of system emulation. The # long term path is to suppress *all* target specific code in case of # system emulation, i.e. a single QEMU executable should support all # CPUs and machines. common-obj-y = $(block-obj-y) blockdev.o ... so, this is the list of files that are shared between all the softmmu (common) and the tools. I am open to suggestions, but all names I thought are worse than shared (common-common-obj-y) :p Later, Juan.
[Qemu-devel] Re: [PATCH 22/22] migration: Make state definitions local
Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp wrote: 2011/2/23 Juan Quintela quint...@redhat.com: Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp wrote: 2011/2/23 Juan Quintela quint...@redhat.com: Although you're right, I would prefer to keep it so that somebody outside of migration may understand the status in the future if there are no harms. my plan is to move MigrationState inside migration.c, and then decide what to export/not export. Well, it may be just a policy, but it's already exported, and I would like to keep it unless it bothers your plan. IIUC, I don't think it does. Next thing to do is move migration to its own thread. Before doing that, I need to know what parts are used/not used outside migration.c. Removing it now means that nothing gets to use it without needing a patch. I've once asked Anthony whether it's possible to make migration to different threads, but his answer was no due to hard dependency of qemu's internal code, and making migration to different threads are bad design. I know. But Anthony is seeing the light O:-) Basically, without an own thread we are not able to: - do anything else while on incoming migration (namely using the monitor) - do anything else than migration. We can try hard and let vcpus to run, but we would still clog the io_thread. - We are not able to saturate 10Gbit networking (basically we are doing 2/3 level of bufferering (depending on how you count). So, once code is there, I guess we will convince Anthony to commit it. Later, Juan.
[Qemu-devel] Re: virtio-serial semantics for binary data and guest agents
On (Wed) 23 Feb 2011 [08:31:52], Michael Roth wrote: On 02/22/2011 10:59 PM, Amit Shah wrote: On (Tue) 22 Feb 2011 [16:40:55], Michael Roth wrote: If something in the guest is attempting to read/write from the virtio-serial device, and nothing is connected to virtio-serial's host character device (say, a socket) 1. writes will block until something connect()s, at which point the write will succeed 2. reads will always return 0 until something connect()s, at which point the reads will block until there's data This makes it difficult (impossible?) to implement the notion of connect/disconnect or open/close over virtio-serial without layering another protocol on top using hackish things like length-encoded payloads or sentinel values to determine the end of one RPC/request/response/session and the start of the next. For instance, if the host side disconnects, then reconnects before we read(), we may never get the read()=0, and our FD remains valid. Whereas with a tcp/unix socket our FD is no longer valid, and the read()=0 is an event we can check for at any point after the other end does a close/disconnect. There's SIGIO support, so host connect-disconnect notifications can be caught via the signal. I recall looking into this at some pointbut don't we get a SIGIO for read/write-ability in general? I don't get you -- the virtio_console driver emits the SIGIO signal only when the host side connects or disconnects. See http://www.linux-kvm.org/page/Virtio-serial_API So whenever you receive a SIGIO, poll() in the signal handler for all fds of interest and whichever has POLLIN set is writable. Whichever has POLLHUP set is not. If you maintain previous state of the fd (before signal), you can figure out if something happened on the host side. So you still need some way differentiate, say, readability from a disconnect/EOF, and the read()=0 that could determine this is still racing with host-side reconnects. Also, nonblocking reads/writes will return -EPIPE if the host-side connection is not up. But we still essentially need to poll() for a host-side disconnected state, which is still racy since they may reconnect before we've done a read/write that would've generated the -EPIPE. It seems like what we really need is for the FD to be invalid from that point forward. This would go against (or abuse) a chardev interface. It would effectively treat a host-side port close as a hot-unplug event. Also, I focused more on the guest-side connect/disconnect detection, but as Anthony mentioned I think the host side shares similar limitations as well. AFAIK once we connect to the chardev that FD remains valid until the connected process closes it, and so races with the guest side on detecting connect/disconnect events in a similar manner. For the host side it looks like virtio-console has guest_close/guest_open callbacks already that we could potentially use...seems like it's just a matter of tying them to the chardev... basically having virtio-serial's guest_close() result in a close() on the corresponding chardev connection's FD. Yes, this could be used. However, the problem with that will be that the chardev can't be opened again (AFAIR) and a new chardev will have to be used. So if this is done on both the sides, the race will be eliminated but the expectation that a chardev port is just a serial port will be broken and we'll try to bake in some connection layer on top of it. That wasn't the original idea. We could extend this, but a better way to achieve this could be a library on either side to abstract these details off. Amit
[Qemu-devel] Re: [PATCH] target-sh4: move intr_at_halt out of cpu_halted()
On Thu, Feb 24, 2011 at 01:05:02PM +0100, Paolo Bonzini wrote: On 02/24/2011 12:54 PM, Aurelien Jarno wrote: All targets except SH4 have the same cpu_halted() routine, and it has only one caller. It is therefore a good candidate for inlining. The difference is the handling of the intr_at_halt, which is necessary to ignore SR.BL when sleeping. Move intr_at_halt handling out of it, by setting this variable while executing the sleep instruction, and clearing it when the CPU has been woken-up by an interrupt, whatever the state of SR.BL. Cc: Paolo Bonzinipbonz...@redhat.com Signed-off-by: Aurelien Jarnoaurel...@aurel32.net Makes sense, thanks! You may want to rename intr_at_halt to env-in_sleep or something like that. Agreed, I will send a new patch. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] [PATCH v2] target-sh4: move intr_at_halt out of cpu_halted()
All targets except SH4 have the same cpu_halted() routine, and it has
only one caller. It is therefore a good candidate for inlining.
The difference is the handling of the intr_at_halt, which is necessary
to ignore SR.BL when sleeping. Move intr_at_halt handling out of it, by
setting this variable while executing the sleep instruction, and
clearing it when the CPU has been woken-up by an interrupt, whatever the
state of SR.BL. Also rename this variable in_sleep.
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
target-sh4/cpu.h |2 +-
target-sh4/exec.h |1 -
target-sh4/helper.c|4 ++--
target-sh4/op_helper.c |1 +
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/target-sh4/cpu.h b/target-sh4/cpu.h
index d9f94e6..dd711cc 100644
--- a/target-sh4/cpu.h
+++ b/target-sh4/cpu.h
@@ -188,7 +188,7 @@ typedef struct CPUSH4State {
uint32_t cvr; /* Cache Version Register */
void *intc_handle;
-int intr_at_halt; /* SR_BL ignored during sleep */
+int in_sleep; /* SR_BL ignored during sleep */
memory_content *movcal_backup;
memory_content **movcal_backup_tail;
} CPUSH4State;
diff --git a/target-sh4/exec.h b/target-sh4/exec.h
index 2999c02..61bc121 100644
--- a/target-sh4/exec.h
+++ b/target-sh4/exec.h
@@ -37,7 +37,6 @@ static inline int cpu_halted(CPUState *env) {
return 0;
if (cpu_has_work(env)) {
env-halted = 0;
-env-intr_at_halt = 1;
return 0;
}
return EXCP_HALTED;
diff --git a/target-sh4/helper.c b/target-sh4/helper.c
index b9fcba6..dd1941a 100644
--- a/target-sh4/helper.c
+++ b/target-sh4/helper.c
@@ -90,11 +90,11 @@ void do_interrupt(CPUState * env)
if (do_exp env-exception_index != 0x1e0) {
env-exception_index = 0x000; /* masked exception - reset */
}
-if (do_irq !env-intr_at_halt) {
+if (do_irq !env-in_sleep) {
return; /* masked */
}
-env-intr_at_halt = 0;
}
+env-in_sleep = 0;
if (do_irq) {
irq_vector = sh_intc_get_pending_vector(env-intc_handle,
diff --git a/target-sh4/op_helper.c b/target-sh4/op_helper.c
index 30f9842..b8f4ca2 100644
--- a/target-sh4/op_helper.c
+++ b/target-sh4/op_helper.c
@@ -119,6 +119,7 @@ void helper_debug(void)
void helper_sleep(uint32_t next_pc)
{
env-halted = 1;
+env-in_sleep = 1;
env-exception_index = EXCP_HLT;
env-pc = next_pc;
cpu_loop_exit();
--
1.7.2.3
[Qemu-devel] Re: [PATCH 2/2] build: create shared-obj-y for tools/qemu-softmmu
Juan Quintela quint...@redhat.com writes: Markus Armbruster arm...@redhat.com wrote: Peter Maydell peter.mayd...@linaro.org writes: On 24 February 2011 10:33, Juan Quintela quint...@redhat.com wrote: +# shared-obj-y has the object that are shared by qemu binary and tools + +shared-obj-y = qemu-error.o $(block-obj-y) $(qobject-obj-y) $(oslib-obj-y) +shared-obj-y += qemu-timer-common.o I don't feel very strongly about this, but: It seems a bit odd to have a shared-obj-y variable that isn't actually a list of shared objects (ie .so files, DLLs). Maybe there's a better name? common-obj-y? already taken :-( common-obj-y is the list of files that are shared by all qemu-softmmu ## # libqemu_common.a: Target independent part of system emulation. The # long term path is to suppress *all* target specific code in case of # system emulation, i.e. a single QEMU executable should support all # CPUs and machines. common-obj-y = $(block-obj-y) blockdev.o ... so, this is the list of files that are shared between all the softmmu (common) and the tools. I am open to suggestions, but all names I thought are worse than shared (common-common-obj-y) :p really-common-obj-y? ;) Seriously, what about renaming common-obj-y away? target-indep-obj-y?
[Qemu-devel] Re: [PATCH 2/2] build: create shared-obj-y for tools/qemu-softmmu
On 02/24/2011 02:53 PM, Markus Armbruster wrote: really-common-obj-y?;) Seriously, what about renaming common-obj-y away? target-indep-obj-y? softmmu-obj-y? Paolo
[Qemu-devel] Re: [PATCH 2/2] build: create shared-obj-y for tools/qemu-softmmu
Paolo Bonzini pbonz...@redhat.com wrote: On 02/24/2011 02:53 PM, Markus Armbruster wrote: really-common-obj-y?;) Seriously, what about renaming common-obj-y away? target-indep-obj-y? softmmu-obj-y? Waiting for Anthony to decide anything, renaming the variable is the easy thing to do. Later, Juan.
[Qemu-devel] [PATCH 0/3] Remove wrong savevm sections
Hi This devices savevm support is Not Even Wrong. Just remove it. It has never work for sure. Anthony, please apply. Later, Juan. Juan Quintela (3): vmstate: remove grackle_pci savevm code vmstate: remove uninorth savevm code gt64xxx: remove savevm support hw/grackle_pci.c | 19 --- hw/gt64xxx.c | 21 - hw/unin_pci.c| 21 - 3 files changed, 0 insertions(+), 61 deletions(-) -- 1.7.4
[Qemu-devel] [PATCH 1/3] vmstate: remove grackle_pci savevm code
It was migrating the wrong structures, no way it would work
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/grackle_pci.c | 19 ---
1 files changed, 0 insertions(+), 19 deletions(-)
diff --git a/hw/grackle_pci.c b/hw/grackle_pci.c
index bd3d6b0..d35701f 100644
--- a/hw/grackle_pci.c
+++ b/hw/grackle_pci.c
@@ -57,23 +57,6 @@ static void pci_grackle_set_irq(void *opaque, int irq_num,
int level)
qemu_set_irq(pic[irq_num + 0x15], level);
}
-static void pci_grackle_save(QEMUFile* f, void *opaque)
-{
-PCIDevice *d = opaque;
-
-pci_device_save(d, f);
-}
-
-static int pci_grackle_load(QEMUFile* f, void *opaque, int version_id)
-{
-PCIDevice *d = opaque;
-
-if (version_id != 1)
-return -EINVAL;
-
-return pci_device_load(d, f);
-}
-
static void pci_grackle_reset(void *opaque)
{
}
@@ -115,8 +98,6 @@ static int pci_grackle_init_device(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, pci_mem_config);
sysbus_init_mmio(dev, 0x1000, pci_mem_data);
-register_savevm(dev-qdev, grackle, 0, 1, pci_grackle_save,
-pci_grackle_load, s-host_state);
qemu_register_reset(pci_grackle_reset, s-host_state);
return 0;
}
--
1.7.4
[Qemu-devel] [PATCH 3/3] gt64xxx: remove savevm support
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/gt64xxx.c | 21 -
1 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/hw/gt64xxx.c b/hw/gt64xxx.c
index 923073b..c66188f 100644
--- a/hw/gt64xxx.c
+++ b/hw/gt64xxx.c
@@ -1080,25 +1080,6 @@ static void gt64120_reset(void *opaque)
gt64120_pci_mapping(s);
}
-static void gt64120_save(QEMUFile* f, void *opaque)
-{
-PCIDevice *d = opaque;
-pci_device_save(d, f);
-}
-
-static int gt64120_load(QEMUFile* f, void *opaque, int version_id)
-{
-PCIDevice *d = opaque;
-int ret;
-
-if (version_id != 1)
-return -EINVAL;
-ret = pci_device_load(d, f);
-if (ret 0)
-return ret;
-return 0;
-}
-
PCIBus *gt64120_register(qemu_irq *pic)
{
SysBusDevice *s;
@@ -1131,8 +1112,6 @@ static int gt64120_init(SysBusDevice *dev)
does not fully work. */
isa_mem_base = 0x1000;
qemu_register_reset(gt64120_reset, s);
-register_savevm(dev-qdev, GT64120 PCI Bus, 0, 1,
-gt64120_save, gt64120_load, s-pci);
return 0;
}
--
1.7.4
[Qemu-devel] [PATCH 2/3] vmstate: remove uninorth savevm code
It was migrating the wrong structures, no way it would work
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/unin_pci.c | 21 -
1 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index 5f15058..c57c0a1 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -63,23 +63,6 @@ static void pci_unin_set_irq(void *opaque, int irq_num, int
level)
qemu_set_irq(pic[unin_irq_line[irq_num]], level);
}
-static void pci_unin_save(QEMUFile* f, void *opaque)
-{
-PCIDevice *d = opaque;
-
-pci_device_save(d, f);
-}
-
-static int pci_unin_load(QEMUFile* f, void *opaque, int version_id)
-{
-PCIDevice *d = opaque;
-
-if (version_id != 1)
-return -EINVAL;
-
-return pci_device_load(d, f);
-}
-
static void pci_unin_reset(void *opaque)
{
}
@@ -158,8 +141,6 @@ static int pci_unin_main_init_device(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, pci_mem_config);
sysbus_init_mmio(dev, 0x1000, pci_mem_data);
-register_savevm(dev-qdev, uninorth, 0, 1,
-pci_unin_save, pci_unin_load, s-host_state);
qemu_register_reset(pci_unin_reset, s-host_state);
return 0;
}
@@ -181,8 +162,6 @@ static int pci_u3_agp_init_device(SysBusDevice *dev)
sysbus_init_mmio(dev, 0x1000, pci_mem_config);
sysbus_init_mmio(dev, 0x1000, pci_mem_data);
-register_savevm(dev-qdev, uninorth, 0, 1,
-pci_unin_save, pci_unin_load, s-host_state);
qemu_register_reset(pci_unin_reset, s-host_state);
return 0;
--
1.7.4
Re: [Qemu-devel] [PATCH V6 3/4] qmp, nmi: convert do_inject_nmi() to QObject
On 02/24/2011 02:33 AM, Markus Armbruster wrote:
Anthony Liguorianth...@codemonkey.ws writes:
On 01/27/2011 02:20 AM, Lai Jiangshan wrote:
Make we can inject NMI via qemu-monitor-protocol.
We use inject-nmi for the qmp command name, the meaning is clearer.
Signed-off-by: Lai Jiangshanla...@cn.fujitsu.com
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index ec1a4db..e763bf9 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -725,7 +725,8 @@ ETEXI
.params = [cpu],
.help = Inject an NMI on all CPUs if no argument is given,
otherwise inject it on the specified CPU,
-.mhandler.cmd = do_inject_nmi,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
},
#endif
STEXI
diff --git a/monitor.c b/monitor.c
index 387b020..1b1c0ba 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2542,7 +2542,7 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
#endif
#if defined(TARGET_I386)
-static void do_inject_nmi(Monitor *mon, const QDict *qdict)
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
CPUState *env;
int cpu_index;
@@ -2550,7 +2550,7 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
if (!qdict_haskey(qdict, cpu-index)) {
for (env = first_cpu; env != NULL; env = env-next_cpu)
cpu_interrupt(env, CPU_INTERRUPT_NMI);
-return;
+return 0;
}
cpu_index = qdict_get_int(qdict, cpu-index);
@@ -2560,8 +2560,10 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
kvm_inject_interrupt(env, CPU_INTERRUPT_NMI);
else
cpu_interrupt(env, CPU_INTERRUPT_NMI);
-break;
+return 0;
}
+
+return -1;
}
#endif
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 56c4d8b..a887dd5 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -429,6 +429,34 @@ Example:
EQMP
+#if defined(TARGET_I386)
+{
+.name = inject-nmi,
+.args_type = cpu-index:i?,
+.params = [cpu],
+.help = Inject an NMI on all CPUs if no argument is given,
+ otherwise inject it on the specified CPU,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
+},
+#endif
+SQMP
+inject-nmi
+--
+
+Inject an NMI on all CPUs or the given CPU (x86 only).
+
+Arguments:
+
+- cpu-index: the index of the CPU to be injected NMI (json-int, optional)
+
+Example:
+
+- { execute: inject-nmi, arguments: { cpu-index: 0 } }
+- { return: {} }
Please describe all expected errors.
Quoting qmp-commands.hx:
3. Errors, in special, are not documented. Applications should NOT check
for specific errors classes or data (it's strongly recommended to only
check for the error key)
Indeed, not a single error is documented there. This is intentional.
Yeah, but we're not 0.14 anymore and for 0.15, we need to document
errors. If you are suggesting I send a patch to remove that section,
I'm more than happy to.
Once we have an error design in place that has a reasonable hope to
stand the test of time, and have errors documented for at least some of
the commands here, we can start to require proper error documentation
for new commands. But not now.
I'm quite happy with the error design we have today. The only problem
is that we don't propagate errors in a sane way but I've got that all
but fixed in my qapi tree.
Don't hide this command for
!defined(TARGET_I386), instead have it throw an error in the
implementation.
Works for me.
Don't have commands that multiple behavior based on the presence or
absence of arguments. Make it take a list of cpus if you want the
ability to inject the NMI to more than one CPU.
Having optional arguments is fine. It's good taste to give them
default semantics, i.e. no argument is shorthand for one specific
argument value.
Luiz already pointed to the thread where we discussed this command
before. Executive summary:
* Real hardware's NMI button injects all CPUs. This is the primary use
case.
* Lai said injecting a single CPU can be useful for debugging. Was
deemed acceptable as secondary use case.
Lai also pointed out that the human monitor's nmi command injects a
single CPU. That was dismissed as irrelevant for QMP.
* No other use cases have been presented.
Therefore, the list of CPUs idea was shot down as overly general.
That's fine, then we should do two commands. Think of it from the
perspective of the client. This appears as:
in C:
qmp_inject_nmi(sess, false, 0, err);
in Python:
sess.inject_nmi()
The first example doesn't tell you at all what's happening. The second
API does look really nice until you see the following later:
[Qemu-devel] null mac address
Hi, I got some troubles hot plugging network pci devices. An attach works as expected but the mac address is still set to 00:00:00:00:00:00 on the guest machine. I have to reboot the guest to get the correct mac address. I first tried through libvirt with: # virsh attach-interface dom0 network default --mac 52:54:00:f6:84:ba and then through qemu monitor to make sure that it wasn't a libvirt issue: device_add rtl8139 or device_add rtl8139,mac=01:02:03:04:05:06 Always the same result on the guest. A device info on qemu give the correct result, that is to say, with a correct mac address. I went through rtl8139.c and saw that the mac address is set in `rtl8139_reset`. This function was called in `pci_rtl8139_init` but removed since c169998802505c244b8bcad562633f29de7d74a4 commit, because it doesn't make sense to call it when the virtual machine is shutdown. I'm now wondering where I am supposed to call this reset function when live attaching a pci device. I think it could fix the mac address issue. I will be very pleased to receive some tips to create a patch for this issue. Regards, -- William
[Qemu-devel] Re: virtio-serial semantics for binary data and guest agents
On 02/24/2011 06:48 AM, Amit Shah wrote: On (Wed) 23 Feb 2011 [08:31:52], Michael Roth wrote: On 02/22/2011 10:59 PM, Amit Shah wrote: On (Tue) 22 Feb 2011 [16:40:55], Michael Roth wrote: If something in the guest is attempting to read/write from the virtio-serial device, and nothing is connected to virtio-serial's host character device (say, a socket) 1. writes will block until something connect()s, at which point the write will succeed 2. reads will always return 0 until something connect()s, at which point the reads will block until there's data This makes it difficult (impossible?) to implement the notion of connect/disconnect or open/close over virtio-serial without layering another protocol on top using hackish things like length-encoded payloads or sentinel values to determine the end of one RPC/request/response/session and the start of the next. For instance, if the host side disconnects, then reconnects before we read(), we may never get the read()=0, and our FD remains valid. Whereas with a tcp/unix socket our FD is no longer valid, and the read()=0 is an event we can check for at any point after the other end does a close/disconnect. There's SIGIO support, so host connect-disconnect notifications can be caught via the signal. I recall looking into this at some pointbut don't we get a SIGIO for read/write-ability in general? I don't get you -- the virtio_console driver emits the SIGIO signal only when the host side connects or disconnects. See Um, that's not the expected semantics of SIGIO. SIGIO can be delivered for any number of reasons (including on a normal file descriptor) so if there's no way to poll for the specific event then the mechanism is inherently racy. Regards, Anthony Liguori http://www.linux-kvm.org/page/Virtio-serial_API So whenever you receive a SIGIO, poll() in the signal handler for all fds of interest and whichever has POLLIN set is writable. Whichever has POLLHUP set is not. If you maintain previous state of the fd (before signal), you can figure out if something happened on the host side. So you still need some way differentiate, say, readability from a disconnect/EOF, and the read()=0 that could determine this is still racing with host-side reconnects. Also, nonblocking reads/writes will return -EPIPE if the host-side connection is not up. But we still essentially need to poll() for a host-side disconnected state, which is still racy since they may reconnect before we've done a read/write that would've generated the -EPIPE. It seems like what we really need is for the FD to be invalid from that point forward. This would go against (or abuse) a chardev interface. It would effectively treat a host-side port close as a hot-unplug event. Also, I focused more on the guest-side connect/disconnect detection, but as Anthony mentioned I think the host side shares similar limitations as well. AFAIK once we connect to the chardev that FD remains valid until the connected process closes it, and so races with the guest side on detecting connect/disconnect events in a similar manner. For the host side it looks like virtio-console has guest_close/guest_open callbacks already that we could potentially use...seems like it's just a matter of tying them to the chardev... basically having virtio-serial's guest_close() result in a close() on the corresponding chardev connection's FD. Yes, this could be used. However, the problem with that will be that the chardev can't be opened again (AFAIR) and a new chardev will have to be used. So if this is done on both the sides, the race will be eliminated but the expectation that a chardev port is just a serial port will be broken and we'll try to bake in some connection layer on top of it. That wasn't the original idea. We could extend this, but a better way to achieve this could be a library on either side to abstract these details off. Amit
Re: [Qemu-devel] Re: [PATCH 22/22] migration: Make state definitions local
On 02/24/2011 06:23 AM, Juan Quintela wrote: Yoshiaki Tamuratamura.yoshi...@lab.ntt.co.jp wrote: 2011/2/23 Juan Quintelaquint...@redhat.com: Yoshiaki Tamuratamura.yoshi...@lab.ntt.co.jp wrote: 2011/2/23 Juan Quintelaquint...@redhat.com: Although you're right, I would prefer to keep it so that somebody outside of migration may understand the status in the future if there are no harms. my plan is to move MigrationState inside migration.c, and then decide what to export/not export. Well, it may be just a policy, but it's already exported, and I would like to keep it unless it bothers your plan. IIUC, I don't think it does. Next thing to do is move migration to its own thread. Before doing that, I need to know what parts are used/not used outside migration.c. Removing it now means that nothing gets to use it without needing a patch. I've once asked Anthony whether it's possible to make migration to different threads, but his answer was no due to hard dependency of qemu's internal code, and making migration to different threads are bad design. I know. But Anthony is seeing the light O:-) Let's be very careful about quoting Anthony as he's known to be incoherent 90% of the time :-) I don't quite recall the context of the discussion with Yoshi, but I'm not quite there in terms of advocating that we throw a bucket full of threads at migration. I think we should move the ram migration to another I/O thread that doesn't hold a lock against the main I/O thread. That's all. Regards, Anthony Liguori Basically, without an own thread we are not able to: - do anything else while on incoming migration (namely using the monitor) - do anything else than migration. We can try hard and let vcpus to run, but we would still clog the io_thread. - We are not able to saturate 10Gbit networking (basically we are doing 2/3 level of bufferering (depending on how you count). So, once code is there, I guess we will convince Anthony to commit it. Later, Juan.
Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop
On 02/24/2011 04:19 AM, Stefan Hajnoczi wrote: Any chance of reusing info qtree, QemuOpts, or other existing infrastructure for the config file? I'm nowhere near implementation details like that. I'm still trying to understand whether this is a Good Idea at all. Regards, Anthony Liguori Config file set/get/format code tends to be just toggling variables and manipulating strings. There is similarity here with the option parsing and qdev properties. Stefan
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On 02/24/2011 02:54 AM, Avi Kivity wrote:
On 02/23/2011 10:18 PM, Anthony Liguori wrote:
Then the management stack has to worry about yet another way of
interacting via qemu.
{ 'StateItem': { 'key': 'str', 'value': 'str' } }
{ 'StateSection': { 'kind': 'str', 'name': 'str', 'items': [
'StateItem' ] } }
{ 'StateInfo': { 'sections': [ 'StateSection' ] } }
{ 'query-state', {}, {}, 'StateInfo' }
A management tool never need to worry about anything other than this
command if it so chooses. If we have the pre-machine init mode for
0.16, then this can even be used to inspect state without running a
guest.
So we have yet another information tree. If we store the cd-rom eject
state here, then we need to make an association between the device
path of the cd-rom, and the StateItem key.
And this linkage is key.
Let's say I launch QEMU with:
qemu -cdrom ~/foo.img
And then in the monitor, I do:
(qemu) eject ide1-cd0
The question is, what command can I now use to launch the same qemu
instance?
When I think of stateful config, what I really think of is a way to spit
out a command line that essentially becomes, this is how you now launch
QEMU.
In this case, it would be:
qemu -cdrom ~/foo.img -device ide-disk,id=ide1-cd0,drive=
Or, we could think of this in terms of:
qemu -cdrom ~/foo.img -readconfig foo.cfg
Where foo.cfg contained:
[device ide1-cd0]
driver=ide-disk
drive=
So what I'm really suggesting is that we generate foo.cfg whenever
monitor commands do things that change the command line and introduce a
new option to reflect this, IOW:
qemu -cdrom ~/foo.img -config foo.cfg
Far better to store it in the device itself. For example, we could
make a layered block format driver that stores the eject state and a
backing file containing the actual media. Eject and media change
would be recorded in the block format driver's state. You could then
hot-unplug a USB cd-writer and hot-plug it back into a different
guest, implementing a virtual sneakernet.
I think you're far too hung up on store it in the device itself. The
recipe to create the device model is not intrinsic to the device model.
It's an independent thing that's a combination of the command line
arguments and any executed monitor commands.
Maybe a better way to think about the stateful config file is a
mechanism to replay the monitor history.
The fact that the state is visible in the filesystem is an
implementation detail.
A detail that has to be catered for by the management stack - it has
to provide a safe place for it, back it up, etc.
If it cares for QEMU to preserve state. Today, this all gets thrown away.
It doesn't work for eject unless you interpose an acknowledged
event. Ultimately, this is a simple problem. If you want
reliability, we either need symmetric RPCs so that the device model
can call (and wait) to the management layer to acknowledge a change
or QEMU can post an event to the management layer, and maintain the
state in a reliable fashion.
I don't see why it doesn't work. Please explain.
1) guest eject
2) qemu posts eject event
3) qemu acknowledges eject to the guest
4) management tool sees eject event and updates guest config
There's a race between 3 4. It can only be addressed by interposing 4
between 2 and 3 OR making qemu persist this state between 2 and 3 such
that the management tool can reliably query it.
You still have the race condition around guest initiated events
like eject. Unless you have an acknowledged event from a
management tool (which we can't do in QMP today) whereas you don't
complete the guest initiated eject operation until management ack's
it, we need to store that state ourself.
I don't see why.
If management crashes, it queries the eject state when it reconnects
to qemu.
If qemu crashes, the eject state is lost, but that is fine. My
CD-ROM drive tray pulls itself in when the machine is started.
Pick any of a number of possible events that change the machine's
state. We can wave our hands at some things saying they don't matter
and do one off solutions for others, or we can just have a robust way
of handling this consistently.
Both block live copy and cd-rom eject state can be solved with layered
block format drivers. I don't think a central place for random data
makes sense. State belongs near the device that maintains it, esp. if
the device is hot-pluggable, so it's easy to associate the state with
the device.
You're introducing the need for additional code in the management
layer, the care and feeding for the stateful non-config file.
If a management layer ignores the stateful non-config file, as you
like to call it, it'll get the same semantics it has today. I think
managing a single thing is a whole lot easier than managing an NVRAM
file, a block migration layering file, and all of the future things
we're going to add once we decide they are important too.
I disagree. Storing NVRAM as a
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On Thu, Feb 24, 2011 at 10:58:10AM +0200, Avi Kivity wrote: On 02/23/2011 07:49 PM, Marcelo Tosatti wrote: On Wed, Feb 23, 2011 at 03:01:14PM +0200, Avi Kivity wrote: On 02/23/2011 01:14 AM, Anthony Liguori wrote: -drive already ties into the qemuopts infrastructure and we have readconfig and writeconfig. I don't think we're missing any major pieces to do this in a more proper fashion. The problem with qemu config files is that it splits the authoritative source of where images are stored into two. Is it in the management tool's database or is it in qemu's config file? For the problem at hand, one solution is to make qemu stop after the copy, and then management can issue an additional command to rearrange the disk and resume the guest. A drawback here is that if management dies, the guest is stopped until it restarts. We also make management latency guest visible, even if it doesn't die at an inconvenient place. An alternative approach is to have the copy be performed by a new layered block format driver: - create a new image, type = live-copy, containing three pieces of information - source image - destination image - copy state (initially nothing is copied) - tell qemu switch to the new image There is a similar situation with atomicity here. Mgmt app requests a switch and dies immediately, before receiving the command reply. Qemu crashes. Which image is the uptodate one, source or live-copy? - qemu starts copying, updates copy state as needed - copy finishes, event is emitted; reads and writes still serviced - management receives event, switches qemu to destination image - management removes live-copy image If management dies while this is happening, it can simply query the state of the copy. Similarly, if qemu dies, the copy state is persistent (could be 0/1 or real range of blocks). You don't know if a given block is uptodate or not without the dirty bitmap. So unless you also keep track of dirty log somehow, this is meaningless. First, you no longer need the dirty bitmap. Since all writes go through the layered block format driver, you know first-hand what is dirty and what isn't. So a commit file as proposed indicates copy state (in 0/1 fashion). The difference in your proposal is that such information is stored inside a special purpose image format? It could also store the already synced range. The difference is that the file is self contained. You could hot-unplug the image and hot-plug it later (continuing the copy with qemu-img), Then there's no need for live copy. qemu-img does that already. or live migrate it. You can live migrate (but not live migrate with live block migration) with live copy in progress, its just that its not supported yet. In fact I think a qemu RAID-1 driver removes the restriction that you can't live-migrate and live-copy simultaneously. As mentioned its just an implementation detail.
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On Wed, Feb 23, 2011 at 03:41:30PM -0600, Anthony Liguori wrote: On 02/23/2011 02:44 PM, Marcelo Tosatti wrote: Any indirect qemu state. Block migration is an example, but other examples would be VNC server information (like current password), WCE setting (depending on whether we modelled eeprom for the drivers), and persisted device settings (lots of devices have eeprom these days). Agreed. Why a separate location for this stateful non-config section, however? The state in question (backing image property, device presence, VNC info, etc) is already represented in either host or guest configuration, so why not simply expose that? Hrm, are you suggesting that the stateful non-config be hidden directly from the user such that only existing monitor interfaces are used to query it's contents? Yes. So that the guest can be restarted with the same VM parameters. I'll have to think about that a bit. Obviously, the existing commands would still be authoritative even with a query-state command. I think the only question is whether there's value in making this totally opaque. Why you need a query-state command at all? Regards, Anthony Liguori
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On 02/24/2011 05:00 PM, Anthony Liguori wrote:
On 02/24/2011 02:54 AM, Avi Kivity wrote:
On 02/23/2011 10:18 PM, Anthony Liguori wrote:
Then the management stack has to worry about yet another way of
interacting via qemu.
{ 'StateItem': { 'key': 'str', 'value': 'str' } }
{ 'StateSection': { 'kind': 'str', 'name': 'str', 'items': [
'StateItem' ] } }
{ 'StateInfo': { 'sections': [ 'StateSection' ] } }
{ 'query-state', {}, {}, 'StateInfo' }
A management tool never need to worry about anything other than this
command if it so chooses. If we have the pre-machine init mode for
0.16, then this can even be used to inspect state without running a
guest.
So we have yet another information tree. If we store the cd-rom
eject state here, then we need to make an association between the
device path of the cd-rom, and the StateItem key.
And this linkage is key.
Let's say I launch QEMU with:
qemu -cdrom ~/foo.img
And then in the monitor, I do:
(qemu) eject ide1-cd0
The question is, what command can I now use to launch the same qemu
instance?
When I think of stateful config, what I really think of is a way to
spit out a command line that essentially becomes, this is how you now
launch QEMU.
In this case, it would be:
qemu -cdrom ~/foo.img -device ide-disk,id=ide1-cd0,drive=
Or, we could think of this in terms of:
qemu -cdrom ~/foo.img -readconfig foo.cfg
Where foo.cfg contained:
[device ide1-cd0]
driver=ide-disk
drive=
So what I'm really suggesting is that we generate foo.cfg whenever
monitor commands do things that change the command line and introduce
a new option to reflect this, IOW:
qemu -cdrom ~/foo.img -config foo.cfg
If you move the cdrom to a different IDE channel, you have to update the
stateful non-config file.
Whereas if you do
$ qemu-img create -f cd-tray -b ~/foo.img ~/foo-media-tray.img
$ qemu -cdrom ~/foo-media-tray.img
the cd-rom tray state will be tracked in the image file.
Far better to store it in the device itself. For example, we could
make a layered block format driver that stores the eject state and a
backing file containing the actual media. Eject and media change
would be recorded in the block format driver's state. You could then
hot-unplug a USB cd-writer and hot-plug it back into a different
guest, implementing a virtual sneakernet.
I think you're far too hung up on store it in the device itself.
The recipe to create the device model is not intrinsic to the device
model. It's an independent thing that's a combination of the command
line arguments and any executed monitor commands.
Maybe a better way to think about the stateful config file is a
mechanism to replay the monitor history.
Again the question is who is the authoritative source of the
configuration. Is it the management tool or is it qemu?
The management tool already has to keep track of (the optional parts of)
the guest device tree. It cannot start reading the stateful non-config
file at random points in time. So all that is left is the guest
controlled portions of the device tree, which are pretty rare, and
random events like live-copy migration. I think that introducing a new
authoritative source of information will create a lot of problems.
The fact that the state is visible in the filesystem is an
implementation detail.
A detail that has to be catered for by the management stack - it has
to provide a safe place for it, back it up, etc.
If it cares for QEMU to preserve state. Today, this all gets thrown
away.
Right, but we should make it easy, not hard.
It doesn't work for eject unless you interpose an acknowledged
event. Ultimately, this is a simple problem. If you want
reliability, we either need symmetric RPCs so that the device model
can call (and wait) to the management layer to acknowledge a change
or QEMU can post an event to the management layer, and maintain the
state in a reliable fashion.
I don't see why it doesn't work. Please explain.
1) guest eject
2) qemu posts eject event
3) qemu acknowledges eject to the guest
4) management tool sees eject event and updates guest config
There's a race between 3 4. It can only be addressed by interposing
4 between 2 and 3 OR making qemu persist this state between 2 and 3
such that the management tool can reliably query it.
If it is my cd-rom tray block format driver, it works. It's really
the same in action as the stateful non-config, except it's part of the
device/image, not a central location.
I disagree. Storing NVRAM as a disk image is a simple extension of
existing management tools. Block live-copy and cd-rom eject state
also make sense as per-image state if you take hotunplug and hotplug
into account.
Everything can be stored in a block driver but when the data is highly
structured, isn't it nice to expose it in a structured, human readable
way? I know I'd personally prefer a text representation of CMOS than
a binary blob.
Have a
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On 02/24/2011 05:14 PM, Marcelo Tosatti wrote: The problem with qemu config files is that it splits the authoritative source of where images are stored into two. Is it in the management tool's database or is it in qemu's config file? For the problem at hand, one solution is to make qemu stop after the copy, and then management can issue an additional command to rearrange the disk and resume the guest. A drawback here is that if management dies, the guest is stopped until it restarts. We also make management latency guest visible, even if it doesn't die at an inconvenient place. An alternative approach is to have the copy be performed by a new layered block format driver: - create a new image, type = live-copy, containing three pieces of information - source image - destination image - copy state (initially nothing is copied) - tell qemu switch to the new image There is a similar situation with atomicity here. Mgmt app requests a switch and dies immediately, before receiving the command reply. Qemu crashes. Which image is the uptodate one, source or live-copy? live-copy (or it's new name, RAID-1). Once you've created it it is equivalent to source. Once it switches to state=synced you can switch back to either source or destination (I guess by telling qemu to detach the one you don't want first, so it falls back to state=degraded). You could hot-unplug the image and hot-plug it later (continuing the copy with qemu-img), Then there's no need for live copy. qemu-img does that already. It will start from the beginning. or live migrate it. You can live migrate (but not live migrate with live block migration) with live copy in progress, its just that its not supported yet. A RAID-1 driver will work with block live migration too. In fact I think a qemu RAID-1 driver removes the restriction that you can't live-migrate and live-copy simultaneously. As mentioned its just an implementation detail. I think it's an important one. It moves the code from the generic layer to a driver. It allows generic RAID-1 functionality (for high availablity). -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 1/5] Add TPM 1.2 device interface
On 02/18/2011 05:37 PM, Stefan Berger wrote: [...] I have a tpm_tis.c with major changes in it getting rid of the polling, closer to specs that passes a test suite and a registerable backend as well that has several more interface functions, due to support for snapshotting etc. Unfortunately it doesn't make much sense for me to post it since the backend is based on a library that's currently in the Fedora review process and nobody else could build or test it -- unless there really was interest in reviewing at least some part of it. It would certainly be desirable if your backend and mine could be accommodate. I am looking for a rather soon integration of this functionality (at least with my host passthrough backend) into the main project. We could try to integrate your improved device emulation frontend along with the infrastructure for using different backends while your library is still being reviewed. I would post my (rather simple) direct host passthrough backend along with it, so testing can be done. That way, we would have the better part of the TPM emulation framework available in Qemu and you could post your library-based backend as soon as it has finished its review. Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: [Qemu-devel] [PATCH v3 05/16] vnc: tight: use the update frequency to choose between lossy and lossless
On 4 February 2011 08:05, Corentin Chary corenti...@iksaif.net wrote: Use the new update frequency infrastructure to use jpeg for regions with high update frequency. Signed-off-by: Corentin Chary corenti...@iksaif.net @@ -1514,6 +1536,8 @@ static int send_sub_rect(VncState *vs, int x, int y, int w, int h) uint32_t bg = 0, fg = 0; int colors; int ret = 0; + bool force_jpeg = false; + bool allow_jpeg = true; vnc_framebuffer_update(vs, x, y, w, h, vs-tight.type); This (ie git master, since this has been committed) doesn't compile if CONFIG_VNC_JPEG isn't defined: cam-vm-266:maverick:qemu$ make CCui/vnc-enc-tight.o cc1: warnings being treated as errors ui/vnc-enc-tight.c: In function ‘send_sub_rect’: ui/vnc-enc-tight.c:1540: error: unused variable ‘allow_jpeg’ ui/vnc-enc-tight.c:1539: error: unused variable ‘force_jpeg’ ui/vnc-enc-tight.c: In function ‘tight_send_framebuffer_update’: ui/vnc-enc-tight.c:1717: error: ‘tight_jpeg_conf’ undeclared (first use in this function) ui/vnc-enc-tight.c:1717: error: (Each undeclared identifier is reported only once ui/vnc-enc-tight.c:1717: error: for each function it appears in.) make: *** [ui/vnc-enc-tight.o] Error 1 -- PMM
Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop
On 02/24/2011 01:12 AM, Anthony Liguori wrote: What is the plan from here? 1) Decouple QMP from qemu_machine_init(). This really requires the introduction of the new QAPI server that exists outside of the chardev infrastructure since chardevs are currently initialized in qemu_machine_init(). Is it really necessary? What's blocking us from initializing chardevs early? It would be a pity to divorce the monitor from chardevs, they're really flexible. 2) Make qemu_machine_init() take no parameters and just reference global state. 3) Teach all QMP functions to behave themselves if called before qemu_machine_init() 4) Introduce QMP function to call qemu_machine_init() An alternative is to remove all guest-visible content from qemu_machine_init(). So machine-init() would take no parameters and only build the static devices (power supply?). Everything else would be hot-plugged (perhaps some would fail if the machine was started - cold-plug only). 5) Introduce new command line flag to not automatically call qemu_machine_init() 6) Convert all command line options to just be QMP function calls (6) can be started right now. (1) comes with the QAPI merge. (2) is pretty easy to do after applying this patch. (3) is probably something that can be done shortly after (1). (4) and (5) really require everything but (6) to be in place before we can meaningful do it. I think we can lay out much of the ground work for this in 0.15 and I think we can have a total conversion realistically for 0.16. That means that by EOY, we could invoke QEMU with no options and do everything through QMP. It's something that I've agitated for a long while, but when I see all the work needed, I'm not sure it's cost effective. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] ui/vnc-enc-tight.c: Fix compile failure if CONFIG_VNC_JPEG not defined
Add some missing #ifdefs to fix compilation failures in the !CONFIG_VNC_JPEG
case introduced by commit ce702e93.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
ui/vnc-enc-tight.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c
index 5933394..2522936 100644
--- a/ui/vnc-enc-tight.c
+++ b/ui/vnc-enc-tight.c
@@ -1536,8 +1536,10 @@ static int send_sub_rect(VncState *vs, int x, int y, int
w, int h)
uint32_t bg = 0, fg = 0;
int colors;
int ret = 0;
+#ifdef CONFIG_VNC_JPEG
bool force_jpeg = false;
bool allow_jpeg = true;
+#endif
vnc_framebuffer_update(vs, x, y, w, h, vs-tight.type);
@@ -1711,6 +1713,7 @@ static int tight_send_framebuffer_update(VncState *vs,
int x, int y,
vs-tight.pixel24 = false;
}
+#ifdef CONFIG_VNC_JPEG
if (vs-tight.quality != (uint8_t)-1) {
double freq = vnc_update_freq(vs, x, y, w, h);
@@ -1718,6 +1721,7 @@ static int tight_send_framebuffer_update(VncState *vs,
int x, int y,
return send_rect_simple(vs, x, y, w, h, false);
}
}
+#endif
if (w * h VNC_TIGHT_MIN_SPLIT_RECT_SIZE) {
return send_rect_simple(vs, x, y, w, h, true);
--
1.7.1
Re: [Qemu-devel] [PATCH V10 02/15] xen: Make xen build only on x86 target.
On 02/02/2011 08:49 AM, anthony.per...@citrix.com wrote:
From: Anthony PERARDanthony.per...@citrix.com
Signed-off-by: Anthony PERARDanthony.per...@citrix.com
Acked-by: Alexander Grafag...@suse.de
Is this really necessary? The advantage to building globally is that it
keeps the code from getting unnecessary i386-isms.
Regards,
Anthony Liguori
---
Makefile.objs |4
Makefile.target |4 +++-
configure |5 +
3 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/Makefile.objs b/Makefile.objs
index 93406ff..d91b9bc 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -150,10 +150,6 @@ slirp-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o
tcp_input.o tcp_output.o
slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o
common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y))
-# xen backend driver support
-common-obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o
-common-obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o
-
##
# libuser
diff --git a/Makefile.target b/Makefile.target
index b0ba95f..db29e96 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -206,7 +206,9 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
# xen backend driver support
-obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
+obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o
+obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o
+obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
# Inter-VM PCI shared memory
obj-$(CONFIG_KVM) += ivshmem.o
diff --git a/configure b/configure
index 210670c..5a9121d 100755
--- a/configure
+++ b/configure
@@ -1151,7 +1151,6 @@ int main(void) { xs_daemon_open(); xc_interface_open();
return 0; }
EOF
if compile_prog $xen_libs ; then
xen=yes
-libs_softmmu=$xen_libs $libs_softmmu
else
if test $xen = yes ; then
feature_not_found xen
@@ -2674,9 +2673,6 @@ if test $bluez = yes ; then
echo CONFIG_BLUEZ=y $config_host_mak
echo BLUEZ_CFLAGS=$bluez_cflags $config_host_mak
fi
-if test $xen = yes ; then
- echo CONFIG_XEN=y $config_host_mak
-fi
if test $io_thread = yes ; then
echo CONFIG_IOTHREAD=y $config_host_mak
echo CONFIG_THREAD=y $config_host_mak
@@ -3012,6 +3008,7 @@ case $target_arch2 in
i386|x86_64)
if test $xen = yes -a $target_softmmu = yes ; then
echo CONFIG_XEN=y $config_target_mak
+ echo LIBS+=$xen_libs $config_target_mak
fi
esac
case $target_arch2 in
Re: [Qemu-devel] [PATCH V6 3/4] qmp, nmi: convert do_inject_nmi() to QObject
Anthony Liguori aligu...@linux.vnet.ibm.com writes:
On 02/24/2011 02:33 AM, Markus Armbruster wrote:
Anthony Liguorianth...@codemonkey.ws writes:
On 01/27/2011 02:20 AM, Lai Jiangshan wrote:
Make we can inject NMI via qemu-monitor-protocol.
We use inject-nmi for the qmp command name, the meaning is clearer.
Signed-off-by: Lai Jiangshanla...@cn.fujitsu.com
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index ec1a4db..e763bf9 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -725,7 +725,8 @@ ETEXI
.params = [cpu],
.help = Inject an NMI on all CPUs if no argument is
given,
otherwise inject it on the specified CPU,
-.mhandler.cmd = do_inject_nmi,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
},
#endif
STEXI
diff --git a/monitor.c b/monitor.c
index 387b020..1b1c0ba 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2542,7 +2542,7 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
#endif
#if defined(TARGET_I386)
-static void do_inject_nmi(Monitor *mon, const QDict *qdict)
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject
**ret_data)
{
CPUState *env;
int cpu_index;
@@ -2550,7 +2550,7 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
if (!qdict_haskey(qdict, cpu-index)) {
for (env = first_cpu; env != NULL; env = env-next_cpu)
cpu_interrupt(env, CPU_INTERRUPT_NMI);
-return;
+return 0;
}
cpu_index = qdict_get_int(qdict, cpu-index);
@@ -2560,8 +2560,10 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
kvm_inject_interrupt(env, CPU_INTERRUPT_NMI);
else
cpu_interrupt(env, CPU_INTERRUPT_NMI);
-break;
+return 0;
}
+
+return -1;
}
#endif
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 56c4d8b..a887dd5 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -429,6 +429,34 @@ Example:
EQMP
+#if defined(TARGET_I386)
+{
+.name = inject-nmi,
+.args_type = cpu-index:i?,
+.params = [cpu],
+.help = Inject an NMI on all CPUs if no argument is given,
+ otherwise inject it on the specified CPU,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
+},
+#endif
+SQMP
+inject-nmi
+--
+
+Inject an NMI on all CPUs or the given CPU (x86 only).
+
+Arguments:
+
+- cpu-index: the index of the CPU to be injected NMI (json-int,
optional)
+
+Example:
+
+- { execute: inject-nmi, arguments: { cpu-index: 0 } }
+- { return: {} }
Please describe all expected errors.
Quoting qmp-commands.hx:
3. Errors, in special, are not documented. Applications should NOT check
for specific errors classes or data (it's strongly recommended to
only
check for the error key)
Indeed, not a single error is documented there. This is intentional.
Yeah, but we're not 0.14 anymore and for 0.15, we need to document
errors. If you are suggesting I send a patch to remove that section,
I'm more than happy to.
Two separate issues here: 1. Are we ready to commit to the current
design of errors, and 2. Is it fair to reject Lai's patch now because he
doesn't document his errors.
I'm not commenting on 1. here.
Regarding 2.: rejecting a patch because it doesn't document an aspect
that current master intentionally leaves undocumented is not how you
treat contributors. At least not if you want any other than certified
masochists who enjoy pain, and professionals who get adequately
compensated for it.
Lead by example, not by fiat.
Once we have an error design in place that has a reasonable hope to
stand the test of time, and have errors documented for at least some of
the commands here, we can start to require proper error documentation
for new commands. But not now.
I'm quite happy with the error design we have today. The only problem
is that we don't propagate errors in a sane way but I've got that all
but fixed in my qapi tree.
I don't think error propagation is the only problem we have with QError.
QError makes it way too hard to emit error messages fit for human
consumption. The consequence is that we get errors unfit for humans.
Don't hide this command for
!defined(TARGET_I386), instead have it throw an error in the
implementation.
Works for me.
Don't have commands that multiple behavior based on the presence or
absence of arguments. Make it take a list of cpus if you want the
ability to inject the NMI to more than one CPU.
Having optional arguments is fine. It's good taste to give them
default semantics, i.e. no argument is shorthand
Re: [Xen-devel] Re: [Qemu-devel] [PATCH V10 02/15] xen: Make xen build only on x86 target.
On Thu, Feb 24, 2011 at 16:11, Anthony Liguori anth...@codemonkey.ws wrote: Is this really necessary? The advantage to building globally is that it keeps the code from getting unnecessary i386-isms. Nop, is not necessary, I add this patch after this mail: http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg00044.html -- Anthony PERARD
[Qemu-devel] Re: [PATCH] ui/vnc-enc-tight.c: Fix compile failure if CONFIG_VNC_JPEG not defined
On Thu, Feb 24, 2011 at 4:04 PM, Peter Maydell peter.mayd...@linaro.org wrote: Add some missing #ifdefs to fix compilation failures in the !CONFIG_VNC_JPEG case introduced by commit ce702e93. Ooops. Acked-By: Corentin Chary corentin.ch...@gmail.com -- Corentin Chary http://xf.iksaif.net
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On Thu, Feb 24, 2011 at 05:28:20PM +0200, Avi Kivity wrote: On 02/24/2011 05:14 PM, Marcelo Tosatti wrote: The problem with qemu config files is that it splits the authoritative source of where images are stored into two. Is it in the management tool's database or is it in qemu's config file? For the problem at hand, one solution is to make qemu stop after the copy, and then management can issue an additional command to rearrange the disk and resume the guest. A drawback here is that if management dies, the guest is stopped until it restarts. We also make management latency guest visible, even if it doesn't die at an inconvenient place. An alternative approach is to have the copy be performed by a new layered block format driver: - create a new image, type = live-copy, containing three pieces of information - source image - destination image - copy state (initially nothing is copied) - tell qemu switch to the new image There is a similar situation with atomicity here. Mgmt app requests a switch and dies immediately, before receiving the command reply. Qemu crashes. Which image is the uptodate one, source or live-copy? live-copy (or it's new name, RAID-1). Once you've created it it is equivalent to source. Once it switches to state=synced you can switch back to either source or destination (I guess by telling qemu to detach the one you don't want first, so it falls back to state=degraded). You could hot-unplug the image and hot-plug it later (continuing the copy with qemu-img), Then there's no need for live copy. qemu-img does that already. It will start from the beginning. or live migrate it. You can live migrate (but not live migrate with live block migration) with live copy in progress, its just that its not supported yet. A RAID-1 driver will work with block live migration too. Nobody cares about that one (block copy and block live migration in progress). In fact, i doubt anybody cares about parallel block migration and block copy either (mgmt can easily cope with that limitation, stop live copy if migration is needed). In fact I think a qemu RAID-1 driver removes the restriction that you can't live-migrate and live-copy simultaneously. As mentioned its just an implementation detail. I meant the restriction of live-migrate and live-copy in parallel. I think it's an important one. It moves the code from the generic layer to a driver. Well it is a nice idea, but devil is in the details: - Guest writes must invalidate in progress live copy reads and live copy writes, so you have to maintain a queue for live copy AIO. - Live copy writes must be aware of in progress guest AIO writes, so you have to maintain a queue for guest AIO. - Guest writes must be mirrored to source and destination. - qemu-img must handle this new format. So my view ATM is that this is overengineering. It allows generic RAID-1 functionality (for high availablity). Isnt HA responsability of the host filesystem?
Re: [Qemu-devel] [PATCH V6 3/4] qmp, nmi: convert do_inject_nmi() to QObject
On 02/24/2011 10:20 AM, Markus Armbruster wrote:
Anthony Liguorialigu...@linux.vnet.ibm.com writes:
On 02/24/2011 02:33 AM, Markus Armbruster wrote:
Anthony Liguorianth...@codemonkey.ws writes:
On 01/27/2011 02:20 AM, Lai Jiangshan wrote:
Make we can inject NMI via qemu-monitor-protocol.
We use inject-nmi for the qmp command name, the meaning is clearer.
Signed-off-by: Lai Jiangshanla...@cn.fujitsu.com
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index ec1a4db..e763bf9 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -725,7 +725,8 @@ ETEXI
.params = [cpu],
.help = Inject an NMI on all CPUs if no argument is given,
otherwise inject it on the specified CPU,
-.mhandler.cmd = do_inject_nmi,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
},
#endif
STEXI
diff --git a/monitor.c b/monitor.c
index 387b020..1b1c0ba 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2542,7 +2542,7 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
#endif
#if defined(TARGET_I386)
-static void do_inject_nmi(Monitor *mon, const QDict *qdict)
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
CPUState *env;
int cpu_index;
@@ -2550,7 +2550,7 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
if (!qdict_haskey(qdict, cpu-index)) {
for (env = first_cpu; env != NULL; env = env-next_cpu)
cpu_interrupt(env, CPU_INTERRUPT_NMI);
-return;
+return 0;
}
cpu_index = qdict_get_int(qdict, cpu-index);
@@ -2560,8 +2560,10 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
kvm_inject_interrupt(env, CPU_INTERRUPT_NMI);
else
cpu_interrupt(env, CPU_INTERRUPT_NMI);
-break;
+return 0;
}
+
+return -1;
}
#endif
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 56c4d8b..a887dd5 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -429,6 +429,34 @@ Example:
EQMP
+#if defined(TARGET_I386)
+{
+.name = inject-nmi,
+.args_type = cpu-index:i?,
+.params = [cpu],
+.help = Inject an NMI on all CPUs if no argument is given,
+ otherwise inject it on the specified CPU,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
+},
+#endif
+SQMP
+inject-nmi
+--
+
+Inject an NMI on all CPUs or the given CPU (x86 only).
+
+Arguments:
+
+- cpu-index: the index of the CPU to be injected NMI (json-int, optional)
+
+Example:
+
+-{ execute: inject-nmi, arguments: { cpu-index: 0 } }
+- { return: {} }
Please describe all expected errors.
Quoting qmp-commands.hx:
3. Errors, in special, are not documented. Applications should NOT check
for specific errors classes or data (it's strongly recommended to only
check for the error key)
Indeed, not a single error is documented there. This is intentional.
Yeah, but we're not 0.14 anymore and for 0.15, we need to document
errors. If you are suggesting I send a patch to remove that section,
I'm more than happy to.
Two separate issues here: 1. Are we ready to commit to the current
design of errors, and 2. Is it fair to reject Lai's patch now because he
doesn't document his errors.
I'm not commenting on 1. here.
Regarding 2.: rejecting a patch because it doesn't document an aspect
that current master intentionally leaves undocumented is not how you
treat contributors. At least not if you want any other than certified
masochists who enjoy pain, and professionals who get adequately
compensated for it.
Lead by example, not by fiat.
http://repo.or.cz/w/qemu/aliguori.git/blob/refs/heads/glib:/qmp-schema.json
I am in the process of documenting the errors of every command. It's a
royal pain but I'm going to document everything we have right now. It's
actually the last bit of work I need to finish before sending QAPI out.
So for new commands being added, it would be hugely helpful for the
authors to document the errors such that I don't have to reverse
engineer all of the possible error conditions.
Once we have an error design in place that has a reasonable hope to
stand the test of time, and have errors documented for at least some of
the commands here, we can start to require proper error documentation
for new commands. But not now.
I'm quite happy with the error design we have today. The only problem
is that we don't propagate errors in a sane way but I've got that all
but fixed in my qapi tree.
I don't think error propagation is the only problem we have with QError.
QError makes it way too hard to emit error messages fit for human
consumption. The consequence is that we get
Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop
On 02/24/2011 10:01 AM, Avi Kivity wrote: On 02/24/2011 01:12 AM, Anthony Liguori wrote: What is the plan from here? 1) Decouple QMP from qemu_machine_init(). This really requires the introduction of the new QAPI server that exists outside of the chardev infrastructure since chardevs are currently initialized in qemu_machine_init(). Is it really necessary? What's blocking us from initializing chardevs early? Well We initialize all chardevs at once right now and what set of chardevs there are depends on the machine (by the way defaults are applied). You could initialize chardevs in two stages although that requires quite a bit of additional complexity. It would be a pity to divorce the monitor from chardevs, they're really flexible. Couple considerations: 1) chardevs don't support multiple simultaneous connections. I view this as a blocker for QMP. 2) Because chardevs don't support multiple connections, we can't reasonably hook on things like connect/disconnect which means that fd's sent via SCM_RIGHTs have to be handled in a very special way. By going outside of the chardev layer, we can let fd's via SCM_RIGHTS queue up naturally and have getfd/setfd refer to the fd at the top of the queue. It makes it quite a bit easier to work with (I believe Daniel had actually requested this a while ago). 3) By treating QMP as a special case, we don't have to treat chardevs overall as a special case. This feels more right to me although I can't say I have a strong opinion formed yet. 2) Make qemu_machine_init() take no parameters and just reference global state. 3) Teach all QMP functions to behave themselves if called before qemu_machine_init() 4) Introduce QMP function to call qemu_machine_init() An alternative is to remove all guest-visible content from qemu_machine_init(). So machine-init() would take no parameters and only build the static devices (power supply?). Everything else would be hot-plugged (perhaps some would fail if the machine was started - cold-plug only). All that qemu_machine_init() is is guest-visible content. That's the point of refactoring this. 5) Introduce new command line flag to not automatically call qemu_machine_init() 6) Convert all command line options to just be QMP function calls (6) can be started right now. (1) comes with the QAPI merge. (2) is pretty easy to do after applying this patch. (3) is probably something that can be done shortly after (1). (4) and (5) really require everything but (6) to be in place before we can meaningful do it. I think we can lay out much of the ground work for this in 0.15 and I think we can have a total conversion realistically for 0.16. That means that by EOY, we could invoke QEMU with no options and do everything through QMP. It's something that I've agitated for a long while, but when I see all the work needed, I'm not sure it's cost effective. There's a lot of secondary benefits that come from doing this. QMP becomes a much stronger interface. A lot of operations that right now are only specifiable by the command line become dynamic which mitigates reboots in the long term. It also lays the ground work for a fully decoupled device model whereas the only interface between the devices and the outside world is a subset of QMP (think seccomp()). Whether creating a machine with no command line options is high value is probably irrelevant. I think we want to go in this direction regardless. Regards, Anthony Liguori
Re: [Xen-devel] Re: [Qemu-devel] [PATCH V10 02/15] xen: Make xen build only on x86 target.
On 02/24/2011 10:25 AM, Anthony PERARD wrote: On Thu, Feb 24, 2011 at 16:11, Anthony Liguorianth...@codemonkey.ws wrote: Is this really necessary? The advantage to building globally is that it keeps the code from getting unnecessary i386-isms. Nop, is not necessary, I add this patch after this mail: http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg00044.html Alex, do you feel strongly here? Regards, Anthony Liguori
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On 02/24/2011 06:39 PM, Marcelo Tosatti wrote: You can live migrate (but not live migrate with live block migration) with live copy in progress, its just that its not supported yet. A RAID-1 driver will work with block live migration too. Nobody cares about that one (block copy and block live migration in progress). In fact, i doubt anybody cares about parallel block migration and block copy either (mgmt can easily cope with that limitation, stop live copy if migration is needed). It's a lot better to have an orthogonal feature set where everything works with everything. These sort of constraints aren't very good, especially as they aren't documented. The code that deals with live migration and live copy may be in different places and now we force the management tool authors to tangle it up. In fact I think a qemu RAID-1 driver removes the restriction that you can't live-migrate and live-copy simultaneously. As mentioned its just an implementation detail. I meant the restriction of live-migrate and live-copy in parallel. I think it's an important one. It moves the code from the generic layer to a driver. Well it is a nice idea, but devil is in the details: - Guest writes must invalidate in progress live copy reads and live copy writes, so you have to maintain a queue for live copy AIO. You just add the locations to a queue and fire them off again when the live copy write returns. - Live copy writes must be aware of in progress guest AIO writes, so you have to maintain a queue for guest AIO. - Guest writes must be mirrored to source and destination. Don't you need to do this for live-copy? Ah, you do it asynchronously from the dirty log. You can do the same with the RAID-1 driver by invalidating the destination block instead of dual-issuing the write. - qemu-img must handle this new format. So my view ATM is that this is overengineering. I believe it will actually be smaller since there's no interfacing with the dirty log. It allows generic RAID-1 functionality (for high availablity). Isnt HA responsability of the host filesystem? So is sparseness, snapshots, etc. Yet we do them in qemu. In a perfect world we'd have just raw files (and use RAID over loop or something for live-copy). -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH V10 06/15] xen: Add the Xen platform pci device
On 02/02/2011 08:49 AM, anthony.per...@citrix.com wrote:
From: Steven Smithssm...@xensource.com
Introduce a new emulated PCI device, specific to fully virtualized Xen
guests. The device is necessary for PV on HVM drivers to work.
Signed-off-by: Steven Smithssm...@xensource.com
Signed-off-by: Anthony PERARDanthony.per...@citrix.com
Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com
---
Makefile.target |1 +
hw/hw.h |3 +
hw/pc_piix.c |4 +
hw/pci_ids.h |2 +
hw/xen.h |2 +
hw/xen_platform.c | 348 +
xen-stub.c|4 +
7 files changed, 364 insertions(+), 0 deletions(-)
create mode 100644 hw/xen_platform.c
diff --git a/Makefile.target b/Makefile.target
index 00bb690..7a4fd72 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -215,6 +215,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o
obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o
obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
+obj-i386-$(CONFIG_XEN) += xen_platform.o
# Inter-VM PCI shared memory
obj-$(CONFIG_KVM) += ivshmem.o
diff --git a/hw/hw.h b/hw/hw.h
index dd993de..298df31 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -672,6 +672,9 @@ extern const VMStateDescription vmstate_i2c_slave;
#define VMSTATE_INT32_LE(_f, _s) \
VMSTATE_SINGLE(_f, _s, 0, vmstate_info_int32_le, int32_t)
+#define VMSTATE_UINT8_TEST(_f, _s, _t) \
+VMSTATE_SINGLE_TEST(_f, _s, _t, 0, vmstate_info_uint8, uint8_t)
+
#define VMSTATE_UINT16_TEST(_f, _s, _t) \
VMSTATE_SINGLE_TEST(_f, _s, _t, 0, vmstate_info_uint16, uint16_t)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0ab8907..765877c 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -120,6 +120,10 @@ static void pc_init1(ram_addr_t ram_size,
pc_vga_init(pci_enabled? pci_bus: NULL);
+if (xen_enabled()) {
+pci_xen_platform_init(pci_bus);
+}
+
/* init basic PC hardware */
pc_basic_device_init(isa_irq,floppy_controller,rtc_state);
diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index ea3418c..6e9eabc 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -108,3 +108,5 @@
#define PCI_DEVICE_ID_INTEL_82371AB 0x7111
#define PCI_DEVICE_ID_INTEL_82371AB_20x7112
#define PCI_DEVICE_ID_INTEL_82371AB_30x7113
+
+#define PCI_VENDOR_ID_XENSOURCE 0x5853
diff --git a/hw/xen.h b/hw/xen.h
index 3984069..53a2ca4 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -29,6 +29,8 @@ static inline int xen_enabled(void)
#endif
}
+void pci_xen_platform_init(PCIBus *bus);
+
int xen_init(int smp_cpus);
#if defined(CONFIG_XEN) CONFIG_XEN_CTRL_INTERFACE_VERSION 400
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
new file mode 100644
index 000..383cfcf
--- /dev/null
+++ b/hw/xen_platform.c
@@ -0,0 +1,348 @@
+/*
+ * XEN platform pci device, formerly known as the event channel device
+ *
+ * Copyright (c) 2003-2004 Intel Corp.
+ * Copyright (c) 2006 XenSource
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include hw.h
+#include pc.h
+#include pci.h
+#include irq.h
+#include xen_common.h
+#include net.h
+#include xen_backend.h
+#include qemu-log.h
+#include rwhandler.h
+
+#includeassert.h
+#includexenguest.h
+
+//#define DEBUG_PLATFORM
+
+#ifdef DEBUG_PLATFORM
+#define DPRINTF(fmt, ...) do { \
+fprintf(stderr, xen_platform: fmt, ## __VA_ARGS__); \
+} while (0)
+#else
+#define DPRINTF(fmt, ...) do { } while (0)
+#endif
+
+#define PFFLAG_ROM_LOCK 1 /* Sets whether ROM memory area is RW or RO */
+
+typedef struct PCIXenPlatformState {
+PCIDevice pci_dev;
+uint8_t flags; /* used only for version_id == 2 */
+int drivers_blacklisted;
+uint16_t driver_product_version;
+
+/* Log from guest drivers */
+char log_buffer[4096];
+
Re: [Qemu-devel] [PATCH V10 05/15] xen: Add xenfv machine
On 02/02/2011 08:49 AM, anthony.per...@citrix.com wrote:
From: Anthony PERARDanthony.per...@citrix.com
Introduce the Xen FV (Fully Virtualized) machine to Qemu, some more Xen
specific call will be added in further patches.
Signed-off-by: Anthony PERARDanthony.per...@citrix.com
---
hw/pc.c | 19 +--
hw/pc_piix.c | 21 -
hw/xen.h |4
3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
index 4dfdc0b..ab9d365 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -41,6 +41,7 @@
#include sysemu.h
#include blockdev.h
#include ui/qemu-spice.h
+#include xen.h
/* output Bochs bios info messages */
//#define DEBUG_BIOS
@@ -906,7 +907,11 @@ static void pc_cpu_reset(void *opaque)
CPUState *env = opaque;
cpu_reset(env);
-env-halted = !cpu_is_bsp(env);
+if (!xen_enabled()) {
+env-halted = !cpu_is_bsp(env);
+} else {
+env-halted = 1;
+}
}
static CPUState *pc_new_cpu(const char *cpu_model)
@@ -940,7 +945,12 @@ void pc_cpus_init(const char *cpu_model)
#endif
}
-for(i = 0; i smp_cpus; i++) {
+if (!xen_enabled()) {
+for(i = 0; i smp_cpus; i++) {
+pc_new_cpu(cpu_model);
+}
+} else {
+/* Xen require only one Qemu VCPU */
pc_new_cpu(cpu_model);
}
}
@@ -968,6 +978,11 @@ void pc_memory_init(ram_addr_t ram_size,
*above_4g_mem_size_p = above_4g_mem_size;
*below_4g_mem_size_p = below_4g_mem_size;
+if (xen_enabled()) {
+/* Nothing to do for Xen */
+return;
+}
+
#if TARGET_PHYS_ADDR_BITS == 32
if (above_4g_mem_size 0) {
hw_error(To much RAM for 32-bit physical address);
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 7b74473..0ab8907 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -36,6 +36,10 @@
#include sysbus.h
#include arch_init.h
#include blockdev.h
+#include xen.h
+#ifdef CONFIG_XEN
+# include xen/hvm/hvm_info_table.h
+#endif
Admittedly a nit, but isn't this a system header?
Regards,
Anthony Liguori
Re: [Qemu-devel] [PATCH V10 07/15] piix_pci: Introduces Xen specific call for irq.
On 02/02/2011 08:49 AM, anthony.per...@citrix.com wrote:
From: Anthony PERARDanthony.per...@citrix.com
This patch introduces Xen specific call in piix_pci.
The specific part for Xen is in write_config, set_irq and get_pirq.
Signed-off-by: Anthony PERARDanthony.per...@citrix.com
Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com
Acked-by: Alexander Grafag...@suse.de
---
hw/piix_pci.c | 28 ++--
hw/xen.h |6 ++
xen-all.c | 31 +++
xen-stub.c| 13 +
4 files changed, 76 insertions(+), 2 deletions(-)
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 358da58..152fcc0 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -29,6 +29,7 @@
#include isa.h
#include sysbus.h
#include range.h
+#include xen.h
/*
* I440FX chipset data sheet.
@@ -151,6 +152,13 @@ static void i440fx_write_config(PCIDevice *dev,
}
}
+static void i440fx_write_config_xen(PCIDevice *dev,
+uint32_t address, uint32_t val, int len)
+{
+xen_piix_pci_write_config_client(address, val, len);
+i440fx_write_config(dev, address, val, len);
+}
+
static int i440fx_load_old(QEMUFile* f, void *opaque, int version_id)
{
PCII440FXState *d = opaque;
@@ -230,13 +238,21 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int
*piix3_devfn, qemu_irq *
s-bus = b;
qdev_init_nofail(dev);
-d = pci_create_simple(b, 0, i440FX);
+if (xen_enabled()) {
+d = pci_create_simple(b, 0, i440FX-xen);
+} else {
+d = pci_create_simple(b, 0, i440FX);
We don't really want to have a device that magically becomes another
device if Xen is enabled.
You should introduce an i440fx_xen_init() and make enough of the code
common here to simply it. We don't want to have if (xen_enabled())'s
sprinkled through the device model.
Regards,
Anthony Liguori
+}
*pi440fx_state = DO_UPCAST(PCII440FXState, dev, d);
piix3 = DO_UPCAST(PIIX3State, dev,
pci_create_simple_multifunction(b, -1, true, PIIX3));
piix3-pic = pic;
-pci_bus_irqs(b, piix3_set_irq, pci_slot_get_pirq, piix3, 4);
+if (xen_enabled()) {
+pci_bus_irqs(b, xen_piix3_set_irq, xen_pci_slot_get_pirq, piix3, 4);
+} else {
+pci_bus_irqs(b, piix3_set_irq, pci_slot_get_pirq, piix3, 4);
+}
(*pi440fx_state)-piix3 = piix3;
*piix3_devfn = piix3-dev.devfn;
@@ -352,6 +368,14 @@ static PCIDeviceInfo i440fx_info[] = {
.init = i440fx_initfn,
.config_write = i440fx_write_config,
},{
+.qdev.name= i440FX-xen,
+.qdev.desc= Host bridge,
+.qdev.size= sizeof(PCII440FXState),
+.qdev.vmsd=vmstate_i440fx,
+.qdev.no_user = 1,
+.init = i440fx_initfn,
+.config_write = i440fx_write_config_xen,
+},{
.qdev.name= PIIX3,
.qdev.desc= ISA bridge,
.qdev.size= sizeof(PIIX3State),
diff --git a/hw/xen.h b/hw/xen.h
index 53a2ca4..2a53f8b 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -8,6 +8,8 @@
*/
#includeinttypes.h
+#include qemu-common.h
+
/* xen-machine.c */
enum xen_mode {
XEN_EMULATE = 0, // xen emulation, using xenner (default)
@@ -29,6 +31,10 @@ static inline int xen_enabled(void)
#endif
}
+int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
+void xen_piix3_set_irq(void *opaque, int irq_num, int level);
+void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len);
+
void pci_xen_platform_init(PCIBus *bus);
int xen_init(int smp_cpus);
diff --git a/xen-all.c b/xen-all.c
index 8d77d42..123decb 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -8,9 +8,40 @@
#include config.h
+#include hw/pci.h
#include hw/xen_common.h
#include hw/xen_backend.h
+/* Xen specific function for piix pci */
+
+int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
+{
+return irq_num + ((pci_dev-devfn 3) 2);
+}
+
+void xen_piix3_set_irq(void *opaque, int irq_num, int level)
+{
+xc_hvm_set_pci_intx_level(xen_xc, xen_domid, 0, 0, irq_num 2,
+ irq_num 3, level);
+}
+
+void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
+{
+int i;
+
+/* Scan for updates to PCI link routes (0x60-0x63). */
+for (i = 0; i len; i++) {
+uint8_t v = (val (8 * i)) 0xff;
+if (v 0x80) {
+v = 0;
+}
+v= 0xf;
+if (((address + i)= 0x60) ((address + i)= 0x63)) {
+xc_hvm_set_pci_link_route(xen_xc, xen_domid, address + i - 0x60,
v);
+}
+}
+}
+
/* Initialise Xen */
int xen_init(int smp_cpus)
diff --git a/xen-stub.c b/xen-stub.c
index a6d5850..ba95537 100644
--- a/xen-stub.c
+++ b/xen-stub.c
@@ -11,6 +11,19 @@
#include qemu-common.h
#include hw/xen.h
+int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
+{
+return -1;
Re: [Qemu-devel] [PATCH V10 06/15] xen: Add the Xen platform pci device
On 02/24/2011 06:33 PM, Anthony Liguori wrote:
On 02/02/2011 08:49 AM, anthony.per...@citrix.com wrote:
From: Steven Smithssm...@xensource.com
Introduce a new emulated PCI device, specific to fully virtualized Xen
guests. The device is necessary for PV on HVM drivers to work.
Signed-off-by: Steven Smithssm...@xensource.com
Signed-off-by: Anthony PERARDanthony.per...@citrix.com
Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com
---
Makefile.target | 1 +
hw/hw.h | 3 +
hw/pc_piix.c | 4 +
hw/pci_ids.h | 2 +
hw/xen.h | 2 +
hw/xen_platform.c | 348
+
xen-stub.c | 4 +
7 files changed, 364 insertions(+), 0 deletions(-)
create mode 100644 hw/xen_platform.c
diff --git a/Makefile.target b/Makefile.target
index 00bb690..7a4fd72 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -215,6 +215,7 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o
obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o
obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o
+obj-i386-$(CONFIG_XEN) += xen_platform.o
# Inter-VM PCI shared memory
obj-$(CONFIG_KVM) += ivshmem.o
diff --git a/hw/hw.h b/hw/hw.h
index dd993de..298df31 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -672,6 +672,9 @@ extern const VMStateDescription vmstate_i2c_slave;
#define VMSTATE_INT32_LE(_f, _s) \
VMSTATE_SINGLE(_f, _s, 0, vmstate_info_int32_le, int32_t)
+#define VMSTATE_UINT8_TEST(_f, _s, _t) \
+ VMSTATE_SINGLE_TEST(_f, _s, _t, 0, vmstate_info_uint8, uint8_t)
+
#define VMSTATE_UINT16_TEST(_f, _s, _t) \
VMSTATE_SINGLE_TEST(_f, _s, _t, 0, vmstate_info_uint16, uint16_t)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 0ab8907..765877c 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -120,6 +120,10 @@ static void pc_init1(ram_addr_t ram_size,
pc_vga_init(pci_enabled? pci_bus: NULL);
+ if (xen_enabled()) {
+ pci_xen_platform_init(pci_bus);
+ }
+
/* init basic PC hardware */
pc_basic_device_init(isa_irq,floppy_controller,rtc_state);
diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index ea3418c..6e9eabc 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -108,3 +108,5 @@
#define PCI_DEVICE_ID_INTEL_82371AB 0x7111
#define PCI_DEVICE_ID_INTEL_82371AB_2 0x7112
#define PCI_DEVICE_ID_INTEL_82371AB_3 0x7113
+
+#define PCI_VENDOR_ID_XENSOURCE 0x5853
diff --git a/hw/xen.h b/hw/xen.h
index 3984069..53a2ca4 100644
--- a/hw/xen.h
+++ b/hw/xen.h
@@ -29,6 +29,8 @@ static inline int xen_enabled(void)
#endif
}
+void pci_xen_platform_init(PCIBus *bus);
+
int xen_init(int smp_cpus);
#if defined(CONFIG_XEN) CONFIG_XEN_CTRL_INTERFACE_VERSION 400
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
new file mode 100644
index 000..383cfcf
--- /dev/null
+++ b/hw/xen_platform.c
@@ -0,0 +1,348 @@
+/*
+ * XEN platform pci device, formerly known as the event channel device
+ *
+ * Copyright (c) 2003-2004 Intel Corp.
+ * Copyright (c) 2006 XenSource
+ *
+ * Permission is hereby granted, free of charge, to any person
obtaining a copy
+ * of this software and associated documentation files (the
Software), to deal
+ * in the Software without restriction, including without limitation
the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include hw.h
+#include pc.h
+#include pci.h
+#include irq.h
+#include xen_common.h
+#include net.h
+#include xen_backend.h
+#include qemu-log.h
+#include rwhandler.h
+
+#includeassert.h
+#includexenguest.h
+
+//#define DEBUG_PLATFORM
+
+#ifdef DEBUG_PLATFORM
+#define DPRINTF(fmt, ...) do { \
+ fprintf(stderr, xen_platform: fmt, ## __VA_ARGS__); \
+} while (0)
+#else
+#define DPRINTF(fmt, ...) do { } while (0)
+#endif
+
+#define PFFLAG_ROM_LOCK 1 /* Sets whether ROM memory area is RW or RO */
+
+typedef struct PCIXenPlatformState {
+ PCIDevice pci_dev;
+ uint8_t flags; /* used only for version_id == 2 */
+ int drivers_blacklisted;
+ uint16_t driver_product_version;
+
+ /* Log from guest drivers */
+ char log_buffer[4096];
+ int log_buffer_off;
+} PCIXenPlatformState;
+
+#define XEN_PLATFORM_IOPORT 0x10
+
+/* Send bytes to syslog */
+static void log_writeb(PCIXenPlatformState *s, char val)
+{
+ if (val == '\n' || s-log_buffer_off == sizeof(s-log_buffer) - 1) {
+
Re: [Qemu-devel] [PATCH V10 03/15] xen: Support new libxc calls from xen unstable.
On 02/02/2011 08:49 AM, anthony.per...@citrix.com wrote:
From: Anthony PERARDanthony.per...@citrix.com
This patch adds a generic layer for xc calls, allowing us to choose between the
xenner and xen implementations at runtime.
It also update the libxenctrl calls in Qemu to use the new interface,
otherwise Qemu wouldn't be able to build against new versions of the
library.
We check libxenctrl version in configure, from Xen 3.3.0 to Xen
unstable.
Signed-off-by: Anthony PERARDanthony.per...@citrix.com
Signed-off-by: Stefano Stabellinistefano.stabell...@eu.citrix.com
Acked-by: Alexander Grafag...@suse.de
---
Makefile.target |3 +
configure| 62 +++-
hw/xen_backend.c | 74 ++-
hw/xen_backend.h |7 +-
hw/xen_common.h | 38 ++
hw/xen_console.c | 10 +-
hw/xen_devconfig.c | 10 +-
hw/xen_disk.c| 28 ---
hw/xen_domainbuild.c | 29
hw/xen_interfaces.c | 191
hw/xen_interfaces.h | 198 ++
hw/xen_nic.c | 36 +-
hw/xenfb.c | 14 ++--
13 files changed, 584 insertions(+), 116 deletions(-)
create mode 100644 hw/xen_interfaces.c
create mode 100644 hw/xen_interfaces.h
diff --git a/Makefile.target b/Makefile.target
index db29e96..d09719f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -205,6 +205,9 @@ QEMU_CFLAGS += $(VNC_SASL_CFLAGS)
QEMU_CFLAGS += $(VNC_JPEG_CFLAGS)
QEMU_CFLAGS += $(VNC_PNG_CFLAGS)
+# xen support
+obj-$(CONFIG_XEN) += xen_interfaces.o
+
# xen backend driver support
obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o
obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o
diff --git a/configure b/configure
index 5a9121d..fde9bad 100755
--- a/configure
+++ b/configure
@@ -126,6 +126,7 @@ vnc_jpeg=
vnc_png=
vnc_thread=no
xen=
+xen_ctrl_version=
linux_aio=
attr=
vhost_net=
@@ -1144,13 +1145,71 @@ fi
if test $xen != no ; then
xen_libs=-lxenstore -lxenctrl -lxenguest
+
+ # Xen unstable
cat $TMPCEOF
#includexenctrl.h
#includexs.h
-int main(void) { xs_daemon_open(); xc_interface_open(); return 0; }
+#includestdint.h
+#includexen/hvm/hvm_info_table.h
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+ xc_interface *xc;
+ xs_daemon_open();
+ xc = xc_interface_open(0, 0, 0);
+ xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+ xc_gnttab_open(NULL, 0);
+ return 0;
+}
EOF
if compile_prog $xen_libs ; then
+xen_ctrl_version=410
+xen=yes
+
+ # Xen 4.0.0
+ elif (
+ cat $TMPCEOF
+#includexenctrl.h
+#includexs.h
+#includestdint.h
+#includexen/hvm/hvm_info_table.h
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+ xs_daemon_open();
+ xc_interface_open();
+ xc_gnttab_open();
+ xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+ return 0;
+}
+EOF
+ compile_prog $xen_libs
+) ; then
+xen_ctrl_version=400
+xen=yes
+
+ # Xen 3.3.0, 3.4.0
+ elif (
+ cat $TMPCEOF
+#includexenctrl.h
+#includexs.h
+int main(void) {
+ xs_daemon_open();
+ xc_interface_open();
+ xc_gnttab_open();
+ xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+ return 0;
+}
+EOF
+ compile_prog $xen_libs
+) ; then
+xen_ctrl_version=330
xen=yes
+
+ # Xen not found or unsupported
else
if test $xen = yes ; then
feature_not_found xen
@@ -3009,6 +3068,7 @@ case $target_arch2 in
if test $xen = yes -a $target_softmmu = yes ; then
echo CONFIG_XEN=y $config_target_mak
echo LIBS+=$xen_libs $config_target_mak
+ echo CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version
$config_target_mak
fi
esac
case $target_arch2 in
diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 860b038..cf081e1 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -43,7 +43,8 @@
/* - */
/* public */
-int xen_xc;
+XenXC xen_xc = XC_HANDLER_INITIAL_VALUE;
+XenGnttab xen_xcg = XC_HANDLER_INITIAL_VALUE;
struct xs_handle *xenstore = NULL;
const char *xen_protocol;
@@ -58,7 +59,7 @@ int xenstore_write_str(const char *base, const char *node,
const char *val)
char abspath[XEN_BUFSIZE];
snprintf(abspath, sizeof(abspath), %s/%s, base, node);
-if (!xs_write(xenstore, 0, abspath, val, strlen(val)))
+if (!xs_ops.write(xenstore, 0, abspath, val, strlen(val)))
return -1;
return 0;
}
@@ -70,7 +71,7 @@ char *xenstore_read_str(const char *base, const char *node)
char *str, *ret = NULL;
snprintf(abspath, sizeof(abspath), %s/%s, base, node);
-str = xs_read(xenstore, 0, abspath,len);
+str = xs_ops.read(xenstore, 0, abspath,len);
I think I gave this feedback before but I'd really like to see static
inlines here.
It's very likely that you'll either
Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
On 02/24/2011 10:39 AM, Marcelo Tosatti wrote: On Thu, Feb 24, 2011 at 05:28:20PM +0200, Avi Kivity wrote: On 02/24/2011 05:14 PM, Marcelo Tosatti wrote: The problem with qemu config files is that it splits the authoritative source of where images are stored into two. Is it in the management tool's database or is it in qemu's config file? For the problem at hand, one solution is to make qemu stop after the copy, and then management can issue an additional command to rearrange the disk and resume the guest. A drawback here is that if management dies, the guest is stopped until it restarts. We also make management latency guest visible, even if it doesn't die at an inconvenient place. An alternative approach is to have the copy be performed by a new layered block format driver: - create a new image, type = live-copy, containing three pieces of information - source image - destination image - copy state (initially nothing is copied) - tell qemu switch to the new image There is a similar situation with atomicity here. Mgmt app requests a switch and dies immediately, before receiving the command reply. Qemu crashes. Which image is the uptodate one, source or live-copy? live-copy (or it's new name, RAID-1). Once you've created it it is equivalent to source. Once it switches to state=synced you can switch back to either source or destination (I guess by telling qemu to detach the one you don't want first, so it falls back to state=degraded). You could hot-unplug the image and hot-plug it later (continuing the copy with qemu-img), Then there's no need for live copy. qemu-img does that already. It will start from the beginning. or live migrate it. You can live migrate (but not live migrate with live block migration) with live copy in progress, its just that its not supported yet. A RAID-1 driver will work with block live migration too. Nobody cares about that one (block copy and block live migration in progress). In fact, i doubt anybody cares about parallel block migration and block copy either (mgmt can easily cope with that limitation, stop live copy if migration is needed). In fact I think a qemu RAID-1 driver removes the restriction that you can't live-migrate and live-copy simultaneously. As mentioned its just an implementation detail. I meant the restriction of live-migrate and live-copy in parallel. I think it's an important one. It moves the code from the generic layer to a driver. Well it is a nice idea, but devil is in the details: - Guest writes must invalidate in progress live copy reads and live copy writes, so you have to maintain a queue for live copy AIO. - Live copy writes must be aware of in progress guest AIO writes, so you have to maintain a queue for guest AIO. - Guest writes must be mirrored to source and destination. - qemu-img must handle this new format. So my view ATM is that this is overengineering. Yeah, it feels like we're introducing QEMU level RAID. At what point are we going to add RAID5 support and not just RAID1. And it certainly begs the question of whether this use-case can be satisfied by just using Linux's RAID stack leaving one drive degraded and enabling the other drive when the time comes to fail over. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH V10 00/15] Xen device model support
On 02/02/2011 08:49 AM, anthony.per...@citrix.com wrote: From: Anthony PERARDanthony.per...@citrix.com Hi, There is a lot of change since the V9 of the Xen device model. One of theme is to use the 'pc' machine for Xen instead of duplicate this machine in another file. Here is the change since the last version: - typedef of qemu_xc_interface, qemu_xc_gnttab and qemu_xc_evtchn have been renamed to XenXC, XenGnttab and XenEvtchn; - replace asprintf by snprintf; - rename Xen i8259 to Xen Interrupt Controller; - remove xen_redirect.h file and replace all Xen calls to use xen_interfaces calls; - add copyright header in some files; - in mapcache, use RLIMIT_AS to have the max mapcache size, instead of have a max depends on the architecture; - in mapcache, set rlimit_as.rlim_cur = rlimit_as.rlim_max; - in xen platform pci device, removed the throttle; - qemu_ram_ptr_unlock renamed to qemu_put_ram_ptr; - put specific xen calls into pc_piix and xen_machine_fv have been removed; - fix few coding style. This series depends on the series Introduce machine QemuOpts. Looks pretty good minus the few comments I made! Regards, Anthony Liguori You can find a git tree here: git://xenbits.xen.org/people/aperard/qemu-dm.git qemu-dm-v10 Anthony PERARD (12): xen: Replace some tab-indents with spaces (clean-up). xen: Make xen build only on x86 target. xen: Support new libxc calls from xen unstable. xen: Add initialisation of Xen xen: Add xenfv machine piix_pci: Introduces Xen specific call for irq. xen: Introduce Xen Interrupt Controller configure: Always use 64bits target physical addresses with xen enabled. Introduce qemu_put_ram_ptr vl.c: Introduce getter for shutdown_requested and reset_requested. xen: Set running state in xenstore. xen: Add Xen hypercall for sleep state in the cmos_s3 callback. Arun Sharma (1): xen: Initialize event channels and io rings Jun Nakajima (1): xen: Introduce the Xen mapcache Steven Smith (1): xen: Add the Xen platform pci device Makefile.objs|4 - Makefile.target | 14 ++- configure| 71 ++- cpu-common.h |1 + exec.c | 50 - hw/hw.h |3 + hw/pc.c | 19 ++- hw/pc_piix.c | 39 +++- hw/pci_ids.h |2 + hw/piix_pci.c| 28 +++- hw/xen.h | 41 hw/xen_backend.c | 372 hw/xen_backend.h |7 +- hw/xen_common.h | 40 +++-- hw/xen_console.c | 10 +- hw/xen_devconfig.c | 10 +- hw/xen_disk.c| 402 ++- hw/xen_domainbuild.c | 29 ++-- hw/xen_interfaces.c | 191 + hw/xen_interfaces.h | 198 + hw/xen_nic.c | 230 ++-- hw/xen_platform.c| 348 ++ hw/xenfb.c | 14 +- sysemu.h |2 + vl.c | 12 + xen-all.c| 579 ++ xen-mapcache-stub.c | 40 xen-mapcache.c | 344 ++ xen-mapcache.h | 22 ++ xen-stub.c | 47 30 files changed, 2599 insertions(+), 570 deletions(-) create mode 100644 hw/xen_interfaces.c create mode 100644 hw/xen_interfaces.h create mode 100644 hw/xen_platform.c create mode 100644 xen-all.c create mode 100644 xen-mapcache-stub.c create mode 100644 xen-mapcache.c create mode 100644 xen-mapcache.h create mode 100644 xen-stub.c
Re: [Xen-devel] Re: [Qemu-devel] [PATCH V10 02/15] xen: Make xen build only on x86 target.
On 2011-02-24 18:27, Anthony Liguori wrote: On 02/24/2011 10:25 AM, Anthony PERARD wrote: On Thu, Feb 24, 2011 at 16:11, Anthony Liguorianth...@codemonkey.ws wrote: Is this really necessary? The advantage to building globally is that it keeps the code from getting unnecessary i386-isms. Nop, is not necessary, I add this patch after this mail: http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg00044.html Alex, do you feel strongly here? I'm not Alex, but I brought this issue up: Either build xen bits once for all archs or restrict it to the only foreseeable arch with support in qemu. But please don't built it for each and every target separately. BTW: index b0ba95f..db29e96 100644 --- a/Makefile.target +++ b/Makefile.target @@ -206,7 +206,9 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS) QEMU_CFLAGS += $(VNC_PNG_CFLAGS) # xen backend driver support -obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o +obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o +obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o +obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o Why restricting the last line to i386? Doesn't CONFIG_XEN also control here if the arch is xen-capable? Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH 55/58] piix4: create PIIX4State
It only contains a PCIDevice by know, but it makes easy to use migration code
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/piix4.c | 29 +
1 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/hw/piix4.c b/hw/piix4.c
index 72073cd..40cd91a 100644
--- a/hw/piix4.c
+++ b/hw/piix4.c
@@ -30,10 +30,14 @@
PCIDevice *piix4_dev;
+typedef struct PIIX4State {
+PCIDevice dev;
+} PIIX4State;
+
static void piix4_reset(void *opaque)
{
-PCIDevice *d = opaque;
-uint8_t *pci_conf = d-config;
+PIIX4State *d = opaque;
+uint8_t *pci_conf = d-dev.config;
pci_conf[0x04] = 0x07; // master, memory and I/O
pci_conf[0x05] = 0x00;
@@ -70,31 +74,32 @@ static void piix4_reset(void *opaque)
static void piix_save(QEMUFile* f, void *opaque)
{
-PCIDevice *d = opaque;
-pci_device_save(d, f);
+PIIX4State *d = opaque;
+pci_device_save(d-dev, f);
}
static int piix_load(QEMUFile* f, void *opaque, int version_id)
{
-PCIDevice *d = opaque;
+PIIX4State *d = opaque;
if (version_id != 2)
return -EINVAL;
-return pci_device_load(d, f);
+return pci_device_load(d-dev, f);
}
-static int piix4_initfn(PCIDevice *d)
+static int piix4_initfn(PCIDevice *dev)
{
+PIIX4State *d = DO_UPCAST(PIIX4State, dev, dev);
uint8_t *pci_conf;
-isa_bus_new(d-qdev);
-register_savevm(d-qdev, PIIX4, 0, 2, piix_save, piix_load, d);
+isa_bus_new(d-dev.qdev);
+register_savevm(d-dev.qdev, PIIX4, 0, 2, piix_save, piix_load, d);
-pci_conf = d-config;
+pci_conf = d-dev.config;
pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_INTEL);
pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_INTEL_82371AB_0); //
82371AB/EB/MB PIIX4 PCI-to-ISA bridge
pci_config_set_class(pci_conf, PCI_CLASS_BRIDGE_ISA);
-piix4_dev = d;
+piix4_dev = d-dev;
qemu_register_reset(piix4_reset, d);
return 0;
}
@@ -111,7 +116,7 @@ static PCIDeviceInfo piix4_info[] = {
{
.qdev.name= PIIX4,
.qdev.desc= ISA bridge,
-.qdev.size= sizeof(PCIDevice),
+.qdev.size= sizeof(PIIX4State),
.qdev.no_user = 1,
.no_hotplug = 1,
.init = piix4_initfn,
--
1.7.4
[Qemu-devel] [PATCH 56/58] vmstate: port piix4
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/piix4.c | 25 +++--
1 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/hw/piix4.c b/hw/piix4.c
index 40cd91a..71f1f84 100644
--- a/hw/piix4.c
+++ b/hw/piix4.c
@@ -72,19 +72,16 @@ static void piix4_reset(void *opaque)
pci_conf[0xae] = 0x00;
}
-static void piix_save(QEMUFile* f, void *opaque)
-{
-PIIX4State *d = opaque;
-pci_device_save(d-dev, f);
-}
-
-static int piix_load(QEMUFile* f, void *opaque, int version_id)
-{
-PIIX4State *d = opaque;
-if (version_id != 2)
-return -EINVAL;
-return pci_device_load(d-dev, f);
-}
+static const VMStateDescription vmstate_piix4 = {
+.name = PIIX4,
+.version_id = 2,
+.minimum_version_id = 2,
+.minimum_version_id_old = 2,
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(dev, PIIX4State),
+VMSTATE_END_OF_LIST()
+}
+};
static int piix4_initfn(PCIDevice *dev)
{
@@ -92,7 +89,6 @@ static int piix4_initfn(PCIDevice *dev)
uint8_t *pci_conf;
isa_bus_new(d-dev.qdev);
-register_savevm(d-dev.qdev, PIIX4, 0, 2, piix_save, piix_load, d);
pci_conf = d-dev.config;
pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_INTEL);
@@ -117,6 +113,7 @@ static PCIDeviceInfo piix4_info[] = {
.qdev.name= PIIX4,
.qdev.desc= ISA bridge,
.qdev.size= sizeof(PIIX4State),
+.qdev.vmsd= vmstate_piix4,
.qdev.no_user = 1,
.no_hotplug = 1,
.init = piix4_initfn,
--
1.7.4
[Qemu-devel] [PATCH 57/58] mac_dbdma: create DBDMAState instead of passing one array around
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/mac_dbdma.c | 45 +++--
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/hw/mac_dbdma.c b/hw/mac_dbdma.c
index 5680fa9..c108aee 100644
--- a/hw/mac_dbdma.c
+++ b/hw/mac_dbdma.c
@@ -165,6 +165,10 @@ typedef struct DBDMA_channel {
int processing;
} DBDMA_channel;
+typedef struct {
+DBDMA_channel channels[DBDMA_CHANNELS];
+} DBDMAState;
+
#ifdef DEBUG_DBDMA
static void dump_dbdma_cmd(dbdma_cmd *cmd)
{
@@ -617,31 +621,34 @@ static void channel_run(DBDMA_channel *ch)
}
}
-static void DBDMA_run (DBDMA_channel *ch)
+static void DBDMA_run(DBDMAState *s)
{
int channel;
-for (channel = 0; channel DBDMA_CHANNELS; channel++, ch++) {
-uint32_t status = ch-regs[DBDMA_STATUS];
-if (!ch-processing (status RUN) (status ACTIVE))
-channel_run(ch);
+for (channel = 0; channel DBDMA_CHANNELS; channel++) {
+DBDMA_channel *ch = s-channels[channel];
+uint32_t status = ch-regs[DBDMA_STATUS];
+if (!ch-processing (status RUN) (status ACTIVE)) {
+channel_run(ch);
+}
}
}
static void DBDMA_run_bh(void *opaque)
{
-DBDMA_channel *ch = opaque;
+DBDMAState *s = opaque;
DBDMA_DPRINTF(DBDMA_run_bh\n);
-DBDMA_run(ch);
+DBDMA_run(s);
}
void DBDMA_register_channel(void *dbdma, int nchan, qemu_irq irq,
DBDMA_rw rw, DBDMA_flush flush,
void *opaque)
{
-DBDMA_channel *ch = ( DBDMA_channel *)dbdma + nchan;
+DBDMAState *s = dbdma;
+DBDMA_channel *ch = s-channels[nchan];
DBDMA_DPRINTF(DBDMA_register_channel 0x%x\n, nchan);
@@ -700,7 +707,8 @@ static void dbdma_writel (void *opaque,
target_phys_addr_t addr, uint32_t value)
{
int channel = addr DBDMA_CHANNEL_SHIFT;
-DBDMA_channel *ch = (DBDMA_channel *)opaque + channel;
+DBDMAState *s = opaque;
+DBDMA_channel *ch = s-channels[channel];
int reg = (addr - (channel DBDMA_CHANNEL_SHIFT)) 2;
DBDMA_DPRINTF(writel 0x TARGET_FMT_plx = 0x%08x\n, addr, value);
@@ -749,7 +757,8 @@ static uint32_t dbdma_readl (void *opaque,
target_phys_addr_t addr)
{
uint32_t value;
int channel = addr DBDMA_CHANNEL_SHIFT;
-DBDMA_channel *ch = (DBDMA_channel *)opaque + channel;
+DBDMAState *s = opaque;
+DBDMA_channel *ch = s-channels[channel];
int reg = (addr - (channel DBDMA_CHANNEL_SHIFT)) 2;
value = ch-regs[reg];
@@ -803,17 +812,17 @@ static CPUReadMemoryFunc * const dbdma_read[] = {
static void dbdma_save(QEMUFile *f, void *opaque)
{
-DBDMA_channel *s = opaque;
+DBDMAState *s = opaque;
unsigned int i, j;
for (i = 0; i DBDMA_CHANNELS; i++)
for (j = 0; j DBDMA_REGS; j++)
-qemu_put_be32s(f, s[i].regs[j]);
+qemu_put_be32s(f, s-channels[i].regs[j]);
}
static int dbdma_load(QEMUFile *f, void *opaque, int version_id)
{
-DBDMA_channel *s = opaque;
+DBDMAState *s = opaque;
unsigned int i, j;
if (version_id != 2)
@@ -821,25 +830,25 @@ static int dbdma_load(QEMUFile *f, void *opaque, int
version_id)
for (i = 0; i DBDMA_CHANNELS; i++)
for (j = 0; j DBDMA_REGS; j++)
-qemu_get_be32s(f, s[i].regs[j]);
+qemu_get_be32s(f, s-channels[i].regs[j]);
return 0;
}
static void dbdma_reset(void *opaque)
{
-DBDMA_channel *s = opaque;
+DBDMAState *s = opaque;
int i;
for (i = 0; i DBDMA_CHANNELS; i++)
-memset(s[i].regs, 0, DBDMA_SIZE);
+memset(s-channels[i].regs, 0, DBDMA_SIZE);
}
void* DBDMA_init (int *dbdma_mem_index)
{
-DBDMA_channel *s;
+DBDMAState *s;
-s = qemu_mallocz(sizeof(DBDMA_channel) * DBDMA_CHANNELS);
+s = qemu_mallocz(sizeof(DBDMAState));
*dbdma_mem_index = cpu_register_io_memory(dbdma_read, dbdma_write, s,
DEVICE_LITTLE_ENDIAN);
--
1.7.4
[Qemu-devel] [PATCH 58/58] vmstate: port mac_dbdma
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/mac_dbdma.c | 46 ++
1 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/hw/mac_dbdma.c b/hw/mac_dbdma.c
index c108aee..3522552 100644
--- a/hw/mac_dbdma.c
+++ b/hw/mac_dbdma.c
@@ -810,30 +810,28 @@ static CPUReadMemoryFunc * const dbdma_read[] = {
dbdma_readl,
};
-static void dbdma_save(QEMUFile *f, void *opaque)
-{
-DBDMAState *s = opaque;
-unsigned int i, j;
-
-for (i = 0; i DBDMA_CHANNELS; i++)
-for (j = 0; j DBDMA_REGS; j++)
-qemu_put_be32s(f, s-channels[i].regs[j]);
-}
-
-static int dbdma_load(QEMUFile *f, void *opaque, int version_id)
-{
-DBDMAState *s = opaque;
-unsigned int i, j;
-
-if (version_id != 2)
-return -EINVAL;
-
-for (i = 0; i DBDMA_CHANNELS; i++)
-for (j = 0; j DBDMA_REGS; j++)
-qemu_get_be32s(f, s-channels[i].regs[j]);
+static const VMStateDescription vmstate_dbdma_channel = {
+.name = dbdma_channel,
+.version_id = 0,
+.minimum_version_id = 0,
+.minimum_version_id_old = 0,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32_ARRAY(regs, struct DBDMA_channel, DBDMA_REGS),
+VMSTATE_END_OF_LIST()
+}
+};
-return 0;
-}
+static const VMStateDescription vmstate_dbdma = {
+.name = dbdma,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_STRUCT_ARRAY(channels, DBDMAState, DBDMA_CHANNELS, 1,
+ vmstate_dbdma_channel, DBDMA_channel),
+VMSTATE_END_OF_LIST()
+}
+};
static void dbdma_reset(void *opaque)
{
@@ -852,7 +850,7 @@ void* DBDMA_init (int *dbdma_mem_index)
*dbdma_mem_index = cpu_register_io_memory(dbdma_read, dbdma_write, s,
DEVICE_LITTLE_ENDIAN);
-register_savevm(NULL, dbdma, -1, 1, dbdma_save, dbdma_load, s);
+vmstate_register(NULL, -1, vmstate_dbdma, s);
qemu_register_reset(dbdma_reset, s);
dbdma_bh = qemu_bh_new(DBDMA_run_bh, s);
--
1.7.4
Re: [Xen-devel] Re: [Qemu-devel] [PATCH V10 02/15] xen: Make xen build only on x86 target.
On 02/24/2011 11:46 AM, Jan Kiszka wrote: On 2011-02-24 18:27, Anthony Liguori wrote: On 02/24/2011 10:25 AM, Anthony PERARD wrote: On Thu, Feb 24, 2011 at 16:11, Anthony Liguorianth...@codemonkey.ws wrote: Is this really necessary? The advantage to building globally is that it keeps the code from getting unnecessary i386-isms. Nop, is not necessary, I add this patch after this mail: http://lists.nongnu.org/archive/html/qemu-devel/2010-12/msg00044.html Alex, do you feel strongly here? I'm not Alex, but I brought this issue up: Either build xen bits once for all archs or restrict it to the only foreseeable arch with support in qemu. But please don't built it for each and every target separately. Oh yes, I misunderstood. I thought we had previously built it for all architectures. Yes, we should only build it once. Regards, Anthony Liguori BTW: index b0ba95f..db29e96 100644 --- a/Makefile.target +++ b/Makefile.target @@ -206,7 +206,9 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS) QEMU_CFLAGS += $(VNC_PNG_CFLAGS) # xen backend driver support -obj-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o +obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o +obj-$(CONFIG_XEN) += xen_console.o xenfb.o xen_disk.o xen_nic.o +obj-i386-$(CONFIG_XEN) += xen_machine_pv.o xen_domainbuild.o Why restricting the last line to i386? Doesn't CONFIG_XEN also control here if the arch is xen-capable? Thanks, Jan
[Qemu-devel] Re: [PATCH] ui/vnc-enc-tight.c: Fix compile failure if CONFIG_VNC_JPEG not defined
On 02/24/2011 10:04 AM, Peter Maydell wrote:
Add some missing #ifdefs to fix compilation failures in the !CONFIG_VNC_JPEG
case introduced by commit ce702e93.
Signed-off-by: Peter Maydellpeter.mayd...@linaro.org
Applied. Thanks.
Regards,
Anthony Liguori
---
ui/vnc-enc-tight.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c
index 5933394..2522936 100644
--- a/ui/vnc-enc-tight.c
+++ b/ui/vnc-enc-tight.c
@@ -1536,8 +1536,10 @@ static int send_sub_rect(VncState *vs, int x, int y, int
w, int h)
uint32_t bg = 0, fg = 0;
int colors;
int ret = 0;
+#ifdef CONFIG_VNC_JPEG
bool force_jpeg = false;
bool allow_jpeg = true;
+#endif
vnc_framebuffer_update(vs, x, y, w, h, vs-tight.type);
@@ -1711,6 +1713,7 @@ static int tight_send_framebuffer_update(VncState *vs,
int x, int y,
vs-tight.pixel24 = false;
}
+#ifdef CONFIG_VNC_JPEG
if (vs-tight.quality != (uint8_t)-1) {
double freq = vnc_update_freq(vs, x, y, w, h);
@@ -1718,6 +1721,7 @@ static int tight_send_framebuffer_update(VncState *vs,
int x, int y,
return send_rect_simple(vs, x, y, w, h, false);
}
}
+#endif
if (w * h VNC_TIGHT_MIN_SPLIT_RECT_SIZE) {
return send_rect_simple(vs, x, y, w, h, true);
Re: [Qemu-devel] [PATCH] Add TAGS and *~ to .gitignore
On 02/23/2011 11:34 PM, David Gibson wrote: Add the etags output generated by make TAGS and editor backup files to .gitignore. This patch has previously appeared in my series of patches to add pSeries emulation support. However, it obviously has no real connection to that, and can be applied seperately. Please apply. Signed-off-by: David Gibsonda...@gibson.dropbear.id.au Applied. Thanks. Regards, Anthony Liguori --- .gitignore |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 26703e1..1d79680 100644 --- a/.gitignore +++ b/.gitignore @@ -63,3 +63,5 @@ pc-bios/optionrom/multiboot.raw .stgit-* cscope.* tags +TAGS +*~
Re: [Qemu-devel] [RESEND][REBASE] [PATCH] virtio-serial: kill VirtIOSerialDevice
On 02/23/2011 11:44 PM, Amit Shah wrote:
From: Gerd Hoffmannkra...@redhat.com
VirtIOSerialDevice is like VirtIOSerialPort with just the first two
fields, which makes it pretty pointless. Using VirtIOSerialPort
directly works equally well and is less confusing.
[Amit: - rebase
- rename 'dev' to 'port' in function params in virtio-serial.h ]
Signed-off-by: Gerd Hoffmannkra...@redhat.com
Signed-off-by: Amit Shahamit.s...@redhat.com
Applied. Thanks.
Regards,
Anthony Liguori
---
hw/virtio-console.c| 17 ++---
hw/virtio-serial-bus.c | 15 ++-
hw/virtio-serial.h |9 ++---
3 files changed, 14 insertions(+), 27 deletions(-)
diff --git a/hw/virtio-console.c b/hw/virtio-console.c
index 62624ec..c235b27 100644
--- a/hw/virtio-console.c
+++ b/hw/virtio-console.c
@@ -57,10 +57,8 @@ static void chr_event(void *opaque, int event)
}
}
-static int generic_port_init(VirtConsole *vcon, VirtIOSerialDevice *dev)
+static int generic_port_init(VirtConsole *vcon, VirtIOSerialPort *port)
{
-vcon-port.info = dev-info;
-
if (vcon-chr) {
qemu_chr_add_handlers(vcon-chr, chr_can_read, chr_read, chr_event,
vcon);
@@ -70,18 +68,16 @@ static int generic_port_init(VirtConsole *vcon,
VirtIOSerialDevice *dev)
}
/* Virtio Console Ports */
-static int virtconsole_initfn(VirtIOSerialDevice *dev)
+static int virtconsole_initfn(VirtIOSerialPort *port)
{
-VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev,dev-qdev);
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
port-is_console = true;
-return generic_port_init(vcon, dev);
+return generic_port_init(vcon, port);
}
-static int virtconsole_exitfn(VirtIOSerialDevice *dev)
+static int virtconsole_exitfn(VirtIOSerialPort *port)
{
-VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev,dev-qdev);
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
if (vcon-chr) {
@@ -113,12 +109,11 @@ static void virtconsole_register(void)
device_init(virtconsole_register)
/* Generic Virtio Serial Ports */
-static int virtserialport_initfn(VirtIOSerialDevice *dev)
+static int virtserialport_initfn(VirtIOSerialPort *port)
{
-VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev,dev-qdev);
VirtConsole *vcon = DO_UPCAST(VirtConsole, port, port);
-return generic_port_init(vcon, dev);
+return generic_port_init(vcon, port);
}
static VirtIOSerialPortInfo virtserialport_info = {
diff --git a/hw/virtio-serial-bus.c b/hw/virtio-serial-bus.c
index e05ab5e..8446bc2 100644
--- a/hw/virtio-serial-bus.c
+++ b/hw/virtio-serial-bus.c
@@ -658,8 +658,7 @@ static VirtIOSerialBus *virtser_bus_new(DeviceState *dev)
static void virtser_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent)
{
-VirtIOSerialDevice *dev = DO_UPCAST(VirtIOSerialDevice, qdev, qdev);
-VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev,dev-qdev);
+VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev, qdev);
monitor_printf(mon, %*s dev-prop-int: id: %u\n,
indent, , port-id);
@@ -721,9 +720,8 @@ static void remove_port(VirtIOSerial *vser, uint32_t
port_id)
static int virtser_port_qdev_init(DeviceState *qdev, DeviceInfo *base)
{
-VirtIOSerialDevice *dev = DO_UPCAST(VirtIOSerialDevice, qdev, qdev);
+VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev, qdev);
VirtIOSerialPortInfo *info = DO_UPCAST(VirtIOSerialPortInfo, qdev, base);
-VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev,dev-qdev);
VirtIOSerialBus *bus = DO_UPCAST(VirtIOSerialBus, qbus, qdev-parent_bus);
int ret;
bool plugging_port0;
@@ -761,8 +759,8 @@ static int virtser_port_qdev_init(DeviceState *qdev,
DeviceInfo *base)
return -1;
}
-dev-info = info;
-ret = info-init(dev);
+port-info = info;
+ret = info-init(port);
if (ret) {
return ret;
}
@@ -791,8 +789,7 @@ static int virtser_port_qdev_init(DeviceState *qdev,
DeviceInfo *base)
static int virtser_port_qdev_exit(DeviceState *qdev)
{
-VirtIOSerialDevice *dev = DO_UPCAST(VirtIOSerialDevice, qdev, qdev);
-VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev,dev-qdev);
+VirtIOSerialPort *port = DO_UPCAST(VirtIOSerialPort, dev, qdev);
VirtIOSerial *vser = port-vser;
remove_port(port-vser, port-id);
@@ -800,7 +797,7 @@ static int virtser_port_qdev_exit(DeviceState *qdev)
QTAILQ_REMOVE(vser-ports, port, next);
if (port-info-exit)
-port-info-exit(dev);
+port-info-exit(port);
return 0;
}
diff --git a/hw/virtio-serial.h b/hw/virtio-serial.h
index a308196..8cb9fbe 100644
--- a/hw/virtio-serial.h
+++ b/hw/virtio-serial.h
@@ -62,11 +62,6 @@ typedef struct VirtIOSerialBus VirtIOSerialBus;
typedef struct VirtIOSerialPort VirtIOSerialPort;
typedef struct VirtIOSerialPortInfo
[Qemu-devel] [PATCH 06/58] vmstate: add VMSTATE_STRUCT_VARRAY_UINT32
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/hw.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index d439a6d..af88460 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -519,6 +519,16 @@ extern const VMStateInfo vmstate_info_unused_buffer;
.offset = offsetof(_state, _field), \
}
+#define VMSTATE_STRUCT_VARRAY_UINT32(_field, _state, _field_num, _version,
_vmsd, _type) { \
+.name = (stringify(_field)), \
+.num_offset = vmstate_offset_value(_state, _field_num, uint32_t), \
+.version_id = (_version),\
+.vmsd = (_vmsd), \
+.size = sizeof(_type), \
+.flags = VMS_STRUCT|VMS_VARRAY_UINT32, \
+.offset = offsetof(_state, _field), \
+}
+
#define VMSTATE_STATIC_BUFFER(_field, _state, _version, _test, _start, _size)
{ \
.name = (stringify(_field)), \
.version_id = (_version), \
--
1.7.4
[Qemu-devel] [PATCH 04/58] vmstate: add VMSTATE_STRUCT_VARRAY_INT32
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/hw.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index bff56e1..923efc9 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -508,6 +508,17 @@ extern const VMStateInfo vmstate_info_unused_buffer;
.offset = offsetof(_state, _field), \
}
+
+#define VMSTATE_STRUCT_VARRAY_INT32(_field, _state, _field_num, _version,
_vmsd, _type) { \
+.name = (stringify(_field)), \
+.num_offset = vmstate_offset_value(_state, _field_num, int32_t), \
+.version_id = (_version),\
+.vmsd = (_vmsd), \
+.size = sizeof(_type), \
+.flags = VMS_STRUCT|VMS_VARRAY_INT32, \
+.offset = offsetof(_state, _field), \
+}
+
#define VMSTATE_STATIC_BUFFER(_field, _state, _version, _test, _start, _size)
{ \
.name = (stringify(_field)), \
.version_id = (_version), \
--
1.7.4
[Qemu-devel] [PATCH 10/58] vmstate: port adb_kbd
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/adb.c | 40 ++--
1 files changed, 14 insertions(+), 26 deletions(-)
diff --git a/hw/adb.c b/hw/adb.c
index 99b30f6..fbf5080 100644
--- a/hw/adb.c
+++ b/hw/adb.c
@@ -261,30 +261,19 @@ static int adb_kbd_request(ADBDevice *d, uint8_t *obuf,
return olen;
}
-static void adb_kbd_save(QEMUFile *f, void *opaque)
-{
-KBDState *s = (KBDState *)opaque;
-
-qemu_put_buffer(f, s-data, sizeof(s-data));
-qemu_put_sbe32s(f, s-rptr);
-qemu_put_sbe32s(f, s-wptr);
-qemu_put_sbe32s(f, s-count);
-}
-
-static int adb_kbd_load(QEMUFile *f, void *opaque, int version_id)
-{
-KBDState *s = (KBDState *)opaque;
-
-if (version_id != 1)
-return -EINVAL;
-
-qemu_get_buffer(f, s-data, sizeof(s-data));
-qemu_get_sbe32s(f, s-rptr);
-qemu_get_sbe32s(f, s-wptr);
-qemu_get_sbe32s(f, s-count);
-
-return 0;
-}
+static const VMStateDescription vmstate_adb_kbd = {
+.name = adb_kbd,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_BUFFER(data, KBDState),
+VMSTATE_INT32(rptr, KBDState),
+VMSTATE_INT32(wptr, KBDState),
+VMSTATE_INT32(count, KBDState),
+VMSTATE_END_OF_LIST()
+}
+};
static int adb_kbd_reset(ADBDevice *d)
{
@@ -305,8 +294,7 @@ void adb_kbd_init(ADBBusState *bus)
d = adb_register_device(bus, ADB_KEYBOARD, adb_kbd_request,
adb_kbd_reset, s);
qemu_add_kbd_event_handler(adb_kbd_put_keycode, d);
-register_savevm(NULL, adb_kbd, -1, 1, adb_kbd_save,
-adb_kbd_load, s);
+vmstate_register(NULL, -1, vmstate_adb_kbd, s);
}
/***/
--
1.7.4
[Qemu-devel] [PATCH 25/58] vmstate: port stellaris ssi bus
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/stellaris.c | 31 +++
1 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/hw/stellaris.c b/hw/stellaris.c
index 00beaf2..3e77b8f 100644
--- a/hw/stellaris.c
+++ b/hw/stellaris.c
@@ -1219,24 +1219,16 @@ static uint32_t stellaris_ssi_bus_transfer(SSISlave
*dev, uint32_t val)
return ssi_transfer(s-bus[s-current_dev], val);
}
-static void stellaris_ssi_bus_save(QEMUFile *f, void *opaque)
-{
-stellaris_ssi_bus_state *s = (stellaris_ssi_bus_state *)opaque;
-
-qemu_put_be32(f, s-current_dev);
-}
-
-static int stellaris_ssi_bus_load(QEMUFile *f, void *opaque, int version_id)
-{
-stellaris_ssi_bus_state *s = (stellaris_ssi_bus_state *)opaque;
-
-if (version_id != 1)
-return -EINVAL;
-
-s-current_dev = qemu_get_be32(f);
-
-return 0;
-}
+static const VMStateDescription vmstate_stellaris_ssi_bus = {
+.name = stellaris_ssi_bus,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_INT32(current_dev, stellaris_ssi_bus_state),
+VMSTATE_END_OF_LIST()
+}
+};
static int stellaris_ssi_bus_init(SSISlave *dev)
{
@@ -1246,8 +1238,7 @@ static int stellaris_ssi_bus_init(SSISlave *dev)
s-bus[1] = ssi_create_bus(dev-qdev, ssi1);
qdev_init_gpio_in(dev-qdev, stellaris_ssi_bus_select, 1);
-register_savevm(dev-qdev, stellaris_ssi_bus, -1, 1,
-stellaris_ssi_bus_save, stellaris_ssi_bus_load, s);
+vmstate_register(dev-qdev, -1, vmstate_stellaris_ssi_bus, s);
return 0;
}
--
1.7.4
[Qemu-devel] [PATCH 19/58] vmstate: port syborg_rtc
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/syborg_rtc.c | 34 --
1 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/hw/syborg_rtc.c b/hw/syborg_rtc.c
index 329aa42..4e24e52 100644
--- a/hw/syborg_rtc.c
+++ b/hw/syborg_rtc.c
@@ -102,26 +102,17 @@ static CPUWriteMemoryFunc * const syborg_rtc_writefn[] = {
syborg_rtc_write
};
-static void syborg_rtc_save(QEMUFile *f, void *opaque)
-{
-SyborgRTCState *s = opaque;
-
-qemu_put_be64(f, s-offset);
-qemu_put_be64(f, s-data);
-}
-
-static int syborg_rtc_load(QEMUFile *f, void *opaque, int version_id)
-{
-SyborgRTCState *s = opaque;
-
-if (version_id != 1)
-return -EINVAL;
-
-s-offset = qemu_get_be64(f);
-s-data = qemu_get_be64(f);
-
-return 0;
-}
+static const VMStateDescription vmstate_syborg_rtc = {
+.name = syborg_keyboard,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_INT64(offset, SyborgRTCState),
+VMSTATE_INT64(data, SyborgRTCState),
+VMSTATE_END_OF_LIST()
+}
+};
static int syborg_rtc_init(SysBusDevice *dev)
{
@@ -137,8 +128,7 @@ static int syborg_rtc_init(SysBusDevice *dev)
qemu_get_timedate(tm, 0);
s-offset = (uint64_t)mktime(tm) * 10;
-register_savevm(dev-qdev, syborg_rtc, -1, 1,
-syborg_rtc_save, syborg_rtc_load, s);
+vmstate_register(dev-qdev, -1, vmstate_syborg_rtc, s);
return 0;
}
--
1.7.4
[Qemu-devel] [PATCH 13/58] vmstate: port m48t59
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/m48t59.c | 36 +---
1 files changed, 13 insertions(+), 23 deletions(-)
diff --git a/hw/m48t59.c b/hw/m48t59.c
index 2020487..82223c9 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -585,28 +585,18 @@ static CPUReadMemoryFunc * const nvram_read[] = {
nvram_readl,
};
-static void m48t59_save(QEMUFile *f, void *opaque)
-{
-M48t59State *s = opaque;
-
-qemu_put_8s(f, s-lock);
-qemu_put_be16s(f, s-addr);
-qemu_put_buffer(f, s-buffer, s-size);
-}
-
-static int m48t59_load(QEMUFile *f, void *opaque, int version_id)
-{
-M48t59State *s = opaque;
-
-if (version_id != 1)
-return -EINVAL;
-
-qemu_get_8s(f, s-lock);
-qemu_get_be16s(f, s-addr);
-qemu_get_buffer(f, s-buffer, s-size);
-
-return 0;
-}
+static const VMStateDescription vmstate_m48t59 = {
+.name = m48t59,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT8(lock, M48t59State),
+VMSTATE_UINT16(addr, M48t59State),
+VMSTATE_VBUFFER_UINT32(buffer, M48t59State, 0, NULL, 0, size),
+VMSTATE_END_OF_LIST()
+}
+};
static void m48t59_reset_common(M48t59State *NVRAM)
{
@@ -696,7 +686,7 @@ static void m48t59_init_common(M48t59State *s)
}
qemu_get_timedate(s-alarm, 0);
-register_savevm(NULL, m48t59, -1, 1, m48t59_save, m48t59_load, s);
+vmstate_register(NULL, -1, vmstate_m48t59, s);
}
static int m48t59_init_isa1(ISADevice *dev)
--
1.7.4
[Qemu-devel] [PATCH 38/58] vmstate: port syborg_pointer
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/syborg_pointer.c | 73 +++---
1 files changed, 28 insertions(+), 45 deletions(-)
diff --git a/hw/syborg_pointer.c b/hw/syborg_pointer.c
index a886888..2f99707 100644
--- a/hw/syborg_pointer.c
+++ b/hw/syborg_pointer.c
@@ -152,52 +152,36 @@ static void syborg_pointer_event(void *opaque, int dx,
int dy, int dz,
syborg_pointer_update(s);
}
-static void syborg_pointer_save(QEMUFile *f, void *opaque)
-{
-SyborgPointerState *s = (SyborgPointerState *)opaque;
-int i;
-
-qemu_put_be32(f, s-fifo_size);
-qemu_put_be32(f, s-absolute);
-qemu_put_be32(f, s-int_enabled);
-qemu_put_be32(f, s-read_pos);
-qemu_put_be32(f, s-read_count);
-for (i = 0; i s-fifo_size; i++) {
-qemu_put_be32(f, s-event_fifo[i].x);
-qemu_put_be32(f, s-event_fifo[i].y);
-qemu_put_be32(f, s-event_fifo[i].z);
-qemu_put_be32(f, s-event_fifo[i].pointer_buttons);
+static const VMStateDescription vmstate_event_data = {
+.name = dbma_channel,
+.version_id = 0,
+.minimum_version_id = 0,
+.minimum_version_id_old = 0,
+.fields = (VMStateField[]) {
+VMSTATE_INT32(x, event_data),
+VMSTATE_INT32(y, event_data),
+VMSTATE_INT32(z, event_data),
+VMSTATE_INT32(pointer_buttons, event_data),
+VMSTATE_END_OF_LIST()
}
-}
+};
-static int syborg_pointer_load(QEMUFile *f, void *opaque, int version_id)
-{
-SyborgPointerState *s = (SyborgPointerState *)opaque;
-uint32_t val;
-int i;
-
-if (version_id != 1)
-return -EINVAL;
-
-val = qemu_get_be32(f);
-if (val != s-fifo_size)
-return -EINVAL;
-
-val = qemu_get_be32(f);
-if (val != s-absolute)
-return -EINVAL;
-
-s-int_enabled = qemu_get_be32(f);
-s-read_pos = qemu_get_be32(f);
-s-read_count = qemu_get_be32(f);
-for (i = 0; i s-fifo_size; i++) {
-s-event_fifo[i].x = qemu_get_be32(f);
-s-event_fifo[i].y = qemu_get_be32(f);
-s-event_fifo[i].z = qemu_get_be32(f);
-s-event_fifo[i].pointer_buttons = qemu_get_be32(f);
+static const VMStateDescription vmstate_syborg_pointer = {
+.name = syborg_pointer,
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32_EQUAL(fifo_size, SyborgPointerState),
+VMSTATE_UINT32_EQUAL(absolute, SyborgPointerState),
+VMSTATE_INT32(int_enabled, SyborgPointerState),
+VMSTATE_INT32(read_pos, SyborgPointerState),
+VMSTATE_INT32(read_count, SyborgPointerState),
+VMSTATE_STRUCT_VARRAY_UINT32(event_fifo, SyborgPointerState, fifo_size,
+ 1, vmstate_event_data, event_data),
+VMSTATE_END_OF_LIST()
}
-return 0;
-}
+};
static int syborg_pointer_init(SysBusDevice *dev)
{
@@ -219,8 +203,7 @@ static int syborg_pointer_init(SysBusDevice *dev)
qemu_add_mouse_event_handler(syborg_pointer_event, s, s-absolute,
Syborg Pointer);
-register_savevm(dev-qdev, syborg_pointer, -1, 1,
-syborg_pointer_save, syborg_pointer_load, s);
+vmstate_register(dev-qdev, -1, vmstate_syborg_pointer, s);
return 0;
}
--
1.7.4
