[Qemu-devel] [PATCH v12 rebased 5/8] add a new qevent: QEVENT_GUEST_PANICKED
This event will be emited when the guest is panicked.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
---
include/monitor/monitor.h | 1 +
monitor.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index 87fb49c..4006905 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -45,6 +45,7 @@ typedef enum MonitorEvent {
QEVENT_WAKEUP,
QEVENT_BALLOON_CHANGE,
QEVENT_SPICE_MIGRATE_COMPLETED,
+QEVENT_GUEST_PANICKED,
/* Add to 'monitor_event_names' array in monitor.c when
* defining new events here */
diff --git a/monitor.c b/monitor.c
index 9381ed0..61beeb4 100644
--- a/monitor.c
+++ b/monitor.c
@@ -463,6 +463,7 @@ static const char *monitor_event_names[] = {
[QEVENT_WAKEUP] = WAKEUP,
[QEVENT_BALLOON_CHANGE] = BALLOON_CHANGE,
[QEVENT_SPICE_MIGRATE_COMPLETED] = SPICE_MIGRATE_COMPLETED,
+[QEVENT_GUEST_PANICKED] = GUEST_PANICKED,
};
QEMU_BUILD_BUG_ON(ARRAY_SIZE(monitor_event_names) != QEVENT_MAX)
--
1.8.0.1.240.ge8a1f5a
Re: [Qemu-devel] [QEMU PATCH v5 0/3] virtio-net: fix of ctrl commands
On Tue, Jan 22, 2013 at 11:44:43PM +0800, Amos Kong wrote: Currently virtio-net code relys on the layout of descriptor, this patchset removed the assumptions and introduced a control command to set mac address. Last patch is a trivial renaming. V2: check guest's iov_len V3: fix of migration compatibility make mac field in config space read-only when new feature is acked V4: add fix of descriptor layout assumptions, trivial rename V5: fix endianness after iov_to_buf copy Amos Kong (2): virtio-net: introduce a new macaddr control virtio-net: rename ctrl rx commands Michael S. Tsirkin (1): virtio-net: remove layout assumptions for ctrl vq hw/pc_piix.c|4 ++ hw/virtio-net.c | 142 +- hw/virtio-net.h | 26 +++ 3 files changed, 108 insertions(+), 64 deletions(-) Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Re: [Qemu-devel] [Qemu-trivial] [PATCH v3 11/11] qemu-ga: Fix unchecked strdup() by converting to g_strdup()
On Tue, Jan 22, 2013 at 02:54:21PM -0200, Luiz Capitulino wrote: On Tue, 22 Jan 2013 11:08:06 +0100 Markus Armbruster arm...@redhat.com wrote: I figure it's freed somewhere deep down in QAPI, with g_free(). It is, by qapi_dealloc_type_str(). Signed-off-by: Markus Armbruster arm...@redhat.com Reviewed-by: Eric Blake ebl...@redhat.com Reviewed-by: Luiz Capitulino lcapitul...@redhat.com Thanks for the reviews, Luiz. Your Reviewed-by: has been added to the 2 commits. Stefan
[Qemu-devel] [PATCH v12 rebased 1/8] preserve cpu runstate
This patch enables preservation of cpu runstate during save/load vm.
So when a vm is restored from snapshot, the cpu runstate is restored,
too.
See following example:
# save two vms: one is running, the other is paused
(qemu) info status
VM status: running
(qemu) savevm running
(qemu) stop
(qemu) info status
VM status: paused
(qemu) savevm paused
# restore the one running
(qemu) info status
VM status: paused
(qemu) loadvm running
(qemu) info status
VM status: running
# restore the one paused
(qemu) loadvm paused
(qemu) info status
VM status: paused
(qemu) cont
(qemu)info status
VM status: running
Signed-off-by: Hu Tao hu...@cn.fujitsu.com
---
include/sysemu/sysemu.h | 2 ++
migration.c | 6 +-
monitor.c | 5 ++---
savevm.c| 1 +
vl.c| 34 ++
5 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 337ce7d..7a69fde 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -19,6 +19,8 @@ extern uint8_t qemu_uuid[];
int qemu_uuid_parse(const char *str, uint8_t *uuid);
#define UUID_FMT
%02hhx%02hhx%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx
+void save_run_state(void);
+void load_run_state(void);
bool runstate_check(RunState state);
void runstate_set(RunState new_state);
int runstate_is_running(void);
diff --git a/migration.c b/migration.c
index 77c1971..f96cfd6 100644
--- a/migration.c
+++ b/migration.c
@@ -108,11 +108,7 @@ static void process_incoming_migration_co(void *opaque)
/* Make sure all file formats flush their mutable metadata */
bdrv_invalidate_cache_all();
-if (autostart) {
-vm_start();
-} else {
-runstate_set(RUN_STATE_PAUSED);
-}
+load_run_state();
}
static void enter_migration_coroutine(void *opaque)
diff --git a/monitor.c b/monitor.c
index 20bd19b..9381ed0 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2059,13 +2059,12 @@ void qmp_closefd(const char *fdname, Error **errp)
static void do_loadvm(Monitor *mon, const QDict *qdict)
{
-int saved_vm_running = runstate_is_running();
const char *name = qdict_get_str(qdict, name);
vm_stop(RUN_STATE_RESTORE_VM);
-if (load_vmstate(name) == 0 saved_vm_running) {
-vm_start();
+if (load_vmstate(name) == 0) {
+load_run_state();
}
}
diff --git a/savevm.c b/savevm.c
index 304d1ef..10f1d56 100644
--- a/savevm.c
+++ b/savevm.c
@@ -2112,6 +2112,7 @@ void do_savevm(Monitor *mon, const QDict *qdict)
}
saved_vm_running = runstate_is_running();
+save_run_state();
vm_stop(RUN_STATE_SAVE_VM);
memset(sn, 0, sizeof(*sn));
diff --git a/vl.c b/vl.c
index 4ee1302..b0bcf1e 100644
--- a/vl.c
+++ b/vl.c
@@ -520,6 +520,7 @@ static int default_driver_check(QemuOpts *opts, void
*opaque)
/* QEMU state */
static RunState current_run_state = RUN_STATE_PRELAUNCH;
+static RunState saved_run_state = RUN_STATE_PRELAUNCH;
typedef struct {
RunState from;
@@ -543,6 +544,7 @@ static const RunStateTransition runstate_transitions_def[]
= {
{ RUN_STATE_PAUSED, RUN_STATE_FINISH_MIGRATE },
{ RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
+{ RUN_STATE_POSTMIGRATE, RUN_STATE_PAUSED },
{ RUN_STATE_POSTMIGRATE, RUN_STATE_FINISH_MIGRATE },
{ RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
@@ -553,6 +555,7 @@ static const RunStateTransition runstate_transitions_def[]
= {
{ RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
{ RUN_STATE_RESTORE_VM, RUN_STATE_RUNNING },
+{ RUN_STATE_RESTORE_VM, RUN_STATE_PAUSED },
{ RUN_STATE_RUNNING, RUN_STATE_DEBUG },
{ RUN_STATE_RUNNING, RUN_STATE_INTERNAL_ERROR },
@@ -582,11 +585,39 @@ static const RunStateTransition
runstate_transitions_def[] = {
static bool runstate_valid_transitions[RUN_STATE_MAX][RUN_STATE_MAX];
+void save_run_state(void)
+{
+saved_run_state = current_run_state;
+}
+
+void load_run_state(void)
+{
+if (saved_run_state == RUN_STATE_RUNNING) {
+vm_start();
+} else if (!runstate_check(saved_run_state)) {
+runstate_set(saved_run_state);
+} else {
+; /* leave unchanged */
+}
+}
+
bool runstate_check(RunState state)
{
return current_run_state == state;
}
+static void runstate_save(QEMUFile *f, void *opaque)
+{
+qemu_put_byte(f, saved_run_state);
+}
+
+static int runstate_load(QEMUFile *f, void *opaque, int version_id)
+{
+saved_run_state = qemu_get_byte(f);
+
+return 0;
+}
+
static void runstate_init(void)
{
const RunStateTransition *p;
@@ -596,6 +627,9 @@ static void runstate_init(void)
for (p = runstate_transitions_def[0]; p-from != RUN_STATE_MAX; p++) {
runstate_valid_transitions[p-from][p-to] = true;
}
+
+register_savevm(NULL, runstate, 0, 1,
+runstate_save, runstate_load, NULL);
}
/* This function will
[Qemu-devel] [PATCH v12 rebased 8/8] pv event: add document to describe the usage
Signed-off-by: Hu Tao hu...@cn.fujitsu.com --- docs/pv-event.txt | 17 + 1 file changed, 17 insertions(+) create mode 100644 docs/pv-event.txt diff --git a/docs/pv-event.txt b/docs/pv-event.txt new file mode 100644 index 000..ac9e7fa --- /dev/null +++ b/docs/pv-event.txt @@ -0,0 +1,17 @@ +KVM PV EVENT + + +kvm pv event allows guest OS to notify host OS of some events, for +example, guest panic. Currently, there is one event supported, that +is, guest panic. More events can be added later. + +By default, kvm pv event is disabled. In order to enable it, you have +to specify enable_pv_event=on for -machine command line option, along +with -global kvm_pv_event.panicked_action to specify the action taken +when panic event has occurred. Aviable panic actions are: none, +pause, poweroff and reset. Following is example: + + qemu-system-x86_64 -enable-kvm -machine pc-0.12,enable_pv_event=on \ +-global kvm_pv_event.panicked_action=pause other options + +kvm pv event needs kvm support. -- 1.8.0.1.240.ge8a1f5a
Re: [Qemu-devel] [PULL 00/13] thread queue
On 01/17/2013 03:39 PM, Juan Quintela wrote: This is the intersect of the paolo me patches for migration thread, Changes from 2 days ago: - spelling check from Eric - put the commit that patch refered from (Eric) - drop the buffered rename at paolo request. Please, pull. Thanks, Juan. The following changes since commit 47f4dac3fde809e3da4e60d9eb699f1d4b378249: Merge remote-tracking branch 'kraxel/chardev.1' into staging (2013-01-16 15:20:05 -0600) are available in the git repository at: git://repo.or.cz/qemu/quintela.git thread.next for you to fetch changes up to 6522773f88a2e37800f0bf7dc3632a14649f53c6: migration: remove argument to qemu_savevm_state_cancel (2013-01-17 13:54:52 +0100) Juan Quintela (7): qemu-file: Only set last_error if it is not already set migration: move beginning stage to the migration thread migration: Add buffered_flush error handling migration: move exit condition to migration thread migration: unfold rest of migrate_fd_put_ready() into thread migration: Only go to the iterate stage if there is anything to send migration: remove argument to qemu_savevm_state_cancel Paolo Bonzini (6): Unlock ramlist lock also in error case Protect migration_bitmap_sync() with the ramlist lock use XFER_LIMIT_RATIO consistently migration: make function static migration: remove double call to migrate_fd_close migration: fix off-by-one in buffered_rate_limit arch_init.c | 6 +- include/migration/migration.h | 3 - include/sysemu/sysemu.h | 2 +- migration.c | 149 -- savevm.c | 12 ++-- 5 files changed, 81 insertions(+), 91 deletions(-) Looks good to me, Series: Reviewed-by: Orit Wasserman owass...@redhat.com
Re: [Qemu-devel] [PATCH v2] PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
On Wed, Jan 16, 2013 at 07:40:19PM +0100, Laszlo Ersek wrote:
static int piix3_post_load(void *opaque, int version_id)
{
PIIX3State *piix3 = opaque;
piix3_update_irq_levels(piix3);
+piix3-rcr = 2; /* keep System Reset type only */
return 0;
}
Is this necessary? I think only an evil migration source could set
value not in {0x0, 0x2}. And if so, it doesn't seem like our job to
validate that.
+static void rcr_write(void *opaque, hwaddr addr, uint64_t val, unsigned len)
+{
+PIIX3State *d = opaque;
+
+if (val 4) {
+qemu_system_reset_request();
+return;
+}
+d-rcr = val 2; /* keep System Reset type only */
+}
We don't preserve d-rcr across reset:
(qemu) o /b 0xcf9 2
rcr_write val 0x2 rcr 0x2
(qemu) o /b 0xcf9 4
piix3_reset rcr = 0
piix3_reset rcr = 0
Is this okay?
Stefan
Re: [Qemu-devel] [PATCH 0/6] arm devices: mark or remove implicit fallthroughs
Peter Maydell peter.mayd...@linaro.org writes: On 21 January 2013 20:03, Blue Swirl blauwir...@gmail.com wrote: On Mon, Jan 21, 2013 at 12:50 PM, Peter Maydell peter.mayd...@linaro.org wrote: These patches either mark implicit fallthroughs in case statements or (in a few cases) remove them by putting in an explicit 'break' or 'return' rather than relying on the one in the following case. There is no behaviour change for any of these patches, and in all cases I've examined the code and am happy that the behaviour is intentional and correct. Would this be material for 1.4? Well, that depends on your philosophy about softfreeze periods. Personally I would not put these in 1.4 because they do not fix any actual bugs and I am pretty conservative about putting in code after softfreeze. On the other hand as changes go they're pretty safe so I don't have any positive objection to them going into 1.4. http://wiki.qemu.org/Planning/SoftFeatureFreeze By the date of the soft feature freeze, any major feature should have some code posted to the qemu-devel mailing list if it's targeting a given release. Makes it pretty clear to me that soft freeze is about major and feature. These patches are neither. I'd take them.
Re: [Qemu-devel] [PATCH v2] netmap backend (revised)
On Tue, Jan 22, 2013 at 2:50 PM, Anthony Liguori aligu...@us.ibm.comwrote: Hi, Thank you for submitting your patch series. checkpatch.pl has detected that one or more of the patches in this series violate the QEMU coding style. If you believe this message was sent in error, please ignore it or respond here with an explanation. Otherwise, please correct the coding style issues and resubmit a new version of the patch. will do, thanks for the feedback luigi
Re: [Qemu-devel] [PATCH] aio-posix: Fix return value of aio_poll()
Are you using timers in any way? Yes, I call co_sleep_ns(rt_clock, delay) to limit rate to output stream. Use block_job_sleep_ns instead, and only call it when no I/O is pending. Thanks, that works! I currently use qemu_aio_set_fd_handler() to implement async output to the backup stream. While that works, performance is much better (during backup) if I use a separate thread to write the data. Is that known behavior, or should aio give about the same performance as using a thread? Or would I get better performance if I use Linux native AIO support?
[Qemu-devel] [PATCH 1/3] qemu-char: Add new char backend CirMemCharDriver
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
qemu-char.c | 114 +++
qemu-options.hx | 10 +
2 files changed, 124 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 9ba0573..8045869 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -98,6 +98,7 @@
#include ui/qemu-spice.h
#define READ_BUF_LEN 4096
+#define CBUFF_SIZE 65536
/***/
/* character device */
@@ -2643,6 +2644,110 @@ size_t qemu_chr_mem_osize(const CharDriverState *chr)
return d-outbuf_size;
}
+/*/
+/*CircularMemory chardev*/
+
+typedef struct {
+size_t size;
+size_t prod;
+size_t cons;
+uint8_t *cbuf;
+} CirMemCharDriver;
+
+static bool cirmem_chr_is_empty(const CharDriverState *chr)
+{
+const CirMemCharDriver *d = chr-opaque;
+
+return d-cons == d-prod;
+}
+
+static size_t qemu_chr_cirmem_count(const CharDriverState *chr)
+{
+const CirMemCharDriver *d = chr-opaque;
+
+return (d-prod - d-cons);
+}
+
+static int cirmem_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
+{
+CirMemCharDriver *d = chr-opaque;
+int i;
+
+if (!buf || (len 0)) {
+return -1;
+}
+
+for (i = 0; i len; i++ ) {
+/* Avoid writing the IAC information to the queue. */
+if ((unsigned char)buf[i] == IAC) {
+continue;
+}
+
+d-cbuf[d-prod++ % d-size] = buf[i];
+if ((d-prod - d-cons) d-size) {
+d-cons = d-prod - d-size;
+}
+}
+
+return 0;
+}
+
+static int cirmem_chr_read(CharDriverState *chr, uint8_t *buf, int len)
+{
+CirMemCharDriver *d = chr-opaque;
+int i;
+
+for (i = 0; i len !cirmem_chr_is_empty(chr); i++) {
+buf[i] = d-cbuf[d-cons++ % d-size];
+}
+
+return i;
+}
+
+static void cirmem_chr_close(struct CharDriverState *chr)
+{
+CirMemCharDriver *d = chr-opaque;
+
+g_free(d-cbuf);
+g_free(d);
+chr-opaque = NULL;
+}
+
+static CharDriverState *qemu_chr_open_cirmemchr(QemuOpts *opts)
+{
+CharDriverState *chr;
+CirMemCharDriver *d;
+
+chr = g_malloc0(sizeof(CharDriverState));
+d = g_malloc(sizeof(*d));
+
+d-size = qemu_opt_get_number(opts, maxcapacity, 0);
+if (d-size == 0) {
+d-size = CBUFF_SIZE;
+}
+
+/* The size must be power of 2 */
+if (d-size (d-size - 1)) {
+fprintf(stderr, chardev: size of memory device must be power of 2\n);
+goto fail;
+}
+
+d-prod = 0;
+d-cons = 0;
+d-cbuf = g_malloc0(d-size);
+
+chr-opaque = d;
+chr-chr_write = cirmem_chr_write;
+chr-chr_close = cirmem_chr_close;
+
+return chr;
+
+fail:
+g_free(d);
+g_free(chr);
+return NULL;
+}
+
QemuOpts *qemu_chr_parse_compat(const char *label, const char *filename)
{
char host[65], port[33], width[8], height[8];
@@ -2697,6 +2802,11 @@ QemuOpts *qemu_chr_parse_compat(const char *label, const
char *filename)
qemu_opt_set(opts, path, filename);
return opts;
}
+if (strstart(filename, memory, p)) {
+qemu_opt_set(opts, backend, memory);
+qemu_opt_set(opts, maxcapacity, p);
+return opts;
+}
if (strstart(filename, file:, p)) {
qemu_opt_set(opts, backend, file);
qemu_opt_set(opts, path, p);
@@ -2796,6 +2906,7 @@ static const struct {
{ .name = udp, .open = qemu_chr_open_udp },
{ .name = msmouse, .open = qemu_chr_open_msmouse },
{ .name = vc,.open = text_console_init },
+{ .name = memory,.open = qemu_chr_open_cirmemchr },
#ifdef _WIN32
{ .name = file, .open = qemu_chr_open_win_file_out },
{ .name = pipe, .open = qemu_chr_open_win_pipe },
@@ -3055,6 +3166,9 @@ QemuOptsList qemu_chardev_opts = {
},{
.name = debug,
.type = QEMU_OPT_NUMBER,
+},{
+.name = maxcapacity,
+.type = QEMU_OPT_NUMBER,
},
{ /* end of list */ }
},
diff --git a/qemu-options.hx b/qemu-options.hx
index 4e2b499..2d44137 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1736,6 +1736,7 @@ DEF(chardev, HAS_ARG, QEMU_OPTION_chardev,
-chardev msmouse,id=id[,mux=on|off]\n
-chardev
vc,id=id[[,width=width][,height=height]][[,cols=cols][,rows=rows]]\n
[,mux=on|off]\n
+-chardev memory,id=id,maxcapacity=maxcapacity\n
-chardev file,id=id,path=path[,mux=on|off]\n
-chardev pipe,id=id,path=path[,mux=on|off]\n
#ifdef _WIN32
@@ -1777,6 +1778,7 @@ Backend is one of:
@option{udp},
@option{msmouse},
@option{vc},
+@option{memory},
@option{file},
@option{pipe},
@option{console},
@@ -1885,6 +1887,14 @@ the console, in pixels.
@option{cols} and @option{rows} specify that the console be sized to fit a text
console with the given dimensions.
+@item -chardev memory ,id=@var{id}
[Qemu-devel] [PATCH 3/3] QAPI: Introduce memchar-read QMP command
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
hmp-commands.hx | 21 +
hmp.c| 17 +
hmp.h|1 +
qapi-schema.json | 36
qemu-char.c | 48
qmp-commands.hx | 33 +
6 files changed, 156 insertions(+), 0 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index bcfea11..bdd48f3 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -858,6 +858,27 @@ to char device 'memory'.
ETEXI
{
+.name = memchar_read,
+.args_type = device:s,size:i,
+.params = device size,
+.help = Provide read interface for CirMemCharDriver. Read from
+ it and return the data with size.,
+.mhandler.cmd = hmp_memchar_read,
+},
+
+STEXI
+@item memchar_read @var{device}
+@findex memchar_read
+Provide read interface for CirMemCharDriver. Read from char device
+'memory' and return the data.
+
+@var{size} is the size of data want to read from. Refer to unencoded
+size of the raw data, would adjust to the init size of the memchar
+if the requested size is larger than it.
+
+ETEXI
+
+{
.name = migrate,
.args_type = detach:-d,blk:-b,inc:-i,uri:s,
.params = [-d] [-b] [-i] uri,
diff --git a/hmp.c b/hmp.c
index 647316a..1f1df5d 100644
--- a/hmp.c
+++ b/hmp.c
@@ -697,6 +697,23 @@ void hmp_memchar_write(Monitor *mon, const QDict *qdict)
hmp_handle_error(mon, errp);
}
+void hmp_memchar_read(Monitor *mon, const QDict *qdict)
+{
+uint32_t size = qdict_get_int(qdict, size);
+const char *chardev = qdict_get_str(qdict, device);
+MemCharRead *meminfo;
+Error *errp = NULL;
+
+meminfo = qmp_memchar_read(chardev, size, false, 0, errp);
+if (errp) {
+monitor_printf(mon, %s\n, error_get_pretty(errp));
+error_free(errp);
+return;
+}
+
+monitor_printf(mon, %s, \n, meminfo-data);
+}
+
static void hmp_cont_cb(void *opaque, int err)
{
if (!err) {
diff --git a/hmp.h b/hmp.h
index 06d6ea2..076d8cf 100644
--- a/hmp.h
+++ b/hmp.h
@@ -44,6 +44,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
void hmp_memsave(Monitor *mon, const QDict *qdict);
void hmp_pmemsave(Monitor *mon, const QDict *qdict);
void hmp_memchar_write(Monitor *mon, const QDict *qdict);
+void hmp_memchar_read(Monitor *mon, const QDict *qdict);
void hmp_cont(Monitor *mon, const QDict *qdict);
void hmp_system_wakeup(Monitor *mon, const QDict *qdict);
void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
diff --git a/qapi-schema.json b/qapi-schema.json
index 8202311..ad4e276 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -363,6 +363,42 @@
'*format': 'DataFormat'} }
##
+# @MemCharRead
+#
+# Result of QMP command memchar-read.
+#
+# @data: The data read from memchar as string.
+#
+# @count: The numbers of bytes read from.
+#
+# Since: 1.4
+##
+{ 'type': 'MemCharRead',
+ 'data': { 'data': 'str', 'count': 'int' } }
+
+##
+# @memchar-read:
+#
+# Provide read interface for memchardev. Read from the char
+# device 'memory' and return the data.
+#
+# @device: the name of the memory char device.
+#
+# @size: the size to read in bytes.
+#
+# @format: #optional the format of the data want to read from
+# memchardev, by default is 'utf8'.
+#
+# Returns: @MemCharRead
+# If @device is not a valid memchr device, DeviceNotFound
+#
+# Since: 1.4
+##
+{ 'command': 'memchar-read',
+ 'data': {'device': 'str', 'size': 'int', '*format': 'DataFormat'},
+ 'returns': 'MemCharRead' }
+
+##
# @CommandInfo:
#
# Information about a QMP command
diff --git a/qemu-char.c b/qemu-char.c
index dbd1a7c..c45397a 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2790,6 +2790,54 @@ void qmp_memchar_write(const char *device, int64_t size,
}
}
+MemCharRead *qmp_memchar_read(const char *device, int64_t size,
+ bool has_format, enum DataFormat format,
+ Error **errp)
+{
+CharDriverState *chr;
+guchar *read_data;
+MemCharRead *meminfo;
+size_t count;
+
+chr = qemu_chr_find(device);
+if (!chr) {
+error_set(errp, QERR_DEVICE_NOT_FOUND, device);
+return NULL;
+}
+
+if (qemu_is_chr(chr, memory)) {
+error_setg(errp,%s is not memory char device, device);
+return NULL;
+}
+
+if (size = 0) {
+error_setg(errp, size must be greater than zero);
+return NULL;
+}
+
+/* Return empty strings when the buffer is empty. */
+if (cirmem_chr_is_empty(chr)) {
+return NULL;
+}
+
+count = qemu_chr_cirmem_count(chr);
+size = size count ? count : size;
+read_data = g_malloc0(size + 1);
+
+meminfo = g_malloc0(sizeof(MemCharRead));
+meminfo-count = cirmem_chr_read(chr, read_data, size);
+
+if (has_format (format ==
[Qemu-devel] [PATCH 2/3] QAPI: Introduce memchar-write QMP command
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
hmp-commands.hx | 18 ++
hmp.c| 13 +
hmp.h|1 +
qapi-schema.json | 38 ++
qemu-char.c | 42 ++
qmp-commands.hx | 33 +
6 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 0934b9b..bcfea11 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -837,6 +837,24 @@ STEXI
@item nmi @var{cpu}
@findex nmi
Inject an NMI on the given CPU (x86 only).
+
+ETEXI
+
+{
+.name = memchar_write,
+.args_type = device:s,data:s,
+.params = device data,
+.help = Provide writing interface for CirMemCharDriver. Write
+ 'data' to it.,
+.mhandler.cmd = hmp_memchar_write,
+},
+
+STEXI
+@item memchar_write @var{device} @var{data}
+@findex memchar_write
+Provide writing interface for CirMemCharDriver. Write @var{data}
+to char device 'memory'.
+
ETEXI
{
diff --git a/hmp.c b/hmp.c
index c7b6ba0..647316a 100644
--- a/hmp.c
+++ b/hmp.c
@@ -684,6 +684,19 @@ void hmp_pmemsave(Monitor *mon, const QDict *qdict)
hmp_handle_error(mon, errp);
}
+void hmp_memchar_write(Monitor *mon, const QDict *qdict)
+{
+uint32_t size;
+const char *chardev = qdict_get_str(qdict, device);
+const char *data = qdict_get_str(qdict, data);
+Error *errp = NULL;
+
+size = strlen(data);
+qmp_memchar_write(chardev, size, data, false, 0, errp);
+
+hmp_handle_error(mon, errp);
+}
+
static void hmp_cont_cb(void *opaque, int err)
{
if (!err) {
diff --git a/hmp.h b/hmp.h
index 44be683..06d6ea2 100644
--- a/hmp.h
+++ b/hmp.h
@@ -43,6 +43,7 @@ void hmp_system_powerdown(Monitor *mon, const QDict *qdict);
void hmp_cpu(Monitor *mon, const QDict *qdict);
void hmp_memsave(Monitor *mon, const QDict *qdict);
void hmp_pmemsave(Monitor *mon, const QDict *qdict);
+void hmp_memchar_write(Monitor *mon, const QDict *qdict);
void hmp_cont(Monitor *mon, const QDict *qdict);
void hmp_system_wakeup(Monitor *mon, const QDict *qdict);
void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
diff --git a/qapi-schema.json b/qapi-schema.json
index 6d7252b..8202311 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -325,6 +325,44 @@
{ 'command': 'query-chardev', 'returns': ['ChardevInfo'] }
##
+# @DataFormat:
+#
+# An enumeration of data format.
+#
+# @utf8: The data format is 'utf8'.
+#
+# @base64: The data format is 'base64'.
+#
+# Since: 1.4
+##
+{ 'enum': 'DataFormat'
+ 'data': [ 'utf8', 'base64' ] }
+
+##
+# @memchar-write:
+#
+# Provide writing interface for memchardev. Write data to char
+# device 'memory'.
+#
+# @device: the name of the memory char device.
+#
+# @size: the size to write in bytes.
+#
+# @data: the source data write to memchar.
+#
+# @format: #optional the format of the data write to chardev 'memory',
+# by default is 'utf8'.
+#
+# Returns: Nothing on success
+# If @device is not a valid char device, DeviceNotFound
+#
+# Since: 1.4
+##
+{ 'command': 'memchar-write',
+ 'data': {'device': 'str', 'size': 'int', 'data': 'str',
+ '*format': 'DataFormat'} }
+
+##
# @CommandInfo:
#
# Information about a QMP command
diff --git a/qemu-char.c b/qemu-char.c
index 8045869..dbd1a7c 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2748,6 +2748,48 @@ fail:
return NULL;
}
+static bool qemu_is_chr(const CharDriverState *chr, const char *filename)
+{
+return strcmp(chr-filename, filename);
+}
+
+void qmp_memchar_write(const char *device, int64_t size,
+ const char *data, bool has_format,
+ enum DataFormat format,
+ Error **errp)
+{
+CharDriverState *chr;
+guchar *write_data;
+int ret;
+gsize write_count;
+
+chr = qemu_chr_find(device);
+if (!chr) {
+error_set(errp, QERR_DEVICE_NOT_FOUND, device);
+return;
+}
+
+if (qemu_is_chr(chr, memory)) {
+error_setg(errp,%s is not memory char device, device);
+return;
+}
+
+write_count = (gsize)size;
+
+if (has_format (format == DATA_FORMAT_BASE64)) {
+write_data = g_base64_decode(data, write_count);
+} else {
+write_data = (uint8_t *)data;
+}
+
+ret = cirmem_chr_write(chr, write_data, write_count);
+
+if (ret 0) {
+error_setg(errp, Failed to write to device %s, device);
+return;
+}
+}
+
QemuOpts *qemu_chr_parse_compat(const char *label, const char *filename)
{
char host[65], port[33], width[8], height[8];
diff --git a/qmp-commands.hx b/qmp-commands.hx
index cbf1280..8d10a67 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -466,6 +466,39 @@ Note: inject-nmi fails when the guest doesn't support
injecting.
EQMP
{
+.name = memchar-write,
+.args_type
[Qemu-devel] [RESEND PATCH for 1.4 v10 0/3] char: Add CirMemCharDriver and provide QMP interface
Hi Anthony,
Resubmit this series with your comments squashed in and Luiz's new
comments fixed up. I will push console command part in another thread.
Thanks.
This patch series attempts to add new char backend CirMemCharDriver with
a circular buffer and expose it to users by introducing QMP interface
memchar-write and memchar-read and via the command line like the other
CharDriverStates.
Serial ports in qemu always use CharDriverStates as there backends,
Right now, all of our backends always try to write the data from the
guest to a socket or file. The concern from OpenStack is that this could
lead to unbounded disk space usage since they log the serial output.
For more detail of the background info:
https://bugs.launchpad.net/nova/+bug/832507
So we want to use a circular buffer in QEMU instead, and then OpenStack
can periodically read the buffer in QEMU and log it.
The QMP commands introduced like:
{ 'command': 'memchar-write',
'data': {'device': 'str', 'size': 'int', 'data': 'str',
'*format': 'str' } }
{ 'command': 'memchar-read',
'data': {'device': 'str', 'size': 'int', '*format': 'str' },
'returns': 'MemCharRead' }
Expose CirMemCharDriver via the command line like:
qemu -chardev memory,id=foo,maxcapacity=65536 -serial chardev:foo
Note:
Now all of the feature were implemented, and the pervious comments
are fixed up too. Since this patch series have been for mailing list
for some time and missed 1.3, rebase it with minor fix.
Changes since v9:
- Fixup comments from Luiz include:
- Error report and doc improvment.
- Get rid of cirmem_chr_is_full check and just return an
empty string instead of an read error.
- Add support to return the number of bytes read.
Changes since v8:
- Squashed in the comments from Anthony.
- Split the console command part out to another thread.
Changes since v7:
- Rebase the code and fix the format error pointed by Eric.
- Modify the version info.
Changes since v6:
- Improve the document based on Luiz's comments.
- Keep pointing to the right position in cbuf for the case producer
and consumer might overflow for long running VMs pointed by Luiz.
- Limit the size of read_data to the amount of bytes available in the
circular buffer.
- Other fixups from Luiz.
Changes since v5:
- Avoid writing the IAC information to the queue.
- Grammar of the doc for command line options improved from Eric.
Changes since v4:
- Get rid of all CongestionControl bits, and assume a dropping behavior
based on Luiz's suggestion for now. Will add it when we add async
support to QMP.
- Squashed the patches about CirMemCharDriver in one.
- Other fixups from Luiz.
Changes since v3:
- Improve the algorithm of circular buffer based on Anthony's
suggestion.
- Some changes suggested by Luiz and Blue.
- And other fixups.
Changes since v2:
- Add congestion mechanism. For the 'block' option as sync command,
will support it later when we gain the necessary infrastructure
enhancement.
- Add HMP 'console' command so that can interact with multiple
chardevs via a single monitor socket.
- Make the circular buffer backend and the current MemCharDriver
live in parallel, expose a new char backend with circular buffer
CirMemCharDriver suggested by Luiz.
- Other fixs from Eric and Markus.
Changes since v1:
- Exposing the MemCharDriver via command line.
- Support base64 data format suggested by Anthony and Eric.
- Follow the new rule for the name of qmp command from Eric.
Lei Li (3):
qemu-char: Add new char backend CirMemCharDriver
QAPI: Introduce memchar-write QMP command
QAPI: Introduce memchar-read QMP command
hmp-commands.hx | 39 ++
hmp.c| 30
hmp.h|2 +
qapi-schema.json | 74
qemu-char.c | 204 ++
qemu-options.hx | 10 +++
qmp-commands.hx | 66 +
7 files changed, 425 insertions(+), 0 deletions(-)
[Qemu-devel] [PATCH for-1.4] s390-virtio: Check for NULL device in reset hypercall
s390_virtio_bus_find_mem() may return a NULL VirtIOS390Device.
If called with, e.g., args[0] == 0, this leads to a segfault.
Fix this by adding error handling as done for other hypercalls.
Present since baf0b55a9e57b909b1f8b0f732c0b10242867418 (Implement
virtio reset).
Cc: qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/s390-virtio.c |3 +++
1 Datei geändert, 3 Zeilen hinzugefügt(+)
diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
index 5edaabb..5d48aba 100644
--- a/hw/s390-virtio.c
+++ b/hw/s390-virtio.c
@@ -86,6 +86,9 @@ static int s390_virtio_hcall_reset(const uint64_t *args)
VirtIOS390Device *dev;
dev = s390_virtio_bus_find_mem(s390_bus, mem);
+if (dev == NULL) {
+return -EINVAL;
+}
virtio_reset(dev-vdev);
stb_phys(dev-dev_offs + VIRTIO_DEV_OFFS_STATUS, 0);
s390_virtio_device_sync(dev);
--
1.7.10.4
Re: [Qemu-devel] tap devices not receiving packets from a bridge
On Tue, Jan 22, 2013 at 10:04:07AM +0100, Peter Lieven wrote:
On 23.11.2012 12:01, Michael S. Tsirkin wrote:
On Fri, Nov 23, 2012 at 10:41:21AM +0100, Peter Lieven wrote:
Am 23.11.2012 um 08:02 schrieb Stefan Hajnoczi:
On Thu, Nov 22, 2012 at 03:29:52PM +0100, Peter Lieven wrote:
is anyone aware of a problem with the linux network bridge that in very
rare circumstances stops
a bridge from sending pakets to a tap device?
My problem occurs in conjunction with vanilla qemu-kvm-1.2.0 and Ubuntu
Kernel 3.2.0-34.53
which is based on Linux 3.2.33.
I was not yet able to reproduce the issue, it happens in really rare
cases. The symptom is that
the tap does not have any TX packets. RX is working fine. I see the
packets coming in at
the physical interface on the host, but they are not forwarded to the tap
interface.
The bridge itself has learnt the mac address of the vServer that is
connected to the tap interface.
It does not help to toggle the bridge link status, the tap interface
status or the interface in the vServer.
It seems that problem occurs if a tap interface that has previously been
used, but set to nonpersistent
is set persistent again and then is by chance assigned to the same
vServer (=same mac address on same
bridge) again. Unfortunately it seems not to be reproducible.
Not sure but this patch from Michael Tsirkin may help - it solves an
issue with persistent tap devices:
http://patchwork.ozlabs.org/patch/198598/
Hi Stefan,
thanks for the pointer. I have seen this patch, but I have neglected it
because it was dealing
with persistent taps. But maybe the taps in the kernel are not deleted
directly.
Can you remember what the syptomps of the above issue have been? Sorry for
being vague, but I currently have no clue whats going on.
Can someone who has more internal knowledge of the bridging/tap code say if
qemu can
be responsible at all if the tap device is not receiving packets from the
bridge.
If I have the following config. Lets say packets coming in via physical
interface eth1.123,
and a bridge called br123.I further have a virtual machine with tap0. Both
eth1.123
and tap0 are member of br123.
If the issue occurs the vServer has no network connectivity inbound. If I
sent a ping
from the vServer I see it on tap0 and leaving on eth1.123. I see further
the arp reply coming
in via eth1.123, but the reply can't be seen on tap0.
Peter
If guest is not consuming packets, a TX queue in tap device
will with time overrun (there's space for 1000 packets there).
This is code from tun:
if (skb_queue_len(tfile-socket.sk-sk_receive_queue)
= dev-tx_queue_len / tun-numqueues){
if (!(tun-flags TUN_ONE_QUEUE)) {
/* Normal queueing mode. */
/* Packet scheduler handles dropping of further
* packets. */
netif_stop_subqueue(dev, txq);
/* We won't see all dropped packets
* individually, so overrun
* error is more appropriate. */
dev-stats.tx_fifo_errors++;
So you can detect that this triggered by looking at fifo errors counter in
device.
Once this happens TX queue is stopped, then you hit this path:
if (!netif_xmit_stopped(txq)) {
__this_cpu_inc(xmit_recursion);
rc = dev_hard_start_xmit(skb, dev, txq);
__this_cpu_dec(xmit_recursion);
if (dev_xmit_complete(rc)) {
HARD_TX_UNLOCK(dev, txq);
goto out;
}
}
so packets are not passed to device anymore.
It will stay this way until guest consumes some packets and
queue is restarted.
After some time I again have a vServer in this state. It seems not like there
are no TX errors.
# ifconfig tap10
tap10 Link encap:Ethernet HWaddr 7a:59:20:6f:e7:e5
inet6 addr: fe80::7859:20ff:fe6f:e7e5/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:197431 errors:0 dropped:0 overruns:0 frame:0
TX packets:264309 errors:0 dropped:0 overruns:2 carrier:0
collisions:0 txqueuelen:500
RX bytes:13842063 (13.8 MB) TX bytes:35092821 (35.0 MB)
It seems like the bridge is not forwarding any packets to the tap device
anymore altough it has learnt
the MAC-Adresses and there are also broadcast packets coming in.
Any more ideas where I could debug?
Peter
Stefan
Hmm. So there are two overrun errors that triggered, so
it's possible after the second one the queue got stuck in an xoff state.
You'd have to use something like systemtap or kdb to poke at the
queue
[Qemu-devel] [FYI 3/3] qtest: Add virtio-ccw test case
Signed-off-by: Andreas Färber afaer...@suse.de
---
tests/Makefile |2 ++
tests/virtio-ccw-test.c | 38 ++
2 Dateien geändert, 40 Zeilen hinzugefügt(+)
create mode 100644 tests/virtio-ccw-test.c
diff --git a/tests/Makefile b/tests/Makefile
index d86e95a..6ab4610 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -62,6 +62,7 @@ check-qtest-sparc64-y = tests/m48t59-test$(EXESUF)
gcov-files-sparc-y += hw/m48t59.c
check-qtest-arm-y = tests/tmp105-test$(EXESUF)
qcov-files-arm-y += hw/tmp105.c
+check-qtest-s390x-y = tests/virtio-ccw-test$(EXESUF)
GENERATED_HEADERS += tests/test-qapi-types.h tests/test-qapi-visit.h
tests/test-qmp-commands.h
@@ -111,6 +112,7 @@ tests/m48t59-test$(EXESUF): tests/m48t59-test.o
tests/fdc-test$(EXESUF): tests/fdc-test.o
tests/hd-geo-test$(EXESUF): tests/hd-geo-test.o
tests/tmp105-test$(EXESUF): tests/tmp105-test.o
+tests/virtio-ccw-test$(EXESUF): tests/virtio-ccw-test.o
# QTest rules
diff --git a/tests/virtio-ccw-test.c b/tests/virtio-ccw-test.c
new file mode 100644
index 000..8abf8d9
--- /dev/null
+++ b/tests/virtio-ccw-test.c
@@ -0,0 +1,38 @@
+/*
+ * QTest testcase for virtio-ccw
+ *
+ * Copyright (c) 2013 SUSE LINUX Products GmbH
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#include libqtest.h
+
+#include glib.h
+
+#define KVM_S390_VIRTIO_RESET 1
+
+static void test(void)
+{
+hypercall(KVM_S390_VIRTIO_RESET, 1, 128 * 1024 * 1024);
+}
+
+int main(int argc, char **argv)
+{
+QTestState *s = NULL;
+int ret;
+
+g_test_init(argc, argv, NULL);
+
+s = qtest_start(-display none -m 128M);
+
+qtest_add_func(/virtio-ccw/dummy, test);
+
+ret = g_test_run();
+
+if (s) {
+qtest_quit(s);
+}
+
+return ret;
+}
--
1.7.10.4
[Qemu-devel] [RFC 1/3] qtest: Prepare hypercall support
Signed-off-by: Andreas Färber afaer...@suse.de
---
include/sysemu/qtest.h |2 ++
qtest.c| 26 ++
stubs/Makefile.objs|1 +
stubs/qtest.c | 12
tests/libqtest.c | 21 +
tests/libqtest.h | 17 +
6 Dateien geändert, 79 Zeilen hinzugefügt(+)
create mode 100644 stubs/qtest.c
diff --git a/include/sysemu/qtest.h b/include/sysemu/qtest.h
index 723a4f9..75ab29d 100644
--- a/include/sysemu/qtest.h
+++ b/include/sysemu/qtest.h
@@ -32,6 +32,8 @@ static inline int qtest_available(void)
}
int qtest_init(void);
+bool qtest_hypercall_supported(void);
+int qtest_hypercall(uint64_t code, uint64_t *args);
#else
static inline bool qtest_enabled(void)
{
diff --git a/qtest.c b/qtest.c
index c9b58ce..a5b54e3 100644
--- a/qtest.c
+++ b/qtest.c
@@ -117,6 +117,11 @@ static bool qtest_opened;
* where NUM is an IRQ number. For the PC, interrupts can be intercepted
* simply with irq_intercept_in ioapic (note that IRQ0 comes out with
* NUM=0 even though it is remapped to GSI 2).
+ *
+ * Hypercalls:
+ *
+ * hypercall CODE
+ * OK
*/
static int hex2nib(char ch)
@@ -344,6 +349,27 @@ static void qtest_process_command(CharDriverState *chr,
gchar **words)
qtest_clock_warp(ns);
qtest_send_prefix(chr);
qtest_send(chr, OK %PRIi64\n,
(int64_t)qemu_get_clock_ns(vm_clock));
+} else if (strcmp(words[0], hypercall) == 0
+ qtest_hypercall_supported()) {
+uint64_t code;
+uint64_t args[13];
+int ret, i;
+
+g_assert(words[1] != NULL);
+code = strtoull(words[1], NULL, 0);
+
+memset(args, 0, sizeof(args));
+for (i = 0; i 13 words[2 + i] != NULL; i++) {
+args[i] = strtoull(words[2 + i], NULL, 0);
+}
+
+ret = qtest_hypercall(code, args);
+qtest_send_prefix(chr);
+if (ret 0) {
+qtest_send(chr, ERR 0x%x\n, ret);
+return;
+}
+qtest_send(chr, OK 0x%x\n, ret);
} else {
qtest_send_prefix(chr);
qtest_send(chr, FAIL Unknown command `%s'\n, words[0]);
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index a260394..50fb2a7 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -15,6 +15,7 @@ stub-obj-y += mon-printf.o
stub-obj-y += mon-print-filename.o
stub-obj-y += mon-protocol-event.o
stub-obj-y += mon-set-error.o
+stub-obj-y += qtest.o
stub-obj-y += reset.o
stub-obj-y += set-fd-handler.o
stub-obj-y += slirp.o
diff --git a/stubs/qtest.c b/stubs/qtest.c
new file mode 100644
index 000..8860e4f
--- /dev/null
+++ b/stubs/qtest.c
@@ -0,0 +1,12 @@
+#include qemu-common.h
+#include sysemu/qtest.h
+
+bool qtest_hypercall_supported(void)
+{
+return false;
+}
+
+int qtest_hypercall(uint64_t code, uint64_t *args)
+{
+return -EINVAL;
+}
diff --git a/tests/libqtest.c b/tests/libqtest.c
index 913fa05..5eb9521 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -476,3 +476,24 @@ void qtest_memwrite(QTestState *s, uint64_t addr, const
void *data, size_t size)
qtest_sendf(s, \n);
qtest_rsp(s, 0);
}
+
+uint64_t qtest_hypercall(QTestState *s, uint64_t code, int argc, ...)
+{
+va_list va;
+gchar **args;
+uint64_t resp, arg;
+int i;
+
+qtest_sendf(s, hypercall 0x% PRIx64, code);
+va_start(va, argc);
+for (i = 0; i argc; i++) {
+arg = va_arg(va, uint64_t);
+qtest_sendf(s, 0x% PRIx64, arg);
+}
+va_end(va);
+qtest_sendf(s, \n);
+args = qtest_rsp(s, 2);
+resp = g_ascii_strtoull(args[1], NULL, 0);
+g_strfreev(args);
+return resp;
+}
diff --git a/tests/libqtest.h b/tests/libqtest.h
index c8ade85..3a5a8f9 100644
--- a/tests/libqtest.h
+++ b/tests/libqtest.h
@@ -187,6 +187,15 @@ int64_t qtest_clock_step(QTestState *s, int64_t step);
int64_t qtest_clock_set(QTestState *s, int64_t val);
/**
+ * qtest_hypercall:
+ * @s: QTestState instance to operate on.
+ * @code: Hypercall code to call.
+ *
+ * Peform a hypercall @code on the guest.
+ */
+uint64_t qtest_hypercall(QTestState *s, uint64_t code, int argc, ...);
+
+/**
* qtest_get_arch:
*
* Returns the architecture for the QEMU executable under test.
@@ -349,4 +358,12 @@ void qtest_add_func(const char *str, void (*fn));
*/
#define clock_set(val) qtest_clock_set(global_qtest, val)
+/**
+ * hypercall:
+ * @code: Hypercall code.
+ *
+ * Invokes a hypercall in the guest.
+ */
+#define hypercall(code, argc, ...) qtest_hypercall(global_qtest, code, argc,
## __VA_ARGS__)
+
#endif
--
1.7.10.4
[Qemu-devel] [RFC 0/3] qtest hypercall support (s390x for now)
Hello, Here's an initial throw at adding hypercall support to qtest. This aims at making s390 virtio (and soon virtio-ccw) easily testable during refactorings such as Fréderic's. Depending on progress it might also be a route to add qtest support for the individual virtio devices while waiting for a PCI libqos. :-) qtest.c is being compiled once, so it cannot contain target-specific code. I therefore add stubs qtest_hypercall_supported() and qtest_hypercall(). s390x then overrides them indicating support and implementing it. A dummy test case is appending for verification that things compile and work so far. One bug fix was already posted based on this testing; series is based on it. I have not yet investigated what changes may need to be applied to the API to make this work for sPAPR as well. Looking forward to feedback. Regards, Andreas Cc: Anthony Liguori anth...@codemonkey.ws Cc: Blue Swirl blauwir...@gmail.com Cc: Alexander Graf ag...@suse.de Cc: Bruce Rogers brog...@suse.com Cc: Christian Borntraeger borntrae...@de.ibm.com Cc: Cornelia Huck cornelia.h...@de.ibm.com Cc: qemu-ppc qemu-...@nongnu.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: David Gibson da...@gibson.dropbear.id.au Andreas Färber (3): qtest: Prepare hypercall support target-s390x: Prepare qtest hypercall support qtest: Add virtio-ccw test case hw/s390x/s390-virtio-hcall.c | 17 + include/sysemu/qtest.h |2 ++ qtest.c | 26 ++ stubs/Makefile.objs |1 + stubs/qtest.c| 12 tests/Makefile |2 ++ tests/libqtest.c | 21 + tests/libqtest.h | 17 + tests/virtio-ccw-test.c | 38 ++ 9 Dateien geändert, 136 Zeilen hinzugefügt(+) create mode 100644 stubs/qtest.c create mode 100644 tests/virtio-ccw-test.c -- 1.7.10.4
[Qemu-devel] [RFC 2/3] target-s390x: Prepare qtest hypercall support
Signed-off-by: Andreas Färber afaer...@suse.de
---
hw/s390x/s390-virtio-hcall.c | 17 +
1 Datei geändert, 17 Zeilen hinzugefügt(+)
diff --git a/hw/s390x/s390-virtio-hcall.c b/hw/s390x/s390-virtio-hcall.c
index d7938c0..6d044f8 100644
--- a/hw/s390x/s390-virtio-hcall.c
+++ b/hw/s390x/s390-virtio-hcall.c
@@ -11,6 +11,7 @@
#include cpu.h
#include hw/s390-virtio.h
+#include sysemu/qtest.h
#define MAX_DIAG_SUBCODES 255
@@ -34,3 +35,19 @@ int s390_virtio_hypercall(CPUS390XState *env)
return fn(env-regs[2]);
}
+
+int qtest_hypercall(uint64_t code, uint64_t *args)
+{
+s390_virtio_fn fn = s390_diag500_table[code];
+
+if (fn == NULL) {
+return -EINVAL;
+}
+
+return fn(args);
+}
+
+bool qtest_hypercall_supported(void)
+{
+return true;
+}
--
1.7.10.4
Re: [Qemu-devel] [PATCH] ich9: add support for pci assignment
On Tue, Jan 22, 2013 at 07:11:37PM -0700, Alex Williamson wrote:
Fills out support for the pci assignment API. Added:
PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin)
Add calls to pci_bus_fire_intx_routing_notifier() when routing changes
are made.
From: Jason Baron jba...@redhat.com
Signed-off-by: Alex Williamson alex.william...@redhat.com
Anthony any objection if I keep merging these things?
You wanted to be in control when the bulk of the q35
work was being merged but I'm guessing it's ok now?
---
Jason posted this back in October, there were no comments. Updated
and tested for latest tree. Currently attempting to use -device
pci-assign with q35 results in:
qemu-system-x86_64: -device pci-assign,host=b:00.0,addr=6: PCI: Bug -
unimplemented PCI INTx routing (q35-pcihost)
This allows it to work. Note that there's a seabios bug for option
ROMs making use of interrupts, hopefully we can also pull that fix
in for 1.4, but guests not relying on bios programming of the PCI
interrupt line value should work fine.
hw/ich9.h |1 +
hw/lpc_ich9.c | 33 +
hw/pc_q35.c |1 +
3 files changed, 35 insertions(+)
diff --git a/hw/ich9.h b/hw/ich9.h
index b8d8e6d..d4509bb 100644
--- a/hw/ich9.h
+++ b/hw/ich9.h
@@ -18,6 +18,7 @@
void ich9_lpc_set_irq(void *opaque, int irq_num, int level);
int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx);
+PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
void ich9_lpc_pm_init(PCIDevice *pci_lpc, qemu_irq cmos_s3);
PCIBus *ich9_d2pbr_init(PCIBus *bus, int devfn, int sec_bus);
i2c_bus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
diff --git a/hw/lpc_ich9.c b/hw/lpc_ich9.c
index 16843d7..e25689b 100644
--- a/hw/lpc_ich9.c
+++ b/hw/lpc_ich9.c
@@ -158,6 +158,7 @@ static void ich9_cc_write(void *opaque, hwaddr addr,
ich9_cc_addr_len(addr, len);
memcpy(lpc-chip_config + addr, val, len);
+pci_bus_fire_intx_routing_notifier(lpc-d.bus);
ich9_cc_update(lpc);
}
@@ -286,6 +287,32 @@ int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx)
return lpc-irr[PCI_SLOT(pci_dev-devfn)][intx];
}
+PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin)
+{
+ICH9LPCState *lpc = opaque;
+PCIINTxRoute route;
+int pic_irq;
+int pic_dis;
+
+assert(0 = pirq_pin);
+assert(pirq_pin ICH9_LPC_NB_PIRQS);
+
+route.mode = PCI_INTX_ENABLED;
+ich9_lpc_pic_irq(lpc, pirq_pin, pic_irq, pic_dis);
+if (!pic_dis) {
+if (pic_irq ICH9_LPC_PIC_NUM_PINS) {
+route.irq = pic_irq;
+} else {
+route.mode = PCI_INTX_DISABLED;
+route.irq = -1;
+}
+} else {
+route.irq = ich9_pirq_to_gsi(pirq_pin);
+}
+
+return route;
+}
+
static int ich9_lpc_sci_irq(ICH9LPCState *lpc)
{
switch (lpc-d.config[ICH9_LPC_ACPI_CTRL]
@@ -405,6 +432,12 @@ static void ich9_lpc_config_write(PCIDevice *d,
if (ranges_overlap(addr, len, ICH9_LPC_RCBA, 4)) {
ich9_lpc_rcba_update(lpc, rbca_old);
}
+if (ranges_overlap(addr, len, ICH9_LPC_PIRQA_ROUT, 4)) {
+pci_bus_fire_intx_routing_notifier(lpc-d.bus);
+}
+if (ranges_overlap(addr, len, ICH9_LPC_PIRQE_ROUT, 4)) {
+pci_bus_fire_intx_routing_notifier(lpc-d.bus);
+}
}
static void ich9_lpc_reset(DeviceState *qdev)
diff --git a/hw/pc_q35.c b/hw/pc_q35.c
index d82353e..6f5ff8d 100644
--- a/hw/pc_q35.c
+++ b/hw/pc_q35.c
@@ -147,6 +147,7 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
ich9_lpc-ioapic = gsi_state-ioapic_irq;
pci_bus_irqs(host_bus, ich9_lpc_set_irq, ich9_lpc_map_irq, ich9_lpc,
ICH9_LPC_NB_PIRQS);
+pci_bus_set_route_irq_fn(host_bus, ich9_route_intx_pin_to_irq);
isa_bus = ich9_lpc-isa_bus;
/*end early*/
Re: [Qemu-devel] [PATCH for-1.4 qom-cpu 1/9] kvm: Create kvm_arch_vcpu_id() function
On Tue, Jan 22, 2013 at 06:25:01PM -0200, Eduardo Habkost wrote:
This will allow each architecture to define how the VCPU ID is set on
the KVM_CREATE_VCPU ioctl call.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Acked-by: Gleb Natapov g...@redhat.com
---
Cc: k...@vger.kernel.org
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Gleb Natapov g...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Changes v2:
- Get CPUState as argument instead of CPUArchState
Changes v3:
- Convert KVM_CREATE_VCPU ioctl() argument to void*, so
the argument type matches the type expected by kvm_vm_ioctl()
---
include/sysemu/kvm.h | 3 +++
kvm-all.c| 2 +-
target-i386/kvm.c| 5 +
target-ppc/kvm.c | 5 +
target-s390x/kvm.c | 5 +
5 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 22acf91..384ee66 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -196,6 +196,9 @@ int kvm_arch_init(KVMState *s);
int kvm_arch_init_vcpu(CPUState *cpu);
+/* Returns VCPU ID to be used on KVM_CREATE_VCPU ioctl() */
+unsigned long kvm_arch_vcpu_id(CPUState *cpu);
+
void kvm_arch_reset_vcpu(CPUState *cpu);
int kvm_arch_on_sigbus_vcpu(CPUState *cpu, int code, void *addr);
diff --git a/kvm-all.c b/kvm-all.c
index 6278d61..363a358 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -222,7 +222,7 @@ int kvm_init_vcpu(CPUState *cpu)
DPRINTF(kvm_init_vcpu\n);
-ret = kvm_vm_ioctl(s, KVM_CREATE_VCPU, cpu-cpu_index);
+ret = kvm_vm_ioctl(s, KVM_CREATE_VCPU, (void *)kvm_arch_vcpu_id(cpu));
if (ret 0) {
DPRINTF(kvm_create_vcpu failed\n);
goto err;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 3acff40..5f3f789 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -411,6 +411,11 @@ static void cpu_update_state(void *opaque, int running,
RunState state)
}
}
+unsigned long kvm_arch_vcpu_id(CPUState *cpu)
+{
+return cpu-cpu_index;
+}
+
int kvm_arch_init_vcpu(CPUState *cs)
{
struct {
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 2f4f068..2c64c63 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -384,6 +384,11 @@ static inline void kvm_fixup_page_sizes(PowerPCCPU *cpu)
#endif /* !defined (TARGET_PPC64) */
+unsigned long kvm_arch_vcpu_id(CPUState *cpu)
+{
+return cpu-cpu_index;
+}
+
int kvm_arch_init_vcpu(CPUState *cs)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index add6a58..99deddf 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -76,6 +76,11 @@ int kvm_arch_init(KVMState *s)
return 0;
}
+unsigned long kvm_arch_vcpu_id(CPUState *cpu)
+{
+return cpu-cpu_index;
+}
+
int kvm_arch_init_vcpu(CPUState *cpu)
{
int ret = 0;
--
1.8.1
--
Gleb.
Re: [Qemu-devel] [PATCH for-1.4 qom-cpu 2/9] target-i386: kvm: Set vcpu_id to APIC ID instead of CPU index
On Tue, Jan 22, 2013 at 06:25:02PM -0200, Eduardo Habkost wrote:
The CPU ID in KVM is supposed to be the APIC ID, so change the
KVM_CREATE_VCPU call to match it. The current behavior didn't break
anything yet because today the APIC ID is assumed to be equal to the CPU
index, but this won't be true in the future.
Signed-off-by: Eduardo Habkost ehabk...@redhat.com
Reviewed-by: Marcelo Tosatti mtosa...@redhat.com
Acked-by: Gleb Natapov g...@redhat.com
---
Cc: k...@vger.kernel.org
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Gleb Natapov g...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
Changes v2:
- Change only i386 code (kvm_arch_vcpu_id())
Changes v3:
- Get CPUState as argument instead of CPUArchState
---
target-i386/kvm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5f3f789..c440809 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -411,9 +411,10 @@ static void cpu_update_state(void *opaque, int running,
RunState state)
}
}
-unsigned long kvm_arch_vcpu_id(CPUState *cpu)
+unsigned long kvm_arch_vcpu_id(CPUState *cs)
{
-return cpu-cpu_index;
+X86CPU *cpu = X86_CPU(cs);
+return cpu-env.cpuid_apic_id;
}
int kvm_arch_init_vcpu(CPUState *cs)
--
1.8.1
--
Gleb.
Re: [Qemu-devel] [RFC] introduce a general query-config cmd (was: [Qemu PATCH v2] add a boot option to do strict boot)
On Tue, Jan 22, 2013 at 12:26:03PM -0600, Anthony Liguori wrote:
Eric Blake ebl...@redhat.com writes:
On 01/22/2013 08:52 AM, Amos Kong wrote:
Libvirt will need to expose an attribute that lets the user control
whether to use this new option; how do we probe via QMP whether the
new
-boot strict=on command-line option is available?
Hi all,
How about add new info/query command?
(hmp) info strict-boot
on
(qmp) {execute: query-strict-boot}
{return: {state: true}}
It might be not a good solution, I already updated qemu-options.hx,
we can check help message to know if this new option is added or not.
Having libvirt probe the -help output is out of the question. We
already declared that for qemu 1.3 and beyond, ALL command line behavior
must ALSO be probe-able via QMP. I think Anthony had a trick for
testing for existence of various command line options without needing to
add a new query-strict-boot command, but I don't remember what that
trick was.
We need a generic query-config-schema command.
Hi all,
The config info is included in qemu-options.def, current
help() defines QEMU_OPTIONS_GENERATE_HELP, and includes
qemu-options-wrapper.h, DEF macro will output the help
message of options to the stdio.
I tried to add two branches in qemu-options-wrapper.h, which
are used to generate two string arraies (one for option name,
one for help message)
Thy help message is too long, it's failed to output all message to
hmp monitor, always got a segfault, the max limitation maybe reached.
It's more clear to only output help message of one option,
eg: {execute: query-config, arguments : {name: boot}}
{return: {config: -boot [order=drives][,once=drives][,menu=on|off]\n
[,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time][,strict=on|off]\n
'drives': floppy (a), hard disk (c), CD-ROM (d), network (n)\n
'sp_name': the file's name that would be passed to bios as logo picture, if
menu=on\n
'sp_time': the period that splash picture last if menu=on, unit is ms\n
'rb_timeout': the timeout before guest reboot when boot failed, unit is
ms\n}}
But info command of hmp doesn't support parameter
(eg: (hmp) info config boot)
Q1) Is my patch ok for resolve the issue in last email (libvirt can check
the help message of each option)?
Q2) Can we only added a command for qmp monitor?
Q3) Is it ok to output all help message for hmp (info config)?
Q4) query-config or query-config-schema ?
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 010b8c9..13d1840 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1552,6 +1552,8 @@ show the vnc server status
show the current VM name
@item info uuid
show the current VM UUID
+@item info config
+show config
@item info cpustats
show CPU statistics
@item info usernet
diff --git a/hmp.c b/hmp.c
index 9e9e624..c0d84d1 100644
--- a/hmp.c
+++ b/hmp.c
@@ -98,6 +98,17 @@ void hmp_info_uuid(Monitor *mon)
qapi_free_UuidInfo(info);
}
+void hmp_info_config(Monitor *mon)
+{
+ConfigInfo *info;
+
+/* Fixed ME: hmp info command doesn't support parameter */
+
+info = qmp_query_config(boot, NULL);
+monitor_printf(mon, %s\n, info-config);
+qapi_free_ConfigInfo(info);
+}
+
void hmp_info_chardev(Monitor *mon)
{
ChardevInfoList *char_info, *info;
diff --git a/hmp.h b/hmp.h
index 21f3e05..f217a8c 100644
--- a/hmp.h
+++ b/hmp.h
@@ -23,6 +23,7 @@ void hmp_info_version(Monitor *mon);
void hmp_info_kvm(Monitor *mon);
void hmp_info_status(Monitor *mon);
void hmp_info_uuid(Monitor *mon);
+void hmp_info_config(Monitor *mon);
void hmp_info_chardev(Monitor *mon);
void hmp_info_mice(Monitor *mon);
void hmp_info_migrate(Monitor *mon);
diff --git a/monitor.c b/monitor.c
index 9cf419b..6f331fa 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2661,6 +2661,13 @@ static mon_cmd_t info_cmds[] = {
.help = show the current VM UUID,
.mhandler.info = hmp_info_uuid,
},
+{
+.name = config,
+.args_type = ,
+.params = ,
+.help = show the config,
+.mhandler.info = hmp_info_config,
+},
#if defined(TARGET_PPC)
{
.name = cpustats,
diff --git a/qapi-schema.json b/qapi-schema.json
index 5dfa052..8c46d57 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3017,3 +3017,23 @@
# Since: 1.3.0
##
{ 'command': 'nbd-server-stop' }
+
+##
+# @ConfigInfo:
+#
+# Commandline configration information.
+#
+##
+{ 'type': 'ConfigInfo', 'data': {'config': 'str'} }
+
+##
+# @query-config
+#
+# Query configuration information of one option
+#
+# @name: option name
+#
+# Returns: configuration information.
+#
+##
+{'command': 'query-config', 'data': {'name': 'str'}, 'returns': 'ConfigInfo'}
diff --git a/qemu-options-wrapper.h b/qemu-options-wrapper.h
index 13bfea0..97b44fb 100644
--- a/qemu-options-wrapper.h
+++ b/qemu-options-wrapper.h
@@ -18,6 +18,22 @@
#define DEFHEADING(text) ARCHHEADING(text,
Re: [Qemu-devel] [PATCH v2] PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
On 01/23/13 09:36, Stefan Hajnoczi wrote:
On Wed, Jan 16, 2013 at 07:40:19PM +0100, Laszlo Ersek wrote:
static int piix3_post_load(void *opaque, int version_id)
{
PIIX3State *piix3 = opaque;
piix3_update_irq_levels(piix3);
+piix3-rcr = 2; /* keep System Reset type only */
return 0;
}
Is this necessary? I think only an evil migration source could set
value not in {0x0, 0x2}.
I wanted to make sure in general that no write path to piix3-rcr
would let an invalid value through.
And if so, it doesn't seem like our job to
validate that.
Independently of the patch: why not?
+static void rcr_write(void *opaque, hwaddr addr, uint64_t val, unsigned len)
+{
+PIIX3State *d = opaque;
+
+if (val 4) {
+qemu_system_reset_request();
+return;
+}
+d-rcr = val 2; /* keep System Reset type only */
+}
We don't preserve d-rcr across reset:
(qemu) o /b 0xcf9 2
rcr_write val 0x2 rcr 0x2
(qemu) o /b 0xcf9 4
piix3_reset rcr = 0
piix3_reset rcr = 0
Is this okay?
Yes, that was my intent with modifying piix3_reset().
Thanks,
Laszlo
Re: [Qemu-devel] Questions on the virtual disk's cache type
On 01/23/2013 06:14 PM, Daniel P. Berrange wrote: On Wed, Jan 23, 2013 at 06:09:01PM +0800, Liu Yuan wrote: On 01/23/2013 05:30 PM, Daniel P. Berrange wrote: FYI There is a patch proposed for customization https://review.openstack.org/#/c/18042/ Seems that this patch is dropped and declined? I should note that it is wrong to assume that enabling cache mode will improve the performance in general. Allowing caching in the host will require a non-negligable amount of host RAM to have a benefit. RAM is usually the most constrained resource in any virtualization environment. So while the cache may help performance when only one or two Vms are running on the host, it may well in fact hurt performance once the host is running enough VMs to max out RAM. So allowing caching will actually give you quite variable performance, while the cache=none will give you consistent performance regardless of host RAM utilization (underlying contention of the storage device may of course still impact things). Yeah, allowing page cache in the host might not be a good idea to run multiple VMs, but cache type in QEMU has different meaning for network block devices. For e.g, we use 'cache type' to control client side cache of Sheepdog cluster, which implement a object cache in the local disk for performance boost and reducing network traffics. This doesn't consume memory at all, just occupy the disk space where runs sheep daemon. That is a serious abuse of the QEMU cache type variable. You now have one setting with two completely different meanings for the same value. If you want to control whether the sheepdog driver uses a local disk for object cache you should have a completely separate QEMU command line setting which can be controlled independantly of the cache= setting. Hello Stefen and Kevin, Should sheepdog driver use another new command setting to control its internal cache? For network block device, which simply forward the IO requests from VMs via networking and never have chance to touch host's memory, I think it is okay to multiplex the 'cache=type', but it looks that it causes confusion for libvirt code. Thanks, Yuan
Re: [Qemu-devel] Questions on the virtual disk's cache type
On 01/23/2013 06:47 PM, Liu Yuan wrote: On 01/23/2013 06:14 PM, Daniel P. Berrange wrote: On Wed, Jan 23, 2013 at 06:09:01PM +0800, Liu Yuan wrote: On 01/23/2013 05:30 PM, Daniel P. Berrange wrote: FYI There is a patch proposed for customization https://review.openstack.org/#/c/18042/ Seems that this patch is dropped and declined? I should note that it is wrong to assume that enabling cache mode will improve the performance in general. Allowing caching in the host will require a non-negligable amount of host RAM to have a benefit. RAM is usually the most constrained resource in any virtualization environment. So while the cache may help performance when only one or two Vms are running on the host, it may well in fact hurt performance once the host is running enough VMs to max out RAM. So allowing caching will actually give you quite variable performance, while the cache=none will give you consistent performance regardless of host RAM utilization (underlying contention of the storage device may of course still impact things). Yeah, allowing page cache in the host might not be a good idea to run multiple VMs, but cache type in QEMU has different meaning for network block devices. For e.g, we use 'cache type' to control client side cache of Sheepdog cluster, which implement a object cache in the local disk for performance boost and reducing network traffics. This doesn't consume memory at all, just occupy the disk space where runs sheep daemon. That is a serious abuse of the QEMU cache type variable. You now have one setting with two completely different meanings for the same value. If you want to control whether the sheepdog driver uses a local disk for object cache you should have a completely separate QEMU command line setting which can be controlled independantly of the cache= setting. Hello Stefen and Kevin, Should sheepdog driver use another new command setting to control its internal cache? For network block device, which simply forward the IO requests from VMs via networking and never have chance to touch host's memory, I think it is okay to multiplex the 'cache=type', but it looks that it causes confusion for libvirt code. https://review.openstack.org/#/c/18042/ Since there is a ongoing patch set that allow customization of 'cache=type', then there is no problem both for libvirt and QEMU to multiplex this setting if this patch is allowed to get merged, since user should know the different meanings of cache type to the underlying block device, be it simulated by file (which use host memory page to cache blocks) or a network block device (which use whatever other storage to cache blocks). Thanks, Yuan
Re: [Qemu-devel] [PATCH 1.4 0/2] iscsi: add support for iovectors
Il 22/01/2013 23:55, Anthony Liguori ha scritto: Thank you for submitting your patch series. This note is to inform you that this patch series no longer applies against the latest qemu.git tree. FYI, I checked this before I let it send this. It definitely doesn't apply either with --3way or even with fuzzing. If it's against a different tree, you can just put a tag in the subject like [PATCH scsi-next 0/2] to prevent these messages in the future. Yes, it is against my pull request. Paolo
Re: [Qemu-devel] [PATCH v2] netmap backend (revised)
On Tue, Jan 22, 2013 at 08:12:15AM +0100, Luigi Rizzo wrote:
reposting a version without changes that implement bounded
queues in net/queue.c
Hi,
the attached patch implements a qemu backend for the netmap API
thus allowing machines to attach to the VALE software switch as
well as netmap-supported cards (links below).
http://info.iet.unipi.it/~luigi/netmap/
http://info.iet.unipi.it/~luigi/vale/
This is a cleaned up version of code written last summer.
Looks like a clean software approach to low-level packet I/O. I guess
the biggest competitor would be a userspace library with NIC drivers
using modern IOMMUs to avoid the security/reliability problem that
previous userspace approaches suffered. Pretty cool that netmap reuses
kernel NIC driver implementations to avoid duplicating all that code.
I wonder how/if netmaps handles advanced NIC features like multiqueue
and offloads? But I've only read the webpage, not the papers or source
code :).
diff --git a/net/Makefile.objs b/net/Makefile.objs
index a08cd14..068253f 100644
--- a/net/Makefile.objs
+++ b/net/Makefile.objs
@@ -10,3 +10,4 @@ common-obj-$(CONFIG_AIX) += tap-aix.o
common-obj-$(CONFIG_HAIKU) += tap-haiku.o
common-obj-$(CONFIG_SLIRP) += slirp.o
common-obj-$(CONFIG_VDE) += vde.o
+common-obj-$(CONFIG_NETMAP) += qemu-netmap.o
Please drop the qemu- prefix.
diff --git a/net/net.c b/net/net.c
index cdd9b04..816c987 100644
--- a/net/net.c
+++ b/net/net.c
@@ -618,6 +618,9 @@ static int (* const
net_client_init_fun[NET_CLIENT_OPTIONS_KIND_MAX])(
[NET_CLIENT_OPTIONS_KIND_BRIDGE]= net_init_bridge,
#endif
[NET_CLIENT_OPTIONS_KIND_HUBPORT] = net_init_hubport,
+#ifdef CONFIG_NETMAP
+ [NET_CLIENT_OPTIONS_KIND_NETMAP]= net_init_netmap,
+#endif
Please use 4 spaces for indentation and run scripts/checkpatch.pl to
scan patches.
};
diff --git a/net/qemu-netmap.c b/net/qemu-netmap.c
new file mode 100644
index 000..79d7c09
--- /dev/null
+++ b/net/qemu-netmap.c
@@ -0,0 +1,353 @@
+/*
+ * netmap access for qemu
+ *
+ * Copyright (c) 2012-2013 Luigi Rizzo
+ *
+ * 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 config-host.h
+
+/* note paths are different for -head and 1.3 */
Please drop this comment from the patch.
+#define ND(fd, ... ) // debugging
+#define D(format, ...) \
+do {\
+struct timeval __xxts; \
+gettimeofday(__xxts, NULL);\
+printf(%03d.%06d %s [%d] format \n,\
+(int)__xxts.tv_sec % 1000, (int)__xxts.tv_usec, \
+__FUNCTION__, __LINE__, ##__VA_ARGS__); \
+} while (0)
+
+/* rate limited, lps indicates how many per second */
+#define RD(lps, format, ...)\
+do {\
+static int t0, __cnt; \
+struct timeval __xxts; \
+gettimeofday(__xxts, NULL);\
+if (t0 != __xxts.tv_sec) { \
+t0 = __xxts.tv_sec; \
+__cnt = 0; \
+} \
+if (__cnt++ lps) \
+D(format, ##__VA_ARGS__); \
+} while (0)
Have you seen docs/tracing.txt? It can do fprintf(stderr) but also
SystemTap/DTrace and a simple built-in binary tracer.
+
+
+
+/*
+ * private netmap device info
+ */
+struct netmap_state {
QEMU code should use:
typedef struct {
...
} NetmapState;
See
Re: [Qemu-devel] [PATCH] aio-posix: Fix return value of aio_poll()
Il 23/01/2013 09:58, Dietmar Maurer ha scritto: Are you using timers in any way? Yes, I call co_sleep_ns(rt_clock, delay) to limit rate to output stream. Use block_job_sleep_ns instead, and only call it when no I/O is pending. Thanks, that works! I currently use qemu_aio_set_fd_handler() to implement async output to the backup stream. While that works, performance is much better (during backup) if I use a separate thread to write the data. Is that known behavior, or should aio give about the same performance as using a thread? It depends, but this is what we saw for migration too. You may also have less contention on the big QEMU lock if you use a thread. Or would I get better performance if I use Linux native AIO support? That also depends, but in general it should be faster. Paolo
[Qemu-devel] [PATCH V14 00/10] libqblock qemu block layer library
These patches introduce libqblock API, make subdir-libqblock and make check-libqblock could build this library. Functionalities: 1 create a new image. 2 sync access of an image. 3 basic image information retrieving such as backing file. 4 detect if a sector is allocated in an image. Supported Formats: ALL using file protocols. Patch 1 to 3 prepares qemu to accept libqblock. v2: Insert reserved bytes into union. Use uint64_t instead of size_t, offset. Use const char * in filename pointer. Initialization function removed and it was automatically executed when library is loaded. Added compile flag visibility=hidden, to avoid name space pollution. Structure naming style changed. Using byte unit instead of sector for every API. Added a member in image static information structure, to report logical sector size, which is always 512 now. Read and write API can take request not aligned to 512 now. It returns the byte number that have succeed in operation, but now either negative value or the number requested would be returned, because qemu block sync I/O API would not return such number. Typo fix due to comments and improved documents. v3: Removed the code about OOM error, introduced GError. Used a table to map from string to enum types about format. Use typedef for every structure. Improved the gcc compiler macro to warn if gcc was not used. Global variable name changed with prefix libqb_. The struct QBlockStaticInfo was changed to folder full format related information inside, and a new member with pointers pointing to the mostly used members, such as backing file, virt size, was added. This would allow the user to get full information about how it is created in the future. Each patch in the serial can work with qemu now. Typo fixes. v4: Renamed QBroker to QBlockContext. Removed tool objs out of libqblock. Added a check in initialization about structure size for ABI. Added a new helper API to duplicate protocol information, helps to open files in a backing file chain. Check-libqblock will not rebuild libqblock every time now. Test case file renamed to libqblock-[FMT].c. Test use gtest framework now. Test do random creation of test file now, added check for information API in it. Test do random sync io instead of fixed offset io now. Test accept one parameter about where to place the test image, now it is ./tests/libqblock/test_images. v5: Makefile of libqblock was adjusted to be similar as libcacard, added spec file and install section. Removed warning when GCC was not found. Structure names were changed to better ones. Removed the union typedef that contain reserved bytes to reduce the folder depth. Some format related enum options was changed to better name. Added accessors about image static information, hide indirect accessing member detail in the structure. Test Makefile do not create diretory now, test case create it themself. Test build system do not use libtool now, and removed qtest-obj-y in its dependency, make check will automatically execute test anyway now. Removed ifeq ($(LIBTOOL),) in Makefile. v6: Remove address pointer member in image static info structure. v7: Support out of tree building. v8: Fix a bug in out of tree building. v9: Rebase and splitted out small fix patch for qemu. v10: Rebased to upstream, adjusted libqblock build system according to Paolo's comments. v11: Adjusting code in patch 4 to 7, details are in the child patch's commit message. v12: Split a patch to add a function in stubs, other change are in patch 4 to 7 commit messages. v13: Moved another function into stubs, added xml rule in tests/makefile, little changes in patch 4, 6, 7. v14: all: Rebased. 1/10, 2/10: automatically call subdir's clean command if subdir's Makefile added $SUBDIR_CLEAN_RULES, so tests/Makefile do not need to be always included, libqblock's rule can also use it. 3/10: seperated patch for configure support, modified as libcacard's style. 4/10: modifed as libcacard's rule. 5/10: seperated patch, also changed a bit to be a mirror as libcacard's rule. 8/10: use bdrv_pread/bdrv_pwrite, instead of handling the buf allignment by libqblock itself. Removed libqblock-aio.c because most function are in block-obj-y now. 9/10: seperated patch, use LINK instead of custom LT_LINK rule, and now libqblock.la is a dependence in the link rule of test program, to make LINK invoke libtool. Wenchao Xia (10): 1 build: add command check-clean 2 build: use check-clean in root Makefile 3 libqblock: build: add configure support 4 libqblock: build: add rule for libqblock.la 5 libqblock: build: add packaging support 6 block: export function path_has_protocol() 7 libqblock: libqblock API design and type defines 8 libqblock: libqblock API implement 9 libqblock: build: add rules for test case 10 libqblock: test: libqblock test example Makefile |6 +-
[Qemu-devel] [PATCH V14 02/10] build: use check-clean in root Makefile
Now root Makefile simply calls the command and do not care the details of it any more. $SUBDIR_CLEAN_RULES is used for the case that a sub-dir's Makefile is included by root Makefile, in which case 'clean' in subdir's Makefile will cause confict. So If sub-dir's Makefile want to be cleaned, it should extend $SUBDIR_CLEAN_RULES, just like tests/Makefile. Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com --- Makefile |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 73adf42..69472b7 100644 --- a/Makefile +++ b/Makefile @@ -210,7 +210,7 @@ $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) qemu-ga$(EXESUF): $(qga-obj-y) libqemuutil.a libqemustub.a $(call LINK, $^) -clean: +clean: $(SUBDIR_CLEAN_RULES) # avoid old build problems by removing potentially incorrect old files rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h rm -f qemu-options.def @@ -226,7 +226,6 @@ clean: rm -f $(foreach f,$(GENERATED_SOURCES),$(f) $(f)-timestamp) rm -rf qapi-generated rm -rf qga/qapi-generated - $(MAKE) -C tests/tcg clean for d in $(ALL_SUBDIRS); do \ if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \ rm -f $$d/qemu-options.def; \ -- 1.7.1
[Qemu-devel] [PATCH V14 01/10] build: add command check-clean
This command will package the clean operations in tests, to make it easy to be extended. Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com --- tests/Makefile | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index d86e95a..9a759a1 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -122,6 +122,11 @@ qtest-obj-y = tests/libqtest.o libqemuutil.a libqemustub.a qtest-obj-y += tests/libi2c.o tests/libi2c-omap.o $(check-qtest-y): $(qtest-obj-y) +#clean rules + +CHECK_CLEAN_TARGETS=$(check-unit-y) $(check-qtest-i386-y) $(check-qtest-x86_64-y) $(check-qtest-sparc64-y) $(check-qtest-sparc-y) tests/*.o +SUBDIR_CLEAN_RULES+=check-clean + .PHONY: check-help check-help: @echo Regression testing targets: @@ -132,6 +137,7 @@ check-help: @echo make check-unit Run qobject tests @echo make check-block Run block tests @echo make check-report.htmlGenerates an HTML test report + @echo make check-clean Clean the tests @echo @echo Please note that HTML reports do not regenerate if the unit tests @echo has not changed. @@ -191,10 +197,14 @@ check-tests/qemu-iotests-quick.sh: tests/qemu-iotests-quick.sh qemu-img$(EXESUF) # Consolidated targets -.PHONY: check-qtest check-unit check +.PHONY: check-qtest check-unit check check-clean check-qtest: $(patsubst %,check-qtest-%, $(QTEST_TARGETS)) check-unit: $(patsubst %,check-%, $(check-unit-y)) check-block: $(patsubst %,check-%, $(check-block-y)) check: check-unit check-qtest +check-clean: + $(MAKE) -C tests/tcg clean + rm -rf $(CHECK_CLEAN_TARGETS) + -include $(wildcard tests/*.d) -- 1.7.1
[Qemu-devel] [PATCH V14 10/10] libqblock: test: libqblock test example
In this example, first it will create some qcow2 images, then try get
information including backing file relationship, then it will do sync IO on
the image.
Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
---
tests/check-libqblock-qcow2.c | 392 +
1 files changed, 392 insertions(+), 0 deletions(-)
create mode 100644 tests/check-libqblock-qcow2.c
diff --git a/tests/check-libqblock-qcow2.c b/tests/check-libqblock-qcow2.c
new file mode 100644
index 000..1b583e8
--- /dev/null
+++ b/tests/check-libqblock-qcow2.c
@@ -0,0 +1,392 @@
+/*
+ * QEMU block layer library test
+ *
+ * Copyright IBM, Corp. 2012
+ *
+ * Authors:
+ * Wenchao Xia xiaw...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ * Limitation:
+ *1 filename do not support relative path, to save trouble in creating
+ * backing files.
+ */
+
+#include glib.h
+#include stdarg.h
+#include stdio.h
+#include unistd.h
+#include inttypes.h
+#include string.h
+#include stdlib.h
+#include sys/stat.h
+#include sys/types.h
+
+
+#include libqblock.h
+#include libqtest.h
+
+#define LIBQB_TEST_ENV_DIR LIBQBLOCK_TEST_DIR
+#define LIBQB_TEST_DEFAULT_DIR /tmp
+#define LIBQB_TEST_DEFAULT_FILENAME libqblock_qcow2_test_img
+
+typedef struct LibqbTestSettings {
+const char *image_filename;
+uint64_t image_size;
+unsigned int num_backings;
+unsigned int io_buf_size;
+uint64_t io_offset;
+int print_flag;
+} LibqbTestSettings;
+
+LibqbTestSettings libqb_test_settings;
+
+static void print_loc(const QBlockLocationInfo *loc)
+{
+if (loc == NULL) {
+printf(loc is NULL.);
+return;
+}
+switch (loc-prot_type) {
+case QB_PROTO_NONE:
+printf(protocol type [none].);
+break;
+case QB_PROTO_FILE:
+printf(protocol type [file], filename [%s].,
+ loc-o_file.filename);
+break;
+default:
+printf(protocol type not supported.);
+break;
+}
+}
+
+static void print_info_image_static(QBlockStaticInfo *info)
+{
+const uint64_t *virt_size = qb_get_virt_size(info);
+const QBlockLocationInfo *backing_loc = qb_get_backing_loc(info);
+g_assert(virt_size != NULL);
+
+printf(===image location:\n);
+print_loc(info-loc);
+printf(\nvirtual_size % PRId64 , format type %d [%s],
+ *(virt_size),
+ info-fmt.fmt_type, qb_fmttype2str(info-fmt.fmt_type));
+printf(\nbacking image location:\n);
+print_loc(backing_loc);
+printf(\n);
+}
+
+static char *generate_backing_filename(const char *filename, int index)
+{
+char *backing_filename = NULL;
+
+backing_filename = g_strdup_printf(%s_backing_%d, filename, index);
+return backing_filename;
+}
+
+/* get filename in a full path */
+static const char *get_filename(const char *path)
+{
+const char *filename;
+filename = strrchr(path, '/');
+if (filename == NULL) {
+filename = path;
+} else {
+filename++;
+}
+return filename;
+}
+
+/* create a chain of files, num_backings must = 0. */
+static void files_create_qcow2(const char *filename,
+ int num_backings,
+ uint64_t virt_size)
+{
+QBlockContext *context = NULL;
+QBlockImage *qbi = NULL;
+QBlockLocationInfo *loc_info = NULL;
+QBlockFormatInfo *fmt_info = NULL;
+int ret;
+int index;
+int flag;
+char *backing_filename = NULL, *new_filename = NULL;
+const char *relative_filename = NULL;
+
+ret = qb_context_new(context);
+g_assert(ret == 0);
+
+ret = qb_image_new(context, qbi);
+g_assert(ret == 0);
+
+ret = qb_loc_info_new(context, loc_info);
+g_assert(ret == 0);
+
+ret = qb_fmt_info_new(context, fmt_info);
+g_assert(ret == 0);
+
+loc_info-prot_type = QB_PROTO_FILE;
+fmt_info-fmt_type = QB_FMT_QCOW2;
+fmt_info-virt_size = virt_size;
+flag = 0;
+
+index = 0;
+while (index num_backings) {
+new_filename = generate_backing_filename(filename, index);
+loc_info-o_file.filename = new_filename;
+if (backing_filename != NULL) {
+fmt_info-o_qcow2.backing_loc.prot_type = QB_PROTO_FILE;
+relative_filename = get_filename(backing_filename);
+fmt_info-o_qcow2.backing_loc.o_file.filename =
+ relative_filename;
+}
+ret = qb_create(context, qbi, loc_info, fmt_info, flag);
+g_assert(ret == 0);
+free(backing_filename);
+backing_filename = new_filename;
+new_filename = NULL;
+index++;
+}
+
+loc_info-o_file.filename = filename;
+if (backing_filename != NULL) {
+fmt_info-o_qcow2.backing_loc.prot_type = QB_PROTO_FILE;
+relative_filename = get_filename(backing_filename);
+
[Qemu-devel] [PATCH V14 06/10] block: export function path_has_protocol()
libqblock need to use it.
Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
---
block.c |2 +-
include/block/block.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/block.c b/block.c
index 6fa7c90..67afd6a 100644
--- a/block.c
+++ b/block.c
@@ -195,7 +195,7 @@ static void bdrv_io_limits_intercept(BlockDriverState *bs,
}
/* check if the path starts with protocol: */
-static int path_has_protocol(const char *path)
+int path_has_protocol(const char *path)
{
const char *p;
diff --git a/include/block/block.h b/include/block/block.h
index ffd1936..7401f44 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -392,6 +392,8 @@ void bdrv_acct_start(BlockDriverState *bs, BlockAcctCookie
*cookie,
int64_t bytes, enum BlockAcctType type);
void bdrv_acct_done(BlockDriverState *bs, BlockAcctCookie *cookie);
+int path_has_protocol(const char *path);
+
typedef enum {
BLKDBG_L1_UPDATE,
--
1.7.1
[Qemu-devel] [PATCH V14 05/10] libqblock: build: add packaging support
Now libqblock can be packaged and installed by
sudo make install-libqblock'.
Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
---
libqblock/Makefile | 37 -
libqblock/libqblock.pc.in | 13 +
2 files changed, 45 insertions(+), 5 deletions(-)
create mode 100644 libqblock/libqblock-error.h
create mode 100644 libqblock/libqblock-types.h
create mode 100644 libqblock/libqblock.h
create mode 100644 libqblock/libqblock.pc.in
diff --git a/libqblock/Makefile b/libqblock/Makefile
index cdbfffb..b1c9897 100644
--- a/libqblock/Makefile
+++ b/libqblock/Makefile
@@ -1,4 +1,6 @@
-TOOLS += libqblock.la
+libqblock_includedir= $(includedir)/qblock
+
+TOOLS += libqblock.la libqblock.pc
# objects linked into a shared library, built with libtool with -fPIC if
required
libqblock-obj-y = $(libqblock-y) $(util-obj-y)
@@ -7,13 +9,22 @@ libqblock-obj-y += $(block-obj-y)
libqblock-lobj-y=$(patsubst %.o, %.lo, $(libqblock-obj-y))
+libqblock-pub-headers= $(SRC_PATH)/libqblock/libqblock.h \
+ $(SRC_PATH)/libqblock/libqblock-types.h \
+ $(SRC_PATH)/libqblock/libqblock-error.h
+
+libqblock-requires-y = rt gthread-2.0 glib-2.0 z
+libqblock-requires-$(CONFIG_CURL) += curl
+libqblock-requires-$(CONFIG_LIBCAP) += cap-ng
+libqblock-requires-$(CONFIG_UUID) += uuid
+
# libtool will build the .o files, too
$(libqblock-obj-y): | $(libqblock-lobj-y)
-LIBQBLOCK_CLEAN_TARGETS=$(libqblock-lobj-y) libqblock.la libqblock/.libs
+LIBQBLOCK_CLEAN_TARGETS=$(libqblock-lobj-y) libqblock.la libqblock.pc
libqblock/.libs
SUBDIR_CLEAN_RULES+=libqblock-clean
-all: libqblock.la
+all: libqblock.la libqblock.pc
#
# Rules for building libqblock standalone library
@@ -24,8 +35,24 @@ libqblock.la: LDFLAGS += -rpath $(libdir) -no-undefined \
libqblock.la: $(libqblock-lobj-y)
$(call LINK,$^)
-
-.PHONY: libqblock-clean
+libqblock.pc: $(SRC_PATH)/libqblock/libqblock.pc.in
+ $(call quiet-command,sed -e 's|@LIBDIR@|$(libdir)|' \
+ -e 's|@INCLUDEDIR@|$(libqblock_includedir)|' \
+ -e 's|@VERSION@|$(shell cat $(SRC_PATH)/VERSION)|' \
+ -e 's|@PREFIX@|$(prefix)|' \
+ -e 's|@REQUIRES@|$(libqblock-requires-y)|' \
+ $ libqblock.pc,\
+ GEN $@)
+
+.PHONY: libqblock-clean install-libqblock
+
+install-libqblock: libqblock.la libqblock.pc
+ $(INSTALL_DIR) $(DESTDIR)$(libdir)
+ $(INSTALL_DIR) $(DESTDIR)$(libdir)/pkgconfig
+ $(INSTALL_DIR) $(DESTDIR)$(libqblock_includedir)
+ $(INSTALL_LIB) libqblock.la $(DESTDIR)$(libdir)
+ $(INSTALL_DATA) libqblock.pc $(DESTDIR)$(libdir)/pkgconfig
+ $(INSTALL_DATA) $(libqblock-pub-headers)
$(DESTDIR)$(libqblock_includedir)
libqblock-clean:
rm $(LIBQBLOCK_CLEAN_TARGETS) -rf
diff --git a/libqblock/libqblock-error.h b/libqblock/libqblock-error.h
new file mode 100644
index 000..e69de29
diff --git a/libqblock/libqblock-types.h b/libqblock/libqblock-types.h
new file mode 100644
index 000..e69de29
diff --git a/libqblock/libqblock.h b/libqblock/libqblock.h
new file mode 100644
index 000..e69de29
diff --git a/libqblock/libqblock.pc.in b/libqblock/libqblock.pc.in
new file mode 100644
index 000..0901672
--- /dev/null
+++ b/libqblock/libqblock.pc.in
@@ -0,0 +1,13 @@
+prefix=@PREFIX@
+exec_prefix=${prefix}
+libdir=@LIBDIR@
+includedir=@INCLUDEDIR@
+
+Name: qblock
+Description: Qemu block layer library
+Version: @VERSION@
+
+Requires: @REQUIRES@
+Libs: -L${libdir} -lqblock
+Libs.private:
+Cflags: -I${includedir}
--
1.7.1
[Qemu-devel] [PATCH V14 09/10] libqblock: build: add rules for test case
Libtool will be used for final link, the rules do nothing if libqblock was disabled. Temp directory was used to store image created in test, which will be deleted in clean. Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com --- tests/Makefile | 29 ++--- 1 files changed, 26 insertions(+), 3 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index 9a759a1..e5a47af 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -122,9 +122,19 @@ qtest-obj-y = tests/libqtest.o libqemuutil.a libqemustub.a qtest-obj-y += tests/libi2c.o tests/libi2c-omap.o $(check-qtest-y): $(qtest-obj-y) +#libqblock build rules + +LIBQBLOCK_LA = libqblock.la +LIBQBLOCK_TEST_DIR = tests/test_images +check-libqblock-$(CONFIG_LIBQBLOCK) = tests/check-libqblock-qcow2$(EXESUF) +$(check-libqblock-y): QEMU_INCLUDES += -I$(SRC_PATH)/tests -I$(SRC_PATH)/libqblock + +$(check-libqblock-y): %$(EXESUF): %.o $(LIBQBLOCK_LA) + $(call LINK, $^) + #clean rules -CHECK_CLEAN_TARGETS=$(check-unit-y) $(check-qtest-i386-y) $(check-qtest-x86_64-y) $(check-qtest-sparc64-y) $(check-qtest-sparc-y) tests/*.o +CHECK_CLEAN_TARGETS=$(check-unit-y) $(check-qtest-i386-y) $(check-qtest-x86_64-y) $(check-qtest-sparc64-y) $(check-qtest-sparc-y) tests/*.o $(check-libqblock-y) $(LIBQBLOCK_TEST_DIR) SUBDIR_CLEAN_RULES+=check-clean .PHONY: check-help @@ -136,6 +146,7 @@ check-help: @echo make check-qtest Run qtest tests @echo make check-unit Run qobject tests @echo make check-block Run block tests + @echo make check-libqblock Run libqblock tests @echo make check-report.htmlGenerates an HTML test report @echo make check-clean Clean the tests @echo @@ -180,9 +191,20 @@ $(patsubst %, check-report-qtest-%.xml, $(QTEST_TARGETS)): check-report-qtest-%. check-report-unit.xml: $(check-unit-y) $(call quiet-command,gtester -q $(GTESTER_OPTIONS) -o $@ -m=$(SPEED) $^, GTESTER $@) +# gtester tests with libqblock + +check-report-libqblock-$(CONFIG_LIBQBLOCK) = check-report-libqblock.xml + +.PHONY: $(patsubst %, check-%, $(check-libqblock-y)) +$(patsubst %, check-%, $(check-libqblock-y)): check-%: % + $(call quiet-command, LIBQBLOCK_TEST_DIR=$(LIBQBLOCK_TEST_DIR) gtester $(GTESTER_OPTIONS) -m=$(SPEED) $*,GTESTER $*) + +$(check-report-libqblock-y): $(check-libqblock-y) + $(call quiet-command,gtester -q $(GTESTER_OPTIONS) -o $@ -m=$(SPEED) $^, GTESTER $@) + # Reports and overall runs -check-report.xml: $(patsubst %,check-report-qtest-%.xml, $(QTEST_TARGETS)) check-report-unit.xml +check-report.xml: $(patsubst %,check-report-qtest-%.xml, $(QTEST_TARGETS)) check-report-unit.xml $(check-report-libqblock-y) $(call quiet-command,$(SRC_PATH)/scripts/gtester-cat $^ $@, GEN $@) check-report.html: check-report.xml @@ -197,10 +219,11 @@ check-tests/qemu-iotests-quick.sh: tests/qemu-iotests-quick.sh qemu-img$(EXESUF) # Consolidated targets -.PHONY: check-qtest check-unit check check-clean +.PHONY: check-qtest check-unit check-libqblock check check-clean check-qtest: $(patsubst %,check-qtest-%, $(QTEST_TARGETS)) check-unit: $(patsubst %,check-%, $(check-unit-y)) check-block: $(patsubst %,check-%, $(check-block-y)) +check-libqblock: $(patsubst %,check-%, $(check-libqblock-y)) check: check-unit check-qtest check-clean: -- 1.7.1
[Qemu-devel] [PATCH V14 08/10] libqblock: libqblock API implement
This patch contains implemention for APIs. Basically it is a layer
above qemu block general layer now.
Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
---
libqblock/libqblock-error.c | 57 +++
libqblock/libqblock.c | 1071 +++
2 files changed, 1128 insertions(+), 0 deletions(-)
diff --git a/libqblock/libqblock-error.c b/libqblock/libqblock-error.c
index e69de29..2a59970 100644
--- a/libqblock/libqblock-error.c
+++ b/libqblock/libqblock-error.c
@@ -0,0 +1,57 @@
+/*
+ * QEMU block layer library
+ *
+ * Copyright IBM, Corp. 2012
+ *
+ * Authors:
+ * Wenchao Xia xiaw...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include libqblock-error.h
+#include libqblock-internal.h
+
+void qb_error_get_human_str(QBlockContext *context,
+char *buf, size_t buf_size)
+{
+const char *err_ret_str;
+switch (context-err_ret) {
+case QB_ERR_INTERNAL_ERR:
+err_ret_str = Internal error.;
+break;
+case QB_ERR_INVALID_PARAM:
+err_ret_str = Invalid param.;
+break;
+case QB_ERR_BLOCK_OUT_OF_RANGE:
+err_ret_str = request is out of image's range.;
+break;
+default:
+err_ret_str = Unknown error.;
+break;
+}
+if (context == NULL) {
+snprintf(buf, buf_size, %s, err_ret_str);
+return;
+}
+
+if (context-err_ret == QB_ERR_INTERNAL_ERR) {
+snprintf(buf, buf_size, %s %s errno [%d]. strerror [%s].,
+ err_ret_str, context-g_error-message,
+ context-err_no, strerror(-context-err_no));
+} else {
+snprintf(buf, buf_size, %s %s,
+ err_ret_str, context-g_error-message);
+}
+return;
+}
+
+int qb_error_get_errno(QBlockContext *context)
+{
+if (context-err_ret == QB_ERR_INTERNAL_ERR) {
+return context-err_no;
+}
+return 0;
+}
diff --git a/libqblock/libqblock.c b/libqblock/libqblock.c
index e69de29..d53a7a5 100644
--- a/libqblock/libqblock.c
+++ b/libqblock/libqblock.c
@@ -0,0 +1,1071 @@
+/*
+ * QEMU block layer library
+ *
+ * Copyright IBM, Corp. 2012
+ *
+ * Authors:
+ * Wenchao Xia xiaw...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include unistd.h
+#include stdarg.h
+#include pthread.h
+
+#include libqblock.h
+#include libqblock-internal.h
+
+#include block/block_int.h
+
+#define LIBQB_FILENAME_MAX 4096
+
+typedef struct LibqbFormatStrMapping {
+const char *fmt_str;
+QBlockFormat fmt_type;
+} LibqbFormatStrMapping;
+
+LibqbFormatStrMapping libqb_fmtstr_table[] = {
+{cow, QB_FMT_COW},
+{qed, QB_FMT_QED},
+{qcow, QB_FMT_QCOW},
+{qcow2, QB_FMT_QCOW2},
+{raw, QB_FMT_RAW},
+{rbd, QB_FMT_RBD},
+{sheepdog, QB_FMT_SHEEPDOG},
+{vdi, QB_FMT_VDI},
+{vmdk, QB_FMT_VMDK},
+{vpc, QB_FMT_VPC},
+{NULL, 0},
+};
+
+__attribute__((constructor))
+static void libqblock_init(void)
+{
+/* Todo: add an assertion about the ABI. */
+qemu_init_main_loop();
+bdrv_init();
+}
+
+const char *qb_fmttype2str(QBlockFormat fmt_type)
+{
+int i = 0;
+LibqbFormatStrMapping *tb = libqb_fmtstr_table;
+
+if ((fmt_type = QB_FMT_NONE) || (fmt_type = QB_FMT_MAX)) {
+return NULL;
+}
+while (tb[i].fmt_str != NULL) {
+if (tb[i].fmt_type == fmt_type) {
+return tb[i].fmt_str;
+}
+i++;
+}
+return NULL;
+}
+
+QBlockFormat qb_str2fmttype(const char *fmt_str)
+{
+int i = 0;
+LibqbFormatStrMapping *tb = libqb_fmtstr_table;
+
+if (fmt_str == NULL) {
+return QB_FMT_NONE;
+}
+while (tb[i].fmt_str != NULL) {
+if ((strcmp(fmt_str, tb[i].fmt_str) == 0)) {
+return tb[i].fmt_type;
+}
+i++;
+}
+return QB_FMT_NONE;
+}
+
+static void set_context_err(QBlockContext *context, int err_ret,
+const char *fmt, ...)
+{
+va_list ap;
+
+if (context-g_error != NULL) {
+g_error_free(context-g_error);
+}
+
+va_start(ap, fmt);
+context-g_error = g_error_new_valist(G_LIBQBLOCK_ERROR, err_ret, fmt, ap);
+va_end(ap);
+
+context-err_ret = err_ret;
+if (err_ret == QB_ERR_INTERNAL_ERR) {
+context-err_no = -errno;
+} else {
+context-err_no = 0;
+}
+}
+
+int qb_context_new(QBlockContext **p_context)
+{
+*p_context = g_malloc0_n(1, sizeof(QBlockContext));
+
+/* AIO code could comes here later. */
+return 0;
+}
+
+void qb_context_delete(QBlockContext **p_context)
+{
+if ((*p_context)-g_error != NULL) {
+g_error_free((*p_context)-g_error);
+}
+QB_FREE(*p_context);
+return;
+}
+
+int qb_image_new(QBlockContext *context,
+
Re: [Qemu-devel] [PATCH V14 04/10] libqblock: build: add rule for libqblock.la
Il 23/01/2013 12:18, Wenchao Xia ha scritto: Now libqblock.la can be built with neccessary object files, and can be automatically cleaned by make clean in root directory. make libqblock-clean also clean it. -fvisibility=hidden was used to hide symbols, and a special macro was introduced to export symbols that marked as public. Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com --- Makefile.objs |7 +++ libqblock/Makefile | 31 +-- 2 files changed, 36 insertions(+), 2 deletions(-) create mode 100644 libqblock/libqblock-error.c create mode 100644 libqblock/libqblock.c diff --git a/Makefile.objs b/Makefile.objs index d465a72..ab2712d 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -89,6 +89,13 @@ libcacard-y += libcacard/card_7816.o common-obj-$(CONFIG_SMARTCARD_NSS) += $(libcacard-y) ## +# libqblock + +libqblock-y += libqblock/libqblock.o libqblock/libqblock-error.o + +common-obj-$(CONFIG_LIBQBLOCK) += $(libqblock-y) This is not needed. Just include the libqblock/ files into libqblock/Makefile. Otherwise seems okay. Paolo +## # qapi common-obj-y += qmp-marshal.o qapi-visit.o qapi-types.o diff --git a/libqblock/Makefile b/libqblock/Makefile index 734d90e..cdbfffb 100644 --- a/libqblock/Makefile +++ b/libqblock/Makefile @@ -1,4 +1,31 @@ TOOLS += libqblock.la -libqblock.la: - @true +# objects linked into a shared library, built with libtool with -fPIC if required +libqblock-obj-y = $(libqblock-y) $(util-obj-y) +libqblock-obj-y += $(filter-out stubs/set-fd-handler.o, $(stub-obj-y)) +libqblock-obj-y += $(block-obj-y) + +libqblock-lobj-y=$(patsubst %.o, %.lo, $(libqblock-obj-y)) + +# libtool will build the .o files, too +$(libqblock-obj-y): | $(libqblock-lobj-y) + +LIBQBLOCK_CLEAN_TARGETS=$(libqblock-lobj-y) libqblock.la libqblock/.libs +SUBDIR_CLEAN_RULES+=libqblock-clean + +all: libqblock.la + +# +# Rules for building libqblock standalone library + +$(libqblock-lobj-y): QEMU_CFLAGS+= -fvisibility=hidden -D LIBQB_BUILD +libqblock.la: LDFLAGS += -rpath $(libdir) -no-undefined \ + -export-syms $(SRC_PATH)/libqblock/libqblock.syms +libqblock.la: $(libqblock-lobj-y) + $(call LINK,$^) + + +.PHONY: libqblock-clean + +libqblock-clean: + rm $(LIBQBLOCK_CLEAN_TARGETS) -rf diff --git a/libqblock/libqblock-error.c b/libqblock/libqblock-error.c new file mode 100644 index 000..e69de29 diff --git a/libqblock/libqblock.c b/libqblock/libqblock.c new file mode 100644 index 000..e69de29
Re: [Qemu-devel] [PATCH V14 03/10] libqblock: build: add configure support
Il 23/01/2013 12:18, Wenchao Xia ha scritto: @@ -0,0 +1,4 @@ +TOOLS += libqblock.la This is not needed since you have all: libqblock.la in patch 4. Otherwise looks good. + +libqblock.la: + @true Paolo
Re: [Qemu-devel] [PATCH V14 09/10] libqblock: build: add rules for test case
Il 23/01/2013 12:18, Wenchao Xia ha scritto: Libtool will be used for final link, the rules do nothing if libqblock was disabled. Temp directory was used to store image created in test, which will be deleted in clean. Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com --- tests/Makefile | 29 ++--- 1 files changed, 26 insertions(+), 3 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index 9a759a1..e5a47af 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -122,9 +122,19 @@ qtest-obj-y = tests/libqtest.o libqemuutil.a libqemustub.a qtest-obj-y += tests/libi2c.o tests/libi2c-omap.o $(check-qtest-y): $(qtest-obj-y) +#libqblock build rules + +LIBQBLOCK_LA = libqblock.la Please inline this in the rule, and just put it in make check-unit. Paolo +LIBQBLOCK_TEST_DIR = tests/test_images +check-libqblock-$(CONFIG_LIBQBLOCK) = tests/check-libqblock-qcow2$(EXESUF) +$(check-libqblock-y): QEMU_INCLUDES += -I$(SRC_PATH)/tests -I$(SRC_PATH)/libqblock + +$(check-libqblock-y): %$(EXESUF): %.o $(LIBQBLOCK_LA) + $(call LINK, $^) + #clean rules -CHECK_CLEAN_TARGETS=$(check-unit-y) $(check-qtest-i386-y) $(check-qtest-x86_64-y) $(check-qtest-sparc64-y) $(check-qtest-sparc-y) tests/*.o +CHECK_CLEAN_TARGETS=$(check-unit-y) $(check-qtest-i386-y) $(check-qtest-x86_64-y) $(check-qtest-sparc64-y) $(check-qtest-sparc-y) tests/*.o $(check-libqblock-y) $(LIBQBLOCK_TEST_DIR) SUBDIR_CLEAN_RULES+=check-clean .PHONY: check-help @@ -136,6 +146,7 @@ check-help: @echo make check-qtest Run qtest tests @echo make check-unit Run qobject tests @echo make check-block Run block tests + @echo make check-libqblock Run libqblock tests @echo make check-report.htmlGenerates an HTML test report @echo make check-clean Clean the tests @echo @@ -180,9 +191,20 @@ $(patsubst %, check-report-qtest-%.xml, $(QTEST_TARGETS)): check-report-qtest-%. check-report-unit.xml: $(check-unit-y) $(call quiet-command,gtester -q $(GTESTER_OPTIONS) -o $@ -m=$(SPEED) $^, GTESTER $@) +# gtester tests with libqblock + +check-report-libqblock-$(CONFIG_LIBQBLOCK) = check-report-libqblock.xml + +.PHONY: $(patsubst %, check-%, $(check-libqblock-y)) +$(patsubst %, check-%, $(check-libqblock-y)): check-%: % + $(call quiet-command, LIBQBLOCK_TEST_DIR=$(LIBQBLOCK_TEST_DIR) gtester $(GTESTER_OPTIONS) -m=$(SPEED) $*,GTESTER $*) + +$(check-report-libqblock-y): $(check-libqblock-y) + $(call quiet-command,gtester -q $(GTESTER_OPTIONS) -o $@ -m=$(SPEED) $^, GTESTER $@) + # Reports and overall runs -check-report.xml: $(patsubst %,check-report-qtest-%.xml, $(QTEST_TARGETS)) check-report-unit.xml +check-report.xml: $(patsubst %,check-report-qtest-%.xml, $(QTEST_TARGETS)) check-report-unit.xml $(check-report-libqblock-y) $(call quiet-command,$(SRC_PATH)/scripts/gtester-cat $^ $@, GEN $@) check-report.html: check-report.xml @@ -197,10 +219,11 @@ check-tests/qemu-iotests-quick.sh: tests/qemu-iotests-quick.sh qemu-img$(EXESUF) # Consolidated targets -.PHONY: check-qtest check-unit check check-clean +.PHONY: check-qtest check-unit check-libqblock check check-clean check-qtest: $(patsubst %,check-qtest-%, $(QTEST_TARGETS)) check-unit: $(patsubst %,check-%, $(check-unit-y)) check-block: $(patsubst %,check-%, $(check-block-y)) +check-libqblock: $(patsubst %,check-%, $(check-libqblock-y)) check: check-unit check-qtest check-clean:
Re: [Qemu-devel] [PATCH V14 02/10] build: use check-clean in root Makefile
Il 23/01/2013 12:17, Wenchao Xia ha scritto: Now root Makefile simply calls the command and do not care the details of it any more. $SUBDIR_CLEAN_RULES is used for the case that a sub-dir's Makefile is included by root Makefile, in which case 'clean' in subdir's Makefile will cause confict. So If sub-dir's Makefile want to be cleaned, it should extend $SUBDIR_CLEAN_RULES, just like tests/Makefile. Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com --- Makefile |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 73adf42..69472b7 100644 --- a/Makefile +++ b/Makefile @@ -210,7 +210,7 @@ $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) qemu-ga$(EXESUF): $(qga-obj-y) libqemuutil.a libqemustub.a $(call LINK, $^) -clean: +clean: $(SUBDIR_CLEAN_RULES) # avoid old build problems by removing potentially incorrect old files rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h rm -f qemu-options.def @@ -226,7 +226,6 @@ clean: rm -f $(foreach f,$(GENERATED_SOURCES),$(f) $(f)-timestamp) rm -rf qapi-generated rm -rf qga/qapi-generated - $(MAKE) -C tests/tcg clean for d in $(ALL_SUBDIRS); do \ if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \ rm -f $$d/qemu-options.def; \ Just use clean: check-clean and squash this with patch 1. Paolo
[Qemu-devel] [RFC] qemu snapshot enchancement
Hi, I am trying to enhancement qemu's snapshot functionality, and have write a wiki draft on: http://wiki.qemu.org/Features/VMSnapshotEnchancement It mainly serves backup APP, the centric of it is: 1 fixing the vmstate size problem. 2 save vmstate lively for any type. 3 introduce new live snapshot mode, which offload qemu block function to lower components, such as LVM2 or other software even hardware accelerated one. 4 complete the picture of snapshots so they have similar or unified API for block / vmstate / whole vm, and doc it. Please feel free to point out any problem you find or give suggestion. -- Best Regards Wenchao Xia
Re: [Qemu-devel] [PATCH V14 02/10] build: use check-clean in root Makefile
于 2013-1-23 19:32, Paolo Bonzini 写道: Il 23/01/2013 12:17, Wenchao Xia ha scritto: Now root Makefile simply calls the command and do not care the details of it any more. $SUBDIR_CLEAN_RULES is used for the case that a sub-dir's Makefile is included by root Makefile, in which case 'clean' in subdir's Makefile will cause confict. So If sub-dir's Makefile want to be cleaned, it should extend $SUBDIR_CLEAN_RULES, just like tests/Makefile. Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com --- Makefile |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 73adf42..69472b7 100644 --- a/Makefile +++ b/Makefile @@ -210,7 +210,7 @@ $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) qemu-ga$(EXESUF): $(qga-obj-y) libqemuutil.a libqemustub.a $(call LINK, $^) -clean: +clean: $(SUBDIR_CLEAN_RULES) # avoid old build problems by removing potentially incorrect old files rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h rm -f qemu-options.def @@ -226,7 +226,6 @@ clean: rm -f $(foreach f,$(GENERATED_SOURCES),$(f) $(f)-timestamp) rm -rf qapi-generated rm -rf qga/qapi-generated - $(MAKE) -C tests/tcg clean for d in $(ALL_SUBDIRS); do \ if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \ rm -f $$d/qemu-options.def; \ Just use clean: check-clean and squash this with patch 1. Paolo That have a problem if test/Makefile is not included, which will happen if make distclean is called once, then error will be shown if make clean called again. It is also used by libqblock clean. -- Best Regards Wenchao Xia
Re: [Qemu-devel] [PATCH] aio-posix: Fix return value of aio_poll()
I currently use qemu_aio_set_fd_handler() to implement async output to the backup stream. While that works, performance is much better (during backup) if I use a separate thread to write the data. Is that known behavior, or should aio give about the same performance as using a thread? It depends, but this is what we saw for migration too. You may also have less contention on the big QEMU lock if you use a thread. But when I use a thread it triggers the bug in bdrv_drain_all(). So how can I fix bdrv_drain_all() if I use a separate thread to write data? I currently use CoQueue to wait for the output thread. Maybe there is some example code somewhere? Or would I get better performance if I use Linux native AIO support? That also depends, but in general it should be faster. Is there an easy way to switch to native AIO? The code in block/linux-aio.c is only usable inside block drivers? I simply need to write to a unix file descriptor.
Re: [Qemu-devel] [PATCH] aio-posix: Fix return value of aio_poll()
Il 23/01/2013 12:37, Dietmar Maurer ha scritto: I currently use qemu_aio_set_fd_handler() to implement async output to the backup stream. While that works, performance is much better (during backup) if I use a separate thread to write the data. Is that known behavior, or should aio give about the same performance as using a thread? It depends, but this is what we saw for migration too. You may also have less contention on the big QEMU lock if you use a thread. But when I use a thread it triggers the bug in bdrv_drain_all(). So how can I fix bdrv_drain_all() if I use a separate thread to write data? The bug is, in all likelihood, in your own code. Sorry. :) I currently use CoQueue to wait for the output thread. The simplest way to synchronize the main event loop with another thread is a bottom half. There is no example yet, but I will post it soon for migration. In the other direction, use an EventNotifier (for which bottom halves are just a nice wrapper). Maybe there is some example code somewhere? Or would I get better performance if I use Linux native AIO support? That also depends, but in general it should be faster. Is there an easy way to switch to native AIO? The code in block/linux-aio.c is only usable inside block drivers? I simply need to write to a unix file descriptor. First of all, AIO is only usable for files and block devices, not character devices or sockets. If you have one, you can use the block device API rather than the file descriptor API to write it. You'll get native AIO support for free. Support for running the block drivers in a separate thread is not there yet, but I predict it will come later this year. Paolo
Re: [Qemu-devel] [PATCH V14 02/10] build: use check-clean in root Makefile
Il 23/01/2013 12:35, Wenchao Xia ha scritto: Just use clean: check-clean and squash this with patch 1. Paolo That have a problem if test/Makefile is not included, which will happen if make distclean is called once, then error will be shown if make clean called again. It is also used by libqblock clean. You can put the dependency in tests/Makefile. Paolo
Re: [Qemu-devel] [BUG] qemu-1.1.2 [FIXED-BY] qcow2: Fix avail_sectors in cluster allocation code
Am 22.01.2013 15:14, schrieb Kevin Wolf: The series of requests to get into this state is somewhat tricky as it requires a specific physical ordering of clusters in the image file: Host cluster h: Guest cluster g is mapped to here Host cluster h + 1: Free, can be allocated for not yet mapped g + 1 Host cluster h + 2: Guest cluster g + 2 is mapped to here I can get this with this command on a fresh qcow2 image (64k cluster size): ./qemu-io -c 'write -P 0x66 0 64k' -c 'write 64k 64k' -c 'write -P 0x88 128k 64k' -c 'discard 64k 64k' -c 'write -P 0x77 0 160k' /tmp/test.qcow2 Now I get an additional COW for the area from 96k to 128k. However, this alone doesn't corrupt an image - a copy on write by itself is harmless because it only rewrites the data that is already there. The two things I'm going to check next are: a) What happens with concurrent requests now, are requests for the same area still correctly serialised? b) Can I modify the parameters so that copy_sectors() is working with values it wasn't designed for so that the data is copied to a wrong place or something like that. m-nb_available is used as an argument to it, so it certainly seems realistic. I can reliably reproduce a bug with a) at least. It requires some backports to qemu-io in order to get more control of the timing of AIO requests, but then it works like this: write -P 0x66 0 320k write 320k 128k write -P 0x88 448k 128k discard 320k 128k aio_flush break cow_write A aio_write -P 0x77 0 480k wait_break A write -P 0x99 480k 32k resume A aio_flush read -P 0x77 0 480k read -P 0x99 480k 32k read -P 0x88 512k 64k What happens is that the write of 0x99 to 480k doesn't detect an overlap with the running AIO request (because obviously it doesn't overlap), but the COW is actually taking place in the wrong cluster and therefore unprotected. Stop the AIO request between the COW read and the COW write to write 0x99 to that area, and the wrong COW will overwrite it, i.e. corrupt the image. Basing a real test case on this is not trivial, though, because I have to stop on the blkdebug event cow_write - which obviously isn't even emitted in the fixed version. I still have to look into option b) Kevin
[Qemu-devel] [PATCH V14 07/10] libqblock: libqblock API design and type defines
Public API design header files: libqblock.h, libqblock-error.h.
Public type define header files: libqblock-types.h. Private internal used
header files: libqblock-internal. For ABI some reserved bytes are used in
structure defines.
Important APIs:
1 QBlockContext. This structure was used to retrieve errors, every thread
must create one first.
2 QBlockImage. It stands for an block image object.
3 QBlockStaticInfo. It contains static information such as location, backing
file, size.
4 Sync I/O. It is similar to C file open, read, write and close operations.
Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com
---
libqblock/libqblock-error.h| 49 ++
libqblock/libqblock-internal.h | 68
libqblock/libqblock-types.h| 245 +++
libqblock/libqblock.h | 355
4 files changed, 717 insertions(+), 0 deletions(-)
create mode 100644 libqblock/libqblock-internal.h
diff --git a/libqblock/libqblock-error.h b/libqblock/libqblock-error.h
index e69de29..4ffd1f1 100644
--- a/libqblock/libqblock-error.h
+++ b/libqblock/libqblock-error.h
@@ -0,0 +1,49 @@
+/*
+ * QEMU block layer library
+ *
+ * Copyright IBM, Corp. 2012
+ *
+ * Authors:
+ * Wenchao Xia xiaw...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#ifndef LIBQBLOCK_ERROR
+#define LIBQBLOCK_ERROR
+
+#include libqblock-types.h
+
+#define QB_ERR_INTERNAL_ERR (-1)
+#define QB_ERR_INVALID_PARAM (-100)
+#define QB_ERR_BLOCK_OUT_OF_RANGE (-101)
+
+/* error handling */
+/**
+ * qb_error_get_human_str: get human readable error string.
+ *
+ * return a human readable string, it would be truncated if buf is not big
+ * enough.
+ *
+ * @context: operation context, must be valid.
+ * @buf: buf to receive the string.
+ * @buf_size: the size of the string buf.
+ */
+DLL_PUBLIC
+void qb_error_get_human_str(QBlockContext *context,
+char *buf, size_t buf_size);
+
+/**
+ * qb_error_get_errno: get error number, only valid when err_ret is
+ * QB_ERR_INTERNAL_ERR.
+ *
+ * return negative errno if last error is QB_ERR_INTERNAL_ERR, otherwise 0.
+ *
+ * @context: operation context.
+ */
+DLL_PUBLIC
+int qb_error_get_errno(QBlockContext *context);
+
+#endif
diff --git a/libqblock/libqblock-internal.h b/libqblock/libqblock-internal.h
new file mode 100644
index 000..c2229db
--- /dev/null
+++ b/libqblock/libqblock-internal.h
@@ -0,0 +1,68 @@
+/*
+ * QEMU block layer library
+ *
+ * Copyright IBM, Corp. 2012
+ *
+ * Authors:
+ * Wenchao Xia xiaw...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#ifndef LIBQBLOCK_INTERNAL
+#define LIBQBLOCK_INTERNAL
+
+#include glib.h
+
+#include block/block.h
+#include libqblock-types.h
+
+/* this file contains defines and types used inside the library. */
+
+#define QB_FREE(p) { \
+g_free(p); \
+(p) = NULL; \
+}
+
+/* details should be hidden to user */
+struct QBlockImage {
+BlockDriverState *bdrvs;
+/* internal used file name now, if it is not NULL, it means
+ image was opened.
+*/
+char *filename;
+int ref_count;
+};
+
+struct QBlockContext {
+/* last error */
+GError *g_error;
+int err_ret; /* 1st level of error, the libqblock error number */
+int err_no; /* 2nd level of error, errno what below reports */
+};
+
+/**
+ * QBlockStaticInfoAddr: a structure contains a set of pointer.
+ *
+ *this struct contains a set of pointer pointing to some
+ * property related to format or protocol. If a property is not available,
+ * it will be set as NULL. User could use this to get properties directly.
+ *
+ * @backing_loc: backing file location.
+ * @encrypt: encryption flag.
+*/
+
+typedef struct QBlockStaticInfoAddr {
+QBlockLocationInfo *backing_loc;
+bool *encrypt;
+} QBlockStaticInfoAddr;
+
+#define G_LIBQBLOCK_ERROR g_libqblock_error_quark()
+
+static inline GQuark g_libqblock_error_quark(void)
+{
+return g_quark_from_static_string(g-libqblock-error-quark);
+}
+#endif
diff --git a/libqblock/libqblock-types.h b/libqblock/libqblock-types.h
index e69de29..4352bf2 100644
--- a/libqblock/libqblock-types.h
+++ b/libqblock/libqblock-types.h
@@ -0,0 +1,245 @@
+/*
+ * QEMU block layer library
+ *
+ * Copyright IBM, Corp. 2012
+ *
+ * Authors:
+ * Wenchao Xia xiaw...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#ifndef LIBQBLOCK_TYPES_H
+#define LIBQBLOCK_TYPES_H
+
+#include sys/types.h
+#include stdint.h
+#include stdbool.h
+
+#if defined(__GNUC__) __GNUC__ = 4
+#ifdef LIBQB_BUILD
+#define DLL_PUBLIC __attribute__((visibility(default)))
+#else
+
Re: [Qemu-devel] [PATCH v2] netmap backend (revised)
On Wed, Jan 23, 2013 at 12:10:55PM +0100, Stefan Hajnoczi wrote: On Tue, Jan 22, 2013 at 08:12:15AM +0100, Luigi Rizzo wrote: reposting a version without changes that implement bounded queues in net/queue.c Hi, the attached patch implements a qemu backend for the netmap API thus allowing machines to attach to the VALE software switch as well as netmap-supported cards (links below). http://info.iet.unipi.it/~luigi/netmap/ http://info.iet.unipi.it/~luigi/vale/ This is a cleaned up version of code written last summer. Looks like a clean software approach to low-level packet I/O. I guess the biggest competitor would be a userspace library with NIC drivers using modern IOMMUs to avoid the security/reliability problem that previous userspace approaches suffered. Pretty cool that netmap reuses kernel NIC driver implementations to avoid duplicating all that code. I wonder how/if netmaps handles advanced NIC features like multiqueue and offloads? But I've only read the webpage, not the papers or source code :). there are definitely more details in the papers :) IOMMU is not strictly necessary because userspace only sees packet buffers and a device independent replica of the descriptor ring. NIC registers and rings are only manipulated by the kernel within system calls. multiqueue is completely straightforward -- netmap exposes as many queues as the hardware implements, you can attach file descriptors to individual queues, bind threads to queues by just using pthread_setaffinity(). offloading so far is not supported, and that's part of the design: it adds complexity at runtime to check the various possible combinations of offloading in various places in the stack. A single packet format makes the driver extremely efficient. The thing that may make a difference is tcp segmentation and reassembly, we will look at how to support it at some point. I'apply the other changes you suggest below, thanks. Only some comments: The debugging macros (D, RD() ) are taken from our existing code, +#define ND(fd, ... ) // debugging +#define D(format, ...) \ ... +/* rate limited, lps indicates how many per second */ +#define RD(lps, format, ...)\ ... Have you seen docs/tracing.txt? It can do fprintf(stderr) but also SystemTap/DTrace and a simple built-in binary tracer. will look at it. These debugging macros are the same we use in other netmap code so i'd prefer to keep them. +// a fast copy routine only for multiples of 64 bytes, non overlapped. +static inline void +pkt_copy(const void *_src, void *_dst, int l) ... +*dst++ = *src++; +} +} I wonder how different FreeBSD bcopy() is from glibc memcpy() and if the optimization is even a win. The glibc code is probably hand-written assembly that CPU vendors have contributed for specific CPU model families. Did you compare glibc memcpy() against pkt_copy()? I haven't tried in detail on glibc but will run some tests. In any case not all systems have glibc, and on FreeBSD this pkt_copy was a significant win for small packets (saving some 20ns each; of course this counts only when you approach the 10 Mpps range, which is what you get with netmap, and of course when data is in cache). One reason pkt_copy gains something is that if it can assume there is extra space in the buffer, it can work on large chunks avoiding the extra jumps and instructions for the remaining 1-2-4 bytes. + ring-slot[i].len = size; + pkt_copy(buf, dst, size); How does netmap guarantee that the buffer is large enough for this packet? the netmap buffers are 2k, i'll make sure there is a check that the size is not exceeded. +close(s-me.fd); Missing munmap? yes you are correct. cheers luigi
[Qemu-devel] [PATCH V14 04/10] libqblock: build: add rule for libqblock.la
Now libqblock.la can be built with neccessary object files, and can be automatically cleaned by make clean in root directory. make libqblock-clean also clean it. -fvisibility=hidden was used to hide symbols, and a special macro was introduced to export symbols that marked as public. Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com --- Makefile.objs |7 +++ libqblock/Makefile | 31 +-- 2 files changed, 36 insertions(+), 2 deletions(-) create mode 100644 libqblock/libqblock-error.c create mode 100644 libqblock/libqblock.c diff --git a/Makefile.objs b/Makefile.objs index d465a72..ab2712d 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -89,6 +89,13 @@ libcacard-y += libcacard/card_7816.o common-obj-$(CONFIG_SMARTCARD_NSS) += $(libcacard-y) ## +# libqblock + +libqblock-y += libqblock/libqblock.o libqblock/libqblock-error.o + +common-obj-$(CONFIG_LIBQBLOCK) += $(libqblock-y) + +## # qapi common-obj-y += qmp-marshal.o qapi-visit.o qapi-types.o diff --git a/libqblock/Makefile b/libqblock/Makefile index 734d90e..cdbfffb 100644 --- a/libqblock/Makefile +++ b/libqblock/Makefile @@ -1,4 +1,31 @@ TOOLS += libqblock.la -libqblock.la: - @true +# objects linked into a shared library, built with libtool with -fPIC if required +libqblock-obj-y = $(libqblock-y) $(util-obj-y) +libqblock-obj-y += $(filter-out stubs/set-fd-handler.o, $(stub-obj-y)) +libqblock-obj-y += $(block-obj-y) + +libqblock-lobj-y=$(patsubst %.o, %.lo, $(libqblock-obj-y)) + +# libtool will build the .o files, too +$(libqblock-obj-y): | $(libqblock-lobj-y) + +LIBQBLOCK_CLEAN_TARGETS=$(libqblock-lobj-y) libqblock.la libqblock/.libs +SUBDIR_CLEAN_RULES+=libqblock-clean + +all: libqblock.la + +# +# Rules for building libqblock standalone library + +$(libqblock-lobj-y): QEMU_CFLAGS+= -fvisibility=hidden -D LIBQB_BUILD +libqblock.la: LDFLAGS += -rpath $(libdir) -no-undefined \ + -export-syms $(SRC_PATH)/libqblock/libqblock.syms +libqblock.la: $(libqblock-lobj-y) + $(call LINK,$^) + + +.PHONY: libqblock-clean + +libqblock-clean: + rm $(LIBQBLOCK_CLEAN_TARGETS) -rf diff --git a/libqblock/libqblock-error.c b/libqblock/libqblock-error.c new file mode 100644 index 000..e69de29 diff --git a/libqblock/libqblock.c b/libqblock/libqblock.c new file mode 100644 index 000..e69de29 -- 1.7.1
[Qemu-devel] QEMU multithreaded device emulation
Hi, I need to emulate a ARM-based SoC that handles a continuous datastream, extracting and injection data with DMA tranfers from/to the guest main memory. I've been using the cpu_physical_memory_* (read/write/map/unmap) functions to perform data transfer, but I'd like to use several dedicated native/host threads to emulate the datastream pipe, as many CPU-intensive tasks (encryption, decryption, filtering) are involved and to take advantage of multi-core host CPUS. What is the best approach to write this kind of code with the current version of QEMU (1.4 dev)? Concurrent threads need to access guest main memory, and report completion (I'm using qemu_bh_schedule to report completion). I do not see other possible locations for race conditions for now. Is this possible ? I've not been able to figure out if this is the right way to go, how to protect the cpu_physical_memory_* qemu_bh_schedule from race conditions. Or am I taking a dead-end path? Thanks, Manu
[Qemu-devel] [PATCH V14 03/10] libqblock: build: add configure support
Rule for libqblock.la will be included if it is enabled, and will be added to $TOOLS to be automatically built. Signed-off-by: Wenchao Xia xiaw...@linux.vnet.ibm.com --- Makefile |3 +++ configure | 26 ++ libqblock/Makefile |4 3 files changed, 33 insertions(+), 0 deletions(-) create mode 100644 libqblock/Makefile diff --git a/Makefile b/Makefile index 69472b7..87c4303 100644 --- a/Makefile +++ b/Makefile @@ -111,6 +111,9 @@ endif ifeq ($(CONFIG_SMARTCARD_NSS),y) include $(SRC_PATH)/libcacard/Makefile endif +ifeq ($(CONFIG_LIBQBLOCK),y) +include $(SRC_PATH)/libqblock/Makefile +endif all: $(DOCS) $(TOOLS) $(HELPERS-y) recurse-all diff --git a/configure b/configure index c6172ef..9463346 100755 --- a/configure +++ b/configure @@ -226,6 +226,7 @@ coroutine= seccomp= glusterfs= virtio_blk_data_plane= +libqblock= # parse CC options first for opt do @@ -897,6 +898,10 @@ for opt do ;; --enable-virtio-blk-data-plane) virtio_blk_data_plane=yes ;; + --disable-libqblock) libqblock=no + ;; + --enable-libqblock) libqblock=yes + ;; *) echo ERROR: unknown option $opt; show_help=yes ;; esac @@ -1146,6 +1151,8 @@ echo --enable-glusterfs enable GlusterFS backend echo --disable-glusterfs disable GlusterFS backend echo --enable-gcovenable test coverage analysis with gcov echo --gcov=GCOV use specified gcov [$gcov_tool] +echo --enable-libqblock enable shared library libqblock +echo --disable-libqblock disable shared library libqblock echo echo NOTE: The object files are built at the place where configure is launched exit 1 @@ -2429,6 +2436,19 @@ EOF fi fi +## +# libqblock probe +if test $libqblock != no; then +if test -n $libtool; then +libqblock=yes +else +if test $libqblock = yes; then +feature_not_found libqblock +fi +libqblock=no +fi +fi + # # Check for xxxat() functions when we are building linux-user # emulator. This is done because older glibc versions don't @@ -3344,6 +3364,7 @@ echo GlusterFS support $glusterfs echo virtio-blk-data-plane $virtio_blk_data_plane echo gcov $gcov_tool echo gcov enabled $gcov +echo libqblock support $libqblock if test $sdl_too_old = yes; then echo - Your SDL version is too old - please upgrade to have SDL support @@ -3700,6 +3721,10 @@ if test $virtio_blk_data_plane = yes ; then echo CONFIG_VIRTIO_BLK_DATA_PLANE=y $config_host_mak fi +if test $libqblock = yes ; then + echo CONFIG_LIBQBLOCK=y $config_host_mak +fi + # USB host support case $usb in linux) @@ -4283,6 +4308,7 @@ DIRS=tests tests/tcg tests/tcg/cris tests/tcg/lm32 DIRS=$DIRS pc-bios/optionrom pc-bios/spapr-rtas DIRS=$DIRS roms/seabios roms/vgabios DIRS=$DIRS qapi-generated +DIRS=$DIRS libqblock FILES=Makefile tests/tcg/Makefile qdict-test-data.txt FILES=$FILES tests/tcg/cris/Makefile tests/tcg/cris/.gdbinit FILES=$FILES tests/tcg/lm32/Makefile diff --git a/libqblock/Makefile b/libqblock/Makefile new file mode 100644 index 000..734d90e --- /dev/null +++ b/libqblock/Makefile @@ -0,0 +1,4 @@ +TOOLS += libqblock.la + +libqblock.la: + @true -- 1.7.1
[Qemu-devel] [PATCH qom-cpu for-1.4 09/14] qom: Introduce object_class_is_abstract()
This lets a caller check if an ObjectClass as returned by, e.g.,
object_class_by_name() is instantiatable.
Signed-off-by: Andreas Färber afaer...@suse.de
Cc: Anthony Liguori anth...@codemonkey.ws
---
include/qom/object.h |8
qom/object.c |5 +
2 Dateien geändert, 13 Zeilen hinzugefügt(+)
diff --git a/include/qom/object.h b/include/qom/object.h
index 8e16ea8..48e80ba 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -691,6 +691,14 @@ ObjectClass *object_class_get_parent(ObjectClass *klass);
const char *object_class_get_name(ObjectClass *klass);
/**
+ * object_class_is_abstract:
+ * @klass: The class to obtain the abstractness for.
+ *
+ * Returns: %true if @klass is abstract, %false otherwise.
+ */
+bool object_class_is_abstract(ObjectClass *klass);
+
+/**
* object_class_by_name:
* @typename: The QOM typename to obtain the class for.
*
diff --git a/qom/object.c b/qom/object.c
index 03e6f24..e200282 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -501,6 +501,11 @@ ObjectClass *object_get_class(Object *obj)
return obj-class;
}
+bool object_class_is_abstract(ObjectClass *klass)
+{
+return klass-type-abstract;
+}
+
const char *object_class_get_name(ObjectClass *klass)
{
return klass-type-name;
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 10/14] target-alpha: Catch attempt to instantiate abstract type in cpu_init()
This fixes -cpu alpha-cpu asserting.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-alpha/cpu.c |8 ++--
1 Datei geändert, 6 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/target-alpha/cpu.c b/target-alpha/cpu.c
index 0d6975e..0ad69f0 100644
--- a/target-alpha/cpu.c
+++ b/target-alpha/cpu.c
@@ -96,14 +96,15 @@ static ObjectClass *alpha_cpu_class_by_name(const char
*cpu_model)
}
oc = object_class_by_name(cpu_model);
-if (oc != NULL object_class_dynamic_cast(oc, TYPE_ALPHA_CPU) != NULL) {
+if (oc != NULL object_class_dynamic_cast(oc, TYPE_ALPHA_CPU) != NULL
+!object_class_is_abstract(oc)) {
return oc;
}
for (i = 0; i ARRAY_SIZE(alpha_cpu_aliases); i++) {
if (strcmp(cpu_model, alpha_cpu_aliases[i].alias) == 0) {
oc = object_class_by_name(alpha_cpu_aliases[i].typename);
-assert(oc != NULL);
+assert(oc != NULL !object_class_is_abstract(oc));
return oc;
}
}
@@ -111,6 +112,9 @@ static ObjectClass *alpha_cpu_class_by_name(const char
*cpu_model)
typename = g_strdup_printf(%s- TYPE_ALPHA_CPU, cpu_model);
oc = object_class_by_name(typename);
g_free(typename);
+if (oc != NULL object_class_is_abstract(oc)) {
+oc = NULL;
+}
return oc;
}
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 04/14] target-arm: Detect attempt to instantiate non-CPU type in cpu_init()
Consolidate model checking into a new arm_cpu_class_by_name().
If the name matches an existing type, also check whether that type is
actually (a sub-type of) TYPE_ARM_CPU.
This fixes, e.g., -cpu tmp105 asserting.
Cc: qemu-stable qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-arm/cpu.c| 17 +
target-arm/helper.c |6 --
2 Dateien geändert, 21 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 07588a1..d85f251 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -201,6 +201,21 @@ void arm_cpu_realize(ARMCPU *cpu)
/* CPU models */
+static ObjectClass *arm_cpu_class_by_name(const char *cpu_model)
+{
+ObjectClass *oc;
+
+if (cpu_model == NULL) {
+return NULL;
+}
+
+oc = object_class_by_name(cpu_model);
+if (oc == NULL || object_class_dynamic_cast(oc, TYPE_ARM_CPU) == NULL) {
+return NULL;
+}
+return oc;
+}
+
static void arm926_initfn(Object *obj)
{
ARMCPU *cpu = ARM_CPU(obj);
@@ -766,6 +781,8 @@ static void arm_cpu_class_init(ObjectClass *oc, void *data)
acc-parent_reset = cc-reset;
cc-reset = arm_cpu_reset;
+
+cc-class_by_name = arm_cpu_class_by_name;
}
static void cpu_register(const ARMCPUInfo *info)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 37c34a1..4c29117 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1262,12 +1262,14 @@ ARMCPU *cpu_arm_init(const char *cpu_model)
{
ARMCPU *cpu;
CPUARMState *env;
+ObjectClass *oc;
static int inited = 0;
-if (!object_class_by_name(cpu_model)) {
+oc = cpu_class_by_name(TYPE_ARM_CPU, cpu_model);
+if (oc == NULL) {
return NULL;
}
-cpu = ARM_CPU(object_new(cpu_model));
+cpu = ARM_CPU(object_new(object_class_get_name(oc)));
env = cpu-env;
env-cpu_model_str = cpu_model;
arm_cpu_realize(cpu);
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 02/14] target-unicore32: Don't use type_register_static()
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-unicore32/cpu.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c
index 884c101..a38fc4d 100644
--- a/target-unicore32/cpu.c
+++ b/target-unicore32/cpu.c
@@ -88,7 +88,7 @@ static void uc32_register_cpu_type(const UniCore32CPUInfo
*info)
.instance_init = info-instance_init,
};
-type_register_static(type_info);
+type_register(type_info);
}
static const TypeInfo uc32_cpu_type_info = {
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 00/14] QOM CPU fixes for 1.4
Hello, This series fixes a number of bugs surrounding QOM CPU instantiation. Please ack. First, two remaining users of type_register_static() for iterative CPU type registration are moved over to type_register(). TBD: better commit message Second, error checking for -cpu some-random-type is added. This also prepares infrastructure for converting arm, m68k, or32 and uc32 to the new name-arch-cpu type name scheme in follow-up series. Third, error checking for -cpu arch-cpu and any future abstract sub-types is added. A new object_class_is_abstract() accessor function is needed. Note that the ppc target got around this by using object_class_get_list() rather than object_class_by_name(). The CPU realizefn series will need to be rebased on this one (class_init). Regards, Andreas Cc: Peter Maydell peter.mayd...@linaro.org Cc: Richard Henderson r...@twiddle.net Cc: Jia Liu pro...@gmail.com Cc: Guan Xuetao g...@mprc.pku.edu.cn Cc: Alexander Graf ag...@suse.de Cc: Anthony Liguori anth...@codemonkey.ws Andreas Färber (14): target-openrisc: Don't use type_register_static() target-unicore32: Don't use type_register_static() cpu: Add model resolution support to CPUClass target-arm: Detect attempt to instantiate non-CPU type in cpu_init() target-alpha: Detect attempt to instantiate non-CPU type in cpu_init() target-m68k: Detect attempt to instantiate non-CPU type in cpu_init() target-openrisc: Detect attempt to instantiate non-CPU type in cpu_init() target-unicore32: Detect attempt to instantiate non-CPU type in cpu_init() qom: Introduce object_class_is_abstract() target-alpha: Catch attempt to instantiate abstract type in cpu_init() target-arm: Catch attempt to instantiate abstract type in cpu_init() target-m68k: Catch attempt to instantiate abstract type in cpu_init() target-openrisc: Catch attempt to instantiate abstract type in cpu_init() target-unicore32: Catch attempt to instantiate abstract type in cpu_init() include/qom/cpu.h | 13 + include/qom/object.h|8 qom/cpu.c | 13 + qom/object.c|5 + target-alpha/cpu.c | 16 ++-- target-arm/cpu.c| 18 ++ target-arm/helper.c |6 -- target-m68k/cpu.c | 18 ++ target-m68k/helper.c|6 -- target-openrisc/cpu.c | 27 --- target-ppc/translate_init.c |2 ++ target-unicore32/cpu.c | 26 +- target-unicore32/helper.c |4 +++- 13 Dateien geändert, 151 Zeilen hinzugefügt(+), 11 Zeilen entfernt(-) -- 1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 14/14] target-unicore32: Catch attempt to instantiate abstract type in cpu_init()
Fixes -cpu unicore32-cpu asserting.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-unicore32/cpu.c |3 ++-
1 Datei geändert, 2 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c
index e9b9254..0142d7e 100644
--- a/target-unicore32/cpu.c
+++ b/target-unicore32/cpu.c
@@ -31,7 +31,8 @@ static ObjectClass *uc32_cpu_class_by_name(const char
*cpu_model)
}
oc = object_class_by_name(cpu_model);
-if (oc != NULL object_class_dynamic_cast(oc, TYPE_UNICORE32_CPU)) {
+if (oc != NULL (object_class_dynamic_cast(oc, TYPE_UNICORE32_CPU) ||
+ object_class_is_abstract(oc))) {
oc = NULL;
}
return oc;
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 08/14] target-unicore32: Detect attempt to instantiate non-CPU type in cpu_init()
Consolidate model checking into a new uc32_cpu_class_by_name().
If the name matches an existing type, also check whether that type is
actually (a sub-type of) TYPE_UNICORE32_CPU.
This fixes, e.g., -cpu puv3_dma asserting.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-unicore32/cpu.c| 23 +++
target-unicore32/helper.c |4 +++-
2 Dateien geändert, 26 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-unicore32/cpu.c b/target-unicore32/cpu.c
index a38fc4d..e9b9254 100644
--- a/target-unicore32/cpu.c
+++ b/target-unicore32/cpu.c
@@ -22,6 +22,21 @@ static inline void set_feature(CPUUniCore32State *env, int
feature)
/* CPU models */
+static ObjectClass *uc32_cpu_class_by_name(const char *cpu_model)
+{
+ObjectClass *oc;
+
+if (cpu_model == NULL) {
+return NULL;
+}
+
+oc = object_class_by_name(cpu_model);
+if (oc != NULL object_class_dynamic_cast(oc, TYPE_UNICORE32_CPU)) {
+oc = NULL;
+}
+return oc;
+}
+
typedef struct UniCore32CPUInfo {
const char *name;
void (*instance_init)(Object *obj);
@@ -80,6 +95,13 @@ static void uc32_cpu_initfn(Object *obj)
tlb_flush(env, 1);
}
+static void uc32_cpu_class_init(ObjectClass *oc, void *data)
+{
+CPUClass *cc = CPU_CLASS(oc);
+
+cc-class_by_name = uc32_cpu_class_by_name;
+}
+
static void uc32_register_cpu_type(const UniCore32CPUInfo *info)
{
TypeInfo type_info = {
@@ -98,6 +120,7 @@ static const TypeInfo uc32_cpu_type_info = {
.instance_init = uc32_cpu_initfn,
.abstract = true,
.class_size = sizeof(UniCore32CPUClass),
+.class_init = uc32_cpu_class_init,
};
static void uc32_cpu_register_types(void)
diff --git a/target-unicore32/helper.c b/target-unicore32/helper.c
index 5359538..7ace68c 100644
--- a/target-unicore32/helper.c
+++ b/target-unicore32/helper.c
@@ -29,9 +29,11 @@ CPUUniCore32State *uc32_cpu_init(const char *cpu_model)
{
UniCore32CPU *cpu;
CPUUniCore32State *env;
+ObjectClass *oc;
static int inited = 1;
-if (object_class_by_name(cpu_model) == NULL) {
+oc = cpu_class_by_name(TYPE_UNICORE32_CPU, cpu_model);
+if (oc == NULL) {
return NULL;
}
cpu = UNICORE32_CPU(object_new(cpu_model));
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 11/14] target-arm: Catch attempt to instantiate abstract type in cpu_init()
This fixes -cpu arm-cpu asserting.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-arm/cpu.c |3 ++-
1 Datei geändert, 2 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index d85f251..cfc14f3 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -210,7 +210,8 @@ static ObjectClass *arm_cpu_class_by_name(const char
*cpu_model)
}
oc = object_class_by_name(cpu_model);
-if (oc == NULL || object_class_dynamic_cast(oc, TYPE_ARM_CPU) == NULL) {
+if (oc == NULL || object_class_dynamic_cast(oc, TYPE_ARM_CPU) == NULL ||
+object_class_is_abstract(oc)) {
return NULL;
}
return oc;
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 07/14] target-openrisc: Detect attempt to instantiate non-CPU type in cpu_init()
Consolidate model checking into a new openrisc_cpu_class_by_name().
If the name matches an existing type, also check whether that type is
actually (a sub-type of) TYPE_OPENRISC_CPU.
This fixes, e.g., -cpu open_eth asserting.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-openrisc/cpu.c | 24 ++--
1 Datei geändert, 22 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/target-openrisc/cpu.c b/target-openrisc/cpu.c
index 9bd4be4..6f41930 100644
--- a/target-openrisc/cpu.c
+++ b/target-openrisc/cpu.c
@@ -88,6 +88,22 @@ static void openrisc_cpu_initfn(Object *obj)
}
/* CPU models */
+
+static ObjectClass *openrisc_cpu_class_by_name(const char *cpu_model)
+{
+ObjectClass *oc;
+
+if (cpu_model == NULL) {
+return NULL;
+}
+
+oc = object_class_by_name(cpu_model);
+if (oc != NULL object_class_dynamic_cast(oc, TYPE_OPENRISC_CPU)) {
+return NULL;
+}
+return oc;
+}
+
static void or1200_initfn(Object *obj)
{
OpenRISCCPU *cpu = OPENRISC_CPU(obj);
@@ -120,6 +136,8 @@ static void openrisc_cpu_class_init(ObjectClass *oc, void
*data)
occ-parent_reset = cc-reset;
cc-reset = openrisc_cpu_reset;
+
+cc-class_by_name = openrisc_cpu_class_by_name;
}
static void cpu_register(const OpenRISCCPUInfo *info)
@@ -158,11 +176,13 @@ static void openrisc_cpu_register_types(void)
OpenRISCCPU *cpu_openrisc_init(const char *cpu_model)
{
OpenRISCCPU *cpu;
+ObjectClass *oc;
-if (!object_class_by_name(cpu_model)) {
+oc = openrisc_cpu_class_by_name(cpu_model);
+if (oc == NULL) {
return NULL;
}
-cpu = OPENRISC_CPU(object_new(cpu_model));
+cpu = OPENRISC_CPU(object_new(object_class_get_name(oc)));
cpu-env.cpu_model_str = cpu_model;
openrisc_cpu_realize(OBJECT(cpu), NULL);
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 06/14] target-m68k: Detect attempt to instantiate non-CPU type in cpu_init()
Consolidate model checking into a new m68k_cpu_class_by_name().
If the name matches an existing type, also check whether that type is
(a sub-type of) TYPE_M68K_CPU.
This fixes, e.g., -cpu ide-hd asserting.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-m68k/cpu.c| 17 +
target-m68k/helper.c |6 --
2 Dateien geändert, 21 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/target-m68k/cpu.c b/target-m68k/cpu.c
index ce89674..b231d9a 100644
--- a/target-m68k/cpu.c
+++ b/target-m68k/cpu.c
@@ -55,6 +55,21 @@ static void m68k_cpu_reset(CPUState *s)
/* CPU models */
+static ObjectClass *m68k_cpu_class_by_name(const char *cpu_model)
+{
+ObjectClass *oc;
+
+if (cpu_model == NULL) {
+return NULL;
+}
+
+oc = object_class_by_name(cpu_model);
+if (oc != NULL object_class_dynamic_cast(oc, TYPE_M68K_CPU) == NULL) {
+return NULL;
+}
+return oc;
+}
+
static void m5206_cpu_initfn(Object *obj)
{
M68kCPU *cpu = M68K_CPU(obj);
@@ -134,6 +149,8 @@ static void m68k_cpu_class_init(ObjectClass *c, void *data)
mcc-parent_reset = cc-reset;
cc-reset = m68k_cpu_reset;
+
+cc-class_by_name = m68k_cpu_class_by_name;
}
static void register_cpu_type(const M68kCPUInfo *info)
diff --git a/target-m68k/helper.c b/target-m68k/helper.c
index 097fc78..f66e12b 100644
--- a/target-m68k/helper.c
+++ b/target-m68k/helper.c
@@ -97,12 +97,14 @@ CPUM68KState *cpu_m68k_init(const char *cpu_model)
{
M68kCPU *cpu;
CPUM68KState *env;
+ObjectClass *oc;
static int inited;
-if (object_class_by_name(cpu_model) == NULL) {
+oc = cpu_class_by_name(TYPE_M68K_CPU, cpu_model);
+if (oc == NULL) {
return NULL;
}
-cpu = M68K_CPU(object_new(cpu_model));
+cpu = M68K_CPU(object_new(object_class_get_name(oc)));
env = cpu-env;
if (!inited) {
--
1.7.10.4
Re: [Qemu-devel] Questions on the virtual disk's cache type
On Wed, Jan 23, 2013 at 06:47:55PM +0800, Liu Yuan wrote:
On 01/23/2013 06:14 PM, Daniel P. Berrange wrote:
On Wed, Jan 23, 2013 at 06:09:01PM +0800, Liu Yuan wrote:
On 01/23/2013 05:30 PM, Daniel P. Berrange wrote:
FYI There is a patch proposed for customization
https://review.openstack.org/#/c/18042/
Seems that this patch is dropped and declined?
I should note that it is wrong to assume that enabling cache mode will
improve the performance in general. Allowing caching in the host will
require a non-negligable amount of host RAM to have a benefit. RAM is
usually the most constrained resource in any virtualization environment.
So while the cache may help performance when only one or two Vms are
running on the host, it may well in fact hurt performance once the host
is running enough VMs to max out RAM. So allowing caching will actually
give you quite variable performance, while the cache=none will give you
consistent performance regardless of host RAM utilization (underlying
contention of the storage device may of course still impact things).
Yeah, allowing page cache in the host might not be a good idea to run
multiple VMs, but cache type in QEMU has different meaning for network
block devices. For e.g, we use 'cache type' to control client side cache
of Sheepdog cluster, which implement a object cache in the local disk
for performance boost and reducing network traffics. This doesn't
consume memory at all, just occupy the disk space where runs sheep daemon.
How can it be a client-side cache if it doesn't consume memory on the
client?
Please explain how the client-side cache feature works. I'm not
familiar with sheepdog internals.
That is a serious abuse of the QEMU cache type variable. You now have one
setting with two completely different meanings for the same value. If you
want to control whether the sheepdog driver uses a local disk for object
cache you should have a completely separate QEMU command line setting
which can be controlled independantly of the cache= setting.
Hello Stefen and Kevin,
Should sheepdog driver use another new command setting to control its
internal cache?
For network block device, which simply forward the IO requests from
VMs via networking and never have chance to touch host's memory, I think
it is okay to multiplex the 'cache=type', but it looks that it causes
confusion for libvirt code.
From block/sheepdog.c:
/*
* QEMU block layer emulates writethrough cache as 'writeback + flush', so
* we always set SD_FLAG_CMD_CACHE (writeback cache) as default.
*/
s-cache_flags = SD_FLAG_CMD_CACHE;
if (flags BDRV_O_NOCACHE) {
s-cache_flags = SD_FLAG_CMD_DIRECT;
}
That means -drive cache=none and -drive cache=directsync use
SD_FLAG_CMD_DIRECT.
And -drive cache=writeback and cache=writethrough use SD_FLAG_CMD_CACHE.
This matches the behavior that QEMU uses for local files:
none/directsync mean O_DIRECT and writeback/writethrough go via the page
cache.
When you use NFS O_DIRECT also means bypass client-side cache. Where is
the issue?
Stefan
[Qemu-devel] [PATCH qom-cpu for-1.4 01/14] target-openrisc: Don't use type_register_static()
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-openrisc/cpu.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-openrisc/cpu.c b/target-openrisc/cpu.c
index 56544d8..9bd4be4 100644
--- a/target-openrisc/cpu.c
+++ b/target-openrisc/cpu.c
@@ -132,7 +132,7 @@ static void cpu_register(const OpenRISCCPUInfo *info)
.class_size = sizeof(OpenRISCCPUClass),
};
-type_register_static(type_info);
+type_register(type_info);
}
static const TypeInfo openrisc_cpu_type_info = {
--
1.7.10.4
[Qemu-devel] [PATCH qom-cpu for-1.4 13/14] target-openrisc: Catch attempt to instantiate abstract type in cpu_init()
Fixes -cpu openrisc-cpu asserting.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-openrisc/cpu.c |3 ++-
1 Datei geändert, 2 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-openrisc/cpu.c b/target-openrisc/cpu.c
index 6f41930..2ca6787 100644
--- a/target-openrisc/cpu.c
+++ b/target-openrisc/cpu.c
@@ -98,7 +98,8 @@ static ObjectClass *openrisc_cpu_class_by_name(const char
*cpu_model)
}
oc = object_class_by_name(cpu_model);
-if (oc != NULL object_class_dynamic_cast(oc, TYPE_OPENRISC_CPU)) {
+if (oc != NULL (object_class_dynamic_cast(oc, TYPE_OPENRISC_CPU) ||
+ object_class_is_abstract(oc))) {
return NULL;
}
return oc;
--
1.7.10.4
Re: [Qemu-devel] [PATCH v2] PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set
On Wed, Jan 23, 2013 at 11:46:48AM +0100, Laszlo Ersek wrote:
On 01/23/13 09:36, Stefan Hajnoczi wrote:
On Wed, Jan 16, 2013 at 07:40:19PM +0100, Laszlo Ersek wrote:
static int piix3_post_load(void *opaque, int version_id)
{
PIIX3State *piix3 = opaque;
piix3_update_irq_levels(piix3);
+piix3-rcr = 2; /* keep System Reset type only */
return 0;
}
Is this necessary? I think only an evil migration source could set
value not in {0x0, 0x2}.
I wanted to make sure in general that no write path to piix3-rcr
would let an invalid value through.
And if so, it doesn't seem like our job to
validate that.
Independently of the patch: why not?
The migration source and the guest are both untrusted. We just need to
protect against QEMU crashing or doing something unsafe which could lead
to security problems or data corruption.
An invalid value in this register means that the guest sees a junk value
but it's nothing dangerous that QEMU needs to protect against.
The migration source can already create a junk guest. Storing a junk
value in this register is no worse.
We don't validate other migrated values, so it stood out to me. I
wasn't sure if there's some subtle reason why we need to do this.
Consistently validating all register values in a separate patch would be
okay, but having just this one line is confusing.
Stefan
[Qemu-devel] [PATCH qom-cpu for-1.4 03/14] cpu: Add model resolution support to CPUClass
Introduce CPUClass::class_by_name and add a default implementation.
Hook up the alpha and ppc implementations.
Introduce a wrapper function cpu_class_by_name().
Signed-off-by: Andreas Färber afaer...@suse.de
---
include/qom/cpu.h | 13 +
qom/cpu.c | 13 +
target-alpha/cpu.c |8
target-ppc/translate_init.c |2 ++
4 Dateien geändert, 36 Zeilen hinzugefügt(+)
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 773caf9..cd0378e 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -49,6 +49,8 @@ typedef struct CPUClass {
DeviceClass parent_class;
/* public */
+ObjectClass *(*class_by_name)(const char *cpu_model);
+
void (*reset)(CPUState *cpu);
} CPUClass;
@@ -108,6 +110,17 @@ struct CPUState {
void cpu_reset(CPUState *cpu);
/**
+ * cpu_class_by_name:
+ * @typename: The CPU base type.
+ * @cpu_model: The model string without any parameters.
+ *
+ * Looks up a CPU #ObjectClass matching name @cpu_model.
+ *
+ * Returns: A #CPUClass or %NULL if not matching class is found.
+ */
+ObjectClass *cpu_class_by_name(const char *typename, const char *cpu_model);
+
+/**
* qemu_cpu_has_work:
* @cpu: The vCPU to check.
*
diff --git a/qom/cpu.c b/qom/cpu.c
index 49e5134..8fb538b 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -34,11 +34,24 @@ static void cpu_common_reset(CPUState *cpu)
{
}
+ObjectClass *cpu_class_by_name(const char *typename, const char *cpu_model)
+{
+CPUClass *cc = CPU_CLASS(object_class_by_name(typename));
+
+return cc-class_by_name(cpu_model);
+}
+
+static ObjectClass *cpu_common_class_by_name(const char *cpu_model)
+{
+return NULL;
+}
+
static void cpu_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
CPUClass *k = CPU_CLASS(klass);
+k-class_by_name = cpu_common_class_by_name;
k-reset = cpu_common_reset;
dc-no_user = 1;
}
diff --git a/target-alpha/cpu.c b/target-alpha/cpu.c
index 40e9809..3ac0fde 100644
--- a/target-alpha/cpu.c
+++ b/target-alpha/cpu.c
@@ -244,6 +244,13 @@ static void alpha_cpu_initfn(Object *obj)
env-fen = 1;
}
+static void alpha_cpu_class_init(ObjectClass *oc, void *data)
+{
+CPUClass *cc = CPU_CLASS(oc);
+
+cc-class_by_name = alpha_cpu_class_by_name;
+}
+
static const TypeInfo alpha_cpu_type_info = {
.name = TYPE_ALPHA_CPU,
.parent = TYPE_CPU,
@@ -251,6 +258,7 @@ static const TypeInfo alpha_cpu_type_info = {
.instance_init = alpha_cpu_initfn,
.abstract = true,
.class_size = sizeof(AlphaCPUClass),
+.class_init = alpha_cpu_class_init,
};
static void alpha_cpu_register_types(void)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 2d78529..211bd02 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -10566,6 +10566,8 @@ static void ppc_cpu_class_init(ObjectClass *oc, void
*data)
pcc-parent_reset = cc-reset;
cc-reset = ppc_cpu_reset;
+
+cc-class_by_name = ppc_cpu_class_by_name;
}
static const TypeInfo ppc_cpu_type_info = {
--
1.7.10.4
Re: [Qemu-devel] [RFC 1/3] qtest: Prepare hypercall support
Andreas Färber afaer...@suse.de writes:
Signed-off-by: Andreas Färber afaer...@suse.de
---
include/sysemu/qtest.h |2 ++
qtest.c| 26 ++
stubs/Makefile.objs|1 +
stubs/qtest.c | 12
tests/libqtest.c | 21 +
tests/libqtest.h | 17 +
6 Dateien geändert, 79 Zeilen hinzugefügt(+)
create mode 100644 stubs/qtest.c
diff --git a/include/sysemu/qtest.h b/include/sysemu/qtest.h
index 723a4f9..75ab29d 100644
--- a/include/sysemu/qtest.h
+++ b/include/sysemu/qtest.h
@@ -32,6 +32,8 @@ static inline int qtest_available(void)
}
int qtest_init(void);
+bool qtest_hypercall_supported(void);
+int qtest_hypercall(uint64_t code, uint64_t *args);
#else
static inline bool qtest_enabled(void)
{
diff --git a/qtest.c b/qtest.c
index c9b58ce..a5b54e3 100644
--- a/qtest.c
+++ b/qtest.c
@@ -117,6 +117,11 @@ static bool qtest_opened;
* where NUM is an IRQ number. For the PC, interrupts can be intercepted
* simply with irq_intercept_in ioapic (note that IRQ0 comes out with
* NUM=0 even though it is remapped to GSI 2).
+ *
+ * Hypercalls:
+ *
+ * hypercall CODE
+ * OK
*/
static int hex2nib(char ch)
@@ -344,6 +349,27 @@ static void qtest_process_command(CharDriverState *chr,
gchar **words)
qtest_clock_warp(ns);
qtest_send_prefix(chr);
qtest_send(chr, OK %PRIi64\n,
(int64_t)qemu_get_clock_ns(vm_clock));
+} else if (strcmp(words[0], hypercall) == 0
+ qtest_hypercall_supported()) {
+uint64_t code;
+uint64_t args[13];
+int ret, i;
+
+g_assert(words[1] != NULL);
+code = strtoull(words[1], NULL, 0);
+
+memset(args, 0, sizeof(args));
+for (i = 0; i 13 words[2 + i] != NULL; i++) {
+args[i] = strtoull(words[2 + i], NULL, 0);
+}
+
+ret = qtest_hypercall(code, args);
+qtest_send_prefix(chr);
+if (ret 0) {
+qtest_send(chr, ERR 0x%x\n, ret);
+return;
+}
+qtest_send(chr, OK 0x%x\n, ret);
Certainly on x86 hypercalls have a well defined set of arguments. I
seem to recall having this discussion with David and Paul though and
with PAPR, not all hypercalls follow the same conventions in terms of
what registers are used.
David, can you elaborate? Am I remembering incorrectly?
Regards,
Anthony Liguori
} else {
qtest_send_prefix(chr);
qtest_send(chr, FAIL Unknown command `%s'\n, words[0]);
diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs
index a260394..50fb2a7 100644
--- a/stubs/Makefile.objs
+++ b/stubs/Makefile.objs
@@ -15,6 +15,7 @@ stub-obj-y += mon-printf.o
stub-obj-y += mon-print-filename.o
stub-obj-y += mon-protocol-event.o
stub-obj-y += mon-set-error.o
+stub-obj-y += qtest.o
stub-obj-y += reset.o
stub-obj-y += set-fd-handler.o
stub-obj-y += slirp.o
diff --git a/stubs/qtest.c b/stubs/qtest.c
new file mode 100644
index 000..8860e4f
--- /dev/null
+++ b/stubs/qtest.c
@@ -0,0 +1,12 @@
+#include qemu-common.h
+#include sysemu/qtest.h
+
+bool qtest_hypercall_supported(void)
+{
+return false;
+}
+
+int qtest_hypercall(uint64_t code, uint64_t *args)
+{
+return -EINVAL;
+}
diff --git a/tests/libqtest.c b/tests/libqtest.c
index 913fa05..5eb9521 100644
--- a/tests/libqtest.c
+++ b/tests/libqtest.c
@@ -476,3 +476,24 @@ void qtest_memwrite(QTestState *s, uint64_t addr, const
void *data, size_t size)
qtest_sendf(s, \n);
qtest_rsp(s, 0);
}
+
+uint64_t qtest_hypercall(QTestState *s, uint64_t code, int argc, ...)
+{
+va_list va;
+gchar **args;
+uint64_t resp, arg;
+int i;
+
+qtest_sendf(s, hypercall 0x% PRIx64, code);
+va_start(va, argc);
+for (i = 0; i argc; i++) {
+arg = va_arg(va, uint64_t);
+qtest_sendf(s, 0x% PRIx64, arg);
+}
+va_end(va);
+qtest_sendf(s, \n);
+args = qtest_rsp(s, 2);
+resp = g_ascii_strtoull(args[1], NULL, 0);
+g_strfreev(args);
+return resp;
+}
diff --git a/tests/libqtest.h b/tests/libqtest.h
index c8ade85..3a5a8f9 100644
--- a/tests/libqtest.h
+++ b/tests/libqtest.h
@@ -187,6 +187,15 @@ int64_t qtest_clock_step(QTestState *s, int64_t step);
int64_t qtest_clock_set(QTestState *s, int64_t val);
/**
+ * qtest_hypercall:
+ * @s: QTestState instance to operate on.
+ * @code: Hypercall code to call.
+ *
+ * Peform a hypercall @code on the guest.
+ */
+uint64_t qtest_hypercall(QTestState *s, uint64_t code, int argc, ...);
+
+/**
* qtest_get_arch:
*
* Returns the architecture for the QEMU executable under test.
@@ -349,4 +358,12 @@ void qtest_add_func(const char *str, void (*fn));
*/
#define clock_set(val) qtest_clock_set(global_qtest, val)
+/**
+ * hypercall:
+ * @code: Hypercall code.
+ *
+ * Invokes a
[Qemu-devel] [PATCH qom-cpu for-1.4 12/14] target-m68k: Catch attempt to instantiate abstract type in cpu_init()
This fixes -cpu m68k-cpu asserting.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-m68k/cpu.c |3 ++-
1 Datei geändert, 2 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-m68k/cpu.c b/target-m68k/cpu.c
index b231d9a..e6df1ee 100644
--- a/target-m68k/cpu.c
+++ b/target-m68k/cpu.c
@@ -64,7 +64,8 @@ static ObjectClass *m68k_cpu_class_by_name(const char
*cpu_model)
}
oc = object_class_by_name(cpu_model);
-if (oc != NULL object_class_dynamic_cast(oc, TYPE_M68K_CPU) == NULL) {
+if (oc != NULL (object_class_dynamic_cast(oc, TYPE_M68K_CPU) == NULL ||
+ object_class_is_abstract(oc))) {
return NULL;
}
return oc;
--
1.7.10.4
Re: [Qemu-devel] [PATCH v2] netmap backend (revised)
On Wed, Jan 23, 2013 at 12:50:26PM +0100, Luigi Rizzo wrote: On Wed, Jan 23, 2013 at 12:10:55PM +0100, Stefan Hajnoczi wrote: On Tue, Jan 22, 2013 at 08:12:15AM +0100, Luigi Rizzo wrote: The debugging macros (D, RD() ) are taken from our existing code, +#define ND(fd, ... ) // debugging +#define D(format, ...) \ ... +/* rate limited, lps indicates how many per second */ +#define RD(lps, format, ...)\ ... Have you seen docs/tracing.txt? It can do fprintf(stderr) but also SystemTap/DTrace and a simple built-in binary tracer. will look at it. These debugging macros are the same we use in other netmap code so i'd prefer to keep them. Okay. Feel free to leave them. +// a fast copy routine only for multiples of 64 bytes, non overlapped. +static inline void +pkt_copy(const void *_src, void *_dst, int l) ... +*dst++ = *src++; +} +} I wonder how different FreeBSD bcopy() is from glibc memcpy() and if the optimization is even a win. The glibc code is probably hand-written assembly that CPU vendors have contributed for specific CPU model families. Did you compare glibc memcpy() against pkt_copy()? I haven't tried in detail on glibc but will run some tests. In any case not all systems have glibc, and on FreeBSD this pkt_copy was a significant win for small packets (saving some 20ns each; of course this counts only when you approach the 10 Mpps range, which is what you get with netmap, and of course when data is in cache). One reason pkt_copy gains something is that if it can assume there is extra space in the buffer, it can work on large chunks avoiding the extra jumps and instructions for the remaining 1-2-4 bytes. I'd like to drop this code or at least make it FreeBSD-specific since there's no guarantee that this is a good idea on any other libc. I'm even doubtful that it's always a win on FreeBSD. You have a threshold to fall back to bcopy() and who knows what the best value for various CPUs is. Stefan
[Qemu-devel] [PATCH qom-cpu for-1.4 05/14] target-alpha: Detect attempt to instantiate non-CPU type in cpu_init()
Check in alpha_cpu_class_by_name() whether the type found is actually
(a sub-type of) TYPE_ALPHA_CPU.
This fixes, e.g., -cpu typhoon-pcihost asserting.
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-alpha/cpu.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/target-alpha/cpu.c b/target-alpha/cpu.c
index 3ac0fde..0d6975e 100644
--- a/target-alpha/cpu.c
+++ b/target-alpha/cpu.c
@@ -96,7 +96,7 @@ static ObjectClass *alpha_cpu_class_by_name(const char
*cpu_model)
}
oc = object_class_by_name(cpu_model);
-if (oc != NULL) {
+if (oc != NULL object_class_dynamic_cast(oc, TYPE_ALPHA_CPU) != NULL) {
return oc;
}
--
1.7.10.4
Re: [Qemu-devel] [PATCH qom-cpu for-1.4 04/14] target-arm: Detect attempt to instantiate non-CPU type in cpu_init()
On 23 January 2013 12:07, Andreas Färber afaer...@suse.de wrote:
Consolidate model checking into a new arm_cpu_class_by_name().
If the name matches an existing type, also check whether that type is
actually (a sub-type of) TYPE_ARM_CPU.
This fixes, e.g., -cpu tmp105 asserting.
Cc: qemu-stable qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-arm/cpu.c| 17 +
target-arm/helper.c |6 --
2 Dateien geändert, 21 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 07588a1..d85f251 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -201,6 +201,21 @@ void arm_cpu_realize(ARMCPU *cpu)
/* CPU models */
+static ObjectClass *arm_cpu_class_by_name(const char *cpu_model)
+{
+ObjectClass *oc;
+
+if (cpu_model == NULL) {
+return NULL;
+}
explicit == NULL is kind of ugly; established style in
target-arm/ is if (!cpu_model)...
+
+oc = object_class_by_name(cpu_model);
I note that the object_class_by_name() implementation returns
NULL for NULL input, though the documentation doesn't guarantee
it will...
+if (oc == NULL || object_class_dynamic_cast(oc, TYPE_ARM_CPU) == NULL) {
+return NULL;
+}
+return oc;
+}
+
static void arm926_initfn(Object *obj)
{
ARMCPU *cpu = ARM_CPU(obj);
@@ -766,6 +781,8 @@ static void arm_cpu_class_init(ObjectClass *oc, void
*data)
acc-parent_reset = cc-reset;
cc-reset = arm_cpu_reset;
+
+cc-class_by_name = arm_cpu_class_by_name;
Is this a class method because the plan is that eventually
the code that instantiates the CPU object will become
generic rather than target specific?
}
static void cpu_register(const ARMCPUInfo *info)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 37c34a1..4c29117 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1262,12 +1262,14 @@ ARMCPU *cpu_arm_init(const char *cpu_model)
{
ARMCPU *cpu;
CPUARMState *env;
+ObjectClass *oc;
static int inited = 0;
-if (!object_class_by_name(cpu_model)) {
+oc = cpu_class_by_name(TYPE_ARM_CPU, cpu_model);
+if (oc == NULL) {
return NULL;
}
-cpu = ARM_CPU(object_new(cpu_model));
+cpu = ARM_CPU(object_new(object_class_get_name(oc)));
Do we really have to convert back to the char* type
name in order to instantiate an object given the class?
env = cpu-env;
env-cpu_model_str = cpu_model;
arm_cpu_realize(cpu);
--
1.7.10.4
thanks
-- PMM
Re: [Qemu-devel] QEMU multithreaded device emulation
On Wed, Jan 23, 2013 at 01:02:57PM +0100, Emmanuel Blot wrote: I need to emulate a ARM-based SoC that handles a continuous datastream, extracting and injection data with DMA tranfers from/to the guest main memory. I've been using the cpu_physical_memory_* (read/write/map/unmap) functions to perform data transfer, but I'd like to use several dedicated native/host threads to emulate the datastream pipe, as many CPU-intensive tasks (encryption, decryption, filtering) are involved and to take advantage of multi-core host CPUS. What is the best approach to write this kind of code with the current version of QEMU (1.4 dev)? Concurrent threads need to access guest main memory, and report completion (I'm using qemu_bh_schedule to report completion). I do not see other possible locations for race conditions for now. Is this possible ? I've not been able to figure out if this is the right way to go, how to protect the cpu_physical_memory_* qemu_bh_schedule from race conditions. Or am I taking a dead-end path? Today you cannot use cpu_physical_memory_*() from a thread without holding the QEMU global mutex. We need a thread-safe (and hopefully cheap) memory access API eventually but it doesn't exist yet. Have you tried taking the mutex temporarily just for map/unmap and then doing the copy or I/O outside the mutex? qemu_bh_schedule() should be thread-safe (but please double-check). Stefan
Re: [Qemu-devel] Questions on the virtual disk's cache type
On 01/23/2013 08:34 PM, Stefan Hajnoczi wrote:
On Wed, Jan 23, 2013 at 06:47:55PM +0800, Liu Yuan wrote:
On 01/23/2013 06:14 PM, Daniel P. Berrange wrote:
On Wed, Jan 23, 2013 at 06:09:01PM +0800, Liu Yuan wrote:
On 01/23/2013 05:30 PM, Daniel P. Berrange wrote:
FYI There is a patch proposed for customization
https://review.openstack.org/#/c/18042/
Seems that this patch is dropped and declined?
I should note that it is wrong to assume that enabling cache mode will
improve the performance in general. Allowing caching in the host will
require a non-negligable amount of host RAM to have a benefit. RAM is
usually the most constrained resource in any virtualization environment.
So while the cache may help performance when only one or two Vms are
running on the host, it may well in fact hurt performance once the host
is running enough VMs to max out RAM. So allowing caching will actually
give you quite variable performance, while the cache=none will give you
consistent performance regardless of host RAM utilization (underlying
contention of the storage device may of course still impact things).
Yeah, allowing page cache in the host might not be a good idea to run
multiple VMs, but cache type in QEMU has different meaning for network
block devices. For e.g, we use 'cache type' to control client side cache
of Sheepdog cluster, which implement a object cache in the local disk
for performance boost and reducing network traffics. This doesn't
consume memory at all, just occupy the disk space where runs sheep daemon.
How can it be a client-side cache if it doesn't consume memory on the
client?
Please explain how the client-side cache feature works. I'm not
familiar with sheepdog internals.
Let me start with local file as backend of block device of QEMU. It
basically uses host memory pages to cache blocks of emulated device.
Kernel internally maps those blocks into pages of file (A.K.A page
cache) and then we relies on the kernel memory subsystem to do writeback
of those cached pages. When VM read/write some blocks, kernel allocate
pages on demand to serve the read/write requests operated on the pages.
QEMU VM
^
| writeback/readahead pages
V |
POSIX file --- page cache --- disk
|
kernel does page wb/ra and reclaim
Object cache of Sheepdog do the similar things, the difference is that
we map those requested blocks into objects (which is plain fixed size
file on each node) and the sheep daemon play the role of kernel that
doing writeback of the dirty objects and reclaim of the clean objects to
make room to allocate objects for other requests.
QEMU VM
^
| push/pull objects
V |
SD device --- object cache --- SD replicated object storage.
|
Sheep daemon does object push/pull and reclaim
Object is implemented as fixed size file on disks, so for object cache,
those objects are all fixed size files on the node that sheep daemon
runs and sheep does directio on them. In this sense that we don't
consume memory, except those objects' metadata(inode dentry) on the node.
That is a serious abuse of the QEMU cache type variable. You now have one
setting with two completely different meanings for the same value. If you
want to control whether the sheepdog driver uses a local disk for object
cache you should have a completely separate QEMU command line setting
which can be controlled independantly of the cache= setting.
Hello Stefen and Kevin,
Should sheepdog driver use another new command setting to control its
internal cache?
For network block device, which simply forward the IO requests from
VMs via networking and never have chance to touch host's memory, I think
it is okay to multiplex the 'cache=type', but it looks that it causes
confusion for libvirt code.
From block/sheepdog.c:
/*
* QEMU block layer emulates writethrough cache as 'writeback + flush', so
* we always set SD_FLAG_CMD_CACHE (writeback cache) as default.
*/
s-cache_flags = SD_FLAG_CMD_CACHE;
if (flags BDRV_O_NOCACHE) {
s-cache_flags = SD_FLAG_CMD_DIRECT;
}
That means -drive cache=none and -drive cache=directsync use
SD_FLAG_CMD_DIRECT.
And -drive cache=writeback and cache=writethrough use SD_FLAG_CMD_CACHE.
This matches the behavior that QEMU uses for local files:
none/directsync mean O_DIRECT and writeback/writethrough go via the page
cache.
When you use NFS O_DIRECT also means bypass client-side cache. Where is
the issue?
I don't have any issue on this, just Daniel complained that Sheepdog
possible abuse the cache flags, which he thinks it should be page cache
oriented only, if I understand correctly.
Thanks,
Yuan
Re: [Qemu-devel] [RFC] introduce a general query-config cmd
Amos Kong ak...@redhat.com writes: [...] But info command of hmp doesn't support parameter (eg: (hmp) info config boot) It does since Wenchao Xia's recent improvements (commit 84c44613). For an example how to use them, check out his hmp: add function hmp_info_snapshots() (on list, not yet committed). [More questions, left to more competent folks...]
Re: [Qemu-devel] QEMU multithreaded device emulation
On Wed, Jan 23, 2013 at 2:17 PM, Emmanuel Blot eblot...@gmail.com wrote: (I forgot to CC: the list) On Wed, Jan 23, 2013 at 2:16 PM, Emmanuel Blot eblot...@gmail.com wrote: Today you cannot use cpu_physical_memory_*() from a thread without holding the QEMU global mutex. Ok. I have not looked at this part, which API handles this global mutex? See qemu_mutex_lock_iothread()/qemu_mutex_unlock_iothread() in include/qemu/main-loop.h. Stefan
Re: [Qemu-devel] [PATCH qom-cpu for-1.4 04/14] target-arm: Detect attempt to instantiate non-CPU type in cpu_init()
Am 23.01.2013 14:03, schrieb Peter Maydell:
On 23 January 2013 12:07, Andreas Färber afaer...@suse.de wrote:
Consolidate model checking into a new arm_cpu_class_by_name().
If the name matches an existing type, also check whether that type is
actually (a sub-type of) TYPE_ARM_CPU.
This fixes, e.g., -cpu tmp105 asserting.
Cc: qemu-stable qemu-sta...@nongnu.org
Signed-off-by: Andreas Färber afaer...@suse.de
---
target-arm/cpu.c| 17 +
target-arm/helper.c |6 --
2 Dateien geändert, 21 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 07588a1..d85f251 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -201,6 +201,21 @@ void arm_cpu_realize(ARMCPU *cpu)
/* CPU models */
+static ObjectClass *arm_cpu_class_by_name(const char *cpu_model)
+{
+ObjectClass *oc;
+
+if (cpu_model == NULL) {
+return NULL;
+}
explicit == NULL is kind of ugly; established style in
target-arm/ is if (!cpu_model)...
I consistently use !foo only if foo is bool. Any decent compiler will
optimize this appropriately. It not being that way in helper.c most
likely is a symptom of you replacing my patch with your initfn approach. ;)
+
+oc = object_class_by_name(cpu_model);
I note that the object_class_by_name() implementation returns
NULL for NULL input, though the documentation doesn't guarantee
it will...
+if (oc == NULL || object_class_dynamic_cast(oc, TYPE_ARM_CPU) == NULL) {
+return NULL;
+}
+return oc;
+}
+
static void arm926_initfn(Object *obj)
{
ARMCPU *cpu = ARM_CPU(obj);
@@ -766,6 +781,8 @@ static void arm_cpu_class_init(ObjectClass *oc, void
*data)
acc-parent_reset = cc-reset;
cc-reset = arm_cpu_reset;
+
+cc-class_by_name = arm_cpu_class_by_name;
Is this a class method because the plan is that eventually
the code that instantiates the CPU object will become
generic rather than target specific?
Yes, the plan as indicated in the CPUState realizefn series is to
generalize cpu_init() so that it only needs to know which base type to
operate on. I'm not yet sure how to handle CPU properties in a generic
way, but said series got three or four targets into a generic QOM'ish
form already.
}
static void cpu_register(const ARMCPUInfo *info)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 37c34a1..4c29117 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -1262,12 +1262,14 @@ ARMCPU *cpu_arm_init(const char *cpu_model)
{
ARMCPU *cpu;
CPUARMState *env;
+ObjectClass *oc;
static int inited = 0;
-if (!object_class_by_name(cpu_model)) {
+oc = cpu_class_by_name(TYPE_ARM_CPU, cpu_model);
+if (oc == NULL) {
return NULL;
}
-cpu = ARM_CPU(object_new(cpu_model));
+cpu = ARM_CPU(object_new(object_class_get_name(oc)));
Do we really have to convert back to the char* type
name in order to instantiate an object given the class?
Unless someone adds a new function, I fear so... internally TypeImpl is
used as alternative but that's not really exposed so far.
CC'ing Anthony.
Cheers,
Andreas
env = cpu-env;
env-cpu_model_str = cpu_model;
arm_cpu_realize(cpu);
--
1.7.10.4
thanks
-- PMM
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] QEMU multithreaded device emulation
(I forgot to CC: the list) On Wed, Jan 23, 2013 at 2:16 PM, Emmanuel Blot eblot...@gmail.com wrote: Today you cannot use cpu_physical_memory_*() from a thread without holding the QEMU global mutex. Ok. I have not looked at this part, which API handles this global mutex? Have you tried taking the mutex temporarily just for map/unmap and then doing the copy or I/O outside the mutex? Not yet. I've written a prototype (which works, with a single device thread for the datastream pipe + the existing QEMU threads) when I realized that the map/unmap may not be protected. For now I have not observed memory corruption, but I got lucky :-) qemu_bh_schedule() should be thread-safe (but please double-check). Ok. Thanks for your answers, Manu
Re: [Qemu-devel] [PATCH qom-cpu for-1.4 04/14] target-arm: Detect attempt to instantiate non-CPU type in cpu_init()
On 23 January 2013 13:38, Andreas Färber afaer...@suse.de wrote:
Am 23.01.2013 14:03, schrieb Peter Maydell:
On 23 January 2013 12:07, Andreas Färber afaer...@suse.de wrote:
+if (cpu_model == NULL) {
+return NULL;
+}
explicit == NULL is kind of ugly; established style in
target-arm/ is if (!cpu_model)...
I consistently use !foo only if foo is bool. Any decent compiler will
optimize this appropriately.
Yes -- I prefer (!ptr) not because I think the code will be different
but because I think it is better style (and consistent with the
current code -- there are no instances of == NULL in target-arm
today).
Is this a class method because the plan is that eventually
the code that instantiates the CPU object will become
generic rather than target specific?
Yes, the plan as indicated in the CPUState realizefn series is to
generalize cpu_init() so that it only needs to know which base type to
operate on. I'm not yet sure how to handle CPU properties in a generic
way, but said series got three or four targets into a generic QOM'ish
form already.
Cool.
-- PMM
Re: [Qemu-devel] [BUG] qemu-1.1.2 [FIXED-BY] qcow2: Fix avail_sectors in cluster allocation code
Am 23.01.2013 12:43, schrieb Kevin Wolf: Am 22.01.2013 15:14, schrieb Kevin Wolf: The series of requests to get into this state is somewhat tricky as it requires a specific physical ordering of clusters in the image file: Host cluster h: Guest cluster g is mapped to here Host cluster h + 1: Free, can be allocated for not yet mapped g + 1 Host cluster h + 2: Guest cluster g + 2 is mapped to here I can get this with this command on a fresh qcow2 image (64k cluster size): ./qemu-io -c 'write -P 0x66 0 64k' -c 'write 64k 64k' -c 'write -P 0x88 128k 64k' -c 'discard 64k 64k' -c 'write -P 0x77 0 160k' /tmp/test.qcow2 Now I get an additional COW for the area from 96k to 128k. However, this alone doesn't corrupt an image - a copy on write by itself is harmless because it only rewrites the data that is already there. The two things I'm going to check next are: a) What happens with concurrent requests now, are requests for the same area still correctly serialised? b) Can I modify the parameters so that copy_sectors() is working with values it wasn't designed for so that the data is copied to a wrong place or something like that. m-nb_available is used as an argument to it, so it certainly seems realistic. I can reliably reproduce a bug with a) at least. It requires some backports to qemu-io in order to get more control of the timing of AIO requests, but then it works like this: write -P 0x66 0 320k write 320k 128k write -P 0x88 448k 128k discard 320k 128k aio_flush break cow_write A aio_write -P 0x77 0 480k wait_break A write -P 0x99 480k 32k resume A aio_flush read -P 0x77 0 480k read -P 0x99 480k 32k read -P 0x88 512k 64k What happens is that the write of 0x99 to 480k doesn't detect an overlap with the running AIO request (because obviously it doesn't overlap), but the COW is actually taking place in the wrong cluster and therefore unprotected. Stop the AIO request between the COW read and the COW write to write 0x99 to that area, and the wrong COW will overwrite it, i.e. corrupt the image. Basing a real test case on this is not trivial, though, because I have to stop on the blkdebug event cow_write - which obviously isn't even emitted in the fixed version. I still have to look into option b) This is the reproducer using b): write -P 0x66 0 320k write 320k 128k write -P 0x55 1M 128k write -P 0x88 448k 128k discard 320k 128k aio_flush write -P 0x77 0 480k aio_flush read -P 0x77 0 480k read -P 0x88 480k 96k read -P 0x55 1M 128k Not sure if a stable branch for 1.1 is still maintained, but I'm copying qemu-stable just in case. Commit b7ab0fea actually fixes a qcow2 data corruption issue (even though under rare circumstances) and should definitely be cherry-picked for any new 1.1.x release. qemu 1.0 and older don't have the bug. Kevin
Re: [Qemu-devel] [PATCH] aio-posix: Fix return value of aio_poll()
Is that known behavior, or should aio give about the same performance as using a thread? It depends, but this is what we saw for migration too. You may also have less contention on the big QEMU lock if you use a thread. I managed to fix the performance issue by doing the following: - use O_DIRECT to avoid host cache on write - limit write size to max 4096 bytes (throughput gets a bit lower, but VM is much more responsive during backup) Now I get about the same behavior/performance as using a thread. Unfortunately, the bug in bdrv_drain_all() trigger more often. But when I use a thread it triggers the bug in bdrv_drain_all(). So how can I fix bdrv_drain_all() if I use a separate thread to write data? The bug is, in all likelihood, in your own code. Sorry. :) I currently use CoQueue to wait for the output thread. The simplest way to synchronize the main event loop with another thread is a bottom half. There is no example yet, but I will post it soon for migration. The problem is not really how I can synchronize. The problem is that I need to halt the blockjob when the output buffer is full, and this causes the bug in bdrv_drain_all(). I am currently a bit out of ideas - will do more testing.
Re: [Qemu-devel] [BUG] qemu-1.1.2 [FIXED-BY] qcow2: Fix avail_sectors in cluster allocation code
23.01.2013 17:54, Kevin Wolf wrote: [] Not sure if a stable branch for 1.1 is still maintained, but I'm copying qemu-stable just in case. Commit b7ab0fea actually fixes a qcow2 data corruption issue (even though under rare circumstances) and should definitely be cherry-picked for any new 1.1.x release. It's been picked up by me once Philipp found it after bisection. I understand that at that time, it wasn't known what actually happens, but since Philipp tested it in his tree and it is a bugfix and it were applied to master (actually to a released version), I thought it is okay. It is also included in current Debian packages. Speaking of 1.1, I really want to make 1.1.3 release, but I'm just unsure how to do that... ;) Thank you Kevin! /mjt
Re: [Qemu-devel] Questions on the virtual disk's cache type
On Wed, Jan 23, 2013 at 09:15:47PM +0800, Liu Yuan wrote:
On 01/23/2013 08:34 PM, Stefan Hajnoczi wrote:
On Wed, Jan 23, 2013 at 06:47:55PM +0800, Liu Yuan wrote:
On 01/23/2013 06:14 PM, Daniel P. Berrange wrote:
On Wed, Jan 23, 2013 at 06:09:01PM +0800, Liu Yuan wrote:
On 01/23/2013 05:30 PM, Daniel P. Berrange wrote:
FYI There is a patch proposed for customization
https://review.openstack.org/#/c/18042/
Seems that this patch is dropped and declined?
I should note that it is wrong to assume that enabling cache mode will
improve the performance in general. Allowing caching in the host will
require a non-negligable amount of host RAM to have a benefit. RAM is
usually the most constrained resource in any virtualization environment.
So while the cache may help performance when only one or two Vms are
running on the host, it may well in fact hurt performance once the host
is running enough VMs to max out RAM. So allowing caching will actually
give you quite variable performance, while the cache=none will give you
consistent performance regardless of host RAM utilization (underlying
contention of the storage device may of course still impact things).
Yeah, allowing page cache in the host might not be a good idea to run
multiple VMs, but cache type in QEMU has different meaning for network
block devices. For e.g, we use 'cache type' to control client side cache
of Sheepdog cluster, which implement a object cache in the local disk
for performance boost and reducing network traffics. This doesn't
consume memory at all, just occupy the disk space where runs sheep
daemon.
How can it be a client-side cache if it doesn't consume memory on the
client?
Please explain how the client-side cache feature works. I'm not
familiar with sheepdog internals.
Let me start with local file as backend of block device of QEMU. It
basically uses host memory pages to cache blocks of emulated device.
Kernel internally maps those blocks into pages of file (A.K.A page
cache) and then we relies on the kernel memory subsystem to do writeback
of those cached pages. When VM read/write some blocks, kernel allocate
pages on demand to serve the read/write requests operated on the pages.
QEMU VM
^
| writeback/readahead pages
V |
POSIX file --- page cache --- disk
|
kernel does page wb/ra and reclaim
Object cache of Sheepdog do the similar things, the difference is that
we map those requested blocks into objects (which is plain fixed size
file on each node) and the sheep daemon play the role of kernel that
doing writeback of the dirty objects and reclaim of the clean objects to
make room to allocate objects for other requests.
QEMU VM
^
| push/pull objects
V |
SD device --- object cache --- SD replicated object storage.
|
Sheep daemon does object push/pull and reclaim
Object is implemented as fixed size file on disks, so for object cache,
those objects are all fixed size files on the node that sheep daemon
runs and sheep does directio on them. In this sense that we don't
consume memory, except those objects' metadata(inode dentry) on the node.
Does QEMU usually talk to a local sheepdog daemon? I guess it must do
that, otherwise the cache doesn't avoid network traffic.
That is a serious abuse of the QEMU cache type variable. You now have one
setting with two completely different meanings for the same value. If you
want to control whether the sheepdog driver uses a local disk for object
cache you should have a completely separate QEMU command line setting
which can be controlled independantly of the cache= setting.
Hello Stefen and Kevin,
Should sheepdog driver use another new command setting to control its
internal cache?
For network block device, which simply forward the IO requests from
VMs via networking and never have chance to touch host's memory, I think
it is okay to multiplex the 'cache=type', but it looks that it causes
confusion for libvirt code.
From block/sheepdog.c:
/*
* QEMU block layer emulates writethrough cache as 'writeback + flush', so
* we always set SD_FLAG_CMD_CACHE (writeback cache) as default.
*/
s-cache_flags = SD_FLAG_CMD_CACHE;
if (flags BDRV_O_NOCACHE) {
s-cache_flags = SD_FLAG_CMD_DIRECT;
}
That means -drive cache=none and -drive cache=directsync use
SD_FLAG_CMD_DIRECT.
And -drive cache=writeback and cache=writethrough use SD_FLAG_CMD_CACHE.
This matches the behavior that QEMU uses for local files:
none/directsync mean O_DIRECT and writeback/writethrough go via the page
cache.
When you use NFS O_DIRECT also means bypass client-side cache. Where is
the issue?
I don't have any issue on this, just
Re: [Qemu-devel] Questions on the virtual disk's cache type
On 01/23/2013 10:15 PM, Stefan Hajnoczi wrote: On Wed, Jan 23, 2013 at 09:15:47PM +0800, Liu Yuan wrote: On 01/23/2013 08:34 PM, Stefan Hajnoczi wrote: On Wed, Jan 23, 2013 at 06:47:55PM +0800, Liu Yuan wrote: On 01/23/2013 06:14 PM, Daniel P. Berrange wrote: On Wed, Jan 23, 2013 at 06:09:01PM +0800, Liu Yuan wrote: On 01/23/2013 05:30 PM, Daniel P. Berrange wrote: FYI There is a patch proposed for customization https://review.openstack.org/#/c/18042/ Seems that this patch is dropped and declined? I should note that it is wrong to assume that enabling cache mode will improve the performance in general. Allowing caching in the host will require a non-negligable amount of host RAM to have a benefit. RAM is usually the most constrained resource in any virtualization environment. So while the cache may help performance when only one or two Vms are running on the host, it may well in fact hurt performance once the host is running enough VMs to max out RAM. So allowing caching will actually give you quite variable performance, while the cache=none will give you consistent performance regardless of host RAM utilization (underlying contention of the storage device may of course still impact things). Yeah, allowing page cache in the host might not be a good idea to run multiple VMs, but cache type in QEMU has different meaning for network block devices. For e.g, we use 'cache type' to control client side cache of Sheepdog cluster, which implement a object cache in the local disk for performance boost and reducing network traffics. This doesn't consume memory at all, just occupy the disk space where runs sheep daemon. How can it be a client-side cache if it doesn't consume memory on the client? Please explain how the client-side cache feature works. I'm not familiar with sheepdog internals. Let me start with local file as backend of block device of QEMU. It basically uses host memory pages to cache blocks of emulated device. Kernel internally maps those blocks into pages of file (A.K.A page cache) and then we relies on the kernel memory subsystem to do writeback of those cached pages. When VM read/write some blocks, kernel allocate pages on demand to serve the read/write requests operated on the pages. QEMU VM ^ | writeback/readahead pages V | POSIX file --- page cache --- disk | kernel does page wb/ra and reclaim Object cache of Sheepdog do the similar things, the difference is that we map those requested blocks into objects (which is plain fixed size file on each node) and the sheep daemon play the role of kernel that doing writeback of the dirty objects and reclaim of the clean objects to make room to allocate objects for other requests. QEMU VM ^ | push/pull objects V | SD device --- object cache --- SD replicated object storage. | Sheep daemon does object push/pull and reclaim Object is implemented as fixed size file on disks, so for object cache, those objects are all fixed size files on the node that sheep daemon runs and sheep does directio on them. In this sense that we don't consume memory, except those objects' metadata(inode dentry) on the node. Does QEMU usually talk to a local sheepdog daemon? I guess it must do that, otherwise the cache doesn't avoid network traffic. Yeah, mostly on the same node, but there are users separating VM from sheep daemons on different nodes too. Even with QEMU and sheep daemon set on different nodes, object cache can also help reduce the network traffic, because without object cache, a single write request will be replicated to N(copies) nodes, while with object cache, the write request will be handled only on one node and returns after the operation on the hit object. (like page cache hit). So directio in Sheepdog means that bypass object cache and do the normal request handling that is replicated to all the replica nodes. I think this also conform to the page cache directio semantics which bypass page cache. Thanks, Yuan
Re: [Qemu-devel] [RFC] qemu snapshot enchancement
On Wed, Jan 23, 2013 at 07:33:02PM +0800, Wenchao Xia wrote: I am trying to enhancement qemu's snapshot functionality, and have write a wiki draft on: http://wiki.qemu.org/Features/VMSnapshotEnchancement It mainly serves backup APP, the centric of it is: 1 fixing the vmstate size problem. 2 save vmstate lively for any type. 3 introduce new live snapshot mode, which offload qemu block function to lower components, such as LVM2 or other software even hardware accelerated one. 4 complete the picture of snapshots so they have similar or unified API for block / vmstate / whole vm, and doc it. I like the use cases section. I think it would be best to start there and fill in the details all the way down to the QMP API calls that need to be made. At that point we can be sure the use cases are covered and the API proposal will be easy to put together from the wiki page. Comments about the use cases: Case 1: * Step 3: Copy out data may take some time. It must be possible to resume the guest before Step 3 completes. This can be supported easily since backing files are read-only (but care needs to be taken with the commit blockjob and anything else which might write to the backing file). Case 2: * Why take an LVM snapshot after the internal snapshot (block + vmstate)? Case 3: * What does blank data mean? Besides that the use case makes sense. * When discussing this use case in the past it was suggested that the guest doesn't need to be paused during the LVM snapshot. Instead the QEMU block layer might be able to queue I/O requests, allowing the guest to run. Case 4: * Like Case 2, the benefit isn't clear to me. In a scenario where you use both QEMU and LVM snapshots there is now an extra management overhead of cleaning up 2 snapshots instead of just 1 when the user wants to delete a snapshot. I think this will be a headache. I had trouble understanding the General Summary, Subtask Details, General Goals sections. Not much is explained, new words are used without defining them, and the reader is left to puzzle together what you're thinking. But I think they can be dropped if we focus on the use cases instead. Here are the specific things I was wondering about before I skipped to the use cases section: 1 block device live snapshot as internal/external/blank delta data, export sync API for all type. * What does blank delta data mean? Sounds like an external snapshot. * all type means both internal and external snapshots? * I guess this point really means adding internal snapshot support to qmp_transaction()? 2 vmstate live save as internal/external data, export async API for external data, fix the size problem. * I think the first part means the following: * Saving vmstate to external files. * Saving iteratively while the guest is running (like live migration). * What is the async API for external data? * What is the size problem? Subtask Details * static internal block snapshot + internal vmstate save - this must be savevm. And I guess static means that the user cannot combine it with other snapshot or live migration operations. The text is too brief and fails to define the new words it uses. Stefan
Re: [Qemu-devel] [PATCH 0/2] Follow-up for MALLOC_CHECK_=xx failure of test-hbitmap
On 01/22/13 15:01, Paolo Bonzini wrote: Here is a follow-up for the failure that Kevin reported. Paolo Bonzini (2): mirror: do nothing on zero-sized disk hbitmap: add assertion on hbitmap_iter_init block/mirror.c | 2 +- include/qemu/hbitmap.h | 3 ++- tests/test-hbitmap.c | 13 +++-- util/hbitmap.c | 1 + 4 files changed, 7 insertions(+), 12 deletions(-) series Reviewed-by: Laszlo Ersek ler...@redhat.com
Re: [Qemu-devel] [PATCH qom-cpu for-1.4 04/14] target-arm: Detect attempt to instantiate non-CPU type in cpu_init()
Am 23.01.2013 14:41, schrieb Peter Maydell:
On 23 January 2013 13:38, Andreas Färber afaer...@suse.de wrote:
Am 23.01.2013 14:03, schrieb Peter Maydell:
On 23 January 2013 12:07, Andreas Färber afaer...@suse.de wrote:
+if (cpu_model == NULL) {
+return NULL;
+}
explicit == NULL is kind of ugly; established style in
target-arm/ is if (!cpu_model)...
I consistently use !foo only if foo is bool. Any decent compiler will
optimize this appropriately.
Yes -- I prefer (!ptr) not because I think the code will be different
but because I think it is better style (and consistent with the
current code -- there are no instances of == NULL in target-arm
today).
Please see style-changed version here:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu-types
https://github.com/afaerber/qemu-cpu/commit/726554290fa69425d0e94e2e4fd2fdfeeb54e00c
Is this a class method because the plan is that eventually
the code that instantiates the CPU object will become
generic rather than target specific?
Yes, the plan as indicated in the CPUState realizefn series is to
generalize cpu_init() so that it only needs to know which base type to
operate on. I'm not yet sure how to handle CPU properties in a generic
way, but said series got three or four targets into a generic QOM'ish
form already.
https://lists.nongnu.org/archive/html/qemu-devel/2013-01/msg03606.html
Cool.
Preview of rebased CPU realizefn here:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu-realize
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PATCHv3 1/2] qemu-img: find the highest offset in use during check
On Mon, Jan 21, 2013 at 09:25:12AM -0500, Federico Simoncelli wrote:
@@ -1154,7 +1154,7 @@ int qcow2_check_refcounts(BlockDriverState *bs,
BdrvCheckResult *res,
s-refcount_table_offset,
s-refcount_table_size * sizeof(uint64_t));
-for(i = 0; i s-refcount_table_size; i++) {
+for(i = 0, highest_cluster = 0; i s-refcount_table_size; i++) {
uint64_t offset, cluster;
offset = s-refcount_table[i];
cluster = offset s-cluster_bits;
This is the wrong for loop? It should be the next one down.
Stefan
Re: [Qemu-devel] [PATCH v9 4/7] trace: [monitor] Use new event control interface
On Thu, Jan 10, 2013 at 08:23:19PM +0100, Lluís Vilanova wrote:
Signed-off-by: Lluís Vilanova vilan...@ac.upc.edu
---
monitor.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/monitor.c b/monitor.c
index 9cf419b..4c40541 100644
--- a/monitor.c
+++ b/monitor.c
@@ -735,10 +735,24 @@ static void do_trace_event_set_state(Monitor *mon,
const QDict *qdict)
{
const char *tp_name = qdict_get_str(qdict, name);
bool new_state = qdict_get_bool(qdict, option);
-int ret = trace_event_set_state(tp_name, new_state);
-if (!ret) {
-monitor_printf(mon, unknown event name \%s\\n, tp_name);
+if (trace_event_is_pattern(tp_name)) {
+TraceEvent *ev = NULL;
+while ((ev = trace_event_pattern(tp_name, ev)) != NULL) {
+if (!trace_event_get_state_static(ev)) {
+monitor_printf(mon, event \%s\ is not traceable\n,
tp_name);
+}
+trace_event_set_state_dynamic(ev, new_state);
+}
+} else {
+TraceEvent *ev = trace_event_name(tp_name);
+if (ev == NULL) {
+monitor_printf(mon, unknown event name \%s\\n, tp_name);
+} else if (!trace_event_get_state_static(ev)) {
+monitor_printf(mon, event \%s\ is not traceable\n, tp_name);
+} else {
+trace_event_set_state_dynamic(ev, new_state);
+}
Do we need to duplicate the pattern vs not-a-pattern case?
We can loop with trace_event_pattern() and print the unknown event
name only if !trace_event_is_pattern().
Stefan
Re: [Qemu-devel] [PATCH 1/3] qemu-char: Add new char backend CirMemCharDriver
On Wed, 23 Jan 2013 11:15:40 +0800
Lei Li li...@linux.vnet.ibm.com wrote:
+static int cirmem_chr_write(CharDriverState *chr, const uint8_t *buf, int
len)
+{
+CirMemCharDriver *d = chr-opaque;
+int i;
+
+if (!buf || (len 0)) {
+return -1;
+}
Is the above checks really needed? I don't see other char drivers
doing that.
No answer.
+
+for (i = 0; i len; i++ ) {
+/* Avoid writing the IAC information to the queue. */
+if ((unsigned char)buf[i] == IAC) {
+continue;
+}
+
+d-cbuf[d-prod++ % d-size] = buf[i];
You never reset d-prod, can't it overflow?
+if ((d-prod - d-cons) d-size) {
+d-cons = d-prod - d-size;
+}
Why is the the if block above needed?
This algorithm is Anthony's suggestion which I squashed
it in. I think there is no overflow for that we use unsigned,
Actually, it can overflow. However, at least on my system the overflow
reset the variable to 0. Not sure if this will always be the case, but
that's the fix I'd propose anyway.
and
this if block will adjust the index of product and consumer.
I can see that, I asked why it's needed. I'm seeing a bug that might
be related to it:
(qemu) memchar_write foo luiz3
(qemu) memchar_read foo 10
uiz3,
(qemu)
I'd expect to read '3uiz' back.
Re: [Qemu-devel] [PATCHv3 1/2] qemu-img: find the highest offset in use during check
Am 23.01.2013 16:24, schrieb Stefan Hajnoczi:
On Mon, Jan 21, 2013 at 09:25:12AM -0500, Federico Simoncelli wrote:
@@ -1154,7 +1154,7 @@ int qcow2_check_refcounts(BlockDriverState *bs,
BdrvCheckResult *res,
s-refcount_table_offset,
s-refcount_table_size * sizeof(uint64_t));
-for(i = 0; i s-refcount_table_size; i++) {
+for(i = 0, highest_cluster = 0; i s-refcount_table_size; i++) {
uint64_t offset, cluster;
offset = s-refcount_table[i];
cluster = offset s-cluster_bits;
This is the wrong for loop? It should be the next one down.
Oops, how did this happen? I'm pretty sure that one of the earlier
versions had it in the right place.
Anyway, it doesn't change the semantics, could just need a cleanup.
Kevin
Re: [Qemu-devel] [QEMU PATCH v5 1/3] virtio-net: remove layout assumptions for ctrl vq
On Tue, Jan 22, 2013 at 11:44:44PM +0800, Amos Kong wrote:
From: Michael S. Tsirkin m...@redhat.com
Virtio-net code makes assumption about virtqueue descriptor layout
(e.g. sg[0] is the header, sg[1] is the data buffer).
This patch makes code not rely on the layout of descriptors.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Amos Kong ak...@redhat.com
Applied all three, thanks.
---
hw/virtio-net.c | 129
---
1 files changed, 75 insertions(+), 54 deletions(-)
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 3bb01b1..af1f3a1 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -315,44 +315,44 @@ static void virtio_net_set_features(VirtIODevice *vdev,
uint32_t features)
}
static int virtio_net_handle_rx_mode(VirtIONet *n, uint8_t cmd,
- VirtQueueElement *elem)
+ struct iovec *iov, unsigned int iov_cnt)
{
uint8_t on;
+size_t s;
-if (elem-out_num != 2 || elem-out_sg[1].iov_len != sizeof(on)) {
-error_report(virtio-net ctrl invalid rx mode command);
-exit(1);
+s = iov_to_buf(iov, iov_cnt, 0, on, sizeof(on));
+if (s != sizeof(on)) {
+return VIRTIO_NET_ERR;
}
-on = ldub_p(elem-out_sg[1].iov_base);
-
-if (cmd == VIRTIO_NET_CTRL_RX_MODE_PROMISC)
+if (cmd == VIRTIO_NET_CTRL_RX_MODE_PROMISC) {
n-promisc = on;
-else if (cmd == VIRTIO_NET_CTRL_RX_MODE_ALLMULTI)
+} else if (cmd == VIRTIO_NET_CTRL_RX_MODE_ALLMULTI) {
n-allmulti = on;
-else if (cmd == VIRTIO_NET_CTRL_RX_MODE_ALLUNI)
+} else if (cmd == VIRTIO_NET_CTRL_RX_MODE_ALLUNI) {
n-alluni = on;
-else if (cmd == VIRTIO_NET_CTRL_RX_MODE_NOMULTI)
+} else if (cmd == VIRTIO_NET_CTRL_RX_MODE_NOMULTI) {
n-nomulti = on;
-else if (cmd == VIRTIO_NET_CTRL_RX_MODE_NOUNI)
+} else if (cmd == VIRTIO_NET_CTRL_RX_MODE_NOUNI) {
n-nouni = on;
-else if (cmd == VIRTIO_NET_CTRL_RX_MODE_NOBCAST)
+} else if (cmd == VIRTIO_NET_CTRL_RX_MODE_NOBCAST) {
n-nobcast = on;
-else
+} else {
return VIRTIO_NET_ERR;
+}
return VIRTIO_NET_OK;
}
static int virtio_net_handle_mac(VirtIONet *n, uint8_t cmd,
- VirtQueueElement *elem)
+ struct iovec *iov, unsigned int iov_cnt)
{
struct virtio_net_ctrl_mac mac_data;
+size_t s;
-if (cmd != VIRTIO_NET_CTRL_MAC_TABLE_SET || elem-out_num != 3 ||
-elem-out_sg[1].iov_len sizeof(mac_data) ||
-elem-out_sg[2].iov_len sizeof(mac_data))
+if (cmd != VIRTIO_NET_CTRL_MAC_TABLE_SET) {
return VIRTIO_NET_ERR;
+}
n-mac_table.in_use = 0;
n-mac_table.first_multi = 0;
@@ -360,54 +360,72 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t
cmd,
n-mac_table.multi_overflow = 0;
memset(n-mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN);
-mac_data.entries = ldl_p(elem-out_sg[1].iov_base);
+s = iov_to_buf(iov, iov_cnt, 0, mac_data.entries,
+ sizeof(mac_data.entries));
+mac_data.entries = ldl_p(mac_data.entries);
+if (s != sizeof(mac_data.entries)) {
+return VIRTIO_NET_ERR;
+}
+iov_discard_front(iov, iov_cnt, s);
-if (sizeof(mac_data.entries) +
-(mac_data.entries * ETH_ALEN) elem-out_sg[1].iov_len)
+if (mac_data.entries * ETH_ALEN iov_size(iov, iov_cnt)) {
return VIRTIO_NET_ERR;
+}
if (mac_data.entries = MAC_TABLE_ENTRIES) {
-memcpy(n-mac_table.macs, elem-out_sg[1].iov_base +
sizeof(mac_data),
- mac_data.entries * ETH_ALEN);
+s = iov_to_buf(iov, iov_cnt, 0, n-mac_table.macs,
+ mac_data.entries * ETH_ALEN);
+if (s != mac_data.entries * ETH_ALEN) {
+return VIRTIO_NET_ERR;
+}
n-mac_table.in_use += mac_data.entries;
} else {
n-mac_table.uni_overflow = 1;
}
+iov_discard_front(iov, iov_cnt, mac_data.entries * ETH_ALEN);
+
n-mac_table.first_multi = n-mac_table.in_use;
-mac_data.entries = ldl_p(elem-out_sg[2].iov_base);
+s = iov_to_buf(iov, iov_cnt, 0, mac_data.entries,
+ sizeof(mac_data.entries));
+mac_data.entries = ldl_p(mac_data.entries);
+if (s != sizeof(mac_data.entries)) {
+return VIRTIO_NET_ERR;
+}
+
+iov_discard_front(iov, iov_cnt, s);
-if (sizeof(mac_data.entries) +
-(mac_data.entries * ETH_ALEN) elem-out_sg[2].iov_len)
+if (mac_data.entries * ETH_ALEN != iov_size(iov, iov_cnt)) {
return VIRTIO_NET_ERR;
+}
-if (mac_data.entries) {
-if (n-mac_table.in_use + mac_data.entries = MAC_TABLE_ENTRIES) {
-memcpy(n-mac_table.macs + (n-mac_table.in_use *
Re: [Qemu-devel] [PATCH 1/8 v6] cutils: unsigned int parsing functions
On 01/18/13 20:41, Eduardo Habkost wrote: Changes v6: Reviewed-by: Laszlo Ersek ler...@redhat.com
Re: [Qemu-devel] [PATCH] ich9: add support for pci assignment
On Tue, Jan 22, 2013 at 07:11:37PM -0700, Alex Williamson wrote:
Fills out support for the pci assignment API. Added:
PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin)
Add calls to pci_bus_fire_intx_routing_notifier() when routing changes
are made.
From: Jason Baron jba...@redhat.com
Signed-off-by: Alex Williamson alex.william...@redhat.com
Applied, thanks for repost (note for the future: it's preferable put
the From: at top of the commit log, this way git am knows to pick it up).
---
Jason posted this back in October, there were no comments. Updated
and tested for latest tree. Currently attempting to use -device
pci-assign with q35 results in:
qemu-system-x86_64: -device pci-assign,host=b:00.0,addr=6: PCI: Bug -
unimplemented PCI INTx routing (q35-pcihost)
This allows it to work. Note that there's a seabios bug for option
ROMs making use of interrupts, hopefully we can also pull that fix
in for 1.4, but guests not relying on bios programming of the PCI
interrupt line value should work fine.
hw/ich9.h |1 +
hw/lpc_ich9.c | 33 +
hw/pc_q35.c |1 +
3 files changed, 35 insertions(+)
diff --git a/hw/ich9.h b/hw/ich9.h
index b8d8e6d..d4509bb 100644
--- a/hw/ich9.h
+++ b/hw/ich9.h
@@ -18,6 +18,7 @@
void ich9_lpc_set_irq(void *opaque, int irq_num, int level);
int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx);
+PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin);
void ich9_lpc_pm_init(PCIDevice *pci_lpc, qemu_irq cmos_s3);
PCIBus *ich9_d2pbr_init(PCIBus *bus, int devfn, int sec_bus);
i2c_bus *ich9_smb_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
diff --git a/hw/lpc_ich9.c b/hw/lpc_ich9.c
index 16843d7..e25689b 100644
--- a/hw/lpc_ich9.c
+++ b/hw/lpc_ich9.c
@@ -158,6 +158,7 @@ static void ich9_cc_write(void *opaque, hwaddr addr,
ich9_cc_addr_len(addr, len);
memcpy(lpc-chip_config + addr, val, len);
+pci_bus_fire_intx_routing_notifier(lpc-d.bus);
ich9_cc_update(lpc);
}
@@ -286,6 +287,32 @@ int ich9_lpc_map_irq(PCIDevice *pci_dev, int intx)
return lpc-irr[PCI_SLOT(pci_dev-devfn)][intx];
}
+PCIINTxRoute ich9_route_intx_pin_to_irq(void *opaque, int pirq_pin)
+{
+ICH9LPCState *lpc = opaque;
+PCIINTxRoute route;
+int pic_irq;
+int pic_dis;
+
+assert(0 = pirq_pin);
+assert(pirq_pin ICH9_LPC_NB_PIRQS);
+
+route.mode = PCI_INTX_ENABLED;
+ich9_lpc_pic_irq(lpc, pirq_pin, pic_irq, pic_dis);
+if (!pic_dis) {
+if (pic_irq ICH9_LPC_PIC_NUM_PINS) {
+route.irq = pic_irq;
+} else {
+route.mode = PCI_INTX_DISABLED;
+route.irq = -1;
+}
+} else {
+route.irq = ich9_pirq_to_gsi(pirq_pin);
+}
+
+return route;
+}
+
static int ich9_lpc_sci_irq(ICH9LPCState *lpc)
{
switch (lpc-d.config[ICH9_LPC_ACPI_CTRL]
@@ -405,6 +432,12 @@ static void ich9_lpc_config_write(PCIDevice *d,
if (ranges_overlap(addr, len, ICH9_LPC_RCBA, 4)) {
ich9_lpc_rcba_update(lpc, rbca_old);
}
+if (ranges_overlap(addr, len, ICH9_LPC_PIRQA_ROUT, 4)) {
+pci_bus_fire_intx_routing_notifier(lpc-d.bus);
+}
+if (ranges_overlap(addr, len, ICH9_LPC_PIRQE_ROUT, 4)) {
+pci_bus_fire_intx_routing_notifier(lpc-d.bus);
+}
}
static void ich9_lpc_reset(DeviceState *qdev)
diff --git a/hw/pc_q35.c b/hw/pc_q35.c
index d82353e..6f5ff8d 100644
--- a/hw/pc_q35.c
+++ b/hw/pc_q35.c
@@ -147,6 +147,7 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
ich9_lpc-ioapic = gsi_state-ioapic_irq;
pci_bus_irqs(host_bus, ich9_lpc_set_irq, ich9_lpc_map_irq, ich9_lpc,
ICH9_LPC_NB_PIRQS);
+pci_bus_set_route_irq_fn(host_bus, ich9_route_intx_pin_to_irq);
isa_bus = ich9_lpc-isa_bus;
/*end early*/
Re: [Qemu-devel] [PATCH 1/3] qemu-char: Add new char backend CirMemCharDriver
On Wed, 23 Jan 2013 13:31:37 -0200
Luiz Capitulino lcapitul...@redhat.com wrote:
On Wed, 23 Jan 2013 11:15:40 +0800
Lei Li li...@linux.vnet.ibm.com wrote:
+static int cirmem_chr_write(CharDriverState *chr, const uint8_t *buf,
int len)
+{
+CirMemCharDriver *d = chr-opaque;
+int i;
+
+if (!buf || (len 0)) {
+return -1;
+}
Is the above checks really needed? I don't see other char drivers
doing that.
No answer.
+
+for (i = 0; i len; i++ ) {
+/* Avoid writing the IAC information to the queue. */
+if ((unsigned char)buf[i] == IAC) {
+continue;
+}
+
+d-cbuf[d-prod++ % d-size] = buf[i];
You never reset d-prod, can't it overflow?
+if ((d-prod - d-cons) d-size) {
+d-cons = d-prod - d-size;
+}
Why is the the if block above needed?
This algorithm is Anthony's suggestion which I squashed
it in. I think there is no overflow for that we use unsigned,
Actually, it can overflow. However, at least on my system the overflow
reset the variable to 0. Not sure if this will always be the case, but
that's the fix I'd propose anyway.
and
this if block will adjust the index of product and consumer.
I can see that, I asked why it's needed. I'm seeing a bug that might
be related to it:
(qemu) memchar_write foo luiz3
(qemu) memchar_read foo 10
uiz3,
(qemu)
I'd expect to read '3uiz' back.
Forgot to say that, my buffer size is 4 bytes:
-chardev memory,id=foo,maxcapacity=4
Re: [Qemu-devel] [PATCH 2/3] QAPI: Introduce memchar-write QMP command
On Wed, 23 Jan 2013 11:30:23 +0800
Lei Li li...@linux.vnet.ibm.com wrote:
On 01/23/2013 12:27 AM, Luiz Capitulino wrote:
On Tue, 22 Jan 2013 16:12:51 +0800
Lei Li li...@linux.vnet.ibm.com wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
hmp-commands.hx | 16
hmp.c| 13 +
hmp.h|1 +
qapi-schema.json | 41 +
qemu-char.c | 48
qmp-commands.hx | 34 ++
6 files changed, 153 insertions(+), 0 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 0934b9b..e546c76 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -837,6 +837,22 @@ STEXI
@item nmi @var{cpu}
@findex nmi
Inject an NMI on the given CPU (x86 only).
+
+ETEXI
+
+{
+.name = memchar_write,
+.args_type = chardev:s,data:s,
+.params = chardev data,
This is missing .help. Please look at the other entries for examples.
Hmm, I did add .help here before version 5, and I get rid of them
based on your comments Help doesn't make sense for HMP
Did I really say that? The help text makes sense _only_ for HMP.
I may have quoted the wrong .hx file. If I did that I'm sorry, but it's
also just a matter of checking other entries in the file to see if
yours is correct.
Re: [Qemu-devel] [PATCH 3/3] QAPI: Introduce memchar-read QMP command
On Wed, 23 Jan 2013 17:06:12 +0800
Lei Li li...@linux.vnet.ibm.com wrote:
Signed-off-by: Lei Li li...@linux.vnet.ibm.com
---
hmp-commands.hx | 21 +
hmp.c| 17 +
hmp.h|1 +
qapi-schema.json | 36
qemu-char.c | 48
qmp-commands.hx | 33 +
6 files changed, 156 insertions(+), 0 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index bcfea11..bdd48f3 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -858,6 +858,27 @@ to char device 'memory'.
ETEXI
{
+.name = memchar_read,
+.args_type = device:s,size:i,
+.params = device size,
+.help = Provide read interface for CirMemCharDriver. Read
from
+ it and return the data with size.,
+.mhandler.cmd = hmp_memchar_read,
+},
+
+STEXI
+@item memchar_read @var{device}
+@findex memchar_read
+Provide read interface for CirMemCharDriver. Read from char device
+'memory' and return the data.
+
+@var{size} is the size of data want to read from. Refer to unencoded
+size of the raw data, would adjust to the init size of the memchar
+if the requested size is larger than it.
+
+ETEXI
+
+{
.name = migrate,
.args_type = detach:-d,blk:-b,inc:-i,uri:s,
.params = [-d] [-b] [-i] uri,
diff --git a/hmp.c b/hmp.c
index 647316a..1f1df5d 100644
--- a/hmp.c
+++ b/hmp.c
@@ -697,6 +697,23 @@ void hmp_memchar_write(Monitor *mon, const QDict *qdict)
hmp_handle_error(mon, errp);
}
+void hmp_memchar_read(Monitor *mon, const QDict *qdict)
+{
+uint32_t size = qdict_get_int(qdict, size);
+const char *chardev = qdict_get_str(qdict, device);
+MemCharRead *meminfo;
+Error *errp = NULL;
+
+meminfo = qmp_memchar_read(chardev, size, false, 0, errp);
+if (errp) {
+monitor_printf(mon, %s\n, error_get_pretty(errp));
+error_free(errp);
+return;
+}
+
+monitor_printf(mon, %s, \n, meminfo-data);
+}
+
static void hmp_cont_cb(void *opaque, int err)
{
if (!err) {
diff --git a/hmp.h b/hmp.h
index 06d6ea2..076d8cf 100644
--- a/hmp.h
+++ b/hmp.h
@@ -44,6 +44,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
void hmp_memsave(Monitor *mon, const QDict *qdict);
void hmp_pmemsave(Monitor *mon, const QDict *qdict);
void hmp_memchar_write(Monitor *mon, const QDict *qdict);
+void hmp_memchar_read(Monitor *mon, const QDict *qdict);
void hmp_cont(Monitor *mon, const QDict *qdict);
void hmp_system_wakeup(Monitor *mon, const QDict *qdict);
void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
diff --git a/qapi-schema.json b/qapi-schema.json
index 8202311..ad4e276 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -363,6 +363,42 @@
'*format': 'DataFormat'} }
##
+# @MemCharRead
+#
+# Result of QMP command memchar-read.
+#
+# @data: The data read from memchar as string.
+#
+# @count: The numbers of bytes read from.
+#
+# Since: 1.4
+##
+{ 'type': 'MemCharRead',
+ 'data': { 'data': 'str', 'count': 'int' } }
+
+##
+# @memchar-read:
+#
+# Provide read interface for memchardev. Read from the char
+# device 'memory' and return the data.
+#
+# @device: the name of the memory char device.
+#
+# @size: the size to read in bytes.
+#
+# @format: #optional the format of the data want to read from
+# memchardev, by default is 'utf8'.
+#
+# Returns: @MemCharRead
+# If @device is not a valid memchr device, DeviceNotFound
+#
+# Since: 1.4
+##
+{ 'command': 'memchar-read',
+ 'data': {'device': 'str', 'size': 'int', '*format': 'DataFormat'},
+ 'returns': 'MemCharRead' }
+
+##
# @CommandInfo:
#
# Information about a QMP command
diff --git a/qemu-char.c b/qemu-char.c
index dbd1a7c..c45397a 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2790,6 +2790,54 @@ void qmp_memchar_write(const char *device, int64_t
size,
}
}
+MemCharRead *qmp_memchar_read(const char *device, int64_t size,
+ bool has_format, enum DataFormat format,
+ Error **errp)
+{
+CharDriverState *chr;
+guchar *read_data;
+MemCharRead *meminfo;
+size_t count;
+
+chr = qemu_chr_find(device);
+if (!chr) {
+error_set(errp, QERR_DEVICE_NOT_FOUND, device);
+return NULL;
+}
+
+if (qemu_is_chr(chr, memory)) {
+error_setg(errp,%s is not memory char device, device);
+return NULL;
+}
+
+if (size = 0) {
+error_setg(errp, size must be greater than zero);
+return NULL;
+}
+
+/* Return empty strings when the buffer is empty. */
+if (cirmem_chr_is_empty(chr)) {
+return NULL;
+}
You can't just return NULL
Re: [Qemu-devel] [PATCH qom-cpu for-1.4 04/14] target-arm: Detect attempt to instantiate non-CPU type in cpu_init()
On 23 January 2013 15:25, Andreas Färber afaer...@suse.de wrote:
Am 23.01.2013 14:41, schrieb Peter Maydell:
On 23 January 2013 13:38, Andreas Färber afaer...@suse.de wrote:
Am 23.01.2013 14:03, schrieb Peter Maydell:
On 23 January 2013 12:07, Andreas Färber afaer...@suse.de wrote:
+if (cpu_model == NULL) {
+return NULL;
+}
explicit == NULL is kind of ugly; established style in
target-arm/ is if (!cpu_model)...
I consistently use !foo only if foo is bool. Any decent compiler will
optimize this appropriately.
Yes -- I prefer (!ptr) not because I think the code will be different
but because I think it is better style (and consistent with the
current code -- there are no instances of == NULL in target-arm
today).
Please see style-changed version here:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu-types
https://github.com/afaerber/qemu-cpu/commit/726554290fa69425d0e94e2e4fd2fdfeeb54e00c
Thanks.
Acked-by: Peter Maydell peter.mayd...@linaro.org
for the arm related patches in this series.
-- PMM
Re: [Qemu-devel] [RESEND PATCH for 1.4 v10 0/3] char: Add CirMemCharDriver and provide QMP interface
On Wed, 23 Jan 2013 17:06:09 +0800 Lei Li li...@linux.vnet.ibm.com wrote: Hi Anthony, Resubmit this series with your comments squashed in and Luiz's new comments fixed up. I will push console command part in another thread. There are two bugs in this series. QEMU started with: # qemu [...] -chardev memory,id=foo,maxcapacity=4 This explodes: (qemu) memchar_read foo 10 I'd expect to read '3uiz' in the steps below: (qemu) memchar_write foo luiz3 (qemu) memchar_read foo 10 uiz3, (qemu) Also, please, wait for a discussion to settle before sending a new version, otherwise we'll reach V50 and this won't be merged...
