Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options
On Wed, Jun 6, 2012 at 1:42 PM, Anthony Liguori aligu...@us.ibm.com wrote: On 06/06/2012 11:31 AM, Benjamin Herrenschmidt wrote: On Wed, 2012-06-06 at 10:52 +0800, li zhang wrote: Hi Anthony, Any comment on this? Allright, this is all quite confusing... He's what I think should happen: When no option is passed -at-all-, we should have vga std and usb ohci + usb mouse + usb ps2. When -nodefault is passed, we should have none of the above. -nodefault is a pretty ugly hack. I don't think there's any good reason to involve -nodefault into this discussion. -vga should only affect vga (a shortcut for -device pick_your_vga_poison) Ack. -usb should be essentially useless by default unless -nodefault is passed in which case it is necessary to enable usb support, and -device (or equivalent) to manually add the keyboard and mouse (libvirt). If you want pseries to always have usb, just make it there by default and yeah, -usb would be useless. If you want the option to not have usb, introduce a machine option I guess. Thanks Anthony. It's a better way to introduce one machine option. :) I think it's over thinking it though. There's little harm in having a usb controller present all the time. Got it. Thanks. Regards, Anthony Liguori That's the best I can think of ... however it might be a bit tricky seeing how qemu does things in vl.c at the moment, we might want to introduce a default_usb variable which is used to set usb_enabled. BTW. The mac models should essentially behave the same, at least the 64-bit one (32-bit supports CUDA for keyboard/mouse so USB isn't strictly necessary). Cheers, Ben. Thanks. On Tue, Jun 5, 2012 at 5:48 PM, li zhangzhlci...@gmail.com wrote: Hi all, For pseries, when creating VMs with -vga std, it requires usb mouse and usb kbd devices to be added. But with default options, vga is enabled and usb is disabled. User may use default options as the following commands: $qemu -M pseries If vga is enabled, usb mouse and usb kbd is disabled, the mouse and kbd can't be used. So it's very hard for users to use. I think it's necessary to enable usb with default options. Any idea about that? Your comments are very appreciated. :) Thanks. -Li -- Best Regards -Li -- Best Regards -Li
[Qemu-devel] [PATCH 0/2] Clean up includes of monitor.h
There is no reason why QAPI clients should use monitor.h at all,
qerror.h suffices.
qmp-commands.h uses the Monitor typedef, but it is only included
from files that already get the typedef from qemu-common.h.
Paolo Bonzini (2):
kvm: add missing include files
qmp: do not include monitor.h from qapi-types-core.h
hmp.c |1 +
kvm-all.c |2 ++
qapi/qapi-types-core.h |4 +---
3 files changed, 4 insertions(+), 3 deletions(-)
--
1.7.10.1
From 669822329cc01dd8e55e0e080aae20bee4878dd4 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Fri, 11 May 2012 14:36:34 +0200
Subject: [PATCH 1/2] kvm: add missing include files
These are included via monitor.h right now, add them explicitly.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
kvm-all.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/kvm-all.c b/kvm-all.c
index 489ee53..831651d 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -22,6 +22,8 @@
#include qemu-common.h
#include qemu-barrier.h
+#include qemu-option.h
+#include qemu-config.h
#include sysemu.h
#include hw/hw.h
#include hw/msi.h
--
1.7.10.1
From 64cda12bfeb007b180e3328b757818f88c5d7302 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Fri, 11 May 2012 14:34:32 +0200
Subject: [PATCH 2/2] qmp: do not include monitor.h from qapi-types-core.h
The comment is stale, monitor.h is not needed anymore (only qerror.h
is, because it contains the schema for errors).
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hmp.c |1 +
qapi/qapi-types-core.h |4 +---
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/hmp.c b/hmp.c
index bb0952e..7be673e 100644
--- a/hmp.c
+++ b/hmp.c
@@ -16,6 +16,7 @@
#include hmp.h
#include qemu-timer.h
#include qmp-commands.h
+#include monitor.h
static void hmp_handle_error(Monitor *mon, Error **errp)
{
diff --git a/qapi/qapi-types-core.h b/qapi/qapi-types-core.h
index 27e6be0..f781fc3 100644
--- a/qapi/qapi-types-core.h
+++ b/qapi/qapi-types-core.h
@@ -16,8 +16,6 @@
#include qemu-common.h
#include error.h
-
-/* FIXME this is temporary until we remove middle mode */
-#include monitor.h
+#include qerror.h
#endif
--
1.7.10.1
[Qemu-devel] [PATCH 2/2] qmp: do not include monitor.h from qapi-types-core.h
The comment is stale, monitor.h is not needed anymore (only qerror.h
is, because it contains the schema for errors).
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
hmp.c |1 +
qapi/qapi-types-core.h |4 +---
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/hmp.c b/hmp.c
index bb0952e..7be673e 100644
--- a/hmp.c
+++ b/hmp.c
@@ -16,6 +16,7 @@
#include hmp.h
#include qemu-timer.h
#include qmp-commands.h
+#include monitor.h
static void hmp_handle_error(Monitor *mon, Error **errp)
{
diff --git a/qapi/qapi-types-core.h b/qapi/qapi-types-core.h
index 27e6be0..f781fc3 100644
--- a/qapi/qapi-types-core.h
+++ b/qapi/qapi-types-core.h
@@ -16,8 +16,6 @@
#include qemu-common.h
#include error.h
-
-/* FIXME this is temporary until we remove middle mode */
-#include monitor.h
+#include qerror.h
#endif
--
1.7.10.1
[Qemu-devel] [PATCH 5/6] blkdebug: optionally tie errors to a specific sector
This makes blkdebug scripts more powerful, and independent of the
exact sequence of operations performed by streaming.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/blkdebug.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/block/blkdebug.c b/block/blkdebug.c
index d12ebbf..59dcea0 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -59,6 +59,7 @@ typedef struct BlkdebugRule {
int error;
int immediately;
int once;
+int64_t sector;
} inject;
struct {
int new_state;
@@ -85,6 +86,10 @@ static QemuOptsList inject_error_opts = {
.type = QEMU_OPT_NUMBER,
},
{
+.name = sector,
+.type = QEMU_OPT_NUMBER,
+},
+{
.name = once,
.type = QEMU_OPT_BOOL,
},
@@ -213,6 +218,7 @@ static int add_rule(QemuOpts *opts, void *opaque)
rule-options.inject.once = qemu_opt_get_bool(opts, once, 0);
rule-options.inject.immediately =
qemu_opt_get_bool(opts, immediately, 0);
+rule-options.inject.sector = qemu_opt_get_number(opts, sector, -1);
break;
case ACTION_SET_STATE:
@@ -343,7 +349,15 @@ static BlockDriverAIOCB
*blkdebug_aio_readv(BlockDriverState *bs,
BlockDriverCompletionFunc *cb, void *opaque)
{
BDRVBlkdebugState *s = bs-opaque;
-BlkdebugRule *rule = QSIMPLEQ_FIRST(s-active_rules);
+BlkdebugRule *rule = NULL;
+
+QSIMPLEQ_FOREACH(rule, s-active_rules, active_next) {
+if (rule-options.inject.sector == -1 ||
+(rule-options.inject.sector = sector_num
+ rule-options.inject.sector sector_num + nb_sectors)) {
+break;
+}
+}
if (rule rule-options.inject.error) {
return inject_error(bs, cb, opaque, rule);
@@ -357,7 +371,15 @@ static BlockDriverAIOCB
*blkdebug_aio_writev(BlockDriverState *bs,
BlockDriverCompletionFunc *cb, void *opaque)
{
BDRVBlkdebugState *s = bs-opaque;
-BlkdebugRule *rule = QSIMPLEQ_FIRST(s-active_rules);
+BlkdebugRule *rule = NULL;
+
+QSIMPLEQ_FOREACH(rule, s-active_rules, active_next) {
+if (rule-options.inject.sector == -1 ||
+(rule-options.inject.sector = sector_num
+ rule-options.inject.sector sector_num + nb_sectors)) {
+break;
+}
+}
if (rule rule-options.inject.error) {
return inject_error(bs, cb, opaque, rule);
--
1.7.10.1
[Qemu-devel] [PATCH 2/6] blkdebug: tiny cleanup
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- block/blkdebug.c |8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/block/blkdebug.c b/block/blkdebug.c index 1eff940..1f79ef2 100644 --- a/block/blkdebug.c +++ b/block/blkdebug.c @@ -361,9 +361,7 @@ static BlockDriverAIOCB *blkdebug_aio_readv(BlockDriverState *bs, return inject_error(bs, cb, opaque); } -BlockDriverAIOCB *acb = -bdrv_aio_readv(bs-file, sector_num, qiov, nb_sectors, cb, opaque); -return acb; +return bdrv_aio_readv(bs-file, sector_num, qiov, nb_sectors, cb, opaque); } static BlockDriverAIOCB *blkdebug_aio_writev(BlockDriverState *bs, @@ -376,9 +374,7 @@ static BlockDriverAIOCB *blkdebug_aio_writev(BlockDriverState *bs, return inject_error(bs, cb, opaque); } -BlockDriverAIOCB *acb = -bdrv_aio_writev(bs-file, sector_num, qiov, nb_sectors, cb, opaque); -return acb; +return bdrv_aio_writev(bs-file, sector_num, qiov, nb_sectors, cb, opaque); } static void blkdebug_close(BlockDriverState *bs) -- 1.7.10.1
[Qemu-devel] [PATCH 6/6] raw: hook into blkdebug
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/raw.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/block/raw.c b/block/raw.c
index 09d9b48..ff34ea4 100644
--- a/block/raw.c
+++ b/block/raw.c
@@ -12,12 +12,14 @@ static int raw_open(BlockDriverState *bs, int flags)
static int coroutine_fn raw_co_readv(BlockDriverState *bs, int64_t sector_num,
int nb_sectors, QEMUIOVector *qiov)
{
+BLKDBG_EVENT(bs-file, BLKDBG_READ_AIO);
return bdrv_co_readv(bs-file, sector_num, nb_sectors, qiov);
}
static int coroutine_fn raw_co_writev(BlockDriverState *bs, int64_t sector_num,
int nb_sectors, QEMUIOVector *qiov)
{
+BLKDBG_EVENT(bs-file, BLKDBG_WRITE_AIO);
return bdrv_co_writev(bs-file, sector_num, nb_sectors, qiov);
}
--
1.7.10.1
[Qemu-devel] [PATCH v2 09/25] build: put qom/ rules in a Makefile.objs file
qom/ already used a separate makefile. Convert it to use relative paths, and make it declare both common-obj-y and user-obj-y. This way, the upper makefiles do not need to know that some QOM files are compiled twice. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs | 13 +++-- qom/Makefile |2 -- qom/Makefile.objs |4 3 files changed, 11 insertions(+), 8 deletions(-) delete mode 100644 qom/Makefile create mode 100644 qom/Makefile.objs diff --git a/Makefile.objs b/Makefile.objs index e06db12..ef49a09 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -12,9 +12,7 @@ universal-obj-y += $(qobject-obj-y) ### # QOM -include $(SRC_PATH)/qom/Makefile -qom-obj-y = $(addprefix qom/, $(qom-y)) -qom-obj-twice-y = $(addprefix qom/, $(qom-twice-y)) +qom-obj-y = qom/ universal-obj-y += $(qom-obj-y) @@ -94,7 +92,7 @@ fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) common-obj-y = $(block-obj-y) blockdev.o common-obj-y += $(net-obj-y) -common-obj-y += $(qom-obj-twice-y) +common-obj-y += qom/ common-obj-$(CONFIG_LINUX) += $(fsdev-obj-$(CONFIG_LINUX)) common-obj-y += readline.o console.o cursor.o common-obj-y += $(oslib-obj-y) @@ -202,7 +200,7 @@ user-obj-y += cutils.o cache-utils.o user-obj-y += module.o user-obj-y += qemu-user.o user-obj-y += $(trace-obj-y) -user-obj-y += $(qom-obj-twice-y) +user-obj-y += qom/ ## # libhw @@ -468,5 +466,8 @@ vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS) QEMU_CFLAGS+=$(GLIB_CFLAGS) -nested-vars += # ... +nested-vars += \ + qom-obj-y \ + user-obj-y \ + common-obj-y dummy := $(call unnest-vars) diff --git a/qom/Makefile b/qom/Makefile deleted file mode 100644 index 34c6de5..000 --- a/qom/Makefile +++ /dev/null @@ -1,2 +0,0 @@ -qom-y = object.o container.o qom-qobject.o -qom-twice-y = cpu.o diff --git a/qom/Makefile.objs b/qom/Makefile.objs new file mode 100644 index 000..5ef060a --- /dev/null +++ b/qom/Makefile.objs @@ -0,0 +1,4 @@ +qom-obj-y = object.o container.o qom-qobject.o +qom-obj-twice-y = cpu.o +common-obj-y = $(qom-obj-twice-y) +user-obj-y = $(qom-obj-twice-y) -- 1.7.10.1
[Qemu-devel] [PATCH v2 04/25] build: move *-user/ objects to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.target| 32 ++-- bsd-user/Makefile.objs |2 ++ configure |8 +++- linux-user/Makefile.objs |7 +++ linux-user/arm/nwfpe/Makefile.objs |2 ++ 5 files changed, 28 insertions(+), 23 deletions(-) create mode 100644 bsd-user/Makefile.objs create mode 100644 linux-user/Makefile.objs create mode 100644 linux-user/arm/nwfpe/Makefile.objs diff --git a/Makefile.target b/Makefile.target index 95a82be..6ffb556 100644 --- a/Makefile.target +++ b/Makefile.target @@ -113,32 +113,20 @@ user-exec.o: QEMU_CFLAGS += $(HELPER_CFLAGS) # Note: this is a workaround. The real fix is to avoid compiling # cpu_signal_handler() in user-exec.c. -signal.o: QEMU_CFLAGS += $(HELPER_CFLAGS) +%/signal.o: QEMU_CFLAGS += $(HELPER_CFLAGS) # # Linux user emulator target ifdef CONFIG_LINUX_USER -$(call set-vpath, $(SRC_PATH)/linux-user:$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)) - QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR) -I$(SRC_PATH)/linux-user -obj-y = main.o syscall.o strace.o mmap.o signal.o thunk.o \ - elfload.o linuxload.o uaccess.o gdbstub.o cpu-uname.o \ - user-exec.o $(oslib-obj-y) - -obj-$(TARGET_HAS_BFLT) += flatload.o - -obj-$(TARGET_I386) += vm86.o +obj-y += linux-user/ +obj-y += gdbstub.o thunk.o user-exec.o $(oslib-obj-y) obj-i386-y += ioport-user.o - -nwfpe-obj-y = fpa11.o fpa11_cpdo.o fpa11_cpdt.o fpa11_cprt.o fpopcode.o -nwfpe-obj-y += single_cpdo.o double_cpdo.o extended_cpdo.o -obj-arm-y += $(addprefix nwfpe/, $(nwfpe-obj-y)) -obj-arm-y += arm-semi.o - -obj-m68k-y += m68k-sim.o m68k-semi.o +obj-$(TARGET_ARM) += arm-semi.o +obj-$(TARGET_M68K) += m68k-semi.o obj-y += $(addprefix ../, $(universal-obj-y)) obj-y += $(addprefix ../libuser/, $(user-obj-y)) @@ -152,13 +140,10 @@ endif #CONFIG_LINUX_USER ifdef CONFIG_BSD_USER -$(call set-vpath, $(SRC_PATH)/bsd-user) - QEMU_CFLAGS+=-I$(SRC_PATH)/bsd-user -I$(SRC_PATH)/bsd-user/$(TARGET_ARCH) -obj-y = main.o bsdload.o elfload.o mmap.o signal.o strace.o syscall.o \ -gdbstub.o uaccess.o user-exec.o - +obj-y += bsd-user/ +obj-y += gdbstub.o user-exec.o obj-i386-y += ioport-user.o obj-y += $(addprefix ../, $(universal-obj-y)) @@ -403,6 +388,9 @@ endif # CONFIG_LINUX_USER obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o +nested-vars = obj-y +dummy := $(call unnest-vars) + ifdef QEMU_PROGW # The linker builds a windows executable. Make also a console executable. $(QEMU_PROGW): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) diff --git a/bsd-user/Makefile.objs b/bsd-user/Makefile.objs new file mode 100644 index 000..5e77f57 --- /dev/null +++ b/bsd-user/Makefile.objs @@ -0,0 +1,2 @@ +obj-y = main.o bsdload.o elfload.o mmap.o signal.o strace.o syscall.o \ + uaccess.o diff --git a/configure b/configure index 1f338f8..d5647f3 100755 --- a/configure +++ b/configure @@ -3520,8 +3520,14 @@ mkdir -p $target_dir/ide mkdir -p $target_dir/usb mkdir -p $target_dir/9pfs mkdir -p $target_dir/kvm +if test $target_linux_user = yes; then + mkdir -p $target_dir/linux-user +fi +if test $target_bsd_user = yes; then + mkdir -p $target_dir/bsd-user +fi if test $target = arm-linux-user -o $target = armeb-linux-user -o $target = arm-bsd-user -o $target = armeb-bsd-user ; then - mkdir -p $target_dir/nwfpe + mkdir -p $target_dir/linux-user/arm/nwfpe fi symlink $source_path/Makefile.target $target_dir/Makefile diff --git a/linux-user/Makefile.objs b/linux-user/Makefile.objs new file mode 100644 index 000..5899d72 --- /dev/null +++ b/linux-user/Makefile.objs @@ -0,0 +1,7 @@ +obj-y = main.o syscall.o strace.o mmap.o signal.o \ + elfload.o linuxload.o uaccess.o cpu-uname.o + +obj-$(TARGET_HAS_BFLT) += flatload.o +obj-$(TARGET_I386) += vm86.o +obj-$(TARGET_ARM) += arm/nwfpe/ +obj-$(TARGET_M68K) += m68k-sim.o diff --git a/linux-user/arm/nwfpe/Makefile.objs b/linux-user/arm/nwfpe/Makefile.objs new file mode 100644 index 000..51b0c32 --- /dev/null +++ b/linux-user/arm/nwfpe/Makefile.objs @@ -0,0 +1,2 @@ +obj-y = fpa11.o fpa11_cpdo.o fpa11_cpdt.o fpa11_cprt.o fpopcode.o +obj-y += single_cpdo.o double_cpdo.o extended_cpdo.o -- 1.7.10.1
[Qemu-devel] [PATCH v2 00/25] per-directory Makefile.objs snippets, limit vpath (ab)use
Here is v2 of the nested Makefile patches. Thanks all for the enthusiasm! The main change is that rules can now be put in the per-directory snippets. This is done for op_helper.o already. Paolo v1-v2: do not call nested files Makefile (Andreas) do not create directories at configure time (Anthony) allow per-snippet rules, use it for op_helper.o (Blue Swirl) whitespace fixes (Blue Swirl) fix Xen (myself) Paolo Bonzini (25): build: remove trace-nested-y build: do not sprinkle around GENERATED_HEADERS dependencies build: add rules for nesting build: move *-user/ objects to nested Makefile.objs build: move obj-TARGET-y variables to nested Makefile.objs build: move libobj-y variable to nested Makefile.objs build: move other target-*/ objects to nested Makefile.objs build: move rules for nesting to Makefile.objs build: put qom/ rules in a Makefile.objs file build: move block/ objects to nested Makefile.objs build: move net/ objects to nested Makefile.objs build: move fsdev/ objects to nested Makefile.objs build: move ui/ objects to nested Makefile.objs build: move audio/ objects to nested Makefile.objs build: move slirp/ objects to nested Makefile.objs build: move qapi/ objects to nested Makefile.objs build: move qga/ objects to nested Makefile.objs build: move target-independent hw/ objects to nested Makefile.objs build: convert libhw to nested Makefile.objs build: move per-target hw/ objects to nested Makefile.objs build: move device tree to per-target Makefile build: libcacard Makefile cleanups build: limit usage of vpath build: compile oslib-obj-y once build: do not create directories at configure time Makefile | 32 ++- Makefile.hw |7 +- Makefile.objs| 317 Makefile.target | 333 -- audio/Makefile.objs | 14 ++ block/Makefile.objs | 11 + bsd-user/Makefile.objs |2 + configure| 55 ++--- fsdev/Makefile.objs |9 + hw/9pfs/Makefile.objs|9 + hw/Makefile.objs | 165 + hw/alpha/Makefile.objs |4 + hw/arm/Makefile.objs | 40 hw/cris/Makefile.objs| 13 + hw/i386/Makefile.objs| 13 + hw/ide/Makefile.objs | 10 + hw/lm32/Makefile.objs| 23 ++ hw/m68k/Makefile.objs|4 + hw/microblaze/Makefile.objs | 14 ++ hw/mips/Makefile.objs|6 + hw/ppc/Makefile.objs | 32 +++ hw/s390x/Makefile.objs |3 + hw/sh4/Makefile.objs |5 + hw/sparc/Makefile.objs |8 + hw/sparc64/Makefile.objs |4 + hw/usb/Makefile.objs | 13 + hw/xtensa/Makefile.objs |5 + libcacard/Makefile | 17 +- linux-user/Makefile.objs |7 + linux-user/arm/nwfpe/Makefile.objs |2 + net/Makefile.objs| 12 + qapi/Makefile.objs |3 + qga/Makefile.objs|3 + qom/Makefile |2 - qom/Makefile.objs|4 + rules.mak| 40 slirp/Makefile.objs |3 + target-alpha/Makefile.objs |3 + target-arm/Makefile.objs |6 + arm-semi.c = target-arm/arm-semi.c |0 target-cris/Makefile.objs|4 + target-i386/Makefile.objs|7 + ioport-user.c = target-i386/ioport-user.c |0 target-lm32/Makefile.objs|4 + target-m68k/Makefile.objs|5 + m68k-semi.c = target-m68k/m68k-semi.c |0 target-microblaze/Makefile.objs |4 + target-mips/Makefile.objs|4 + target-ppc/Makefile.objs |6 + target-s390x/Makefile.objs |5 + target-sh4/Makefile.objs |4 + target-sparc/Makefile.objs |8 + target-unicore32/Makefile.objs |4 + target-xtensa/Makefile.objs |8 + xtensa-semi.c = target-xtensa/xtensa-semi.c |0 tests/Makefile |1 - ui/Makefile.objs | 18 ++ 57 files changed, 701 insertions(+), 634 deletions(-) create mode
[Qemu-devel] [PATCH v2 19/25] build: convert libhw to nested Makefile.objs
After this patch, the libhw* directories will have a hierarchy that mimics the source tree. This is useful because we do have a couple of files there that are in the top source directory. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.hw |6 +-- Makefile.objs | 143 + configure |7 +-- hw/9pfs/Makefile.objs |7 +++ hw/Makefile.objs | 115 +++ hw/ide/Makefile.objs | 10 hw/usb/Makefile.objs |9 7 files changed, 150 insertions(+), 147 deletions(-) create mode 100644 hw/9pfs/Makefile.objs create mode 100644 hw/ide/Makefile.objs diff --git a/Makefile.hw b/Makefile.hw index 33f1ab0..155a0c3 100644 --- a/Makefile.hw +++ b/Makefile.hw @@ -7,7 +7,7 @@ include $(SRC_PATH)/rules.mak .PHONY: all -$(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw) +$(call set-vpath, $(SRC_PATH)) QEMU_CFLAGS+=-I.. QEMU_CFLAGS += -I$(SRC_PATH)/include @@ -19,7 +19,7 @@ all: $(hw-obj-y) @true clean: - rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~ + rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~ */*/*.d # Include automatically generated dependency files --include $(wildcard *.d */*.d) +-include $(wildcard *.d */*.d */*/*.d) diff --git a/Makefile.objs b/Makefile.objs index 4aa5f0f..ae3770a 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -109,147 +109,7 @@ user-obj-y += qom/ ## # libhw -hw-obj-y = -hw-obj-y += vl.o loader.o -hw-obj-$(CONFIG_VIRTIO) += virtio-console.o -hw-obj-y += usb/libhw.o -hw-obj-$(CONFIG_VIRTIO_PCI) += virtio-pci.o -hw-obj-y += fw_cfg.o -hw-obj-$(CONFIG_PCI) += pci.o pci_bridge.o pci_bridge_dev.o -hw-obj-$(CONFIG_PCI) += msix.o msi.o -hw-obj-$(CONFIG_PCI) += shpc.o -hw-obj-$(CONFIG_PCI) += slotid_cap.o -hw-obj-$(CONFIG_PCI) += pci_host.o pcie_host.o -hw-obj-$(CONFIG_PCI) += ioh3420.o xio3130_upstream.o xio3130_downstream.o -hw-obj-y += watchdog.o -hw-obj-$(CONFIG_ISA_MMIO) += isa_mmio.o -hw-obj-$(CONFIG_ECC) += ecc.o -hw-obj-$(CONFIG_NAND) += nand.o -hw-obj-$(CONFIG_PFLASH_CFI01) += pflash_cfi01.o -hw-obj-$(CONFIG_PFLASH_CFI02) += pflash_cfi02.o - -hw-obj-$(CONFIG_M48T59) += m48t59.o -hw-obj-$(CONFIG_ESCC) += escc.o -hw-obj-$(CONFIG_EMPTY_SLOT) += empty_slot.o - -hw-obj-$(CONFIG_SERIAL) += serial.o -hw-obj-$(CONFIG_PARALLEL) += parallel.o -hw-obj-$(CONFIG_I8254) += i8254_common.o i8254.o -hw-obj-$(CONFIG_PCSPK) += pcspk.o -hw-obj-$(CONFIG_PCKBD) += pckbd.o -hw-obj-$(CONFIG_USB_UHCI) += usb/hcd-uhci.o -hw-obj-$(CONFIG_USB_OHCI) += usb/hcd-ohci.o -hw-obj-$(CONFIG_USB_EHCI) += usb/hcd-ehci.o -hw-obj-$(CONFIG_USB_XHCI) += usb/hcd-xhci.o -hw-obj-$(CONFIG_FDC) += fdc.o -hw-obj-$(CONFIG_ACPI) += acpi.o acpi_piix4.o -hw-obj-$(CONFIG_APM) += pm_smbus.o apm.o -hw-obj-$(CONFIG_DMA) += dma.o -hw-obj-$(CONFIG_I82374) += i82374.o -hw-obj-$(CONFIG_HPET) += hpet.o -hw-obj-$(CONFIG_APPLESMC) += applesmc.o -hw-obj-$(CONFIG_SMARTCARD) += usb/dev-smartcard-reader.o ccid-card-passthru.o -hw-obj-$(CONFIG_SMARTCARD_NSS) += ccid-card-emulated.o -hw-obj-$(CONFIG_USB_REDIR) += usb/redirect.o -hw-obj-$(CONFIG_I8259) += i8259_common.o i8259.o - -# PPC devices -hw-obj-$(CONFIG_PREP_PCI) += prep_pci.o -hw-obj-$(CONFIG_I82378) += i82378.o -# Mac shared devices -hw-obj-$(CONFIG_MACIO) += macio.o -hw-obj-$(CONFIG_CUDA) += cuda.o -hw-obj-$(CONFIG_ADB) += adb.o -hw-obj-$(CONFIG_MAC_NVRAM) += mac_nvram.o -hw-obj-$(CONFIG_MAC_DBDMA) += mac_dbdma.o -# OldWorld PowerMac -hw-obj-$(CONFIG_HEATHROW_PIC) += heathrow_pic.o -hw-obj-$(CONFIG_GRACKLE_PCI) += grackle_pci.o -# NewWorld PowerMac -hw-obj-$(CONFIG_UNIN_PCI) += unin_pci.o -hw-obj-$(CONFIG_DEC_PCI) += dec_pci.o -# PowerPC E500 boards -hw-obj-$(CONFIG_PPCE500_PCI) += ppce500_pci.o - -# MIPS devices -hw-obj-$(CONFIG_PIIX4) += piix4.o -hw-obj-$(CONFIG_G364FB) += g364fb.o -hw-obj-$(CONFIG_JAZZ_LED) += jazz_led.o - -# PCI watchdog devices -hw-obj-$(CONFIG_PCI) += wdt_i6300esb.o - -hw-obj-$(CONFIG_PCI) += pcie.o pcie_aer.o pcie_port.o - -# PCI network cards -hw-obj-$(CONFIG_NE2000_PCI) += ne2000.o -hw-obj-$(CONFIG_EEPRO100_PCI) += eepro100.o -hw-obj-$(CONFIG_PCNET_PCI) += pcnet-pci.o -hw-obj-$(CONFIG_PCNET_COMMON) += pcnet.o -hw-obj-$(CONFIG_E1000_PCI) += e1000.o -hw-obj-$(CONFIG_RTL8139_PCI) += rtl8139.o - -hw-obj-$(CONFIG_SMC91C111) += smc91c111.o -hw-obj-$(CONFIG_LAN9118) += lan9118.o -hw-obj-$(CONFIG_NE2000_ISA) += ne2000-isa.o -hw-obj-$(CONFIG_OPENCORES_ETH) += opencores_eth.o - -# IDE -hw-obj-$(CONFIG_IDE_CORE) += ide/core.o ide/atapi.o -hw-obj-$(CONFIG_IDE_QDEV) += ide/qdev.o -hw-obj-$(CONFIG_IDE_PCI) += ide/pci.o -hw-obj-$(CONFIG_IDE_ISA) += ide/isa.o -hw-obj-$(CONFIG_IDE_PIIX) += ide/piix.o -hw-obj-$(CONFIG_IDE_CMD646) += ide/cmd646.o -hw-obj-$(CONFIG_IDE_MACIO) += ide/macio.o -hw-obj-$(CONFIG_IDE_VIA) += ide/via.o -hw-obj-$(CONFIG_AHCI) += ide/ahci.o -hw-obj-$(CONFIG_AHCI) += ide/ich.o - -# SCSI layer -hw-obj-$(CONFIG_LSI_SCSI_PCI) +=
[Qemu-devel] [PATCH v2 08/25] build: move rules for nesting to Makefile.objs
At this point we will start adding nesting behavior to other files than Makefile.target. Because Makefile.objs is included by Makefile.target, it is simpler to move the processing of subdirectories there. To enable this, only add per-target files to obj-y. Use a separate variable for the linker dependencies, all-obj-y. This variable includes obj-y and also all objects that are taken from other directories. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs |2 ++ Makefile.target | 47 ++- 2 files changed, 24 insertions(+), 25 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index 1daa92c..e06db12 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -468,3 +468,5 @@ vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS) QEMU_CFLAGS+=$(GLIB_CFLAGS) +nested-vars += # ... +dummy := $(call unnest-vars) diff --git a/Makefile.target b/Makefile.target index 4714a30..006f1cd 100644 --- a/Makefile.target +++ b/Makefile.target @@ -19,8 +19,6 @@ QEMU_CFLAGS += -I../linux-headers endif QEMU_CFLAGS += -I.. -I$(TARGET_PATH) -DNEED_CPU_H -include $(SRC_PATH)/Makefile.objs - QEMU_CFLAGS+=-I$(SRC_PATH)/include ifdef CONFIG_USER_ONLY @@ -105,10 +103,6 @@ QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR) -I$(SRC_PATH)/linux-user obj-y += linux-user/ obj-y += gdbstub.o thunk.o user-exec.o $(oslib-obj-y) -obj-y += $(addprefix ../, $(universal-obj-y)) -obj-y += $(addprefix ../libuser/, $(user-obj-y)) -obj-y += $(addprefix ../libdis-user/, $(libdis-y)) - endif #CONFIG_LINUX_USER # @@ -121,10 +115,6 @@ QEMU_CFLAGS+=-I$(SRC_PATH)/bsd-user -I$(SRC_PATH)/bsd-user/$(TARGET_ARCH) obj-y += bsd-user/ obj-y += gdbstub.o user-exec.o -obj-y += $(addprefix ../, $(universal-obj-y)) -obj-y += $(addprefix ../libuser/, $(user-obj-y)) -obj-y += $(addprefix ../libdis-user/, $(libdis-y)) - endif #CONFIG_BSD_USER # @@ -185,33 +175,40 @@ main.o: QEMU_CFLAGS+=$(GPROF_CFLAGS) GENERATED_HEADERS += hmp-commands.h qmp-commands-old.h -obj-y += $(addprefix ../, $(universal-obj-y)) -obj-y += $(addprefix ../, $(common-obj-y)) -obj-y += $(addprefix ../libdis/, $(libdis-y)) -obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) -obj-y += $(addprefix ../, $(trace-obj-y)) - endif # CONFIG_SOFTMMU -ifndef CONFIG_LINUX_USER -ifndef CONFIG_BSD_USER +nested-vars += obj-y + +# This resolves all nested paths, so it must come last +include $(SRC_PATH)/Makefile.objs + +all-obj-y = $(obj-y) +all-obj-y += $(addprefix ../, $(universal-obj-y)) + +ifdef CONFIG_SOFTMMU + +all-obj-y += $(addprefix ../, $(common-obj-y)) +all-obj-y += $(addprefix ../libdis/, $(libdis-y)) +all-obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) +all-obj-y += $(addprefix ../, $(trace-obj-y)) + # libcacard needs qemu-thread support, and besides is only needed by devices # so not requires with linux-user / bsd-user targets -obj-$(CONFIG_SMARTCARD_NSS) += $(addprefix ../libcacard/, $(libcacard-y)) -endif # CONFIG_BSD_USER -endif # CONFIG_LINUX_USER +all-obj-$(CONFIG_SMARTCARD_NSS) += $(addprefix ../libcacard/, $(libcacard-y)) -nested-vars = obj-y -dummy := $(call unnest-vars) +else +all-obj-y += $(addprefix ../libuser/, $(user-obj-y)) +all-obj-y += $(addprefix ../libdis-user/, $(libdis-y)) +endif #CONFIG_LINUX_USER ifdef QEMU_PROGW # The linker builds a windows executable. Make also a console executable. -$(QEMU_PROGW): $(obj-y) +$(QEMU_PROGW): $(all-obj-y) $(call LINK,$^) $(QEMU_PROG): $(QEMU_PROGW) $(call quiet-command,$(OBJCOPY) --subsystem console $(QEMU_PROGW) $(QEMU_PROG), GEN $(TARGET_DIR)$(QEMU_PROG)) else -$(QEMU_PROG): $(obj-y) +$(QEMU_PROG): $(all-obj-y) $(call LINK,$^) endif -- 1.7.10.1
[Qemu-devel] [PATCH v2 03/25] build: add rules for nesting
This adds the 'magic' rules that take care of subdirectories. The subdirectory makefiles in the source tree are not complete; they only define some variables (listed in nested-vars) according to the configuration. The magic rules descend into subdirectory makefiles and gather the evaluated values of those variables. The values from all subdirectories are joined together, each prefixed with the subdirectory name, and used by the real makefiles. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- rules.mak | 39 +++ 1 file changed, 39 insertions(+) diff --git a/rules.mak b/rules.mak index efef6f2..f65283c 100644 --- a/rules.mak +++ b/rules.mak @@ -73,3 +73,42 @@ TRACETOOL=$(PYTHON) $(SRC_PATH)/scripts/tracetool.py # will delete the target of a rule if commands exit with a nonzero exit status .DELETE_ON_ERROR: + +# magic to descend into other directories + +obj := . +old-nested-dirs := + +define push-var +$(eval save-$2-$1 = $(value $1)) +$(eval $1 :=) +endef + +define pop-var +$(eval subdir-$2-$1 := $(if $(filter $2,$(save-$2-$1)),$(addprefix $2,$($1 +$(eval $1 = $(value save-$2-$1) $$(subdir-$2-$1)) +$(eval save-$2-$1 :=) +endef + +define unnest-dir +$(foreach var,$(nested-vars),$(call push-var,$(var),$1/)) +$(eval obj := $(obj)/$1) +$(eval include $(SRC_PATH)/$1/Makefile.objs) +$(eval obj := $(patsubst %/$1,%,$(obj))) +$(foreach var,$(nested-vars),$(call pop-var,$(var),$1/)) +endef + +define unnest-vars-1 +$(eval nested-dirs := $(filter-out \ +$(old-nested-dirs), \ +$(sort $(foreach var,$(nested-vars), $(filter %/, $($(var))) +$(if $(nested-dirs), + $(foreach dir,$(nested-dirs),$(call unnest-dir,$(patsubst %/,%,$(dir + $(eval old-nested-dirs := $(old-nested-dirs) $(nested-dirs)) + $(call unnest-vars-1)) +endef + +define unnest-vars +$(call unnest-vars-1) +$(foreach var,$(nested-vars),$(eval $(var) := $(filter-out %/, $($(var) +endef -- 1.7.10.1
[Qemu-devel] [PATCH 1/2] kvm: add missing include files
These are included via monitor.h right now, add them explicitly. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- kvm-all.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/kvm-all.c b/kvm-all.c index 489ee53..831651d 100644 --- a/kvm-all.c +++ b/kvm-all.c @@ -22,6 +22,8 @@ #include qemu-common.h #include qemu-barrier.h +#include qemu-option.h +#include qemu-config.h #include sysemu.h #include hw/hw.h #include hw/msi.h -- 1.7.10.1
[Qemu-devel] [PATCH 0/6] blkdebug changes extracted from 1.2 streaming patches
Hi, these patches are prerequisites for testing streaming error handling. They should be useful on their own, so I am sending them early to keep the queue small. Paolo Bonzini (6): blkdebug: remove sync i/o events blkdebug: tiny cleanup blkdebug: pass getlength to underlying file blkdebug: store list of active rules blkdebug: optionally tie errors to a specific sector raw: hook into blkdebug block.h |2 - block/blkdebug.c | 107 +++--- block/qed.c |2 +- block/raw.c |2 + 4 files changed, 64 insertions(+), 49 deletions(-) -- 1.7.10.1
[Qemu-devel] [PATCH v2 13/25] build: move ui/ objects to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs| 21 ++--- ui/Makefile.objs | 18 ++ 2 files changed, 20 insertions(+), 19 deletions(-) create mode 100644 ui/Makefile.objs diff --git a/Makefile.objs b/Makefile.objs index 4acdbaa..a6310e3 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -110,7 +110,6 @@ common-obj-$(CONFIG_BRLAPI) += baum.o common-obj-$(CONFIG_POSIX) += migration-exec.o migration-unix.o migration-fd.o common-obj-$(CONFIG_WIN32) += version.o -common-obj-$(CONFIG_SPICE) += ui/spice-core.o ui/spice-input.o ui/spice-display.o spice-qemu-char.o audio-obj-y = audio.o noaudio.o wavaudio.o mixeng.o audio-obj-$(CONFIG_SDL) += sdlaudio.o @@ -127,24 +126,8 @@ audio-obj-$(CONFIG_AUDIO_PT_INT) += audio_pt_int.o audio-obj-$(CONFIG_AUDIO_WIN_INT) += audio_win_int.o audio-obj-y += wavcapture.o common-obj-y += $(addprefix audio/, $(audio-obj-y)) - -ui-obj-y += keymaps.o -ui-obj-$(CONFIG_SDL) += sdl.o sdl_zoom.o x_keymap.o -ui-obj-$(CONFIG_COCOA) += cocoa.o -ui-obj-$(CONFIG_CURSES) += curses.o -vnc-obj-y += vnc.o d3des.o -vnc-obj-y += vnc-enc-zlib.o vnc-enc-hextile.o -vnc-obj-y += vnc-enc-tight.o vnc-palette.o -vnc-obj-y += vnc-enc-zrle.o -vnc-obj-$(CONFIG_VNC_TLS) += vnc-tls.o vnc-auth-vencrypt.o -vnc-obj-$(CONFIG_VNC_SASL) += vnc-auth-sasl.o -ifdef CONFIG_VNC_THREAD -vnc-obj-y += vnc-jobs-async.o -else -vnc-obj-y += vnc-jobs-sync.o -endif -common-obj-y += $(addprefix ui/, $(ui-obj-y)) -common-obj-$(CONFIG_VNC) += $(addprefix ui/, $(vnc-obj-y)) +common-obj-$(CONFIG_SPICE) += spice-qemu-char.o +common-obj-y += ui/ common-obj-y += iov.o acl.o common-obj-$(CONFIG_POSIX) += compatfd.o diff --git a/ui/Makefile.objs b/ui/Makefile.objs new file mode 100644 index 000..3687c8a --- /dev/null +++ b/ui/Makefile.objs @@ -0,0 +1,18 @@ +vnc-obj-y += vnc.o d3des.o +vnc-obj-y += vnc-enc-zlib.o vnc-enc-hextile.o +vnc-obj-y += vnc-enc-tight.o vnc-palette.o +vnc-obj-y += vnc-enc-zrle.o +vnc-obj-$(CONFIG_VNC_TLS) += vnc-tls.o vnc-auth-vencrypt.o +vnc-obj-$(CONFIG_VNC_SASL) += vnc-auth-sasl.o +ifdef CONFIG_VNC_THREAD +vnc-obj-y += vnc-jobs-async.o +else +vnc-obj-y += vnc-jobs-sync.o +endif + +common-obj-y += keymaps.o +common-obj-$(CONFIG_SPICE) += spice-core.o spice-input.o spice-display.o +common-obj-$(CONFIG_SDL) += sdl.o sdl_zoom.o x_keymap.o +common-obj-$(CONFIG_COCOA) += cocoa.o +common-obj-$(CONFIG_CURSES) += curses.o +common-obj-$(CONFIG_VNC) += $(vnc-obj-y) -- 1.7.10.1
Re: [Qemu-devel] [PATCH v2 6/6] qapi: convert sendkey
On 05/06/12 23:05, Eric Blake wrote: On 06/05/2012 08:55 AM, Amos Kong wrote: +# @sendkey: +# +# Send keys to VM. +# +# @keys: key sequence +# @hold-time: time to delay key up events, milliseconds +# +# Returns: Nothing on success +# If key is unknown or redundant, QERR_INVALID_PARAMETER +# If keys number is over the limitation, QERR_OVERFLOW +# +# Notes: Send keys to the emulator. Keys could be the name of the +#key or the raw value in either decimal or hexadecimal format. Use +#- to press several keys simultaneously. These notes don't really correspond to the QMP interface of passing in a JSON array of simultaneous keys to press. # Notes: Send keys to the emulator. Keys could be the name of the #key or the raw value in either decimal or hexadecimal format. Use #a JSON array to press several keys simultaneously. Ho, I found another bug in my code, key in decimal or hexadecimal format is not supported. I will fix it. How do you plan to support decimal in QMP? In old do_sendkey(), only key-name and hexadecimal were supported, the description needs to be fixed. I don't think it's possible, at least not without still keeping a JSON array of keys to press. On the other hand, I'm not sure if we need to worry about that. Let me explain: Let's suppose the QMP interface is symbolic only. In the HMP interface, _you_ can use the lookup list to convert decimal to key name, so that the HMP interface is a wrapper around the QMP interface, but everything is symbolic by the time we get that far. In the libvirt case, where libvirt talks directly to QMP, It seems we can only support key-name for QMP, and support key-name/hexadecimal for HMP. Is it acceptable? libvirt also has the same table for looking up keysyms vs. values (in fact, libvirt already uses that table to convert between different keysets, so for an example, the libvirt user can specify a command using xt_kbd or usb or ... mappings, which libvirt then converts into the mapping desired by qemu). Since libvirt already consults a table, libvirt can ensure that the table has the proper QMP symbolic names in that table. Finally, I know there was a patch proposed by Dan Berrange a while back to let both libvirt and qemu share a common database of keyset names and corresponding integer mappings. I don't remember if it was applied to qemu; if not, it should be revived and used at this time. -- Amos.
[Qemu-devel] [PATCH v2 24/25] build: compile oslib-obj-y once
There is no difference in oslib-obj-y between user-mode and system targets. There used to be when user-mode could optionally be compiled with PIE. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs |3 ++- Makefile.target |2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index 74110dd..8e72f09 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -22,6 +22,8 @@ oslib-obj-y = osdep.o oslib-obj-$(CONFIG_WIN32) += oslib-win32.o qemu-thread-win32.o oslib-obj-$(CONFIG_POSIX) += oslib-posix.o qemu-thread-posix.o +universal-obj-y += $(oslib-obj-y) + ### # coroutines coroutine-obj-y = qemu-coroutine.o qemu-coroutine-lock.o qemu-coroutine-io.o @@ -62,7 +64,6 @@ common-obj-y = $(block-obj-y) blockdev.o common-obj-y += net.o net/ common-obj-y += qom/ common-obj-y += readline.o console.o cursor.o -common-obj-y += $(oslib-obj-y) common-obj-$(CONFIG_WIN32) += os-win32.o common-obj-$(CONFIG_POSIX) += os-posix.o diff --git a/Makefile.target b/Makefile.target index cfbd265..1b4ac98 100644 --- a/Makefile.target +++ b/Makefile.target @@ -96,7 +96,7 @@ ifdef CONFIG_LINUX_USER QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR) -I$(SRC_PATH)/linux-user obj-y += linux-user/ -obj-y += gdbstub.o thunk.o user-exec.o $(oslib-obj-y) +obj-y += gdbstub.o thunk.o user-exec.o endif #CONFIG_LINUX_USER -- 1.7.10.1
[Qemu-devel] [PATCH v2 22/25] build: libcacard Makefile cleanups
Build vscclient from toplevel Makefile, limit usage of vpath. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile |4 Makefile.objs |8 +++- Makefile.target|6 -- configure | 12 +--- libcacard/Makefile | 17 ++--- 5 files changed, 22 insertions(+), 25 deletions(-) diff --git a/Makefile b/Makefile index a10005a..1d34b95 100644 --- a/Makefile +++ b/Makefile @@ -147,6 +147,10 @@ libcacard.la: $(oslib-obj-y) qemu-timer-common.o $(addsuffix .lo, $(basename $(t install-libcacard: libcacard.la $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C libcacard V=$(V) TARGET_DIR=$*/ install-libcacard,) endif + +vscclient$(EXESUF): $(libcacard-y) $(oslib-obj-y) qemu-timer-common.o libcacard/vscclient.o + $(call quiet-command,$(CC) -o $@ $^ $(libcacard_libs) $(LIBS), LINK $@) + ## qemu-img.o: qemu-img-cmds.h diff --git a/Makefile.objs b/Makefile.objs index ae3770a..74110dd 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -198,7 +198,13 @@ $(trace-obj-y): $(GENERATED_HEADERS) ## # smartcard -libcacard-y = cac.o event.o vcard.o vreader.o vcard_emul_nss.o vcard_emul_type.o card_7816.o +libcacard-y += libcacard/cac.o libcacard/event.o +libcacard-y += libcacard/vcard.o libcacard/vreader.o +libcacard-y += libcacard/vcard_emul_nss.o +libcacard-y += libcacard/vcard_emul_type.o +libcacard-y += libcacard/card_7816.o + +common-obj-$(CONFIG_SMARTCARD_NSS) += $(libcacard-y) ## # qapi diff --git a/Makefile.target b/Makefile.target index f25e278..9728c46 100644 --- a/Makefile.target +++ b/Makefile.target @@ -158,16 +158,10 @@ all-obj-y = $(obj-y) all-obj-y += $(addprefix ../, $(universal-obj-y)) ifdef CONFIG_SOFTMMU - all-obj-y += $(addprefix ../, $(common-obj-y)) all-obj-y += $(addprefix ../libdis/, $(libdis-y)) all-obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) all-obj-y += $(addprefix ../, $(trace-obj-y)) - -# libcacard needs qemu-thread support, and besides is only needed by devices -# so not requires with linux-user / bsd-user targets -all-obj-$(CONFIG_SMARTCARD_NSS) += $(addprefix ../libcacard/, $(libcacard-y)) - else all-obj-y += $(addprefix ../libuser/, $(user-obj-y)) all-obj-y += $(addprefix ../libdis-user/, $(libdis-y)) diff --git a/configure b/configure index d90255a..301b574 100755 --- a/configure +++ b/configure @@ -2927,6 +2927,9 @@ if test $softmmu = yes ; then fi fi fi +if test $smartcard_nss = yes ; then + tools=vscclient\$(EXESUF) $tools +fi # Mac OS X ships with a broken assembler roms= @@ -3951,9 +3954,10 @@ DIRS=$DIRS roms/seabios roms/vgabios DIRS=$DIRS fsdev ui hw hw/usb DIRS=$DIRS qapi qapi-generated DIRS=$DIRS qga trace qom +DIRS=$DIRS libcacard libcacard/libcacard libcacard/trace 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 +FILES=$FILES tests/tcg/lm32/Makefile libcacard/Makefile FILES=$FILES pc-bios/optionrom/Makefile pc-bios/keymaps FILES=$FILES pc-bios/spapr-rtas/Makefile FILES=$FILES roms/seabios/Makefile roms/vgabios/Makefile @@ -3997,12 +4001,6 @@ for hwlib in 32 64; do echo QEMU_CFLAGS+=-DTARGET_PHYS_ADDR_BITS=$hwlib $d/config.mak done -if [ $source_path != `pwd` ]; then -# out of tree build -mkdir -p libcacard -symlink $source_path/libcacard/Makefile libcacard/Makefile -fi - d=libuser mkdir -p $d mkdir -p $d/trace diff --git a/libcacard/Makefile b/libcacard/Makefile index c6a896a..fdc2873 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -2,29 +2,23 @@ -include $(SRC_PATH)/Makefile.objs -include $(SRC_PATH)/rules.mak -libcacard_srcpath=$(SRC_PATH)/libcacard libcacard_includedir=$(includedir)/cacard -$(call set-vpath, $(SRC_PATH):$(libcacard_srcpath)) - -# objects linked against normal qemu binaries, not compiled with libtool -QEMU_OBJS=$(addprefix ../,$(oslib-obj-y) qemu-timer-common.o $(trace-obj-y)) +$(call set-vpath, $(SRC_PATH)) # objects linked into a shared library, built with libtool with -fPIC if required -QEMU_OBJS_LIB=$(addsuffix .lo,$(basename $(QEMU_OBJS))) +QEMU_OBJS=$(oslib-obj-y) qemu-timer-common.o $(trace-obj-y) +QEMU_OBJS_LIB=$(patsubst %.o,%.lo,$(QEMU_OBJS)) QEMU_CFLAGS+=-I../ -libcacard.lib-y=$(addsuffix .lo,$(basename $(libcacard-y))) - -vscclient: $(libcacard-y) $(QEMU_OBJS) vscclient.o - $(call quiet-command,$(CC) -o $@ $^ $(libcacard_libs) $(LIBS), LINK $@) +libcacard.lib-y=$(patsubst %.o,%.lo,$(libcacard-y)) clean: rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~ vscclient *.lo .libs/* *.la *.pc rm -Rf .libs -all: vscclient +all: libcacard.la libcacard.pc # Dummy command so that make thinks it has done something @true @@ -41,6 +35,7
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/05/2012 03:19 PM, Gerd Hoffmann wrote: Hi, snip Suggestion: add a _guest marker for ordinary state. Fail the build on unmarked fields. This ensures that some thought is given to each field, instead of having a default that may be correct most of the time, but not always. Suggestion: add a mandatory position hint (_guest(7) or _pos(7)) that generates ordering within the fields. This decouples the order of lines in the struct from the protocol, so you can add state where it make sense, or rearrange lines when they don't, and detect copy/paste errors. I wouldn't make the position mandatory. I expect the next generation migration wire protocol transmits the field names anyway, so the ordering will not matter any more, we need it for compatibility with today's format only. We can remove the position hints when the old protocol is no longer supported, but until then, it's IMO too easy to break compatibility by moving lines around. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH v2 23/25] build: limit usage of vpath
All paths are now explicitly given, and the object tree mimics the source tree, so there is no need to apply special vpaths. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile|2 +- Makefile.target |5 ++--- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 1d34b95..32550cb 100644 --- a/Makefile +++ b/Makefile @@ -33,7 +33,7 @@ configure: ; .PHONY: all clean cscope distclean dvi html info install install-doc \ pdf recurse-all speed tar tarbin test build-all -$(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw) +$(call set-vpath, $(SRC_PATH)) LIBS+=-lz $(LIBS_TOOLS) diff --git a/Makefile.target b/Makefile.target index 9728c46..cfbd265 100644 --- a/Makefile.target +++ b/Makefile.target @@ -8,12 +8,11 @@ ifneq ($(HWDIR),) include $(HWDIR)/config.mak endif -TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH) -$(call set-vpath, $(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw) +$(call set-vpath, $(SRC_PATH)) ifdef CONFIG_LINUX QEMU_CFLAGS += -I../linux-headers endif -QEMU_CFLAGS += -I.. -I$(TARGET_PATH) -DNEED_CPU_H +QEMU_CFLAGS += -I.. -I$(SRC_PATH)/target-$(TARGET_BASE_ARCH) -DNEED_CPU_H QEMU_CFLAGS+=-I$(SRC_PATH)/include -- 1.7.10.1
[Qemu-devel] [PATCH v2 07/25] build: move other target-*/ objects to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.target |6 +++--- target-alpha/Makefile.objs |3 ++- target-arm/Makefile.objs|3 ++- target-cris/Makefile.objs |4 ++-- target-i386/Makefile.objs |5 +++-- target-lm32/Makefile.objs |3 ++- target-m68k/Makefile.objs |3 ++- target-microblaze/Makefile.objs |4 ++-- target-mips/Makefile.objs |3 ++- target-ppc/Makefile.objs|3 +++ target-s390x/Makefile.objs |4 +++- target-sh4/Makefile.objs|3 ++- target-sparc/Makefile.objs |3 ++- target-unicore32/Makefile.objs |3 ++- target-xtensa/Makefile.objs |3 ++- 15 files changed, 34 insertions(+), 19 deletions(-) diff --git a/Makefile.target b/Makefile.target index 714659e..4714a30 100644 --- a/Makefile.target +++ b/Makefile.target @@ -76,7 +76,7 @@ all: $(PROGS) stap # # cpu emulator library -obj-y = exec.o translate-all.o cpu-exec.o translate.o +obj-y = exec.o translate-all.o cpu-exec.o obj-y += tcg/tcg.o tcg/optimize.o obj-$(CONFIG_TCG_INTERPRETER) += tci.o obj-y += fpu/softfloat.o @@ -131,7 +131,7 @@ endif #CONFIG_BSD_USER # System emulator target ifdef CONFIG_SOFTMMU -obj-y += arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o ioport.o +obj-y += arch_init.o cpus.o monitor.o gdbstub.o balloon.o ioport.o # virtio has to be here due to weird dependency between PCI and virtio-net. # need to fix this properly obj-$(CONFIG_NO_PCI) += pci-stub.o @@ -140,7 +140,7 @@ obj-$(CONFIG_VIRTIO) += virtio-scsi.o obj-y += vhost_net.o obj-$(CONFIG_VHOST_NET) += vhost.o obj-$(CONFIG_REALLY_VIRTFS) += 9pfs/virtio-9p-device.o -obj-$(CONFIG_KVM) += kvm.o kvm-all.o +obj-$(CONFIG_KVM) += kvm-all.o obj-$(CONFIG_NO_KVM) += kvm-stub.o obj-$(CONFIG_VGA) += vga.o obj-y += memory.o savevm.o cputlb.o diff --git a/target-alpha/Makefile.objs b/target-alpha/Makefile.objs index 9a72870..590304c 100644 --- a/target-alpha/Makefile.objs +++ b/target-alpha/Makefile.objs @@ -1,2 +1,3 @@ -obj-y += helper.o cpu.o +obj-$(CONFIG_SOFTMMU) += machine.o +obj-y += translate.o helper.o cpu.o obj-y += int_helper.o fpu_helper.o sys_helper.o mem_helper.o diff --git a/target-arm/Makefile.objs b/target-arm/Makefile.objs index 4dcd3c5..f447c4f 100644 --- a/target-arm/Makefile.objs +++ b/target-arm/Makefile.objs @@ -1,5 +1,6 @@ obj-y += arm-semi.o -obj-y += op_helper.o helper.o cpu.o +obj-$(CONFIG_SOFTMMU) += machine.o +obj-y += translate.o op_helper.o helper.o cpu.o obj-y += neon_helper.o iwmmxt_helper.o $(obj)/op_helper.o: QEMU_CFLAGS += $(HELPER_CFLAGS) diff --git a/target-cris/Makefile.objs b/target-cris/Makefile.objs index 9a50c28..4b09e8c 100644 --- a/target-cris/Makefile.objs +++ b/target-cris/Makefile.objs @@ -1,4 +1,4 @@ -obj-y += op_helper.o helper.o cpu.o -obj-$(CONFIG_SOFTMMU) += mmu.o +obj-y += translate.o op_helper.o helper.o cpu.o +obj-$(CONFIG_SOFTMMU) += mmu.o machine.o $(obj)/op_helper.o: QEMU_CFLAGS += $(HELPER_CFLAGS) diff --git a/target-i386/Makefile.objs b/target-i386/Makefile.objs index 2538c43..51214bb 100644 --- a/target-i386/Makefile.objs +++ b/target-i386/Makefile.objs @@ -1,5 +1,6 @@ -obj-y += op_helper.o helper.o cpu.o -obj-$(CONFIG_KVM) += hyperv.o +obj-y += translate.o op_helper.o helper.o cpu.o +obj-$(CONFIG_SOFTMMU) += machine.o +obj-$(CONFIG_KVM) += kvm.o hyperv.o obj-$(CONFIG_LINUX_USER) += ioport-user.o obj-$(CONFIG_BSD_USER) += ioport-user.o diff --git a/target-lm32/Makefile.objs b/target-lm32/Makefile.objs index 8e9be60..2e0e093 100644 --- a/target-lm32/Makefile.objs +++ b/target-lm32/Makefile.objs @@ -1,3 +1,4 @@ -obj-y += op_helper.o helper.o cpu.o +obj-y += translate.o op_helper.o helper.o cpu.o +obj-$(CONFIG_SOFTMMU) += machine.o $(obj)/op_helper.o: QEMU_CFLAGS += $(HELPER_CFLAGS) diff --git a/target-m68k/Makefile.objs b/target-m68k/Makefile.objs index 553691d..cda6015 100644 --- a/target-m68k/Makefile.objs +++ b/target-m68k/Makefile.objs @@ -1,4 +1,5 @@ obj-y += m68k-semi.o -obj-y += op_helper.o helper.o cpu.o +obj-y += translate.o op_helper.o helper.o cpu.o +obj-$(CONFIG_SOFTMMU) += machine.o $(obj)/op_helper.o: QEMU_CFLAGS += $(HELPER_CFLAGS) diff --git a/target-microblaze/Makefile.objs b/target-microblaze/Makefile.objs index 9a50c28..4b09e8c 100644 --- a/target-microblaze/Makefile.objs +++ b/target-microblaze/Makefile.objs @@ -1,4 +1,4 @@ -obj-y += op_helper.o helper.o cpu.o -obj-$(CONFIG_SOFTMMU) += mmu.o +obj-y += translate.o op_helper.o helper.o cpu.o +obj-$(CONFIG_SOFTMMU) += mmu.o machine.o $(obj)/op_helper.o: QEMU_CFLAGS += $(HELPER_CFLAGS) diff --git a/target-mips/Makefile.objs b/target-mips/Makefile.objs index 8e9be60..2e0e093 100644 --- a/target-mips/Makefile.objs +++ b/target-mips/Makefile.objs @@ -1,3 +1,4 @@ -obj-y += op_helper.o helper.o cpu.o +obj-y += translate.o op_helper.o helper.o cpu.o +obj-$(CONFIG_SOFTMMU) += machine.o
[Qemu-devel] [PATCH 4/6] blkdebug: store list of active rules
This prepares for the next patch, where some active rules may actually
not trigger depending on input to readv/writev. Store the active rules
in a SIMPLEQ (so that it can be emptied easily with QSIMPLEQ_INIT), and
fetch the errno/once/immediately arguments from there.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/blkdebug.c | 69 --
1 file changed, 31 insertions(+), 38 deletions(-)
diff --git a/block/blkdebug.c b/block/blkdebug.c
index b084a23..d12ebbf 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -26,24 +26,10 @@
#include block_int.h
#include module.h
-typedef struct BlkdebugVars {
-int state;
-
-/* If inject_errno != 0, an error is injected for requests */
-int inject_errno;
-
-/* Decides if all future requests fail (false) or only the next one and
- * after the next request inject_errno is reset to 0 (true) */
-bool inject_once;
-
-/* Decides if aio_readv/writev fails right away (true) or returns an error
- * return value only in the callback (false) */
-bool inject_immediately;
-} BlkdebugVars;
-
typedef struct BDRVBlkdebugState {
-BlkdebugVars vars;
-QLIST_HEAD(list, BlkdebugRule) rules[BLKDBG_EVENT_MAX];
+int state;
+QLIST_HEAD(, BlkdebugRule) rules[BLKDBG_EVENT_MAX];
+QSIMPLEQ_HEAD(, BlkdebugRule) active_rules;
} BDRVBlkdebugState;
typedef struct BlkdebugAIOCB {
@@ -79,6 +65,7 @@ typedef struct BlkdebugRule {
} set_state;
} options;
QLIST_ENTRY(BlkdebugRule) next;
+QSIMPLEQ_ENTRY(BlkdebugRule) active_next;
} BlkdebugRule;
static QemuOptsList inject_error_opts = {
@@ -300,7 +287,7 @@ static int blkdebug_open(BlockDriverState *bs, const char
*filename, int flags)
filename = c + 1;
/* Set initial state */
-s-vars.state = 1;
+s-state = 1;
/* Open the backing file */
ret = bdrv_file_open(bs-file, filename, flags);
@@ -326,18 +313,18 @@ static void blkdebug_aio_cancel(BlockDriverAIOCB
*blockacb)
}
static BlockDriverAIOCB *inject_error(BlockDriverState *bs,
-BlockDriverCompletionFunc *cb, void *opaque)
+BlockDriverCompletionFunc *cb, void *opaque, BlkdebugRule *rule)
{
BDRVBlkdebugState *s = bs-opaque;
-int error = s-vars.inject_errno;
+int error = rule-options.inject.error;
struct BlkdebugAIOCB *acb;
QEMUBH *bh;
-if (s-vars.inject_once) {
-s-vars.inject_errno = 0;
+if (rule-options.inject.once) {
+QSIMPLEQ_INIT(s-active_rules);
}
-if (s-vars.inject_immediately) {
+if (rule-options.inject.immediately) {
return NULL;
}
@@ -356,9 +343,10 @@ static BlockDriverAIOCB
*blkdebug_aio_readv(BlockDriverState *bs,
BlockDriverCompletionFunc *cb, void *opaque)
{
BDRVBlkdebugState *s = bs-opaque;
+BlkdebugRule *rule = QSIMPLEQ_FIRST(s-active_rules);
-if (s-vars.inject_errno) {
-return inject_error(bs, cb, opaque);
+if (rule rule-options.inject.error) {
+return inject_error(bs, cb, opaque, rule);
}
return bdrv_aio_readv(bs-file, sector_num, qiov, nb_sectors, cb, opaque);
@@ -369,9 +357,10 @@ static BlockDriverAIOCB
*blkdebug_aio_writev(BlockDriverState *bs,
BlockDriverCompletionFunc *cb, void *opaque)
{
BDRVBlkdebugState *s = bs-opaque;
+BlkdebugRule *rule = QSIMPLEQ_FIRST(s-active_rules);
-if (s-vars.inject_errno) {
-return inject_error(bs, cb, opaque);
+if (rule rule-options.inject.error) {
+return inject_error(bs, cb, opaque, rule);
}
return bdrv_aio_writev(bs-file, sector_num, qiov, nb_sectors, cb, opaque);
@@ -391,41 +380,45 @@ static void blkdebug_close(BlockDriverState *bs)
}
}
-static void process_rule(BlockDriverState *bs, struct BlkdebugRule *rule,
-BlkdebugVars *old_vars)
+static bool process_rule(BlockDriverState *bs, struct BlkdebugRule *rule,
+int old_state, bool injected)
{
BDRVBlkdebugState *s = bs-opaque;
-BlkdebugVars *vars = s-vars;
/* Only process rules for the current state */
-if (rule-state rule-state != old_vars-state) {
-return;
+if (rule-state rule-state != old_state) {
+return injected;
}
/* Take the action */
switch (rule-action) {
case ACTION_INJECT_ERROR:
-vars-inject_errno = rule-options.inject.error;
-vars-inject_once= rule-options.inject.once;
-vars-inject_immediately = rule-options.inject.immediately;
+if (!injected) {
+QSIMPLEQ_INIT(s-active_rules);
+injected = true;
+}
+QSIMPLEQ_INSERT_HEAD(s-active_rules, rule, active_next);
break;
case ACTION_SET_STATE:
-vars-state = rule-options.set_state.new_state;
+s-state = rule-options.set_state.new_state;
break;
}
+return injected;
}
static void blkdebug_debug_event(BlockDriverState *bs, BlkDebugEvent event)
{
[Qemu-devel] [PATCH v2 02/25] build: do not sprinkle around GENERATED_HEADERS dependencies
Keeping GENERATED_HEADERS dependencies up-to-date everywhere is complex. We can simply make the Makefile depend on them, and they will be built before all other targets. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile| 18 +- Makefile.target | 14 -- tests/Makefile |1 - 3 files changed, 13 insertions(+), 20 deletions(-) diff --git a/Makefile b/Makefile index 9b7a85e..c0ab97a 100644 --- a/Makefile +++ b/Makefile @@ -91,19 +91,18 @@ qemu-options.def: $(SRC_PATH)/qemu-options.hx SUBDIR_RULES=$(patsubst %,subdir-%, $(TARGET_DIRS)) -subdir-%: $(GENERATED_HEADERS) +subdir-%: $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C $* V=$(V) TARGET_DIR=$*/ all,) ifneq ($(wildcard config-host.mak),) include $(SRC_PATH)/Makefile.objs endif -$(universal-obj-y) $(common-obj-y): $(GENERATED_HEADERS) subdir-libcacard: $(oslib-obj-y) $(trace-obj-y) qemu-timer-common.o $(filter %-softmmu,$(SUBDIR_RULES)): $(universal-obj-y) $(trace-obj-y) $(common-obj-y) subdir-libdis -$(filter %-user,$(SUBDIR_RULES)): $(GENERATED_HEADERS) $(universal-obj-y) $(trace-obj-y) subdir-libdis-user subdir-libuser +$(filter %-user,$(SUBDIR_RULES)): $(universal-obj-y) $(trace-obj-y) subdir-libdis-user subdir-libuser ROMSUBDIR_RULES=$(patsubst %,romsubdir-%, $(ROMS)) romsubdir-%: @@ -142,7 +141,7 @@ libcacard.la: install-libcacard: @echo libtool is missing, please install and rerun configure; exit 1 else -libcacard.la: $(GENERATED_HEADERS) $(oslib-obj-y) qemu-timer-common.o $(addsuffix .lo, $(basename $(trace-obj-y))) +libcacard.la: $(oslib-obj-y) qemu-timer-common.o $(addsuffix .lo, $(basename $(trace-obj-y))) $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C libcacard V=$(V) TARGET_DIR=$*/ libcacard.la,) install-libcacard: libcacard.la @@ -151,7 +150,6 @@ endif ## qemu-img.o: qemu-img-cmds.h -qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o cmd.o qemu-ga.o: $(GENERATED_HEADERS) tools-obj-y = $(oslib-obj-y) $(trace-obj-y) qemu-tool.o qemu-timer.o \ qemu-timer-common.o main-loop.o notify.o iohandler.o cutils.o async.o @@ -162,7 +160,6 @@ qemu-nbd$(EXESUF): qemu-nbd.o $(tools-obj-y) $(block-obj-y) qemu-io$(EXESUF): qemu-io.o cmd.o $(tools-obj-y) $(block-obj-y) qemu-bridge-helper$(EXESUF): qemu-bridge-helper.o -qemu-bridge-helper.o: $(GENERATED_HEADERS) fsdev/virtfs-proxy-helper$(EXESUF): fsdev/virtfs-proxy-helper.o fsdev/virtio-9p-marshal.o oslib-posix.o $(trace-obj-y) fsdev/virtfs-proxy-helper$(EXESUF): LIBS += -lcap @@ -170,7 +167,6 @@ fsdev/virtfs-proxy-helper$(EXESUF): LIBS += -lcap qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h $ $@, GEN $@) -$(qapi-obj-y): $(GENERATED_HEADERS) qapi-dir := $(BUILD_DIR)/qapi-generated qemu-ga$(EXESUF): LIBS = $(LIBS_QGA) qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir) @@ -203,8 +199,8 @@ $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py QGALIB_OBJ=$(addprefix $(qapi-dir)/, qga-qapi-types.o qga-qapi-visit.o qga-qmp-marshal.o) QGALIB_GEN=$(addprefix $(qapi-dir)/, qga-qapi-types.h qga-qapi-visit.h qga-qmp-commands.h) -$(QGALIB_OBJ): $(QGALIB_GEN) $(GENERATED_HEADERS) -$(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) $(GENERATED_HEADERS) +$(QGALIB_OBJ): $(QGALIB_GEN) +$(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) qemu-ga$(EXESUF): qemu-ga.o $(qga-obj-y) $(tools-obj-y) $(qapi-obj-y) $(qobject-obj-y) $(version-obj-y) $(QGALIB_OBJ) @@ -399,5 +395,9 @@ tar: cd /tmp tar zcvf ~/$(FILE).tar.gz $(FILE) --exclude CVS --exclude .git --exclude .svn rm -rf /tmp/$(FILE) +# Add a dependency on the generated files, so that they are always +# rebuilt before other object files +Makefile: $(GENERATED_HEADERS) + # Include automatically generated dependency files -include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d ui/*.d qapi/*.d qga/*.d) diff --git a/Makefile.target b/Makefile.target index 1582904..95a82be 100644 --- a/Makefile.target +++ b/Makefile.target @@ -1,6 +1,5 @@ # -*- Mode: makefile -*- -GENERATED_HEADERS = config-target.h CONFIG_NO_PCI = $(if $(subst n,,$(CONFIG_PCI)),n,y) CONFIG_NO_KVM = $(if $(subst n,,$(CONFIG_KVM)),n,y) CONFIG_NO_XEN = $(if $(subst n,,$(CONFIG_XEN)),n,y) @@ -105,8 +104,6 @@ libobj-$(CONFIG_TCI_DIS) += tci-dis.o tci-dis.o: QEMU_CFLAGS += -I$(SRC_PATH)/tcg -I$(SRC_PATH)/tcg/tci -$(libobj-y): $(GENERATED_HEADERS) - # HELPER_CFLAGS is used for all the legacy code compiled with static register # variables ifneq ($(TARGET_BASE_ARCH), sparc) @@ -143,8 +140,6 @@ obj-arm-y += arm-semi.o obj-m68k-y += m68k-sim.o m68k-semi.o -$(obj-y) $(obj-$(TARGET_BASE_ARCH)-y): $(GENERATED_HEADERS) - obj-y += $(addprefix ../, $(universal-obj-y)) obj-y += $(addprefix ../libuser/, $(user-obj-y)) obj-y += $(addprefix ../libdis-user/, $(libdis-y)) @@ -166,8 +161,6 @@ obj-y = main.o bsdload.o
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
Am 05.06.2012 18:21, schrieb Michael Roth:
On Tue, Jun 05, 2012 at 11:25:01AM +0200, Kevin Wolf wrote:
Am 05.06.2012 03:00, schrieb Michael Roth:
This is an import of Anthony's qidl compiler, with some changes squashed
in to add support for doing the visitor generation via QEMU's qapi code
generators rather than directly.
Documentation has been imported as well, as is also viewable at:
https://github.com/aliguori/qidl/blob/master/qc.md
This will be used to add annotations to device structs to aid in
generating visitors that can be used to serialize/unserialize them.
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
scripts/qc.md | 331 ++
scripts/qc.py | 494
+
2 files changed, 825 insertions(+), 0 deletions(-)
create mode 100644 scripts/qc.md
create mode 100755 scripts/qc.py
diff --git a/scripts/qc.md b/scripts/qc.md
new file mode 100644
index 000..4cf4b21
--- /dev/null
+++ b/scripts/qc.md
I think docs/ would be a better place than scripts/
+Getting Started
+---
+
+The first step is to move your device struct definition to a header file.
This
+header file should only contain the struct definition and any preprocessor
+declarations you need to define the structure. This header file will act
as
+the source for the QC IDL compiler.
+
+Do not include any function declarations in this header file as QC does not
+understand function declarations.
Couldn't we use a header file (or even source file) that has some magic
markers for the IDL compiler? Like:
... random stuff ...
/* QIDL START */
struct Foo {
...
};
/* QIDL END */
... random stuff ...
Adding a new header file for each device really doesn't look like a
desirable thing, and this way it could be avoided.
We could always make the compiler smarter (Anthony has already done
so apparently), and in the version posted here the compiler actually
scans line-by-line for the qc_declaration annotation before it begins
processing the annotated structure, so it behaves much like you're
suggestion.
The main reason device state needs to be moved to a seperate file is
because the generated visitors need to access that device state.
The only way I can think of getting around this is to do nasty things
like adding an
#include qapi-generated/mc146818rtc-qapi-visit.c;
in hw/mc146818rtc.c.
If the alternative is making private structs public, which is even
nastier IMHO, this might be the lesser evil.
(And I agree with Paolo that Anthony's version is a bit too much magic
and doesn't really make it cleaner)
Kevin
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/06/2012 12:11 AM, Michael Roth wrote: Is is possible to let the compiler process the .c file, with the IDL delimited by some marker? I like how device models are self contained in one file now. It's possible, but only if we inject the generated visitor code into the devices via an #include qapi-generated/device-qapi-visit.c; I'm not sure how acceptable that is... but it does reduce the churn quite a bit. We could make qc add this #include (or even inject the code directly) by emitting a new C file (with #line directives to direct the debugger to the original) and compiling this intermediate file instead of the source. +There are three cases where state can be suppressed: when it is **immutable**, +**derived**, or **broken**. There is a fourth class, non-guest-visible state (below). There is a fifth class, migrated by other means, which includes memory and block device state, but of course it isn't interesting in this context. There's a higher-level annotation, qc_declaration, which denotes what devices/structs should be processed by the QIDL compiler (and follow it's rules). So there's an implied handled by other means for everything that falls outside this category. Right, but within a qc_declaration struct there can be other means fields. snip Suggestion: add a _guest marker for ordinary state. Fail the build on unmarked fields. This ensures that some thought is given to each field, instead of having a default that may be correct most of the time, but not always. Hmm, I my general thought was that is doesn't hurt to send extra, which made serialization a reasonable default course of action. But there is indeed a risk of overwriting target state with garbage if we don't verify what fields really should/shouldn't be sent. A marker to track this does seem useful in that regard... I don't think the default is unsafe. I just dislike ABIs being cast into stone by carelessness, it can be hard to fix up later. Suppose we have state X and derived state Y that is sent by mistake. But it can also be said that Y is the state and X derives from it, so can we ever remove one or the other? It would be a bigger problem if there were multiple implementations of the protocol (instead of just qemu), but still, I'd rather see more thought going into the protcol when defining it rather than when trying to change it. Suggestion: add a mandatory position hint (_guest(7) or _pos(7)) that generates ordering within the fields. This decouples the order of lines in the struct from the protocol, so you can add state where it make sense, or rearrange lines when they don't, and detect copy/paste errors. I'm in agreement with Gerd that the wire protocol we use should support field names. I think device state constitutes a small enough percentage of total migrated state that the performance impact would be negligable, and migration will invariably add some negotiation/compatibility functionality on top of the serialization that would make having field names intact useful for analyzing/debugging things. I personally like the idea of using compressed json, but I think we could implement a QObject-BER mechanism that would provide this as well. I'd like to see BER too. But we will have to support the old protocol for quite some time (I'd say at least 3 years from the first release that supports the new protocol). We could put the ordering some other place, but that makes it harder to write qc_declarations. Surely there are available lexer/parser packages? This seems promising: http://pygments.org/docs/lexerdevelopment/ IMO some external tool is really needed. I'm sure qc will pick up new features quickly, so separating the protocol description's description from the protocol description's parser is important. You can't get a lot more meta than that. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH v2 05/25] build: move obj-TARGET-y variables to nested Makefile.objs
Also drop duplicate occurrence of device-hotplug.o. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.target | 186 ++ configure| 48 --- hw/alpha/Makefile.objs |4 + hw/arm/Makefile.objs | 39 ++ hw/cris/Makefile.objs| 13 ++ hw/i386/Makefile.objs| 13 ++ hw/lm32/Makefile.objs| 23 hw/m68k/Makefile.objs|4 + hw/microblaze/Makefile.objs | 13 ++ hw/mips/Makefile.objs|6 + hw/ppc/Makefile.objs | 31 + hw/s390x/Makefile.objs |3 + hw/sh4/Makefile.objs |5 + hw/sparc/Makefile.objs |8 ++ hw/sparc64/Makefile.objs |4 + hw/xtensa/Makefile.objs |5 + target-alpha/Makefile.objs |1 + target-arm/Makefile.objs |1 + arm-semi.c = target-arm/arm-semi.c |0 target-cris/Makefile.objs|1 + target-i386/Makefile.objs|3 + ioport-user.c = target-i386/ioport-user.c |0 target-lm32/Makefile.objs|1 + target-m68k/Makefile.objs|1 + m68k-semi.c = target-m68k/m68k-semi.c |0 target-microblaze/Makefile.objs |1 + target-mips/Makefile.objs|1 + target-ppc/Makefile.objs |1 + target-s390x/Makefile.objs |1 + target-sh4/Makefile.objs |1 + target-sparc/Makefile.objs |1 + target-unicore32/Makefile.objs |1 + target-xtensa/Makefile.objs |4 + xtensa-semi.c = target-xtensa/xtensa-semi.c |0 34 files changed, 229 insertions(+), 195 deletions(-) create mode 100644 hw/alpha/Makefile.objs create mode 100644 hw/arm/Makefile.objs create mode 100644 hw/cris/Makefile.objs create mode 100644 hw/i386/Makefile.objs create mode 100644 hw/lm32/Makefile.objs create mode 100644 hw/m68k/Makefile.objs create mode 100644 hw/microblaze/Makefile.objs create mode 100644 hw/mips/Makefile.objs create mode 100644 hw/ppc/Makefile.objs create mode 100644 hw/s390x/Makefile.objs create mode 100644 hw/sh4/Makefile.objs create mode 100644 hw/sparc/Makefile.objs create mode 100644 hw/sparc64/Makefile.objs create mode 100644 hw/xtensa/Makefile.objs create mode 100644 target-alpha/Makefile.objs create mode 100644 target-arm/Makefile.objs rename arm-semi.c = target-arm/arm-semi.c (100%) create mode 100644 target-cris/Makefile.objs create mode 100644 target-i386/Makefile.objs rename ioport-user.c = target-i386/ioport-user.c (100%) create mode 100644 target-lm32/Makefile.objs create mode 100644 target-m68k/Makefile.objs rename m68k-semi.c = target-m68k/m68k-semi.c (100%) create mode 100644 target-microblaze/Makefile.objs create mode 100644 target-mips/Makefile.objs create mode 100644 target-ppc/Makefile.objs create mode 100644 target-s390x/Makefile.objs create mode 100644 target-sh4/Makefile.objs create mode 100644 target-sparc/Makefile.objs create mode 100644 target-unicore32/Makefile.objs create mode 100644 target-xtensa/Makefile.objs rename xtensa-semi.c = target-xtensa/xtensa-semi.c (100%) diff --git a/Makefile.target b/Makefile.target index 6ffb556..a2697e9 100644 --- a/Makefile.target +++ b/Makefile.target @@ -102,6 +102,8 @@ libobj-$(TARGET_ALPHA) += int_helper.o fpu_helper.o sys_helper.o mem_helper.o libobj-y += disas.o libobj-$(CONFIG_TCI_DIS) += tci-dis.o +obj-y += target-$(TARGET_BASE_ARCH)/ + tci-dis.o: QEMU_CFLAGS += -I$(SRC_PATH)/tcg -I$(SRC_PATH)/tcg/tci # HELPER_CFLAGS is used for all the legacy code compiled with static register @@ -124,9 +126,6 @@ QEMU_CFLAGS+=-I$(SRC_PATH)/linux-user/$(TARGET_ABI_DIR) -I$(SRC_PATH)/linux-user obj-y += linux-user/ obj-y += gdbstub.o thunk.o user-exec.o $(oslib-obj-y) -obj-i386-y += ioport-user.o -obj-$(TARGET_ARM) += arm-semi.o -obj-$(TARGET_M68K) += m68k-semi.o obj-y += $(addprefix ../, $(universal-obj-y)) obj-y += $(addprefix ../libuser/, $(user-obj-y)) @@ -144,7 +143,6 @@ QEMU_CFLAGS+=-I$(SRC_PATH)/bsd-user -I$(SRC_PATH)/bsd-user/$(TARGET_ARCH) obj-y += bsd-user/ obj-y += gdbstub.o user-exec.o -obj-i386-y += ioport-user.o obj-y += $(addprefix ../, $(universal-obj-y)) obj-y += $(addprefix ../libuser/, $(user-obj-y)) @@ -157,7 +155,7 @@ endif #CONFIG_BSD_USER # System emulator target ifdef CONFIG_SOFTMMU -obj-y = arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o ioport.o +obj-y += arch_init.o cpus.o monitor.o machine.o gdbstub.o balloon.o ioport.o # virtio has to be here due to weird dependency between PCI and virtio-net. # need
[Qemu-devel] [PATCH 1/6] blkdebug: remove sync i/o events
These are unused, except (by mistake more or less) in QED.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block.h |2 --
block/blkdebug.c |2 --
block/qed.c |2 +-
3 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/block.h b/block.h
index bff5a9b..80c1768 100644
--- a/block.h
+++ b/block.h
@@ -391,9 +391,7 @@ typedef enum {
BLKDBG_L2_ALLOC_COW_READ,
BLKDBG_L2_ALLOC_WRITE,
-BLKDBG_READ,
BLKDBG_READ_AIO,
-BLKDBG_READ_BACKING,
BLKDBG_READ_BACKING_AIO,
BLKDBG_READ_COMPRESSED,
diff --git a/block/blkdebug.c b/block/blkdebug.c
index e56e37d..1eff940 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -147,9 +147,7 @@ static const char *event_names[BLKDBG_EVENT_MAX] = {
[BLKDBG_L2_ALLOC_COW_READ] = l2_alloc.cow_read,
[BLKDBG_L2_ALLOC_WRITE] = l2_alloc.write,
-[BLKDBG_READ] = read,
[BLKDBG_READ_AIO] = read_aio,
-[BLKDBG_READ_BACKING] = read_backing,
[BLKDBG_READ_BACKING_AIO] = read_backing_aio,
[BLKDBG_READ_COMPRESSED]= read_compressed,
diff --git a/block/qed.c b/block/qed.c
index ab59724..dd2832a 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -748,7 +748,7 @@ static void qed_read_backing_file(BDRVQEDState *s, uint64_t
pos,
/* If the read straddles the end of the backing file, shorten it */
size = MIN((uint64_t)backing_length - pos, qiov-size);
-BLKDBG_EVENT(s-bs-file, BLKDBG_READ_BACKING);
+BLKDBG_EVENT(s-bs-file, BLKDBG_READ_BACKING_AIO);
bdrv_aio_readv(s-bs-backing_hd, pos / BDRV_SECTOR_SIZE,
qiov, size / BDRV_SECTOR_SIZE, cb, opaque);
}
--
1.7.10.1
[Qemu-devel] [PATCH v2 12/25] build: move fsdev/ objects to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile|2 +- Makefile.objs | 11 +-- fsdev/Makefile.objs |9 + 3 files changed, 15 insertions(+), 7 deletions(-) create mode 100644 fsdev/Makefile.objs diff --git a/Makefile b/Makefile index c0ab97a..0c0540d 100644 --- a/Makefile +++ b/Makefile @@ -100,7 +100,7 @@ endif subdir-libcacard: $(oslib-obj-y) $(trace-obj-y) qemu-timer-common.o -$(filter %-softmmu,$(SUBDIR_RULES)): $(universal-obj-y) $(trace-obj-y) $(common-obj-y) subdir-libdis +$(filter %-softmmu,$(SUBDIR_RULES)): $(universal-obj-y) $(trace-obj-y) $(common-obj-y) $(extra-obj-y) subdir-libdis $(filter %-user,$(SUBDIR_RULES)): $(universal-obj-y) $(trace-obj-y) subdir-libdis-user subdir-libuser diff --git a/Makefile.objs b/Makefile.objs index f40be38..4acdbaa 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -51,11 +51,7 @@ ifeq ($(CONFIG_VIRTIO)$(CONFIG_VIRTFS)$(CONFIG_PCI),yyy) # Lots of the fsdev/9pcode is pulled in by vl.c via qemu_fsdev_add. # only pull in the actual virtio-9p device if we also enabled virtio. CONFIG_REALLY_VIRTFS=y -fsdev-nested-y = qemu-fsdev.o virtio-9p-marshal.o -else -fsdev-nested-y = qemu-fsdev-dummy.o endif -fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) ## # Target independent part of system emulation. The long term path is to @@ -65,12 +61,14 @@ fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) common-obj-y = $(block-obj-y) blockdev.o common-obj-y += net.o net/ common-obj-y += qom/ -common-obj-$(CONFIG_LINUX) += $(fsdev-obj-$(CONFIG_LINUX)) common-obj-y += readline.o console.o cursor.o common-obj-y += $(oslib-obj-y) common-obj-$(CONFIG_WIN32) += os-win32.o common-obj-$(CONFIG_POSIX) += os-posix.o +common-obj-$(CONFIG_LINUX) += fsdev/ +extra-obj-$(CONFIG_LINUX) += fsdev/ + common-obj-y += tcg-runtime.o host-utils.o main-loop.o common-obj-y += irq.o input.o common-obj-$(CONFIG_PTIMER) += ptimer.o @@ -442,5 +440,6 @@ nested-vars += \ block-obj-y \ qom-obj-y \ user-obj-y \ - common-obj-y + common-obj-y \ + extra-obj-y dummy := $(call unnest-vars) diff --git a/fsdev/Makefile.objs b/fsdev/Makefile.objs new file mode 100644 index 000..cb1e250 --- /dev/null +++ b/fsdev/Makefile.objs @@ -0,0 +1,9 @@ +ifeq ($(CONFIG_REALLY_VIRTFS),y) +common-obj-y = qemu-fsdev.o virtio-9p-marshal.o + +# Toplevel always builds this; targets without virtio will put it in +# common-obj-y +extra-obj-y = qemu-fsdev-dummy.o +else +common-obj-y = qemu-fsdev-dummy.o +endif -- 1.7.10.1
[Qemu-devel] [PATCH v2 20/25] build: move per-target hw/ objects to nested Makefile.objs
This completes the move to nested Makefile.objs for virtio and a few other files that were not part of obj-TARGET-y, but still were compiled separately for each target. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.hw |5 +++-- Makefile.target | 31 +-- configure |1 + hw/9pfs/Makefile.objs |2 ++ hw/Makefile.objs | 18 ++ 5 files changed, 29 insertions(+), 28 deletions(-) diff --git a/Makefile.hw b/Makefile.hw index 155a0c3..2bcbaff 100644 --- a/Makefile.hw +++ b/Makefile.hw @@ -19,7 +19,8 @@ all: $(hw-obj-y) @true clean: - rm -f *.o */*.o *.d */*.d *.a */*.a *~ */*~ */*/*.d + rm -f $(addsuffix /*.o, $(dir $(sort $(hw-obj-y + rm -f $(addsuffix /*.d, $(dir $(sort $(hw-obj-y # Include automatically generated dependency files --include $(wildcard *.d */*.d */*/*.d) +-include $(patsubst %.o, %.d, $(hw-obj-y)) diff --git a/Makefile.target b/Makefile.target index 006f1cd..be09865 100644 --- a/Makefile.target +++ b/Makefile.target @@ -1,9 +1,5 @@ # -*- Mode: makefile -*- -CONFIG_NO_PCI = $(if $(subst n,,$(CONFIG_PCI)),n,y) -CONFIG_NO_KVM = $(if $(subst n,,$(CONFIG_KVM)),n,y) -CONFIG_NO_XEN = $(if $(subst n,,$(CONFIG_XEN)),n,y) - include ../config-host.mak include config-devices.mak include config-target.mak @@ -120,19 +116,14 @@ endif #CONFIG_BSD_USER # # System emulator target ifdef CONFIG_SOFTMMU +CONFIG_NO_PCI = $(if $(subst n,,$(CONFIG_PCI)),n,y) +CONFIG_NO_KVM = $(if $(subst n,,$(CONFIG_KVM)),n,y) +CONFIG_NO_XEN = $(if $(subst n,,$(CONFIG_XEN)),n,y) obj-y += arch_init.o cpus.o monitor.o gdbstub.o balloon.o ioport.o -# virtio has to be here due to weird dependency between PCI and virtio-net. -# need to fix this properly -obj-$(CONFIG_NO_PCI) += pci-stub.o -obj-$(CONFIG_VIRTIO) += virtio.o virtio-blk.o virtio-balloon.o virtio-net.o virtio-serial-bus.o -obj-$(CONFIG_VIRTIO) += virtio-scsi.o -obj-y += vhost_net.o -obj-$(CONFIG_VHOST_NET) += vhost.o -obj-$(CONFIG_REALLY_VIRTFS) += 9pfs/virtio-9p-device.o +obj-y += hw/ obj-$(CONFIG_KVM) += kvm-all.o obj-$(CONFIG_NO_KVM) += kvm-stub.o -obj-$(CONFIG_VGA) += vga.o obj-y += memory.o savevm.o cputlb.o LIBS+=-lz @@ -142,21 +133,9 @@ QEMU_CFLAGS += $(VNC_JPEG_CFLAGS) QEMU_CFLAGS += $(VNC_PNG_CFLAGS) # xen support -obj-$(CONFIG_XEN) += xen-all.o xen_machine_pv.o xen_domainbuild.o xen-mapcache.o +obj-$(CONFIG_XEN) += xen-all.o xen-mapcache.o obj-$(CONFIG_NO_XEN) += xen-stub.o -# Inter-VM PCI shared memory -CONFIG_IVSHMEM = -ifeq ($(CONFIG_KVM), y) - ifeq ($(CONFIG_PCI), y) -CONFIG_IVSHMEM = y - endif -endif -obj-$(CONFIG_IVSHMEM) += ivshmem.o - -# Generic hotplugging -obj-y += device-hotplug.o - # Hardware support ifeq ($(TARGET_ARCH), sparc64) obj-y += hw/sparc64/ diff --git a/configure b/configure index b9637dc..d90255a 100755 --- a/configure +++ b/configure @@ -3675,6 +3675,7 @@ mkdir -p $target_dir/9pfs mkdir -p $target_dir/hw mkdir -p $target_dir/hw/ide mkdir -p $target_dir/hw/usb +mkdir -p $target_dir/hw/9pfs mkdir -p $target_dir/hw/kvm mkdir -p $target_dir/hw/$TARGET_ARCH mkdir -p $target_dir/hw/$TARGET_BASE_ARCH diff --git a/hw/9pfs/Makefile.objs b/hw/9pfs/Makefile.objs index 2700772..972df24 100644 --- a/hw/9pfs/Makefile.objs +++ b/hw/9pfs/Makefile.objs @@ -5,3 +5,5 @@ hw-obj-y += virtio-9p-coth.o cofs.o codir.o cofile.o hw-obj-y += coxattr.o virtio-9p-synth.o hw-obj-$(CONFIG_OPEN_BY_HANDLE) += virtio-9p-handle.o hw-obj-y += virtio-9p-proxy.o + +obj-y += virtio-9p-device.o diff --git a/hw/Makefile.objs b/hw/Makefile.objs index 08dde63..7e17504 100644 --- a/hw/Makefile.objs +++ b/hw/Makefile.objs @@ -145,3 +145,21 @@ common-obj-$(CONFIG_BRLAPI) += baum.o # xen backend driver support common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o common-obj-$(CONFIG_XEN_BACKEND) += xen_console.o xenfb.o xen_disk.o xen_nic.o + +# Per-target files +# virtio has to be here due to weird dependency between PCI and virtio-net. +# need to fix this properly +obj-$(CONFIG_VIRTIO) += virtio.o virtio-blk.o virtio-balloon.o virtio-net.o +obj-$(CONFIG_VIRTIO) += virtio-serial-bus.o virtio-scsi.o +obj-$(CONFIG_SOFTMMU) += vhost_net.o +obj-$(CONFIG_VHOST_NET) += vhost.o +obj-$(CONFIG_REALLY_VIRTFS) += 9pfs/ +obj-$(CONFIG_NO_PCI) += pci-stub.o +obj-$(CONFIG_VGA) += vga.o +obj-$(CONFIG_SOFTMMU) += device-hotplug.o +obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o + +# Inter-VM PCI shared memory +ifeq ($(CONFIG_PCI), y) +obj-$(CONFIG_KVM) += ivshmem.o +endif -- 1.7.10.1
[Qemu-devel] [PATCH v2 21/25] build: move device tree to per-target Makefile
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.target |7 --- hw/arm/Makefile.objs|1 + hw/microblaze/Makefile.objs |1 + hw/ppc/Makefile.objs|1 + 4 files changed, 3 insertions(+), 7 deletions(-) diff --git a/Makefile.target b/Makefile.target index be09865..f25e278 100644 --- a/Makefile.target +++ b/Makefile.target @@ -143,13 +143,6 @@ else obj-y += hw/$(TARGET_BASE_ARCH)/ endif -# Device tree -ifeq ($(CONFIG_FDT), y) -obj-$(TARGET_ARM) += device_tree.o -obj-$(TARGET_MICROBLAZE) += device_tree.o -obj-$(TARGET_PPC) += device_tree.o -endif - main.o: QEMU_CFLAGS+=$(GPROF_CFLAGS) GENERATED_HEADERS += hmp-commands.h qmp-commands-old.h diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs index 92b4f1e..a0ff6a6 100644 --- a/hw/arm/Makefile.objs +++ b/hw/arm/Makefile.objs @@ -35,5 +35,6 @@ obj-y += vexpress.o obj-y += strongarm.o obj-y += collie.o obj-y += pl041.o lm4549.o +obj-$(CONFIG_FDT) += ../device_tree.o obj-y := $(addprefix ../,$(obj-y)) diff --git a/hw/microblaze/Makefile.objs b/hw/microblaze/Makefile.objs index 4172442..020f7b6 100644 --- a/hw/microblaze/Makefile.objs +++ b/hw/microblaze/Makefile.objs @@ -9,5 +9,6 @@ obj-y += xilinx_uartlite.o obj-y += xilinx_ethlite.o obj-y += xilinx_axidma.o obj-y += xilinx_axienet.o +obj-$(CONFIG_FDT) += ../device_tree.o obj-y := $(addprefix ../,$(obj-y)) diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs index 5b09849..842e7b9 100644 --- a/hw/ppc/Makefile.objs +++ b/hw/ppc/Makefile.objs @@ -21,6 +21,7 @@ obj-y += virtex_ml507.o obj-$(CONFIG_KVM) += kvm_ppc.o # PowerPC OpenPIC obj-y += openpic.o +obj-$(CONFIG_FDT) += ../device_tree.o # Xilinx PPC peripherals obj-y += xilinx_intc.o -- 1.7.10.1
[Qemu-devel] [PATCH v2 15/25] build: move slirp/ objects to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs |5 + slirp/Makefile.objs |3 +++ 2 files changed, 4 insertions(+), 4 deletions(-) create mode 100644 slirp/Makefile.objs diff --git a/Makefile.objs b/Makefile.objs index 7ee2bb6..668c148 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -120,10 +120,7 @@ common-obj-$(CONFIG_POSIX) += compatfd.o common-obj-y += notify.o event_notifier.o common-obj-y += qemu-timer.o qemu-timer-common.o -slirp-obj-y = cksum.o if.o ip_icmp.o ip_input.o ip_output.o -slirp-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o tcp_input.o tcp_output.o -slirp-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o arp_table.o -common-obj-$(CONFIG_SLIRP) += $(addprefix slirp/, $(slirp-obj-y)) +common-obj-$(CONFIG_SLIRP) += slirp/ # xen backend driver support common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o diff --git a/slirp/Makefile.objs b/slirp/Makefile.objs new file mode 100644 index 000..bb43d3c --- /dev/null +++ b/slirp/Makefile.objs @@ -0,0 +1,3 @@ +common-obj-y = cksum.o if.o ip_icmp.o ip_input.o ip_output.o +common-obj-y += slirp.o mbuf.o misc.o sbuf.o socket.o tcp_input.o tcp_output.o +common-obj-y += tcp_subr.o tcp_timer.o udp.o bootp.o tftp.o arp_table.o -- 1.7.10.1
[Qemu-devel] [PATCH v2 25/25] build: do not create directories at configure time
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- configure | 35 ++- rules.mak |1 + 2 files changed, 3 insertions(+), 33 deletions(-) diff --git a/configure b/configure index 301b574..07e3ff1 100755 --- a/configure +++ b/configure @@ -3672,26 +3672,6 @@ if [ $TARGET_BASE_ARCH = ]; then TARGET_BASE_ARCH=$TARGET_ARCH fi -mkdir -p $target_dir/fpu -mkdir -p $target_dir/tcg -mkdir -p $target_dir/9pfs -mkdir -p $target_dir/hw -mkdir -p $target_dir/hw/ide -mkdir -p $target_dir/hw/usb -mkdir -p $target_dir/hw/9pfs -mkdir -p $target_dir/hw/kvm -mkdir -p $target_dir/hw/$TARGET_ARCH -mkdir -p $target_dir/hw/$TARGET_BASE_ARCH -mkdir -p $target_dir/target-$TARGET_BASE_ARCH -if test $target_linux_user = yes; then - mkdir -p $target_dir/linux-user -fi -if test $target_bsd_user = yes; then - mkdir -p $target_dir/bsd-user -fi -if test $target = arm-linux-user -o $target = armeb-linux-user -o $target = arm-bsd-user -o $target = armeb-bsd-user ; then - mkdir -p $target_dir/linux-user/arm/nwfpe -fi symlink $source_path/Makefile.target $target_dir/Makefile @@ -3948,12 +3928,9 @@ done # for target in $targets # build tree in object directory in case the source is not in the current directory DIRS=tests tests/tcg tests/tcg/cris tests/tcg/lm32 -DIRS=$DIRS slirp audio block net pc-bios/optionrom -DIRS=$DIRS pc-bios/spapr-rtas +DIRS=$DIRS pc-bios/optionrom pc-bios/spapr-rtas DIRS=$DIRS roms/seabios roms/vgabios -DIRS=$DIRS fsdev ui hw hw/usb -DIRS=$DIRS qapi qapi-generated -DIRS=$DIRS qga trace qom +DIRS=$DIRS qapi-generated DIRS=$DIRS libcacard libcacard/libcacard libcacard/trace FILES=Makefile tests/tcg/Makefile qdict-test-data.txt FILES=$FILES tests/tcg/cris/Makefile tests/tcg/cris/.gdbinit @@ -3992,19 +3969,11 @@ done for hwlib in 32 64; do d=libhw$hwlib - mkdir -p $d - mkdir -p $d/hw - mkdir -p $d/hw/ide - mkdir -p $d/hw/usb symlink $source_path/Makefile.hw $d/Makefile - mkdir -p $d/hw/9pfs echo QEMU_CFLAGS+=-DTARGET_PHYS_ADDR_BITS=$hwlib $d/config.mak done d=libuser -mkdir -p $d -mkdir -p $d/trace -mkdir -p $d/qom symlink $source_path/Makefile.user $d/Makefile if test $docs = yes ; then diff --git a/rules.mak b/rules.mak index f65283c..4bc5e52 100644 --- a/rules.mak +++ b/rules.mak @@ -111,4 +111,5 @@ endef define unnest-vars $(call unnest-vars-1) $(foreach var,$(nested-vars),$(eval $(var) := $(filter-out %/, $($(var) +$(shell mkdir -p $(sort $(foreach var,$(nested-vars),$(dir $($(var)) endef -- 1.7.10.1
Re: [Qemu-devel] [PATCH 11/17] qapi: add qidl-generated qapi schema for rtc
Am 05.06.2012 18:03, schrieb Michael Roth: On Tue, Jun 05, 2012 at 11:29:24AM +0200, Kevin Wolf wrote: Am 05.06.2012 03:00, schrieb Michael Roth: Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com --- qidl-generated/mc146818rtc.json |1 + 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 qidl-generated/mc146818rtc.json I haven't looked at the Makefiles, but does this commit mean that the files aren't generated automatically but you have to run the generator manually after changing any device struct? Nope, the files are automatically generated when changes are made to QIDL sources and you do a build. The reason they're still checked-in is so that changes to a device's serialization schema can be signed-off by the author that made the change. This applies to qidl-generated vmstate descriptions as well. Doesn't really make sense to me. You already have a sign-off for the changed header/source file. It also makes an automated `make check-qidl` and, in the case of qidl-generated vmstate descriptions, `make check-vmstate` possible, so that a submitter/maintainer can detect and bring attention to changes to serialized device state that need to be addressed/signed-off when testing/reviewing patches. Why can't 'make check-qidl' generate the new version itself like a simple 'make' would do? We could get part of the way there by just keeping tabs on changes to qidl sources, but ultimately how we do the serialization is a matter of how the generated visitors look, in which case the generated QAPI schemas are the more reliable representation. Annotations are hints, schemas are ABI, so tracking the latter is more important. So your statement is that the generator is likely buggy and therefore its output should be reviewed as well as the source changes? Similar rationale for vmstate: the relationship between annotations and the generated vmstate descriptions isn't strong enough that we can easily infer changes based on qidl annotations, and in many cases those inferred changes will be overwritten by special handling in the vmstate generator. I don't understand. Is this file generated or manually edited? If the former, why does having it in the repository add anything new when you can (and with appropriate Makefile magic will) always run the generator after pulling changes to source files? If the latter, why does the subject say it's generated? Kevin
[Qemu-devel] [PATCH v2 17/25] build: move qga/ objects to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs |7 ++- qga/Makefile.objs |3 +++ 2 files changed, 5 insertions(+), 5 deletions(-) create mode 100644 qga/Makefile.objs diff --git a/Makefile.objs b/Makefile.objs index e7f7a85..fec21a4 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -385,11 +385,7 @@ universal-obj-y += $(qapi-obj-y) ## # guest agent -qga-nested-y = commands.o guest-agent-command-state.o -qga-nested-$(CONFIG_POSIX) += commands-posix.o channel-posix.o -qga-nested-$(CONFIG_WIN32) += commands-win32.o channel-win32.o service-win32.o -qga-obj-y = $(addprefix qga/, $(qga-nested-y)) -qga-obj-y += qemu-ga.o module.o +qga-obj-y = qga/ qemu-ga.o module.o qga-obj-$(CONFIG_WIN32) += oslib-win32.o qga-obj-$(CONFIG_POSIX) += oslib-posix.o qemu-sockets.o qemu-option.o @@ -400,6 +396,7 @@ vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS) QEMU_CFLAGS+=$(GLIB_CFLAGS) nested-vars += \ + qga-obj-y \ block-obj-y \ qom-obj-y \ qapi-obj-y \ diff --git a/qga/Makefile.objs b/qga/Makefile.objs new file mode 100644 index 000..6a4d843 --- /dev/null +++ b/qga/Makefile.objs @@ -0,0 +1,3 @@ +qga-obj-y = commands.o guest-agent-command-state.o +qga-obj-$(CONFIG_POSIX) += commands-posix.o channel-posix.o +qga-obj-$(CONFIG_WIN32) += commands-win32.o channel-win32.o service-win32.o -- 1.7.10.1
Re: [Qemu-devel] [qemu-devel][RFC] Enable usb with default options
On Wed, 2012-06-06 at 10:52 +0800, li zhang wrote: Hi Anthony, Any comment on this? Allright, this is all quite confusing... He's what I think should happen: When no option is passed -at-all-, we should have vga std and usb ohci + usb mouse + usb ps2. When -nodefault is passed, we should have none of the above. -vga should only affect vga (a shortcut for -device pick_your_vga_poison) -usb should be essentially useless by default unless -nodefault is passed in which case it is necessary to enable usb support, and -device (or equivalent) to manually add the keyboard and mouse (libvirt). That's the best I can think of ... however it might be a bit tricky seeing how qemu does things in vl.c at the moment, we might want to introduce a default_usb variable which is used to set usb_enabled. BTW. The mac models should essentially behave the same, at least the 64-bit one (32-bit supports CUDA for keyboard/mouse so USB isn't strictly necessary). Cheers, Ben. Thanks. On Tue, Jun 5, 2012 at 5:48 PM, li zhang zhlci...@gmail.com wrote: Hi all, For pseries, when creating VMs with -vga std, it requires usb mouse and usb kbd devices to be added. But with default options, vga is enabled and usb is disabled. User may use default options as the following commands: $qemu -M pseries If vga is enabled, usb mouse and usb kbd is disabled, the mouse and kbd can't be used. So it's very hard for users to use. I think it's necessary to enable usb with default options. Any idea about that? Your comments are very appreciated. :) Thanks. -Li -- Best Regards -Li
[Qemu-devel] [PATCH v2 16/25] build: move qapi/ objects to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs |6 ++ qapi/Makefile.objs |3 +++ 2 files changed, 5 insertions(+), 4 deletions(-) create mode 100644 qapi/Makefile.objs diff --git a/Makefile.objs b/Makefile.objs index 668c148..e7f7a85 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -375,10 +375,7 @@ libcacard-y = cac.o event.o vcard.o vreader.o vcard_emul_nss.o vcard_emul_type.o ## # qapi -qapi-nested-y = qapi-visit-core.o qapi-dealloc-visitor.o qmp-input-visitor.o -qapi-nested-y += qmp-output-visitor.o qmp-registry.o qmp-dispatch.o -qapi-nested-y += string-input-visitor.o string-output-visitor.o -qapi-obj-y = $(addprefix qapi/, $(qapi-nested-y)) +qapi-obj-y = qapi/ common-obj-y += qmp-marshal.o qapi-visit.o qapi-types.o common-obj-y += qmp.o hmp.o @@ -405,6 +402,7 @@ QEMU_CFLAGS+=$(GLIB_CFLAGS) nested-vars += \ block-obj-y \ qom-obj-y \ + qapi-obj-y \ user-obj-y \ common-obj-y \ extra-obj-y diff --git a/qapi/Makefile.objs b/qapi/Makefile.objs new file mode 100644 index 000..d0b0c16 --- /dev/null +++ b/qapi/Makefile.objs @@ -0,0 +1,3 @@ +qapi-obj-y = qapi-visit-core.o qapi-dealloc-visitor.o qmp-input-visitor.o +qapi-obj-y += qmp-output-visitor.o qmp-registry.o qmp-dispatch.o +qapi-obj-y += string-input-visitor.o string-output-visitor.o -- 1.7.10.1
[Qemu-devel] [PATCH v2 10/25] build: move block/ objects to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs | 16 ++-- block/Makefile.objs | 11 +++ 2 files changed, 13 insertions(+), 14 deletions(-) create mode 100644 block/Makefile.objs diff --git a/Makefile.objs b/Makefile.objs index ef49a09..3285949 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -45,20 +45,7 @@ block-obj-y += nbd.o block.o aio.o aes.o qemu-config.o qemu-progress.o qemu-sock block-obj-y += $(coroutine-obj-y) $(qobject-obj-y) $(version-obj-y) block-obj-$(CONFIG_POSIX) += posix-aio-compat.o block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o - -block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o vvfat.o -block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o qcow2-cache.o -block-nested-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o -block-nested-y += qed-check.o -block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o -block-nested-y += stream.o -block-nested-$(CONFIG_WIN32) += raw-win32.o -block-nested-$(CONFIG_POSIX) += raw-posix.o -block-nested-$(CONFIG_LIBISCSI) += iscsi.o -block-nested-$(CONFIG_CURL) += curl.o -block-nested-$(CONFIG_RBD) += rbd.o - -block-obj-y += $(addprefix block/, $(block-nested-y)) +block-obj-y += block/ net-obj-y = net.o net-nested-y = queue.o checksum.o util.o @@ -467,6 +454,7 @@ vl.o: QEMU_CFLAGS+=$(SDL_CFLAGS) QEMU_CFLAGS+=$(GLIB_CFLAGS) nested-vars += \ + block-obj-y \ qom-obj-y \ user-obj-y \ common-obj-y diff --git a/block/Makefile.objs b/block/Makefile.objs new file mode 100644 index 000..b5754d3 --- /dev/null +++ b/block/Makefile.objs @@ -0,0 +1,11 @@ +block-obj-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o vvfat.o +block-obj-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o qcow2-cache.o +block-obj-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o +block-obj-y += qed-check.o +block-obj-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o +block-obj-y += stream.o +block-obj-$(CONFIG_WIN32) += raw-win32.o +block-obj-$(CONFIG_POSIX) += raw-posix.o +block-obj-$(CONFIG_LIBISCSI) += iscsi.o +block-obj-$(CONFIG_CURL) += curl.o +block-obj-$(CONFIG_RBD) += rbd.o -- 1.7.10.1
[Qemu-devel] [PATCH v2 14/25] build: move audio/ objects to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs | 18 ++ audio/Makefile.objs | 14 ++ 2 files changed, 16 insertions(+), 16 deletions(-) create mode 100644 audio/Makefile.objs diff --git a/Makefile.objs b/Makefile.objs index a6310e3..7ee2bb6 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -110,23 +110,9 @@ common-obj-$(CONFIG_BRLAPI) += baum.o common-obj-$(CONFIG_POSIX) += migration-exec.o migration-unix.o migration-fd.o common-obj-$(CONFIG_WIN32) += version.o - -audio-obj-y = audio.o noaudio.o wavaudio.o mixeng.o -audio-obj-$(CONFIG_SDL) += sdlaudio.o -audio-obj-$(CONFIG_OSS) += ossaudio.o -audio-obj-$(CONFIG_SPICE) += spiceaudio.o -audio-obj-$(CONFIG_COREAUDIO) += coreaudio.o -audio-obj-$(CONFIG_ALSA) += alsaaudio.o -audio-obj-$(CONFIG_DSOUND) += dsoundaudio.o -audio-obj-$(CONFIG_FMOD) += fmodaudio.o -audio-obj-$(CONFIG_ESD) += esdaudio.o -audio-obj-$(CONFIG_PA) += paaudio.o -audio-obj-$(CONFIG_WINWAVE) += winwaveaudio.o -audio-obj-$(CONFIG_AUDIO_PT_INT) += audio_pt_int.o -audio-obj-$(CONFIG_AUDIO_WIN_INT) += audio_win_int.o -audio-obj-y += wavcapture.o -common-obj-y += $(addprefix audio/, $(audio-obj-y)) common-obj-$(CONFIG_SPICE) += spice-qemu-char.o + +common-obj-y += audio/ common-obj-y += ui/ common-obj-y += iov.o acl.o diff --git a/audio/Makefile.objs b/audio/Makefile.objs new file mode 100644 index 000..0f2932d --- /dev/null +++ b/audio/Makefile.objs @@ -0,0 +1,14 @@ +common-obj-y = audio.o noaudio.o wavaudio.o mixeng.o +common-obj-$(CONFIG_SDL) += sdlaudio.o +common-obj-$(CONFIG_OSS) += ossaudio.o +common-obj-$(CONFIG_SPICE) += spiceaudio.o +common-obj-$(CONFIG_COREAUDIO) += coreaudio.o +common-obj-$(CONFIG_ALSA) += alsaaudio.o +common-obj-$(CONFIG_DSOUND) += dsoundaudio.o +common-obj-$(CONFIG_FMOD) += fmodaudio.o +common-obj-$(CONFIG_ESD) += esdaudio.o +common-obj-$(CONFIG_PA) += paaudio.o +common-obj-$(CONFIG_WINWAVE) += winwaveaudio.o +common-obj-$(CONFIG_AUDIO_PT_INT) += audio_pt_int.o +common-obj-$(CONFIG_AUDIO_WIN_INT) += audio_win_int.o +common-obj-y += wavcapture.o -- 1.7.10.1
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/06/2012 02:51 AM, Anthony Liguori wrote:
+during device construction and never changes. This means we can add an
+**_immutable** marker to it:
Even if it does change (suppose we add a monitor command to retarget a
the serial device's chardev), it need not be migrated since it doesn't
describe guest state, only host state. Maybe we should mark *chr _host
instead of _immutable.
No, this is just another example of C's type system sucking and being
ambiguous.
Consider the following example:
struct PS2Keyboard {
DeviceState parent;
PCKBDState _immutable *controller; // link
...
};
This is definitely '_immutable' even though *something* has to marshal
that PCKBDState. That's because this is a reference to an externally
managed object. As long as references don't change due to guest
initiated actions, they're immutable.
In fact C allows you to express this:
const T *foo; // *foo may not change, but foo may
T * const foo; // foo may not change, but *foo may
Although every time I see this, I have to stop and think, which activity
I usually try to avoid. So your example would be written
PCKBDState * _immutable controller; // link
if we adopt the same system. But I wasn't referring to that at all.
Instead, some state is simply not relevant to the guest view, even
though it is state. We don't have a lot of that since most host state
is behind nice interfaces, but think of a vga device that keeps track of
the host window size and alt-ctrl status. Those are not guest state and
need not be migrated.
In the case of a CharDriverState, the reference is always immutable. If
we supported changing char backends dynamically, it would not happen by
changing the reference, but almost certainly by having the ability to
reopen the char driver in place. IOW, while the referenced object
changes, the reference doesn't change.
In either case, state changes. The reason we don't send it over is
because it's not guest state, not because we reopen in place or not (and
migration shouldn't depend on how we choose to implement changing
chardev backends -- reopen or delete/new).
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 16/17] qidl: add qidl-generated vmstate fields for rtc
On 06/06/2012 02:38 AM, Anthony Liguori wrote: On 06/05/2012 06:26 PM, Avi Kivity wrote: On 06/05/2012 04:00 AM, Michael Roth wrote: Initial check-in of the qidl-generated vmstate fields for rtc. Don't, please. As Mike said in another note, we want to keep the device schema in the tree so we can determine when it changes in 'make check' and complain loudly. But I think we need a better way to do this. Something like a 'make schema-update' target that will regenerate schemas and prepare them for checkin. Yes, that's much better. Also would be good to pretty-print them so that incremental changes are easy to spot using 'diff'. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH v2 06/25] build: move libobj-y variable to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.target | 41 +++ configure |6 -- target-alpha/Makefile.objs |3 ++- target-arm/Makefile.objs|4 target-cris/Makefile.objs |5 - target-i386/Makefile.objs |3 +++ target-lm32/Makefile.objs |4 +++- target-m68k/Makefile.objs |3 +++ target-microblaze/Makefile.objs |5 - target-mips/Makefile.objs |4 +++- target-ppc/Makefile.objs|4 +++- target-s390x/Makefile.objs |4 +++- target-sh4/Makefile.objs|4 +++- target-sparc/Makefile.objs |8 +++- target-unicore32/Makefile.objs |4 +++- target-xtensa/Makefile.objs |3 +++ 16 files changed, 55 insertions(+), 50 deletions(-) diff --git a/Makefile.target b/Makefile.target index a2697e9..714659e 100644 --- a/Makefile.target +++ b/Makefile.target @@ -76,41 +76,19 @@ all: $(PROGS) stap # # cpu emulator library -libobj-y = exec.o translate-all.o cpu-exec.o translate.o -libobj-y += tcg/tcg.o tcg/optimize.o -libobj-$(CONFIG_TCG_INTERPRETER) += tci.o -libobj-y += fpu/softfloat.o -ifneq ($(TARGET_BASE_ARCH), sparc) -ifneq ($(TARGET_BASE_ARCH), alpha) -libobj-y += op_helper.o -endif -endif -libobj-y += helper.o -ifneq ($(TARGET_BASE_ARCH), ppc) -libobj-y += cpu.o -endif -libobj-$(TARGET_SPARC64) += vis_helper.o -libobj-$(CONFIG_NEED_MMU) += mmu.o -libobj-$(TARGET_ARM) += neon_helper.o iwmmxt_helper.o -ifeq ($(TARGET_BASE_ARCH), sparc) -libobj-y += fop_helper.o cc_helper.o win_helper.o mmu_helper.o ldst_helper.o -endif -libobj-$(TARGET_SPARC) += int32_helper.o -libobj-$(TARGET_SPARC64) += int64_helper.o -libobj-$(TARGET_ALPHA) += int_helper.o fpu_helper.o sys_helper.o mem_helper.o - -libobj-y += disas.o -libobj-$(CONFIG_TCI_DIS) += tci-dis.o - +obj-y = exec.o translate-all.o cpu-exec.o translate.o +obj-y += tcg/tcg.o tcg/optimize.o +obj-$(CONFIG_TCG_INTERPRETER) += tci.o +obj-y += fpu/softfloat.o +obj-y += disas.o +obj-$(CONFIG_TCI_DIS) += tci-dis.o obj-y += target-$(TARGET_BASE_ARCH)/ +obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o tci-dis.o: QEMU_CFLAGS += -I$(SRC_PATH)/tcg -I$(SRC_PATH)/tcg/tci # HELPER_CFLAGS is used for all the legacy code compiled with static register # variables -ifneq ($(TARGET_BASE_ARCH), sparc) -op_helper.o: QEMU_CFLAGS += $(HELPER_CFLAGS) -endif user-exec.o: QEMU_CFLAGS += $(HELPER_CFLAGS) # Note: this is a workaround. The real fix is to avoid compiling @@ -130,7 +108,6 @@ obj-y += gdbstub.o thunk.o user-exec.o $(oslib-obj-y) obj-y += $(addprefix ../, $(universal-obj-y)) obj-y += $(addprefix ../libuser/, $(user-obj-y)) obj-y += $(addprefix ../libdis-user/, $(libdis-y)) -obj-y += $(libobj-y) endif #CONFIG_LINUX_USER @@ -147,7 +124,6 @@ obj-y += gdbstub.o user-exec.o obj-y += $(addprefix ../, $(universal-obj-y)) obj-y += $(addprefix ../libuser/, $(user-obj-y)) obj-y += $(addprefix ../libdis-user/, $(libdis-y)) -obj-y += $(libobj-y) endif #CONFIG_BSD_USER @@ -212,7 +188,6 @@ GENERATED_HEADERS += hmp-commands.h qmp-commands-old.h obj-y += $(addprefix ../, $(universal-obj-y)) obj-y += $(addprefix ../, $(common-obj-y)) obj-y += $(addprefix ../libdis/, $(libdis-y)) -obj-y += $(libobj-y) obj-y += $(addprefix $(HWDIR)/, $(hw-obj-y)) obj-y += $(addprefix ../, $(trace-obj-y)) @@ -226,8 +201,6 @@ obj-$(CONFIG_SMARTCARD_NSS) += $(addprefix ../libcacard/, $(libcacard-y)) endif # CONFIG_BSD_USER endif # CONFIG_LINUX_USER -obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o - nested-vars = obj-y dummy := $(call unnest-vars) diff --git a/configure b/configure index afcca8d..afa7937 100755 --- a/configure +++ b/configure @@ -3903,12 +3903,6 @@ if test $target_softmmu = yes ; then esac fi -if test $target_softmmu = yes -a \( \ -$TARGET_ARCH = microblaze -o \ -$TARGET_ARCH = cris \) ; then - echo CONFIG_NEED_MMU=y $config_target_mak -fi - if test $gprof = yes ; then echo TARGET_GPROF=yes $config_target_mak if test $target_linux_user = yes ; then diff --git a/target-alpha/Makefile.objs b/target-alpha/Makefile.objs index c574c9e..9a72870 100644 --- a/target-alpha/Makefile.objs +++ b/target-alpha/Makefile.objs @@ -1 +1,2 @@ -# still empty +obj-y += helper.o cpu.o +obj-y += int_helper.o fpu_helper.o sys_helper.o mem_helper.o diff --git a/target-arm/Makefile.objs b/target-arm/Makefile.objs index f5bb920..4dcd3c5 100644 --- a/target-arm/Makefile.objs +++ b/target-arm/Makefile.objs @@ -1 +1,5 @@ obj-y += arm-semi.o +obj-y += op_helper.o helper.o cpu.o +obj-y += neon_helper.o iwmmxt_helper.o + +$(obj)/op_helper.o: QEMU_CFLAGS += $(HELPER_CFLAGS) diff --git a/target-cris/Makefile.objs b/target-cris/Makefile.objs index c574c9e..9a50c28 100644 --- a/target-cris/Makefile.objs +++ b/target-cris/Makefile.objs @@ -1 +1,4 @@ -# still empty +obj-y += op_helper.o helper.o
Re: [Qemu-devel] Sporadic AHCI boot failures
On 06/05/2012 10:08 PM, Jan Kiszka wrote: Do things work again after system_reset on the monitor? Maybe the reset function is just broken and we finish some asynchronous stuff after reset? The problem both occurs after power on as well as reset. Sometimes it takes multiple system_reset calls to get the system booting. Think I found it: There is bug in the new in-kernel PIT userspace code that lets Seabios detect some 4..7 MHz CPU. So all the timeouts finish way too early. This also affects IDE and possible other stuff in the bios that depends on timeouts. Digging into this... This is probably Yongjie Ren's problem as well. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH 3/6] blkdebug: pass getlength to underlying file
This is required when using blkdebug with raw format. Unlike qcow2/QED,
raw asks blkdebug for the length of the file, it doesn't get it from
a header.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
block/blkdebug.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/block/blkdebug.c b/block/blkdebug.c
index 1f79ef2..b084a23 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -429,6 +429,11 @@ static void blkdebug_debug_event(BlockDriverState *bs,
BlkDebugEvent event)
}
}
+static int64_t blkdebug_getlength(BlockDriverState *bs)
+{
+return bdrv_getlength(bs-file);
+}
+
static BlockDriver bdrv_blkdebug = {
.format_name= blkdebug,
.protocol_name = blkdebug,
@@ -437,6 +442,7 @@ static BlockDriver bdrv_blkdebug = {
.bdrv_file_open = blkdebug_open,
.bdrv_close = blkdebug_close,
+.bdrv_getlength = blkdebug_getlength,
.bdrv_aio_readv = blkdebug_aio_readv,
.bdrv_aio_writev= blkdebug_aio_writev,
--
1.7.10.1
[Qemu-devel] [PATCH v2 11/25] build: move net/ objects to nested Makefile.objs
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs | 17 + net/Makefile.objs | 12 2 files changed, 13 insertions(+), 16 deletions(-) create mode 100644 net/Makefile.objs diff --git a/Makefile.objs b/Makefile.objs index 3285949..f40be38 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -47,21 +47,6 @@ block-obj-$(CONFIG_POSIX) += posix-aio-compat.o block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o block-obj-y += block/ -net-obj-y = net.o -net-nested-y = queue.o checksum.o util.o -net-nested-y += socket.o -net-nested-y += dump.o -net-nested-$(CONFIG_POSIX) += tap.o -net-nested-$(CONFIG_LINUX) += tap-linux.o -net-nested-$(CONFIG_WIN32) += tap-win32.o -net-nested-$(CONFIG_BSD) += tap-bsd.o -net-nested-$(CONFIG_SOLARIS) += tap-solaris.o -net-nested-$(CONFIG_AIX) += tap-aix.o -net-nested-$(CONFIG_HAIKU) += tap-haiku.o -net-nested-$(CONFIG_SLIRP) += slirp.o -net-nested-$(CONFIG_VDE) += vde.o -net-obj-y += $(addprefix net/, $(net-nested-y)) - ifeq ($(CONFIG_VIRTIO)$(CONFIG_VIRTFS)$(CONFIG_PCI),yyy) # Lots of the fsdev/9pcode is pulled in by vl.c via qemu_fsdev_add. # only pull in the actual virtio-9p device if we also enabled virtio. @@ -78,7 +63,7 @@ fsdev-obj-$(CONFIG_VIRTFS) += $(addprefix fsdev/, $(fsdev-nested-y)) # single QEMU executable should support all CPUs and machines. common-obj-y = $(block-obj-y) blockdev.o -common-obj-y += $(net-obj-y) +common-obj-y += net.o net/ common-obj-y += qom/ common-obj-$(CONFIG_LINUX) += $(fsdev-obj-$(CONFIG_LINUX)) common-obj-y += readline.o console.o cursor.o diff --git a/net/Makefile.objs b/net/Makefile.objs new file mode 100644 index 000..72f50bc --- /dev/null +++ b/net/Makefile.objs @@ -0,0 +1,12 @@ +common-obj-y = queue.o checksum.o util.o +common-obj-y += socket.o +common-obj-y += dump.o +common-obj-$(CONFIG_POSIX) += tap.o +common-obj-$(CONFIG_LINUX) += tap-linux.o +common-obj-$(CONFIG_WIN32) += tap-win32.o +common-obj-$(CONFIG_BSD) += tap-bsd.o +common-obj-$(CONFIG_SOLARIS) += tap-solaris.o +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 -- 1.7.10.1
[Qemu-devel] [PATCH v2 18/25] build: move target-independent hw/ objects to nested Makefiles
This patch starts converting the hw/ directory. Some files in hw/ are compiled once, some twice (32-/64-bit), some once per target. Each category is moved in a separate patch. After this patch, the files that are compiled once will show the same hierarchy in the build tree as they do in the source tree, for example hw/qdev.o instead of just qdev.o. Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile |6 -- Makefile.objs| 38 +++--- configure|2 +- hw/Makefile.objs | 32 hw/usb/Makefile.objs |4 5 files changed, 44 insertions(+), 38 deletions(-) create mode 100644 hw/Makefile.objs create mode 100644 hw/usb/Makefile.objs diff --git a/Makefile b/Makefile index 0c0540d..a10005a 100644 --- a/Makefile +++ b/Makefile @@ -120,7 +120,7 @@ QEMU_CFLAGS += -I$(SRC_PATH)/include ui/cocoa.o: ui/cocoa.m -ui/sdl.o audio/sdlaudio.o ui/sdl_zoom.o baum.o: QEMU_CFLAGS += $(SDL_CFLAGS) +ui/sdl.o audio/sdlaudio.o ui/sdl_zoom.o hw/baum.o: QEMU_CFLAGS += $(SDL_CFLAGS) ui/vnc.o: QEMU_CFLAGS += $(VNC_TLS_CFLAGS) @@ -214,6 +214,7 @@ clean: rm -Rf .libs rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d fsdev/*.o fsdev/*.d ui/*.o ui/*.d qapi/*.o qapi/*.d qga/*.o qga/*.d rm -f qom/*.o qom/*.d + rm -f usb/*.o usb/*.d hw/*.o hw/*.d rm -f qemu-img-cmds.h rm -f trace/*.o trace/*.d rm -f trace-dtrace.dtrace trace-dtrace.dtrace-timestamp @@ -400,4 +401,5 @@ tar: Makefile: $(GENERATED_HEADERS) # Include automatically generated dependency files --include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d ui/*.d qapi/*.d qga/*.d) +-include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d ui/*.d qapi/*.d) +-include $(wildcard qga/*.d hw/*.d hw/usb/*.d) diff --git a/Makefile.objs b/Makefile.objs index fec21a4..4aa5f0f 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -70,50 +70,22 @@ common-obj-$(CONFIG_LINUX) += fsdev/ extra-obj-$(CONFIG_LINUX) += fsdev/ common-obj-y += tcg-runtime.o host-utils.o main-loop.o -common-obj-y += irq.o input.o -common-obj-$(CONFIG_PTIMER) += ptimer.o -common-obj-$(CONFIG_MAX7310) += max7310.o -common-obj-$(CONFIG_WM8750) += wm8750.o -common-obj-$(CONFIG_TWL92230) += twl92230.o -common-obj-$(CONFIG_TSC2005) += tsc2005.o -common-obj-$(CONFIG_LM832X) += lm832x.o -common-obj-$(CONFIG_TMP105) += tmp105.o -common-obj-$(CONFIG_STELLARIS_INPUT) += stellaris_input.o -common-obj-$(CONFIG_SSD0303) += ssd0303.o -common-obj-$(CONFIG_SSD0323) += ssd0323.o -common-obj-$(CONFIG_ADS7846) += ads7846.o -common-obj-$(CONFIG_MAX111X) += max111x.o -common-obj-$(CONFIG_DS1338) += ds1338.o -common-obj-y += i2c.o smbus.o smbus_eeprom.o -common-obj-y += eeprom93xx.o -common-obj-y += scsi-disk.o cdrom.o -common-obj-y += scsi-generic.o scsi-bus.o -common-obj-y += hid.o -common-obj-y += usb/core.o usb/bus.o usb/desc.o usb/dev-hub.o -common-obj-y += usb/host-$(HOST_USB).o -common-obj-y += usb/dev-hid.o usb/dev-storage.o usb/dev-wacom.o -common-obj-y += usb/dev-serial.o usb/dev-network.o usb/dev-audio.o -common-obj-$(CONFIG_SSI) += ssi.o -common-obj-$(CONFIG_SSI_SD) += ssi-sd.o -common-obj-$(CONFIG_SD) += sd.o -common-obj-y += bt.o bt-host.o bt-vhci.o bt-l2cap.o bt-sdp.o bt-hci.o bt-hid.o -common-obj-y += bt-hci-csr.o usb/dev-bluetooth.o +common-obj-y += input.o common-obj-y += buffered_file.o migration.o migration-tcp.o common-obj-y += qemu-char.o #aio.o -common-obj-y += msmouse.o ps2.o -common-obj-y += qdev.o qdev-properties.o qdev-monitor.o common-obj-y += block-migration.o iohandler.o common-obj-y += pflib.o common-obj-y += bitmap.o bitops.o -common-obj-$(CONFIG_BRLAPI) += baum.o common-obj-$(CONFIG_POSIX) += migration-exec.o migration-unix.o migration-fd.o common-obj-$(CONFIG_WIN32) += version.o common-obj-$(CONFIG_SPICE) += spice-qemu-char.o common-obj-y += audio/ +common-obj-y += hw/ common-obj-y += ui/ +common-obj-y += bt-host.o bt-vhci.o common-obj-y += iov.o acl.o common-obj-$(CONFIG_POSIX) += compatfd.o @@ -122,10 +94,6 @@ common-obj-y += qemu-timer.o qemu-timer-common.o common-obj-$(CONFIG_SLIRP) += slirp/ -# xen backend driver support -common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o -common-obj-$(CONFIG_XEN_BACKEND) += xen_console.o xenfb.o xen_disk.o xen_nic.o - ## # libuser diff --git a/configure b/configure index afa7937..ffae12c 100755 --- a/configure +++ b/configure @@ -3947,7 +3947,7 @@ DIRS=tests tests/tcg tests/tcg/cris tests/tcg/lm32 DIRS=$DIRS slirp audio block net pc-bios/optionrom DIRS=$DIRS pc-bios/spapr-rtas DIRS=$DIRS roms/seabios roms/vgabios -DIRS=$DIRS fsdev ui usb +DIRS=$DIRS fsdev ui hw hw/usb DIRS=$DIRS qapi qapi-generated DIRS=$DIRS qga trace qom FILES=Makefile tests/tcg/Makefile qdict-test-data.txt diff --git a/hw/Makefile.objs
[Qemu-devel] [PATCH v2 01/25] build: remove trace-nested-y
Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- Makefile.objs | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index 70c5c79..1daa92c 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -425,16 +425,11 @@ ifneq ($(TRACE_BACKEND),dtrace) trace-obj-y = trace.o endif -trace-nested-$(CONFIG_TRACE_DEFAULT) += default.o - -trace-nested-$(CONFIG_TRACE_SIMPLE) += simple.o +trace-obj-$(CONFIG_TRACE_DEFAULT) += trace/default.o +trace-obj-$(CONFIG_TRACE_SIMPLE) += trace/simple.o trace-obj-$(CONFIG_TRACE_SIMPLE) += qemu-timer-common.o - -trace-nested-$(CONFIG_TRACE_STDERR) += stderr.o - -trace-nested-y += control.o - -trace-obj-y += $(addprefix trace/, $(trace-nested-y)) +trace-obj-$(CONFIG_TRACE_STDERR) += trace/stderr.o +trace-obj-y += trace/control.o $(trace-obj-y): $(GENERATED_HEADERS) -- 1.7.10.1
Re: [Qemu-devel] [PATCH 0/2] Two small fixes to the streaming test case.
Am 06.06.2012 01:10, schrieb Paolo Bonzini:
Hi Kevin, please take a look at the attached simple patches.
Paolo
Paolo Bonzini (2):
qemu-iotests: fill streaming test image with data
qemu-iotests: start vms in qtest mode
tests/qemu-iotests/030| 15 +--
tests/qemu-iotests/iotests.py |4 +++-
2 files changed, 16 insertions(+), 3 deletions(-)
A real patch series is preferable, having the patches as part of your
signature makes quoting them a bit harder with Thunderbird...
From 644fda4d6da1a5babfc8884f255d87ebaf847616 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Wed, 23 May 2012 13:07:56 +0200
Subject: [PATCH 1/2] qemu-iotests: fill streaming test image with data
This avoids that the job completes too fast when the file system
reports the hole to QEMU (via FIEMAP or SEEK_HOLE).
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Does this really fix the cause or just a symptom? The commit message
sounds like a race and now we happen to win it again. But maybe it's
just a bad wording that gives the impression.
---
tests/qemu-iotests/030 | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index eb7bf99..4ab7d62 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -21,6 +21,7 @@
import os
import iotests
from iotests import qemu_img, qemu_io
+import struct
backing_img = os.path.join(iotests.test_dir, 'backing.img')
mid_img = os.path.join(iotests.test_dir, 'mid.img')
@@ -48,11 +49,21 @@ class ImageStreamingTestCase(iotests.QMPTestCase):
self.assert_no_active_streams()
+def create_image(self, name, size):
+file = open(name, 'w')
+i = 0
+while i size:
+sector = struct.pack('l504xl', i / 512, i / 512)
+file.write(sector)
+i = i + 512
+file.close()
+
+
class TestSingleDrive(ImageStreamingTestCase):
image_len = 1 * 1024 * 1024 # MB
def setUp(self):
-qemu_img('create', backing_img, str(TestSingleDrive.image_len))
+self.create_image(backing_img, TestSingleDrive.image_len)
How about just adding a qemu_io call instead? Looks a bit nicer to me
than reimplementing it, and would also work if we decided to use a
different backing file format later.
qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
backing_img, mid_img)
qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
mid_img, test_img)
self.vm = iotests.VM().add_drive(test_img)
--
1.7.10.1
From 3ba5810860b2eaba1f01c257aa13e28c6f9e2b3f Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Wed, 23 May 2012 12:52:07 +0200
Subject: [PATCH 2/2] qemu-iotests: start vms in qtest mode
This way, they will not execute any code at all. However, right now
one test is relying on being slowed down by TCG executing random
crap, so change the timeouts there.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
BIOS code is random crap? :-)
But I like the idea of using the qtest mode here.
---
tests/qemu-iotests/030|2 +-
tests/qemu-iotests/iotests.py |4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 4ab7d62..cc671dd 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -147,7 +147,7 @@ class TestStreamStop(ImageStreamingTestCase):
result = self.vm.qmp('block-stream', device='drive0')
self.assert_qmp(result, 'return', {})
-time.sleep(1)
+time.sleep(0.1)
events = self.vm.get_qmp_events(wait=False)
self.assertEqual(events, [], 'unexpected QMP event: %s' % events)
Why is waiting for too _long_ a problem? I would understand if we waited
too short so that the QMP event hasn't arrived yet. But shouldn't you
still get all QMP events if you wait one more second before you fetch them?
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index e27b40e..e05b1d6 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -54,7 +54,9 @@ class VM(object):
self._qemu_log_path = os.path.join(test_dir, 'qemu-log.%d' %
os.getpid())
self._args = qemu_args + ['-chardev',
'socket,id=mon,path=' + self._monitor_path,
- '-mon', 'chardev=mon,mode=control', '-nographic']
+ '-mon', 'chardev=mon,mode=control',
+ '-qtest', 'stdio', '-machine', 'accel=qtest',
+ '-display', 'none', '-vga', 'none']
self._num_drives = 0
def add_drive(self, path, opts=''):
--
1.7.10.1
Kevin
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/06/2012 03:45 PM, Avi Kivity wrote:
On 06/06/2012 02:51 AM, Anthony Liguori wrote:
+during device construction and never changes. This means we can add an
+**_immutable** marker to it:
Even if it does change (suppose we add a monitor command to retarget a
the serial device's chardev), it need not be migrated since it doesn't
describe guest state, only host state. Maybe we should mark *chr _host
instead of _immutable.
No, this is just another example of C's type system sucking and being
ambiguous.
Consider the following example:
struct PS2Keyboard {
DeviceState parent;
PCKBDState _immutable *controller; // link
...
};
This is definitely '_immutable' even though *something* has to marshal
that PCKBDState. That's because this is a reference to an externally
managed object. As long as references don't change due to guest
initiated actions, they're immutable.
In fact C allows you to express this:
const T *foo; // *foo may not change, but foo may
T * const foo; // foo may not change, but *foo may
Although every time I see this, I have to stop and think, which activity
I usually try to avoid. So your example would be written
PCKBDState * _immutable controller; // link
if we adopt the same system.
I think you meant to add a const in there, but yeah, I know.
But I wasn't referring to that at all.
Instead, some state is simply not relevant to the guest view, even
though it is state. We don't have a lot of that since most host state
is behind nice interfaces, but think of a vga device that keeps track of
the host window size and alt-ctrl status. Those are not guest state and
need not be migrated.
Both the host window size and alt-ctrl status are not device state. They are
host backend state and they ought to be stored in a different data structure.
This is exactly how we do it (both things are stored in sdl.c or vnc.c).
If we're storing mutable host state in a device structure, that's a bug IMHO.
That's sort of the premise of the QIDL annotations at least.
In the case of a CharDriverState, the reference is always immutable. If
we supported changing char backends dynamically, it would not happen by
changing the reference, but almost certainly by having the ability to
reopen the char driver in place. IOW, while the referenced object
changes, the reference doesn't change.
In either case, state changes. The reason we don't send it over is
because it's not guest state, not because we reopen in place or not (and
migration shouldn't depend on how we choose to implement changing
chardev backends -- reopen or delete/new).
Well the goal is here not to support any possible way of separating guest state
and host state. The goal is here is to be very opinionated about how we
separate guest and host state such that we can take a rigorous approach to
migrating guest state.
I think we're actually pretty good today about separating host and guest state.
I can't think of an example within devices where we don't cleanly separate
things outside of block devices.
Regards,
Anthony Liguori
[Qemu-devel] [Bug 1007269] Re: Can’t install or boot up 32bit win8 guest.
64bit Win8 client can work fine as a kvm guest, however, 32bit can't work. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1007269 Title: Can’t install or boot up 32bit win8 guest. Status in QEMU: New Bug description: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux(rhel6u1) kvm.git Commit:51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 qemu-kvm Commit:3fd9fedb9fae4517d93d76e93a2924559cacf2f6 Host Kernel Version:3.4.0-rc7 Hardware:WSM-EP,Romley-EP Bug detailed description: -- it can't install or boot up 32bit Win8(Consumer Preview Update 2) guest. The guest will crash with the following error, while 64bit Win8 and 32bit Win7 guest work fine. -Win8 Error--- Your computer needs to restart. Please hold down the power button. Error code: 0x005D Parameters: 0x03060D03 0x756E6547 0x49656E69 0x6C65746E -Win8 Error--- 0x005D code means UNSUPPORTED_PROCESSOR in Windows. BTW, you can get 32bit Win8 ISO from the following website. http://windows.microsoft.com/en-US/windows-8/iso Reproduce steps: 1. get 32 bit win8 ISO 2. prepare a disk image: dd if=/dev/zero of=/root/win8-32.img bs=1M count=16384 3. start a guest to install 32bit win8: qemu-system –m 4096 –smp 4 –hda /root/win8-32.img –cdrom /media/32bit-Win8.iso 4. if you have a 32bit win8 image,try to boot it up Current result: 32bit Win8 guest crash Expected result: 32bit win8 guest boot up correctly To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1007269/+subscriptions
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/06/2012 11:27 AM, Anthony Liguori wrote:
On 06/06/2012 03:45 PM, Avi Kivity wrote:
On 06/06/2012 02:51 AM, Anthony Liguori wrote:
+during device construction and never changes. This means we can
add an
+**_immutable** marker to it:
Even if it does change (suppose we add a monitor command to retarget a
the serial device's chardev), it need not be migrated since it doesn't
describe guest state, only host state. Maybe we should mark *chr _host
instead of _immutable.
No, this is just another example of C's type system sucking and being
ambiguous.
Consider the following example:
struct PS2Keyboard {
DeviceState parent;
PCKBDState _immutable *controller; // link
...
};
This is definitely '_immutable' even though *something* has to marshal
that PCKBDState. That's because this is a reference to an externally
managed object. As long as references don't change due to guest
initiated actions, they're immutable.
In fact C allows you to express this:
const T *foo; // *foo may not change, but foo may
T * const foo; // foo may not change, but *foo may
Although every time I see this, I have to stop and think, which activity
I usually try to avoid. So your example would be written
PCKBDState * _immutable controller; // link
if we adopt the same system.
I think you meant to add a const in there, but yeah, I know.
Maybe also a _stupid. How can one get a one line example wrong by
omitting the important word out of five?
But I wasn't referring to that at all.
Instead, some state is simply not relevant to the guest view, even
though it is state. We don't have a lot of that since most host state
is behind nice interfaces, but think of a vga device that keeps track of
the host window size and alt-ctrl status. Those are not guest state and
need not be migrated.
Both the host window size and alt-ctrl status are not device state.
They are host backend state and they ought to be stored in a different
data structure. This is exactly how we do it (both things are stored in
sdl.c or vnc.c).
If we're storing mutable host state in a device structure, that's a bug
IMHO. That's sort of the premise of the QIDL annotations at least.
Ok. But then the backend pointer is not 'const Backend * const', it's
'Backend * const' (if we don't allow retargeting). So we can't say it's
_immutable (and it isn't). It's _host.
In the case of a CharDriverState, the reference is always immutable. If
we supported changing char backends dynamically, it would not happen by
changing the reference, but almost certainly by having the ability to
reopen the char driver in place. IOW, while the referenced object
changes, the reference doesn't change.
In either case, state changes. The reason we don't send it over is
because it's not guest state, not because we reopen in place or not (and
migration shouldn't depend on how we choose to implement changing
chardev backends -- reopen or delete/new).
Well the goal is here not to support any possible way of separating
guest state and host state. The goal is here is to be very opinionated
about how we separate guest and host state such that we can take a
rigorous approach to migrating guest state.
I think we're actually pretty good today about separating host and guest
state. I can't think of an example within devices where we don't
cleanly separate things outside of block devices.
And I agree that if we find such an example we should unexample it
quickly. But you still have a pointer (or even object) in there that is
not immutable. Why not mark it clearly instead of saying well, the
important bits in it are immutable, we don't care about the rest?
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets
On 06/05/2012 10:03 PM, Jan Kiszka wrote: A type definition and a KVMState field initialization escaped the required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a dummy kvm_irqchip_release_virq as virtio-pci references (but does not use) it. Thanks, applied. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/06/2012 04:37 PM, Avi Kivity wrote: On 06/06/2012 11:27 AM, Anthony Liguori wrote: On 06/06/2012 03:45 PM, Avi Kivity wrote: I think you meant to add a const in there, but yeah, I know. Maybe also a _stupid. How can one get a one line example wrong by omitting the important word out of five? For the same reason so few people actually write 'Type * const' in C, it's an incredibly awkward syntax :-/ But I wasn't referring to that at all. Instead, some state is simply not relevant to the guest view, even though it is state. We don't have a lot of that since most host state is behind nice interfaces, but think of a vga device that keeps track of the host window size and alt-ctrl status. Those are not guest state and need not be migrated. Both the host window size and alt-ctrl status are not device state. They are host backend state and they ought to be stored in a different data structure. This is exactly how we do it (both things are stored in sdl.c or vnc.c). If we're storing mutable host state in a device structure, that's a bug IMHO. That's sort of the premise of the QIDL annotations at least. Ok. But then the backend pointer is not 'const Backend * const', it's 'Backend * const' (if we don't allow retargeting). So we can't say it's _immutable (and it isn't). It's _host. 'Backend * const' is immutable That is, the *pointer* is immutable. What it points to is not. If you want to '#define _host _immutable' as a way to improve readability, I'm not against that. But from a conceptional perspective, we don't migrate it because nothing the guest does changes it. It's immutable from the guests PoV. In the case of a CharDriverState, the reference is always immutable. If we supported changing char backends dynamically, it would not happen by changing the reference, but almost certainly by having the ability to reopen the char driver in place. IOW, while the referenced object changes, the reference doesn't change. In either case, state changes. The reason we don't send it over is because it's not guest state, not because we reopen in place or not (and migration shouldn't depend on how we choose to implement changing chardev backends -- reopen or delete/new). Well the goal is here not to support any possible way of separating guest state and host state. The goal is here is to be very opinionated about how we separate guest and host state such that we can take a rigorous approach to migrating guest state. I think we're actually pretty good today about separating host and guest state. I can't think of an example within devices where we don't cleanly separate things outside of block devices. And I agree that if we find such an example we should unexample it quickly. But you still have a pointer (or even object) in there that is not immutable. Why not mark it clearly instead of saying well, the important bits in it are immutable, we don't care about the rest? If your argument is, we can improve readability by further classifying immutable things into why their immutable, I'm with you :-) Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v2 25/25] build: do not create directories at configure time
This results in failures to create symlinks in a new build directory. The
following patch seems to resolve it though.
Regards,
Anthony Liguori
On 06/06/2012 02:36 PM, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzinipbonz...@redhat.com
---
configure | 35 ++-
rules.mak |1 +
2 files changed, 3 insertions(+), 33 deletions(-)
diff --git a/configure b/configure
index 301b574..07e3ff1 100755
--- a/configure
+++ b/configure
@@ -3672,26 +3672,6 @@ if [ $TARGET_BASE_ARCH = ]; then
TARGET_BASE_ARCH=$TARGET_ARCH
fi
-mkdir -p $target_dir/fpu
-mkdir -p $target_dir/tcg
-mkdir -p $target_dir/9pfs
-mkdir -p $target_dir/hw
-mkdir -p $target_dir/hw/ide
-mkdir -p $target_dir/hw/usb
-mkdir -p $target_dir/hw/9pfs
-mkdir -p $target_dir/hw/kvm
-mkdir -p $target_dir/hw/$TARGET_ARCH
-mkdir -p $target_dir/hw/$TARGET_BASE_ARCH
-mkdir -p $target_dir/target-$TARGET_BASE_ARCH
-if test $target_linux_user = yes; then
- mkdir -p $target_dir/linux-user
-fi
-if test $target_bsd_user = yes; then
- mkdir -p $target_dir/bsd-user
-fi
-if test $target = arm-linux-user -o $target = armeb-linux-user -o $target =
arm-bsd-user -o $target = armeb-bsd-user ; then
- mkdir -p $target_dir/linux-user/arm/nwfpe
-fi
symlink $source_path/Makefile.target $target_dir/Makefile
@@ -3948,12 +3928,9 @@ done # for target in $targets
# build tree in object directory in case the source is not in the current
directory
DIRS=tests tests/tcg tests/tcg/cris tests/tcg/lm32
-DIRS=$DIRS slirp audio block net pc-bios/optionrom
-DIRS=$DIRS pc-bios/spapr-rtas
+DIRS=$DIRS pc-bios/optionrom pc-bios/spapr-rtas
DIRS=$DIRS roms/seabios roms/vgabios
-DIRS=$DIRS fsdev ui hw hw/usb
-DIRS=$DIRS qapi qapi-generated
-DIRS=$DIRS qga trace qom
+DIRS=$DIRS qapi-generated
DIRS=$DIRS libcacard libcacard/libcacard libcacard/trace
FILES=Makefile tests/tcg/Makefile qdict-test-data.txt
FILES=$FILES tests/tcg/cris/Makefile tests/tcg/cris/.gdbinit
@@ -3992,19 +3969,11 @@ done
for hwlib in 32 64; do
d=libhw$hwlib
- mkdir -p $d
- mkdir -p $d/hw
- mkdir -p $d/hw/ide
- mkdir -p $d/hw/usb
symlink $source_path/Makefile.hw $d/Makefile
- mkdir -p $d/hw/9pfs
echo QEMU_CFLAGS+=-DTARGET_PHYS_ADDR_BITS=$hwlib $d/config.mak
done
d=libuser
-mkdir -p $d
-mkdir -p $d/trace
-mkdir -p $d/qom
symlink $source_path/Makefile.user $d/Makefile
if test $docs = yes ; then
diff --git a/rules.mak b/rules.mak
index f65283c..4bc5e52 100644
--- a/rules.mak
+++ b/rules.mak
@@ -111,4 +111,5 @@ endef
define unnest-vars
$(call unnest-vars-1)
$(foreach var,$(nested-vars),$(eval $(var) := $(filter-out %/, $($(var)
+$(shell mkdir -p $(sort $(foreach var,$(nested-vars),$(dir $($(var))
endef
From e0e6e5b689cbcb782bca8f158fad89b3389e9e11 Mon Sep 17 00:00:00 2001
From: Anthony Liguori aligu...@us.ibm.com
Date: Wed, 6 Jun 2012 16:57:00 +0800
Subject: [PATCH] configure: ensure directory exists when creating symlink
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
configure |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 07e3ff1..4a7f027 100755
--- a/configure
+++ b/configure
@@ -42,6 +42,7 @@ compile_prog() {
# symbolically link $1 to $2. Portable version of ln -sf.
symlink() {
rm -rf $2
+ mkdir -p `dirname $2`
ln -s $1 $2
}
@@ -3454,14 +3455,12 @@ if test -f ${config_host_ld}~ ; then
fi
for d in libdis libdis-user; do
-mkdir -p $d
symlink $source_path/Makefile.dis $d/Makefile
echo $d/config.mak
done
# use included Linux headers
if test $linux = yes ; then
- mkdir -p linux-headers
case $cpu in
i386|x86_64)
symlink $source_path/linux-headers/asm-x86 linux-headers/asm
--
1.7.5.4
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/06/2012 11:45 AM, Anthony Liguori wrote: Ok. But then the backend pointer is not 'const Backend * const', it's 'Backend * const' (if we don't allow retargeting). So we can't say it's _immutable (and it isn't). It's _host. 'Backend * const' is immutable That is, the *pointer* is immutable. What it points to is not. So, is it reasonable to say uint32_t * _immutable irrp; // Interrupt Request Register and allocate it on the heap during initialization? If you want to '#define _host _immutable' as a way to improve readability, I'm not against that. But from a conceptional perspective, we don't migrate it because nothing the guest does changes it. It's immutable from the guests PoV. It's not only immutable from the guest point of view, it's unreadable as well. That's what _host means -- it doesn't exist as far as the guest is concerned. IMO that's different than immutable. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] configure: fix -enable-debug with newer toolchains
Fedora 17's toolchain wants optimization enabled for _FORTIFY_SOURCE; so disable _FORTIFY_SOURCE when debugging. Signed-off-by: Avi Kivity a...@redhat.com --- configure |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/configure b/configure index 1f338f8..88d9c5b 100755 --- a/configure +++ b/configure @@ -255,7 +255,6 @@ QEMU_CFLAGS=-fno-strict-aliasing $QEMU_CFLAGS QEMU_CFLAGS=-Wall -Wundef -Wwrite-strings -Wmissing-prototypes $QEMU_CFLAGS QEMU_CFLAGS=-Wstrict-prototypes -Wredundant-decls $QEMU_CFLAGS QEMU_CFLAGS=-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE $QEMU_CFLAGS -QEMU_CFLAGS=-D_FORTIFY_SOURCE=2 $QEMU_CFLAGS QEMU_INCLUDES=-I. -I\$(SRC_PATH) -I\$(SRC_PATH)/fpu if test $debug_info = yes; then CFLAGS=-g $CFLAGS @@ -2851,7 +2850,7 @@ fi # After here, no more $cc or $ld runs if test $debug = no ; then - CFLAGS=-O2 $CFLAGS + CFLAGS=-O2 -D_FORTIFY_SOURCE=2 $CFLAGS fi # Consult white-list to determine whether to enable werror -- 1.7.10.1
[Qemu-devel] [PULL] Fix for ppc build breakage
Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Jan Kiszka (1): kvm: Fix build for non-CAP_IRQ_ROUTING targets kvm-all.c | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) -- error compiling committee.c: too many arguments to function
[Qemu-devel] Singlestepping does not work
Dear developers, I have created a vmstate change handler, which logs RUN_STATE_DEBUG states, which is (as far as I know) used when one singlesteps the processor. Apparently this handler is not called, not even when I run qemu-system-microblaze with the -singlestep option. What am I missing? Regards, Gabor Wacha
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
Hi, I would like to add some more points to Gerd's explanation: On 06/05/2012 04:15 PM, Gerd Hoffmann wrote: Hi, Absolutely not. This is hideously ugly and affects a bunch of code. Spice is *not* getting a hook in migration where it gets to add arbitrary amounts of downtime to the migration traffic. That's a terrible idea. I'd like to be more constructive in my response, but you aren't explaining the problem well enough for me to offer an alternative solution. You need to find another way to solve this problem. Actually, this is not the first time we address you with this issues. For example: http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg01805.html (The first part of the above discussion is not directly related to the current one). I'll try to explain in more details: As Gerd mentioned, migrating the spice connection smoothly requires the src server to keep running and send/receive data to/from the client, after migration has already completed, till the client completely transfers to the target. The suggested patch series only delays the migration state change from ACTIVE to COMPLETED/ERROR/CANCELED, till spice signals it has completed its part in migration. As I see it, if spice connection does exists, its migration should be treated as a non separate part of the whole migration process, and thus, the migration state shouldn't change from ACTIVE, till spice has completed its part. Hence, I don't think we should have a qmp event for signaling libvirt about spice migration. The second challenge we are facing, which I addressed in the plans part of the cover-letter, and on which I think you (anthony) actually replied, is how to tackle migrating spice data from the src server to the target server. Such data can be usb/smartcard packets sent from a device connected on the client, to the server, and that haven't reached the device. Or partial data that has been read from a guest character device and that haven't been sent to the client. Other data can be internal server-client state data we would wish to keep on the server in order to avoid establishing the connection to the target from scratch, and possibly also suffer from a slower responsiveness at start. In the cover-letter I suggested to transfer spice migration data via the vmstate infrastructure. The other alternative which we also discussed in the link above, is to transfer the data via the client. The latter also requires holding the src process alive after migration completion, in order to manage to complete transferring the data from the src to the client. The vmstate option has the advantages of faster data transfer (src-dst, instead of src-client-dst), and in addition employing an already existing reliable mechanism for data migration. The disadvantage is that in order to have an updated vmstate we need to communicate with spice client and get all in-flight data before saving the vmstate. So, we can either busy wait on the relevant fds during the pre_save of the vmstates, or have async pre_save, so that the main loop will be active (but I think that it can be risky once the non-live phase started), or have an async notifier for changing from live to non-live phase, (spice will be able to update the vmstates during this notification handler). Of course, we would in any case use a timeout in order to prevent too long delay. To summarize, since we can still use the client to transfer data from the src to the target (instead of using vmstate), the major requirement of spice, is to keep the src running after migration has completed. Yonit. Very short version: The requirement is simply to not kill qemu on the source side until the source spice-server has finished session handover to the target spice-server. Long version: spice-client connects automatically to the target machine, so the user ideally doesn't notice that his virtual machine was just migrated over to another host. Today this happens via switch-host, which is a simple message asking the spice client to connect to the new host. We want move to seamless migration model where we don't start over from scratch, but hand over the session from the source to the target. Advantage is that various state cached in spice-client will stay valid and doesn't need to be retransmitted. It also requires a handshake between spice-servers on source and target. libvirt killing qemu on the source host before the handshake is done isn't exactly helpful. [ Side note: In theory this issue exists even today: in case the data pipe to the client is full spice-server will queue up the switch-host message and qemu might be killed before it is sent out. In practice it doesn't happen though because it goes through the low-traffic main channel so the socket buffers usually have enougth space. ] So, the big question is how to tackle the issue? Option (1): Wait until spice-server is done before signaling completion to libvirt.
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/06/2012 04:59 PM, Avi Kivity wrote:
On 06/06/2012 11:45 AM, Anthony Liguori wrote:
Ok. But then the backend pointer is not 'const Backend * const', it's
'Backend * const' (if we don't allow retargeting). So we can't say it's
_immutable (and it isn't). It's _host.
'Backend * const' is immutable
That is, the *pointer* is immutable. What it points to is not.
So, is it reasonable to say
uint32_t * _immutable irrp; // Interrupt Request Register
and allocate it on the heap during initialization?
No, this would be wrong.
'_immutable' means that the *state* is immutable from the guests point of view.
The state stored by:
struct MyDevice {
Backend _immutable *backend;
}
Is the *reference* to the backend. The state of the backend is not part of the
device's state structure. Only the *reference* to the backend is part of the
device's state and that's immutable.
Contrast this to:
struct MyDevice {
uint32_t *irrp;
}
Where iirp is stored on the heap. While the state is on the heap, it is
effectively owned by the MyDevice structure. irrp is not a reference to another
object but just an indirect address of an extension of the device state.
If you think the syntax is confusing, then once you find a time machine, I'll
happily travel with you 40 years into the past and we can try to convince KR to
introduce a richer pointer syntax that allows for differentiating between
various use-cases of pointers.
If you want to '#define _host _immutable' as a way to improve
readability, I'm not against that. But from a conceptional perspective,
we don't migrate it because nothing the guest does changes it. It's
immutable from the guests PoV.
It's not only immutable from the guest point of view, it's unreadable as
well. That's what _host means -- it doesn't exist as far as the guest
is concerned. IMO that's different than immutable.
This isn't true. Block device backends are absolutely readable within the
guest. But for live migration, they don't change because we assume shared
storage. Therefore it's immutable :-)
Regards,
Anthony Liguori
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
On 06/06/2012 05:10 PM, Yonit Halperin wrote: Hi, I would like to add some more points to Gerd's explanation: On 06/05/2012 04:15 PM, Gerd Hoffmann wrote: Hi, Absolutely not. This is hideously ugly and affects a bunch of code. Spice is *not* getting a hook in migration where it gets to add arbitrary amounts of downtime to the migration traffic. That's a terrible idea. I'd like to be more constructive in my response, but you aren't explaining the problem well enough for me to offer an alternative solution. You need to find another way to solve this problem. Actually, this is not the first time we address you with this issues. For example: http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg01805.html (The first part of the above discussion is not directly related to the current one). I'll try to explain in more details: As Gerd mentioned, migrating the spice connection smoothly requires the src server to keep running and send/receive data to/from the client, after migration has already completed, till the client completely transfers to the target. The suggested patch series only delays the migration state change from ACTIVE to COMPLETED/ERROR/CANCELED, till spice signals it has completed its part in migration. As I see it, if spice connection does exists, its migration should be treated as a non separate part of the whole migration process, and thus, the migration state shouldn't change from ACTIVE, till spice has completed its part. Hence, I don't think we should have a qmp event for signaling libvirt about spice migration. Spice client migration has nothing to do with guest migration. Trying to abuse QEMU to support it is not acceptable. The second challenge we are facing, which I addressed in the plans part of the cover-letter, and on which I think you (anthony) actually replied, is how to tackle migrating spice data from the src server to the target server. Such data can be usb/smartcard packets sent from a device connected on the client, to the server, and that haven't reached the device. Or partial data that has been read from a guest character device and that haven't been sent to the client. Other data can be internal server-client state data we would wish to keep on the server in order to avoid establishing the connection to the target from scratch, and possibly also suffer from a slower responsiveness at start. In the cover-letter I suggested to transfer spice migration data via the vmstate infrastructure. The other alternative which we also discussed in the link above, is to transfer the data via the client. The latter also requires holding the src process alive after migration completion, in order to manage to complete transferring the data from the src to the client. -- To summarize, since we can still use the client to transfer data from the src to the target (instead of using vmstate), the major requirement of spice, is to keep the src running after migration has completed. So send a QMP event and call it a day. Regards, Anthony Liguori Yonit. Very short version: The requirement is simply to not kill qemu on the source side until the source spice-server has finished session handover to the target spice-server. Long version: spice-client connects automatically to the target machine, so the user ideally doesn't notice that his virtual machine was just migrated over to another host. Today this happens via switch-host, which is a simple message asking the spice client to connect to the new host. We want move to seamless migration model where we don't start over from scratch, but hand over the session from the source to the target. Advantage is that various state cached in spice-client will stay valid and doesn't need to be retransmitted. It also requires a handshake between spice-servers on source and target. libvirt killing qemu on the source host before the handshake is done isn't exactly helpful. [ Side note: In theory this issue exists even today: in case the data pipe to the client is full spice-server will queue up the switch-host message and qemu might be killed before it is sent out. In practice it doesn't happen though because it goes through the low-traffic main channel so the socket buffers usually have enougth space. ] So, the big question is how to tackle the issue? Option (1): Wait until spice-server is done before signaling completion to libvirt. This is what this patch series implements. Advantage is that it is completely transparent for libvirt, thats why I like it. Disadvantage is that it indeed adds a small delay for the spice-server handshake. The target qemu doesn't process main loop events while the incoming migration is running, and because of that the spice-server handshake doesn't run in parallel with the final stage of vm migration, which it could in theory. BTW: There will be no arbitrary amounts of downtime. Seamless spice client migration is pretty pointless if it doesn't finish within a fraction of a second, so we can go
Re: [Qemu-devel] [PATCH v2 00/25] per-directory Makefile.objs snippets, limit vpath (ab)use
On 06/06/2012 02:36 PM, Paolo Bonzini wrote: Here is v2 of the nested Makefile patches. Thanks all for the enthusiasm! The main change is that rules can now be put in the per-directory snippets. This is done for op_helper.o already. Paolo v1-v2: do not call nested files Makefile (Andreas) do not create directories at configure time (Anthony) allow per-snippet rules, use it for op_helper.o (Blue Swirl) whitespace fixes (Blue Swirl) fix Xen (myself) FWIW, with my patch, this seems to pass my basic sniff testing. I'll try to apply a v3 quickly once you send it out. Regards, Anthony Liguori Paolo Bonzini (25): build: remove trace-nested-y build: do not sprinkle around GENERATED_HEADERS dependencies build: add rules for nesting build: move *-user/ objects to nested Makefile.objs build: move obj-TARGET-y variables to nested Makefile.objs build: move libobj-y variable to nested Makefile.objs build: move other target-*/ objects to nested Makefile.objs build: move rules for nesting to Makefile.objs build: put qom/ rules in a Makefile.objs file build: move block/ objects to nested Makefile.objs build: move net/ objects to nested Makefile.objs build: move fsdev/ objects to nested Makefile.objs build: move ui/ objects to nested Makefile.objs build: move audio/ objects to nested Makefile.objs build: move slirp/ objects to nested Makefile.objs build: move qapi/ objects to nested Makefile.objs build: move qga/ objects to nested Makefile.objs build: move target-independent hw/ objects to nested Makefile.objs build: convert libhw to nested Makefile.objs build: move per-target hw/ objects to nested Makefile.objs build: move device tree to per-target Makefile build: libcacard Makefile cleanups build: limit usage of vpath build: compile oslib-obj-y once build: do not create directories at configure time Makefile | 32 ++- Makefile.hw |7 +- Makefile.objs| 317 Makefile.target | 333 -- audio/Makefile.objs | 14 ++ block/Makefile.objs | 11 + bsd-user/Makefile.objs |2 + configure| 55 ++--- fsdev/Makefile.objs |9 + hw/9pfs/Makefile.objs|9 + hw/Makefile.objs | 165 + hw/alpha/Makefile.objs |4 + hw/arm/Makefile.objs | 40 hw/cris/Makefile.objs| 13 + hw/i386/Makefile.objs| 13 + hw/ide/Makefile.objs | 10 + hw/lm32/Makefile.objs| 23 ++ hw/m68k/Makefile.objs|4 + hw/microblaze/Makefile.objs | 14 ++ hw/mips/Makefile.objs|6 + hw/ppc/Makefile.objs | 32 +++ hw/s390x/Makefile.objs |3 + hw/sh4/Makefile.objs |5 + hw/sparc/Makefile.objs |8 + hw/sparc64/Makefile.objs |4 + hw/usb/Makefile.objs | 13 + hw/xtensa/Makefile.objs |5 + libcacard/Makefile | 17 +- linux-user/Makefile.objs |7 + linux-user/arm/nwfpe/Makefile.objs |2 + net/Makefile.objs| 12 + qapi/Makefile.objs |3 + qga/Makefile.objs|3 + qom/Makefile |2 - qom/Makefile.objs|4 + rules.mak| 40 slirp/Makefile.objs |3 + target-alpha/Makefile.objs |3 + target-arm/Makefile.objs |6 + arm-semi.c = target-arm/arm-semi.c |0 target-cris/Makefile.objs|4 + target-i386/Makefile.objs|7 + ioport-user.c = target-i386/ioport-user.c |0 target-lm32/Makefile.objs|4 + target-m68k/Makefile.objs|5 + m68k-semi.c = target-m68k/m68k-semi.c |0 target-microblaze/Makefile.objs |4 + target-mips/Makefile.objs|4 + target-ppc/Makefile.objs |6 + target-s390x/Makefile.objs |5 + target-sh4/Makefile.objs |4 + target-sparc/Makefile.objs |8 + target-unicore32/Makefile.objs |4 +
Re: [Qemu-devel] [PATCH] configure: fix -enable-debug with newer toolchains
On 6 June 2012 10:03, Avi Kivity a...@redhat.com wrote: Fedora 17's toolchain wants optimization enabled for _FORTIFY_SOURCE; so disable _FORTIFY_SOURCE when debugging. Well, that sucks, but it seems to be a deliberate change in upstream glibc to make it warn now :-( I guess everybody in the world will have to fix their makefiles... Signed-off-by: Avi Kivity a...@redhat.com --- configure | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/configure b/configure index 1f338f8..88d9c5b 100755 --- a/configure +++ b/configure @@ -255,7 +255,6 @@ QEMU_CFLAGS=-fno-strict-aliasing $QEMU_CFLAGS QEMU_CFLAGS=-Wall -Wundef -Wwrite-strings -Wmissing-prototypes $QEMU_CFLAGS QEMU_CFLAGS=-Wstrict-prototypes -Wredundant-decls $QEMU_CFLAGS QEMU_CFLAGS=-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE $QEMU_CFLAGS -QEMU_CFLAGS=-D_FORTIFY_SOURCE=2 $QEMU_CFLAGS QEMU_INCLUDES=-I. -I\$(SRC_PATH) -I\$(SRC_PATH)/fpu if test $debug_info = yes; then CFLAGS=-g $CFLAGS @@ -2851,7 +2850,7 @@ fi # After here, no more $cc or $ld runs if test $debug = no ; then - CFLAGS=-O2 $CFLAGS + CFLAGS=-O2 -D_FORTIFY_SOURCE=2 $CFLAGS fi It feels a bit odd to have the FORTIFY_SOURCE define in CFLAGS rather than QEMU_CFLAGS, but I think it should behave correctly so I think it's right. -- PMM
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/06/2012 12:17 PM, Anthony Liguori wrote:
So, is it reasonable to say
uint32_t * _immutable irrp; // Interrupt Request Register
and allocate it on the heap during initialization?
No, this would be wrong.
'_immutable' means that the *state* is immutable from the guests point
of view. The state stored by:
struct MyDevice {
Backend _immutable *backend;
}
Is the *reference* to the backend. The state of the backend is not part
of the device's state structure. Only the *reference* to the backend is
part of the device's state and that's immutable.
I think this has degenerated into a disagreement about naming. Yet I
think this is important. I don't think _immutable suggests immutable
from the guest's point of view or even we assume shared storage [1],
therefore it's immutable to a device model author or reviewer. I think
we should choose the names under the assumption that the author did not
read the documentation (why bother when you can copy paste another
device model implementation) or read it and immediately forgot it. This
goes double for the reviewer(s). We need to make this as unsubtle as
possible (but no unsubtler).
If you think the syntax is confusing, then once you find a time machine,
I'll happily travel with you 40 years into the past and we can try to
convince KR to introduce a richer pointer syntax that allows for
differentiating between various use-cases of pointers.
A go port of qemu would be interesting.
[1] we can also live migrate storage; the real reason it doesn't need
serialization is that it falls under the by other means category.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] kernel panic with bridge
On Wed, Jun 6, 2012 at 4:38 AM, Charles.Tsai-蔡清海-研究發展部 charles.t...@cloudena.com wrote: We hit a kernel panic when a VM was configured with bridge mode. After the IpTable was disabled using the following command lines, the kernel panic was gone. We would like to know if there is any fix in latest kernel for this issue? Note that we ran qemu 1.0 on Ubuntu 11.10 Please send distro bugs to the distro's bug tracker (launchpad.net for Ubuntu) and try to include enough information so that maintainers or developers can help you. You did not include the exact kernel package version or the kernel panic output. There's no need to reply with that information to this thread because this report really need to be against the Ubuntu kernel package in launchpad.net. Stefan
Re: [Qemu-devel] Any approach to log the file read/write (I/O data flow) like the -d in_asm option?
On Sun, Jun 3, 2012 at 9:50 PM, Yue Chen ycyc...@gmail.com wrote: I'm doing something like a simple and lightweight REPLAY program out of QEMU, only including CPU, MEMORY, and DISK. I'm implementing it with a shadow CPU (register state), shadow memory(from pmemsave) and shadow .img file (disk). Why doesn't the savevm command provide the snapshotting you need? It sounds like you're trying to do VM snapshots yourself. Stefan
Re: [Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets
On 2012-06-06 10:41, Avi Kivity wrote: On 06/05/2012 10:03 PM, Jan Kiszka wrote: A type definition and a KVMState field initialization escaped the required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a dummy kvm_irqchip_release_virq as virtio-pci references (but does not use) it. Thanks, applied. Please send a pull soon. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH block-next 0/3] qemu-img check/qcow2: Allow fixing refcounts
On Fri, Jun 1, 2012 at 9:26 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Jun 1, 2012 at 4:06 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Jun 1, 2012 at 6:22 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Thu, May 31, 2012 at 5:26 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Wed, May 30, 2012 at 9:31 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Sat, May 12, 2012 at 12:48 AM, Kevin Wolf kw...@redhat.com wrote: A prerequisite for a QED mode in qcow2, which doesn't update the refcount Recently some new concepts such as QED mode in qcow2 are seen frequencely, can anyone explain what it means? thanks. qcow2 has more metadata than qed. More metadata means more write operations when allocating new clusters. In order to overcome this performance issue qcow2 has a metadata cache. But when QEMU is launched with -drive ...,cache=writethrough (the default) the metadata cache *must* be in writethrough mode Why must i be? If the option with -drive ..,cache=writethrough is specified. it means that host page cache is on while guest disk cache is off. Since the metadata cache exists in host page cache, not guest, i think that it is in writeback mode. Since the emulated disk write cache is off, we must ensure that guest writes are on disk before completing them. Therefore we cannot cache metadata updates in host RAM - it would be lost on power failure but But host page cache is *on* in this mode, which means that metadata should be cached in host RAM. how do you explain this? cache=writethrough means that the file is opened with O_SYNC. Every single write reaches the physical disk - that's why it's called a writethrough cache. Read requests, however, can be satisfied from the host page cache. In other words, cache=writethrough ensures that all data reaches the disk but may give performance benefits to read-heavy workloads (especially when guest RAM is much smaller than host RAM, so the host page cache would have a high hit rate). we promised the guest its writes reached the disk! instead of writeback mode. In other words, every metadata update needs to be written to the image file before we complete the guest's What will mean one guest's wirte request is completed? For example, virtio-blk fills in the success status code and raises an interrupt. This notifies the guest that the write is done. Great, thanks. write request. This means the metadata cache only hides the metadata performance issue when -drive ...,cache=direct|writeback are used because there we can keep metadata changes buffered in memory until the guest flushes the emulated disk write cache. QED mode is a solution for -drive ...,cache=writethrough|directsync. It simply doesn't update refcount metadata in the qcow2 image file l1/l2 info need to be updated to qcow2 image file? Yes, this is necessary to ensure written data is accessible in the future. Without the L1/L2 tables we cannot find the data we wrote. Stefan
Re: [Qemu-devel] [PATCH v2] fdc: fix media change detection for windows
Am 05.06.2012 18:34, schrieb Pavel Hrdina:
On 06/05/2012 05:56 PM, Kevin Wolf wrote:
Am 05.06.2012 17:50, schrieb Pavel Hrdina:
Sorry, I forget the qtest. I'll create it and send it again.
Pavel
On 06/05/2012 05:46 PM, Pavel Hrdina wrote:
The Windows uses 'READ' command at the start of an instalation
without checking the 'dir' register. We have to abort the transfer
with an abnormal termination if there is no media in the drive.
We have to also check the 'media_change' bit in the 'fd_seek'. This
internal seek clears the 'media_change' bit, too, if there is
a media inserted.
Signed-off-by: Pavel Hrdinaphrd...@redhat.com
---
hw/fdc.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/hw/fdc.c b/hw/fdc.c
index 30d34e3..2d6dd30 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -127,8 +127,13 @@ static int fd_seek(FDrive *drv, uint8_t head, uint8_t
track, uint8_t sect,
uint32_t sector;
int ret;
+if (drv-bs != NULL bdrv_is_inserted(drv-bs)) {
+drv-media_changed = 0;
+}
+
if (track drv-max_track ||
-(head != 0 (drv-flags FDISK_DBL_SIDES) == 0)) {
+(head != 0 (drv-flags FDISK_DBL_SIDES) == 0) ||
+drv-media_changed) {
Why not directly use bdrv_is_inserted() here?
Fiddling around with media_changed feels rather hacky and is strictly
speaking incorrect because a step pulse is not guaranteed to happen in
the following code. The floppy code doesn't get it quite right today
anyway, but a hack like this would contribute to the problem.
FLOPPY_DPRINTF(try to read %d %02x %02x (max=%d %d %02x
%02x)\n,
head, track, sect, 1,
(drv-flags FDISK_DBL_SIDES) == 0 ? 0 : 1,
Kevin
I'll move the code into the end of 'fd_seek' function, where a step is
guaranteed. Internal seek should also reset the 'media_changed' bit if
there is a media in the drive. I'll create the qtest tomorrow then I'll
send another version of this patch.
My point is that the success of a seek has nothing to do with the DSKCHG
signal. Even if you move the code around, DSKCHG may start to coincide
with the condition you really want to check, but it's logically still
not what should be checked. What's wrong with !bdrv_is_inserted() in the
if condition?
If something is wrong with the media_changed handling, then it's a
separate bug that should be dealt with in a separate patch.
Kevin
Re: [Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets
On 06/06/2012 01:31 PM, Jan Kiszka wrote: On 2012-06-06 10:41, Avi Kivity wrote: On 06/05/2012 10:03 PM, Jan Kiszka wrote: A type definition and a KVMState field initialization escaped the required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a dummy kvm_irqchip_release_virq as virtio-pci references (but does not use) it. Thanks, applied. Please send a pull soon. It was posted already, I just forgot to copy you. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [BUG QEMU 1.1] virtio-9p-handle does not compile
Hi Anthony,
currently QEMU 1.1 doesn't compile virtfs correctly on Ubuntu:
qemu/hw/9pfs/virtio-9p-handle.c: In function ‘handle_update_file_cred’:
qemu/hw/9pfs/virtio-9p-handle.c:66:58: error: ‘AT_EMPTY_PATH’ undeclared (first
use in this function)
qemu/hw/9pfs/virtio-9p-handle.c:66:58: note: each undeclared identifier is
reported only once for each function it appears in
qemu/hw/9pfs/virtio-9p-handle.c: In function ‘handle_lstat’:
qemu/hw/9pfs/virtio-9p-handle.c:87:34: error: ‘AT_EMPTY_PATH’ undeclared (first
use in this function)
qemu/hw/9pfs/virtio-9p-handle.c: In function ‘handle_symlink’:
qemu/hw/9pfs/virtio-9p-handle.c:314:62: error: ‘AT_EMPTY_PATH’ undeclared
(first use in this function)
qemu/hw/9pfs/virtio-9p-handle.c: In function ‘handle_link’:
qemu/hw/9pfs/virtio-9p-handle.c:337:45: error: ‘AT_EMPTY_PATH’ undeclared
(first use in this function)
qemu/hw/9pfs/virtio-9p-handle.c: In function ‘handle_chown’:
qemu/hw/9pfs/virtio-9p-handle.c:373:58: error: ‘AT_EMPTY_PATH’ undeclared
(first use in this function)
a patch was sent on the 24th of Feb to fix the issue (also see below):
http://marc.info/?l=qemu-develm=133011313912147
Even though it is not particularly pretty, in the absence of better
alternatives it should probably be applied.
Cheers,
Stefano
On Fri, 24 Feb 2012, Serge Hallyn wrote:
If AT_EMPTY_PATH is not in one of the included files, go ahead and
define it. qemu won't compile on ubuntu for me without this.
(Note - alternatively we could #include linux/fcntl.h to pick
up the definitions there)
Signed-off-by: Serge Hallyn serge.hal...@canonical.com
---
hw/9pfs/virtio-9p-handle.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
index f96d17a..e403a84 100644
--- a/hw/9pfs/virtio-9p-handle.c
+++ b/hw/9pfs/virtio-9p-handle.c
@@ -39,6 +39,15 @@
#ifndef BTRFS_SUPER_MAGIC
#define BTRFS_SUPER_MAGIC 0x9123683E
#endif
+#ifndef AT_REMOVEDIR
+#define AT_REMOVEDIR0x200
+#endif
+#ifndef AT_EMPTY_PATH
+#define AT_EMPTY_PATH 0x1000 /* Allow empty relative pathname */
+#endif
+#ifndef O_PATH
+#define O_PATH01000
+#endif
struct handle_data {
int mountfd;
--
1.7.9
Re: [Qemu-devel] [PATCH 0/2] scsi: Clean up BlockDriverState use
Am 05.06.2012 23:32, schrieb Paolo Bonzini: Il 05/06/2012 16:49, Markus Armbruster ha scritto: With this and the related fix for xen applied, block_int.h is finally gone from hw/. Markus Armbruster (2): block: New bdrv_get_flags() scsi-disk: Don't peek behind the BlockDriverState abstraction block.c|5 + block.h|1 + hw/scsi-disk.c |3 +-- 3 files changed, 7 insertions(+), 2 deletions(-) Acked-by: Paolo Bonzini pbonz...@redhat.com Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
On Wed, Jun 06, 2012 at 05:22:21PM +0800, Anthony Liguori wrote: On 06/06/2012 05:10 PM, Yonit Halperin wrote: Hi, I would like to add some more points to Gerd's explanation: On 06/05/2012 04:15 PM, Gerd Hoffmann wrote: Hi, Absolutely not. This is hideously ugly and affects a bunch of code. Spice is *not* getting a hook in migration where it gets to add arbitrary amounts of downtime to the migration traffic. That's a terrible idea. I'd like to be more constructive in my response, but you aren't explaining the problem well enough for me to offer an alternative solution. You need to find another way to solve this problem. Actually, this is not the first time we address you with this issues. For example: http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg01805.html (The first part of the above discussion is not directly related to the current one). I'll try to explain in more details: As Gerd mentioned, migrating the spice connection smoothly requires the src server to keep running and send/receive data to/from the client, after migration has already completed, till the client completely transfers to the target. The suggested patch series only delays the migration state change from ACTIVE to COMPLETED/ERROR/CANCELED, till spice signals it has completed its part in migration. As I see it, if spice connection does exists, its migration should be treated as a non separate part of the whole migration process, and thus, the migration state shouldn't change from ACTIVE, till spice has completed its part. Hence, I don't think we should have a qmp event for signaling libvirt about spice migration. Spice client migration has nothing to do with guest migration. Trying to I don't understand this POV. If it were a VNC connection instead of a Spice one would it make a difference? If there is an active VNC client then it is there as a result of a user choosing to use it, so it should be treated as part of the user experience and not as something external. The experience from ignoring this and choosing to treat the remote console as an unrelated part is bound to be suboptimal. abuse QEMU to support it is not acceptable. The second challenge we are facing, which I addressed in the plans part of the cover-letter, and on which I think you (anthony) actually replied, is how to tackle migrating spice data from the src server to the target server. Such data can be usb/smartcard packets sent from a device connected on the client, to the server, and that haven't reached the device. Or partial data that has been read from a guest character device and that haven't been sent to the client. Other data can be internal server-client state data we would wish to keep on the server in order to avoid establishing the connection to the target from scratch, and possibly also suffer from a slower responsiveness at start. In the cover-letter I suggested to transfer spice migration data via the vmstate infrastructure. The other alternative which we also discussed in the link above, is to transfer the data via the client. The latter also requires holding the src process alive after migration completion, in order to manage to complete transferring the data from the src to the client. -- To summarize, since we can still use the client to transfer data from the src to the target (instead of using vmstate), the major requirement of spice, is to keep the src running after migration has completed. So send a QMP event and call it a day. Regards, Anthony Liguori Yonit. Very short version: The requirement is simply to not kill qemu on the source side until the source spice-server has finished session handover to the target spice-server. Long version: spice-client connects automatically to the target machine, so the user ideally doesn't notice that his virtual machine was just migrated over to another host. Today this happens via switch-host, which is a simple message asking the spice client to connect to the new host. We want move to seamless migration model where we don't start over from scratch, but hand over the session from the source to the target. Advantage is that various state cached in spice-client will stay valid and doesn't need to be retransmitted. It also requires a handshake between spice-servers on source and target. libvirt killing qemu on the source host before the handshake is done isn't exactly helpful. [ Side note: In theory this issue exists even today: in case the data pipe to the client is full spice-server will queue up the switch-host message and qemu might be killed before it is sent out. In practice it doesn't happen though because it goes through the low-traffic main channel so the socket buffers usually have enougth space. ] So, the big question is how to tackle the issue? Option (1): Wait until spice-server is done before signaling completion to libvirt. This is what this
[Qemu-devel] [Bug 1007269] Re: Can’t install or boot up 32bit win8 guest.
Try varying the CPU type (-cpu ...). Some work for me here, others don't. Likely some subtle bug(s) in the definitions. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1007269 Title: Can’t install or boot up 32bit win8 guest. Status in QEMU: New Bug description: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux(rhel6u1) kvm.git Commit:51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 qemu-kvm Commit:3fd9fedb9fae4517d93d76e93a2924559cacf2f6 Host Kernel Version:3.4.0-rc7 Hardware:WSM-EP,Romley-EP Bug detailed description: -- it can't install or boot up 32bit Win8(Consumer Preview Update 2) guest. The guest will crash with the following error, while 64bit Win8 and 32bit Win7 guest work fine. -Win8 Error--- Your computer needs to restart. Please hold down the power button. Error code: 0x005D Parameters: 0x03060D03 0x756E6547 0x49656E69 0x6C65746E -Win8 Error--- 0x005D code means UNSUPPORTED_PROCESSOR in Windows. BTW, you can get 32bit Win8 ISO from the following website. http://windows.microsoft.com/en-US/windows-8/iso Reproduce steps: 1. get 32 bit win8 ISO 2. prepare a disk image: dd if=/dev/zero of=/root/win8-32.img bs=1M count=16384 3. start a guest to install 32bit win8: qemu-system –m 4096 –smp 4 –hda /root/win8-32.img –cdrom /media/32bit-Win8.iso 4. if you have a 32bit win8 image,try to boot it up Current result: 32bit Win8 guest crash Expected result: 32bit win8 guest boot up correctly To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1007269/+subscriptions
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
On 06/06/2012 06:54 PM, Alon Levy wrote: On Wed, Jun 06, 2012 at 05:22:21PM +0800, Anthony Liguori wrote: On 06/06/2012 05:10 PM, Yonit Halperin wrote: Spice client migration has nothing to do with guest migration. Trying to I don't understand this POV. If it were a VNC connection instead of a Spice one would it make a difference? Of course, I would say yes if it was VNC. Because the only possibly way I could disagree with something Spice related is because I'm biased against it. Give me the benefit of the doubt at least. More importantly, try to stop and think about what I'm saying before you assume the anti-Spice brigade is coming in to rain on your parade. If there is an active VNC client then it is there as a result of a user choosing to use it, so it should be treated as part of the user experience and not as something external. The experience from ignoring this and choosing to treat the remote console as an unrelated part is bound to be suboptimal. Guest migration affects correctness! If the Spice client is slow (even due to network lag) in responding to your flush message, you will disrupt the guest and potentially drop network connections and/or cause lockup detectors to trigger. Migrating the Spice client is a UI feature. It has absolutely no affect no the workloads that are running in the guest. Impacting migration *correctness* in order to support a UI feature is unacceptable especially when there are ways to achieve the same results without having any impact on correctness. We have had a simple rule with migration in QEMU. Nothing gets to impact downtime with migration. No device gets magic hooks or anything like that. Go read the TPM threads if you want to see another example of this. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v2] kvm: Fix build for non-CAP_IRQ_ROUTING targets
On 06/06/2012 06:44 PM, Avi Kivity wrote: On 06/06/2012 01:31 PM, Jan Kiszka wrote: On 2012-06-06 10:41, Avi Kivity wrote: On 06/05/2012 10:03 PM, Jan Kiszka wrote: A type definition and a KVMState field initialization escaped the required wrapping with KVM_CAP_IRQ_ROUTING. Also, we need to provide a dummy kvm_irqchip_release_virq as virtio-pci references (but does not use) it. Thanks, applied. Please send a pull soon. It was posted already, I just forgot to copy you. It's being tested as we type too. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 04/16] qapi: introduce OptsVisitor
Thank you very much for the review! One question below (and maybe some more later in response to other parts of the review): On 06/05/12 23:12, Paolo Bonzini wrote: Il 22/05/2012 12:45, Laszlo Ersek ha scritto: Optarg values can be of scalar types str / bool / int / size. Michael Roth recently added Visitor interfaces for uint*_t and int*_t, they look like they would simplify the patches very nicely. They do the range checking automatically and only need a type_int callback in the visitor. You can get the patch from http://patchwork.ozlabs.org/patch/150427/, feel free to include it at the beginning of your series. The unsigned functions don't check if the int64_t value to be assigned is negative. What happens in such a case is fully defined, but did Michael really intend the wraparound to unsigned? I thought it was a silent requirement for the int parser to return a non-negative int (which is something I also implemented in opts_type_int() [*]), but the signed visit_type_XXX() functions do check for the negative limit. I'm confused. [*] see the comment in opts-visitor.h: /* Contrarily to qemu-option.c::parse_option_number(), OptsVisitor's int * parser relies on strtoll() instead of strtoull(). Consequences: * - string representations of negative numbers are rejected (parsed values * continue to be non-negative), * - values above INT64_MAX or LLONG_MAX are rejected. */ That's also why I dropped/omitted the 0 checks in net_init_nic() [v1 09/16], net_init_dump() [v1 10/16] and net_init_vde() [v1 13/16]. If you want I can go through all the integer fields I introduced in [v1 06/16] qapi schema: add Netdev types and classify each as strictly as possible (and then remove the checks being obviated). Thanks! Laszlo
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/06/2012 05:58 PM, Avi Kivity wrote:
On 06/06/2012 12:17 PM, Anthony Liguori wrote:
So, is it reasonable to say
uint32_t * _immutable irrp; // Interrupt Request Register
and allocate it on the heap during initialization?
No, this would be wrong.
'_immutable' means that the *state* is immutable from the guests point
of view. The state stored by:
struct MyDevice {
Backend _immutable *backend;
}
Is the *reference* to the backend. The state of the backend is not part
of the device's state structure. Only the *reference* to the backend is
part of the device's state and that's immutable.
I think this has degenerated into a disagreement about naming. Yet I
think this is important. I don't think _immutable suggests immutable
from the guest's point of view or even we assume shared storage [1],
therefore it's immutable to a device model author or reviewer. I think
we should choose the names under the assumption that the author did not
read the documentation (why bother when you can copy paste another
device model implementation) or read it and immediately forgot it. This
goes double for the reviewer(s). We need to make this as unsubtle as
possible (but no unsubtler).
Okay, we're talking past each other then.
I'm not really taking a position on the best naming convention to use for these
things. This is too early of a patch series. Whether we should have multiple
variants of '_immutable' that make it easier for reviewers is something that I'm
100% open too.
But I think it's important to have a strong conceptional model. So far, it's
built on the following:
All device state is serialized unless:
a) It's derived from other state
b) It's immutable (from the guest PoV)
c) We should migrate it but don't know and don't immediately want to change
that
If we want to subdivide (b) into a set of more specific things, that's perfectly
fine by me. But I'm reluctant to just add a (d) it's host state because it
breaks my mental model.
If you think the syntax is confusing, then once you find a time machine,
I'll happily travel with you 40 years into the past and we can try to
convince KR to introduce a richer pointer syntax that allows for
differentiating between various use-cases of pointers.
A go port of qemu would be interesting.
Perhaps in 10 years. I think go is a little too immature right now. Submit
your talks now for KVM Forum 2022 ;-)
Regards,
Anthony Liguori
[1] we can also live migrate storage; the real reason it doesn't need
serialization is that it falls under the by other means category.
Re: [Qemu-devel] [PATCH 01/17] qidl: add QEMU IDL processor
On 06/06/2012 02:12 PM, Anthony Liguori wrote:
On 06/06/2012 05:58 PM, Avi Kivity wrote:
On 06/06/2012 12:17 PM, Anthony Liguori wrote:
So, is it reasonable to say
uint32_t * _immutable irrp; // Interrupt Request Register
and allocate it on the heap during initialization?
No, this would be wrong.
'_immutable' means that the *state* is immutable from the guests point
of view. The state stored by:
struct MyDevice {
Backend _immutable *backend;
}
Is the *reference* to the backend. The state of the backend is not part
of the device's state structure. Only the *reference* to the backend is
part of the device's state and that's immutable.
I think this has degenerated into a disagreement about naming. Yet I
think this is important. I don't think _immutable suggests immutable
from the guest's point of view or even we assume shared storage [1],
therefore it's immutable to a device model author or reviewer. I think
we should choose the names under the assumption that the author did not
read the documentation (why bother when you can copy paste another
device model implementation) or read it and immediately forgot it. This
goes double for the reviewer(s). We need to make this as unsubtle as
possible (but no unsubtler).
Okay, we're talking past each other then.
I'm not really taking a position on the best naming convention to use
for these things. This is too early of a patch series. Whether we
should have multiple variants of '_immutable' that make it easier for
reviewers is something that I'm 100% open too.
But I think it's important to have a strong conceptional model. So far,
it's built on the following:
All device state is serialized unless:
a) It's derived from other state
b) It's immutable (from the guest PoV)
I'm harping again on naming, but using _immutable to mean
_immutable_from_the_guest_point_of_view is confusing. _immutable means
_immutable. I don't think people will be able to answer is this
immutable from a guest point of view easily.
c) We should migrate it but don't know and don't immediately want to
change that
d) the RAM migration code takes care of migrating it
e) the block layer takes care of migrating it
If we want to subdivide (b) into a set of more specific things, that's
perfectly fine by me. But I'm reluctant to just add a (d) it's host
state because it breaks my mental model.
Suppose you save/restore a guest that is connected to a host cdrom. The
cdrom tray state (and indeed the cdrom data) should not be
save/restored, because you want the real (host) data to be used after
restore. The same is true for a serial device that is connected to a
host serial device and reads line state from it.
If you think the syntax is confusing, then once you find a time machine,
I'll happily travel with you 40 years into the past and we can try to
convince KR to introduce a richer pointer syntax that allows for
differentiating between various use-cases of pointers.
A go port of qemu would be interesting.
Perhaps in 10 years. I think go is a little too immature right now.
Submit your talks now for KVM Forum 2022 ;-)
In 10 years go would be old and crusty and I'd be drumming for the hot
new language of the day.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
On Wed, Jun 06, 2012 at 07:05:44PM +0800, Anthony Liguori wrote: On 06/06/2012 06:54 PM, Alon Levy wrote: On Wed, Jun 06, 2012 at 05:22:21PM +0800, Anthony Liguori wrote: On 06/06/2012 05:10 PM, Yonit Halperin wrote: Spice client migration has nothing to do with guest migration. Trying to I don't understand this POV. If it were a VNC connection instead of a Spice one would it make a difference? Of course, I would say yes if it was VNC. Because the only possibly way I could disagree with something Spice related is because I'm biased against it. Give me the benefit of the doubt at least. More importantly, try to stop and think about what I'm saying before you assume the anti-Spice brigade is coming in to rain on your parade. I stand corrected. If there is an active VNC client then it is there as a result of a user choosing to use it, so it should be treated as part of the user experience and not as something external. The experience from ignoring this and choosing to treat the remote console as an unrelated part is bound to be suboptimal. Guest migration affects correctness! If the Spice client is slow (even due to network lag) in responding to your flush message, you will disrupt the guest and potentially drop network connections and/or cause lockup detectors to trigger. OK, you think any timeout here would be too large. Migrating the Spice client is a UI feature. It has absolutely no affect no the workloads that are running in the guest. Impacting migration *correctness* in order to support a UI feature is unacceptable especially when there are ways to achieve the same results without having any impact on correctness. We have had a simple rule with migration in QEMU. Nothing gets to impact downtime with migration. No device gets magic hooks or anything like that. Go read the TPM threads if you want to see another example of this. OK. Regards, Anthony Liguori
Re: [Qemu-devel] The development tree is now open!
On 06/05/2012 04:19 PM, Jan Kiszka wrote: Note, I am holding off on the qemu-kvm-1.1 release pending investigation of the qcow2/ide bug that Yongjie Ren discovered. But if it's holding you off, I can branch 1.1 now and merge this early to master. I'm optimistic that the pull I sent yesterday should still merge cleanly into a master that contains some qcow2 or whatever fix. That wasn't the issue, rather if we branch now I have to work the fix into both trees. But I'll stop being lazy and pull. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 2/2] xen: Don't peek behind the BlockDriverState abstraction
Stefano Stabellini stefano.stabell...@eu.citrix.com writes:
On Tue, 5 Jun 2012, Markus Armbruster wrote:
First offender is xen_config_dev_blk()'s use of disk-bdrv-filename.
Get the filename from disk-opts instead. Same result, except for
snapshots: there, we now get the filename specified by the user
instead of the name of the temporary image created by bdrv_open().
Should be an improvement.
Second offender is blk_init()'s use of blkdev-bs-drv-format_name.
Simply use the appropriate interface to get the format name.
Signed-off-by: Markus Armbruster arm...@redhat.com
---
hw/xen_devconfig.c |6 +++---
hw/xen_disk.c |5 +++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/hw/xen_devconfig.c b/hw/xen_devconfig.c
index 7b7b0a2..0928613 100644
--- a/hw/xen_devconfig.c
+++ b/hw/xen_devconfig.c
@@ -1,6 +1,5 @@
#include xen_backend.h
#include blockdev.h
-#include block_int.h /* XXX */
/* - */
@@ -99,10 +98,11 @@ int xen_config_dev_blk(DriveInfo *disk)
int cdrom = disk-media_cd;
const char *devtype = cdrom ? cdrom : disk;
const char *mode= cdrom ? r : w;
+const char *filename = qemu_opt_get(disk-opts, file);
snprintf(device_name, sizeof(device_name), xvd%c, 'a' + disk-unit);
xen_be_printf(NULL, 1, config disk %d [%s]: %s\n,
- disk-unit, device_name, disk-bdrv-filename);
+ disk-unit, device_name, filename);
xen_config_dev_dirs(vbd, qdisk, vdev, fe, be, sizeof(fe));
/* frontend */
@@ -112,7 +112,7 @@ int xen_config_dev_blk(DriveInfo *disk)
/* backend */
xenstore_write_str(be, dev, device_name);
xenstore_write_str(be, type,file);
-xenstore_write_str(be, params, disk-bdrv-filename);
+xenstore_write_str(be, params, filename);
xenstore_write_str(be, mode,mode);
/* common stuff */
diff --git a/hw/xen_disk.c b/hw/xen_disk.c
index 07594bc..c73b71e 100644
--- a/hw/xen_disk.c
+++ b/hw/xen_disk.c
@@ -40,7 +40,6 @@
#include xen/io/xenbus.h
#include hw.h
-#include block_int.h
#include qemu-char.h
#include xen_blkif.h
#include xen_backend.h
@@ -554,6 +553,7 @@ static int blk_init(struct XenDevice *xendev)
{
struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev,
xendev);
int index, qflags, info = 0;
+char fmt_name[128];
/* read xenstore entries */
if (blkdev-params == NULL) {
@@ -634,9 +634,10 @@ static int blk_init(struct XenDevice *xendev)
blkdev-file_blk = BLOCK_SIZE;
blkdev-file_size = bdrv_getlength(blkdev-bs);
if (blkdev-file_size 0) {
+bdrv_get_format(blkdev-bs, fmt_name, sizeof(fmt_name));
xen_be_printf(blkdev-xendev, 1, bdrv_getlength: %d (%s) | drv
%s\n,
(int)blkdev-file_size, strerror(-blkdev-file_size),
- blkdev-bs-drv ? blkdev-bs-drv-format_name : -);
+ fmt_name[0] ? fmt_name : -);
blkdev-file_size = 0;
}
You might as well move fmt_name here because it is only used if
blkdev-file_size 0.
Matter of taste, and you're the maintainer. Want me to respin?
Apart from this minor nitpick, both patches are OK.
Thanks!
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
On 06/06/2012 07:27 PM, Alon Levy wrote: If there is an active VNC client then it is there as a result of a user choosing to use it, so it should be treated as part of the user experience and not as something external. The experience from ignoring this and choosing to treat the remote console as an unrelated part is bound to be suboptimal. Guest migration affects correctness! If the Spice client is slow (even due to network lag) in responding to your flush message, you will disrupt the guest and potentially drop network connections and/or cause lockup detectors to trigger. OK, you think any timeout here would be too large. What would it's value be? Migration is convergent and our downtime estimate is just that--an estimate. It's literally always a crap-shoot as to whether the actual migration will complete fast enough. What do you propose the timeout to be? 1us? Can you even do a round trip to a client in 1us? 50us? I still question whether a round trip is feasible in that time period and you've blown away the default 30us time anyway. Even 1us would be too much though. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 2/2] xen: Don't peek behind the BlockDriverState abstraction
On 5 June 2012 13:51, Markus Armbruster arm...@redhat.com wrote:
@@ -554,6 +553,7 @@ static int blk_init(struct XenDevice *xendev)
{
struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
int index, qflags, info = 0;
+ char fmt_name[128];
Fixed length array with a hardcoded magic number size ?
If the block layer guarantees that format names are going to be
less than 128 bytes it ought to provide a suitable #define for
people to set array sizes to...
-- PMM
Re: [Qemu-devel] [PATCH v2 25/25] build: do not create directories at configure time
From e0e6e5b689cbcb782bca8f158fad89b3389e9e11 Mon Sep 17 00:00:00 2001
From: Anthony Liguori aligu...@us.ibm.com
Date: Wed, 6 Jun 2012 16:57:00 +0800
Subject: [PATCH] configure: ensure directory exists when creating symlink
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
---
configure |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 07e3ff1..4a7f027 100755
--- a/configure
+++ b/configure
@@ -42,6 +42,7 @@ compile_prog() {
# symbolically link $1 to $2. Portable version of ln -sf.
symlink() {
rm -rf $2
+ mkdir -p `dirname $2`
Please leave the argument quoted, like
dir=`dirname $2`
mkdir -p $dir
Otherwise looks good. Do we need a v3? This can just be committed
before 25/25 or even before all my patches, and that would be just what
I send.
Paolo
ln -s $1 $2
}
@@ -3454,14 +3455,12 @@ if test -f ${config_host_ld}~ ; then
fi
for d in libdis libdis-user; do
-mkdir -p $d
symlink $source_path/Makefile.dis $d/Makefile
echo $d/config.mak
done
# use included Linux headers
if test $linux = yes ; then
- mkdir -p linux-headers
case $cpu in
i386|x86_64)
symlink $source_path/linux-headers/asm-x86 linux-headers/asm
-- 1.7.5.4
Re: [Qemu-devel] [PATCH v2 6/6] qapi: convert sendkey
On 06/06/2012 01:13 AM, Amos Kong wrote: Ho, I found another bug in my code, key in decimal or hexadecimal format is not supported. I will fix it. How do you plan to support decimal in QMP? In old do_sendkey(), only key-name and hexadecimal were supported, the description needs to be fixed. It seems we can only support key-name for QMP, and support key-name/hexadecimal for HMP. Is it acceptable? Yes, that was my argument for bare minimum support - anyone using QMP (like libvirt) will have to be smart enough to use key-name only, while anyone using HMP will be able to use hex because HMP will convert hex to key-name at the appropriate time before calling into QMP. Of course, being able to support hex from QMP would be a nice feature, but I'm not sure how to add it in. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 04/16] qapi: introduce OptsVisitor
Il 06/06/2012 13:12, Laszlo Ersek ha scritto: The unsigned functions don't check if the int64_t value to be assigned is negative. What happens in such a case is fully defined, but did Michael really intend the wraparound to unsigned? I think that's a bug. Please coordinate with Michael and Andreas (since the patch is currently lying in his tree) as to who fixes what. I thought it was a silent requirement for the int parser to return a non-negative int (which is something I also implemented in opts_type_int() [*]), but the signed visit_type_XXX() functions do check for the negative limit. I'm confused. It's not a requirement for the int parser, but I remember now: it was a requirement for the opts visitor, because qemu_opt_get_number returns uint64_t rather than int64_t. However, net_init_* shouldn't assume anything about their struct argument, so the check needs to be added there as if they weren't in the OptsVisitor. Unless you make the types stricter, of course. If you want I can go through all the integer fields I introduced in [v1 06/16] qapi schema: add Netdev types and classify each as strictly as possible (and then remove the checks being obviated). Yes, that would be very nice. Paolo
Re: [Qemu-devel] [PATCH v2 25/25] build: do not create directories at configure time
On 6 June 2012 12:54, Paolo Bonzini pbonz...@redhat.com wrote: From: Anthony Liguori aligu...@us.ibm.com + mkdir -p `dirname $2` Please leave the argument quoted, like dir=`dirname $2` (missing , obviously) mkdir -p $dir Can we use mkdir -p $(dirname $2) or are we still trying to be compatible with some non-POSIX shell from the dawn of time? -- PMM
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
On 06/06/2012 12:22 PM, Anthony Liguori wrote: On 06/06/2012 05:10 PM, Yonit Halperin wrote: Hi, I would like to add some more points to Gerd's explanation: On 06/05/2012 04:15 PM, Gerd Hoffmann wrote: Hi, Absolutely not. This is hideously ugly and affects a bunch of code. Spice is *not* getting a hook in migration where it gets to add arbitrary amounts of downtime to the migration traffic. That's a terrible idea. I'd like to be more constructive in my response, but you aren't explaining the problem well enough for me to offer an alternative solution. You need to find another way to solve this problem. Actually, this is not the first time we address you with this issues. For example: http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg01805.html (The first part of the above discussion is not directly related to the current one). I'll try to explain in more details: As Gerd mentioned, migrating the spice connection smoothly requires the src server to keep running and send/receive data to/from the client, after migration has already completed, till the client completely transfers to the target. The suggested patch series only delays the migration state change from ACTIVE to COMPLETED/ERROR/CANCELED, till spice signals it has completed its part in migration. As I see it, if spice connection does exists, its migration should be treated as a non separate part of the whole migration process, and thus, the migration state shouldn't change from ACTIVE, till spice has completed its part. Hence, I don't think we should have a qmp event for signaling libvirt about spice migration. Spice client migration has nothing to do with guest migration. Trying to abuse QEMU to support it is not acceptable. The second challenge we are facing, which I addressed in the plans part of the cover-letter, and on which I think you (anthony) actually replied, is how to tackle migrating spice data from the src server to the target server. Such data can be usb/smartcard packets sent from a device connected on the client, to the server, and that haven't reached the device. Or partial data that has been read from a guest character device and that haven't been sent to the client. Other data can be internal server-client state data we would wish to keep on the server in order to avoid establishing the connection to the target from scratch, and possibly also suffer from a slower responsiveness at start. In the cover-letter I suggested to transfer spice migration data via the vmstate infrastructure. The other alternative which we also discussed in the link above, is to transfer the data via the client. The latter also requires holding the src process alive after migration completion, in order to manage to complete transferring the data from the src to the client. -- To summarize, since we can still use the client to transfer data from the src to the target (instead of using vmstate), the major requirement of spice, is to keep the src running after migration has completed. So send a QMP event and call it a day. Using a QMP event is making spice seamless migration dependent on libvirt version. Delaying the status change to migration completed, (1) doesn't affect qemu migration time, the migration has already completed, and (2) will allow spice to seamlessly migrate, no matter which libvirt version is used. Yonit. Regards, Anthony Liguori Yonit. Very short version: The requirement is simply to not kill qemu on the source side until the source spice-server has finished session handover to the target spice-server. Long version: spice-client connects automatically to the target machine, so the user ideally doesn't notice that his virtual machine was just migrated over to another host. Today this happens via switch-host, which is a simple message asking the spice client to connect to the new host. We want move to seamless migration model where we don't start over from scratch, but hand over the session from the source to the target. Advantage is that various state cached in spice-client will stay valid and doesn't need to be retransmitted. It also requires a handshake between spice-servers on source and target. libvirt killing qemu on the source host before the handshake is done isn't exactly helpful. [ Side note: In theory this issue exists even today: in case the data pipe to the client is full spice-server will queue up the switch-host message and qemu might be killed before it is sent out. In practice it doesn't happen though because it goes through the low-traffic main channel so the socket buffers usually have enougth space. ] So, the big question is how to tackle the issue? Option (1): Wait until spice-server is done before signaling completion to libvirt. This is what this patch series implements. Advantage is that it is completely transparent for libvirt, thats why I like it. Disadvantage is that it indeed adds a small delay for the spice-server handshake. The target qemu doesn't process main
[Qemu-devel] [PATCH 3/8] s390: make kvm_stat work on s390
From: Jens Freimann jf...@linux.vnet.ibm.com
Add s390_exit_reasons so kvm_stat doesn't crash when called on s390.
Look for 'vendor_id' in /proc/cpuinfo as well, instead of just for
'flags', so we can determine if we run on S390.
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
---
scripts/kvm/kvm_stat | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/scripts/kvm/kvm_stat b/scripts/kvm/kvm_stat
index 56d2bd7..e8d68f0 100755
--- a/scripts/kvm/kvm_stat
+++ b/scripts/kvm/kvm_stat
@@ -141,15 +141,39 @@ svm_exit_reasons = {
0x400: 'NPF',
}
+s390_exit_reasons = {
+ 0x000: 'UNKNOWN',
+ 0x001: 'EXCEPTION',
+ 0x002: 'IO',
+ 0x003: 'HYPERCALL',
+ 0x004: 'DEBUG',
+ 0x005: 'HLT',
+ 0x006: 'MMIO',
+ 0x007: 'IRQ_WINDOW_OPEN',
+ 0x008: 'SHUTDOWN',
+ 0x009: 'FAIL_ENTRY',
+ 0x010: 'INTR',
+ 0x011: 'SET_TPR',
+ 0x012: 'TPR_ACCESS',
+ 0x013: 'S390_SIEIC',
+ 0x014: 'S390_RESET',
+ 0x015: 'DCR',
+ 0x016: 'NMI',
+ 0x017: 'INTERNAL_ERROR',
+ 0x018: 'OSI',
+ 0x019: 'PAPR_HCALL',
+}
+
vendor_exit_reasons = {
'vmx': vmx_exit_reasons,
'svm': svm_exit_reasons,
+'IBM/S390': s390_exit_reasons,
}
exit_reasons = None
for line in file('/proc/cpuinfo').readlines():
-if line.startswith('flags'):
+if line.startswith('flags') or line.startswith('vendor_id'):
for flag in line.split():
if flag in vendor_exit_reasons:
exit_reasons = vendor_exit_reasons[flag]
--
1.7.10.4
[Qemu-devel] [PATCH 7/8] s390: Add SCLP vt220 console support
From: Heinz Graalfs graa...@linux.vnet.ibm.com
Adds console support (in vt220 mode).
In order to run qemu exploiting the SCLP's console functionality in vt220 mode
the user has to specify the following console related parameters:
-chardev stdio,id=charconsole0 -device
sclpconsole,chardev=charconsole0,id=console0
Signed-off-by: Heinz Graalfs graa...@linux.vnet.ibm.com
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
---
hw/s390-event-facility.c | 209 ++
hw/s390-event-facility.h |8 ++
hw/s390-sclp.c | 177 ++-
hw/s390-sclp.h | 22 -
sysemu.h |1 +
target-s390x/op_helper.c |6 ++
vl.c | 41 +
7 files changed, 460 insertions(+), 4 deletions(-)
diff --git a/hw/s390-event-facility.c b/hw/s390-event-facility.c
index b8106a6..cfa5dd4 100644
--- a/hw/s390-event-facility.c
+++ b/hw/s390-event-facility.c
@@ -16,6 +16,11 @@
#include s390-sclp.h
#include s390-event-facility.h
+qemu_irq sclp_read_vt220;
+
+static int size_buffer = 4096;
+static char *sclp_console_data_vt220;
+
struct SCLPDevice {
const char *name;
bool vm_running;
@@ -224,9 +229,213 @@ static TypeInfo sclp_quiesce_info = {
.class_init= sclpef_quiesce_class_init,
};
+/* --- SCLP VT220 console */
+
+static void s390_signal_read_vt220(void *opaque, int n, int level)
+{
+sclp_enable_signal_read_vt220();
+sclp_service_interrupt(opaque, 0);
+}
+
+static void sclpef_set_console(SCLPEvent *event)
+{
+if (event-id == ID_VT220) {
+sclp_read_vt220 = *qemu_allocate_irqs(s390_signal_read_vt220,
+event-evt_fac-opaque, 1);
+}
+}
+
+void sclpef_write_console_vt220(SCLPDevice *sdev, char *buf)
+{
+DeviceState *dev;
+SCLPEventFacility *event_facility;
+static SCLPEvent *event;
+static SCLPEventClass *cons;
+
+event_facility = DO_UPCAST(SCLPEventFacility, sdev, sdev);
+
+if (!cons) {
+QTAILQ_FOREACH(dev, event_facility-sbus.qbus.children, sibling) {
+event = (SCLPEvent *) dev;
+if (event-id == ID_VT220) {
+cons = SCLP_EVENT_GET_CLASS(event);
+assert(cons-have_data);
+break;
+}
+}
+}
+if (cons) {
+cons-have_data(event, (const uint8_t *)buf, strlen(buf));
+}
+}
+
+char *sclpef_get_console_data_vt220(SCLPDevice *sdev)
+{
+DeviceState *dev;
+SCLPEventFacility *event_facility;
+SCLPEvent *event = NULL;
+static SCLPEventClass *cons;
+
+event_facility = DO_UPCAST(SCLPEventFacility, sdev, sdev);
+
+if (!cons) {
+QTAILQ_FOREACH(dev, event_facility-sbus.qbus.children, sibling) {
+event = (SCLPEvent *) dev;
+if (event-id == ID_VT220) {
+cons = SCLP_EVENT_GET_CLASS(event);
+assert(cons-get_data);
+break;
+}
+}
+}
+if (cons) {
+return cons-get_data();
+}
+return NULL;
+}
+
+static char *console_data_vt220(void)
+{
+return sclp_console_data_vt220;
+}
+
+static ssize_t flush_buf(SCLPEvent *event, const uint8_t *buf, size_t len)
+{
+SCLPConsole *scon = DO_UPCAST(SCLPConsole, event, event);
+ssize_t ret;
+
+if (!scon-chr) {
+/* If there's no backend, we can just say we consumed all data. */
+return len;
+}
+
+ret = qemu_chr_fe_write(scon-chr, buf, len);
+
+if (ret 0) {
+/* see virtio-console comments */
+ret = 0;
+}
+
+return ret;
+}
+
+static void guest_open(SCLPEvent *event)
+{
+SCLPConsole *scon = DO_UPCAST(SCLPConsole, event, event);
+
+if (!scon-chr) {
+return;
+}
+qemu_chr_fe_open(scon-chr);
+}
+
+static void guest_close(SCLPEvent *event)
+{
+SCLPConsole *scon = DO_UPCAST(SCLPConsole, event, event);
+
+if (!scon-chr) {
+return;
+}
+qemu_chr_fe_close(scon-chr);
+}
+
+static int chr_can_read(void *opaque)
+{
+return 1;
+}
+
+static void chr_read_vt220(void *opaque, const uint8_t *buf, int size)
+{
+char *offset;
+
+if (!sclp_console_data_vt220) {
+size_buffer = 2 * size;
+sclp_console_data_vt220 = malloc(size_buffer);
+}
+if (size_buffer size + 1) {
+free(sclp_console_data_vt220);
+size_buffer = 2 * size;
+sclp_console_data_vt220 = malloc(size_buffer);
+}
+offset = sclp_console_data_vt220;
+if (offset) {
+memcpy(offset, buf, size);
+offset += size;
+*offset = '\0';
+qemu_irq_raise(sclp_read_vt220);
+} else {
+size_buffer = 0;
+}
+}
+
+static void chr_event(void *opaque, int event)
+{
+switch (event) {
+case CHR_EVENT_OPENED:
+if (!sclp_console_data_vt220) {
+sclp_console_data_vt220 = malloc(size_buffer);
+}
+break;
+case CHR_EVENT_CLOSED:
+break;
+
[Qemu-devel] [PATCH 2/8] s390: autodetect map private
From: Christian Borntraeger borntrae...@de.ibm.com
By default qemu will use MAP_PRIVATE for guest pages. This will write
protect pages and thus break on s390 systems that dont support this feature.
Therefore qemu has a hack to always use MAP_SHARED for s390. But MAP_SHARED
has other problems (no dirty pages tracking, a lot more swap overhead etc.)
Newer systems allow the distinction via KVM_CAP_S390_COW. With this feature
qemu can use the standard qemu alloc if available, otherwise it will use
the old s390 hack.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
---
exec.c | 54 +---
kvm.h |9 +
oslib-posix.c |3 +++
target-s390x/kvm.c |6 ++
4 files changed, 57 insertions(+), 15 deletions(-)
diff --git a/exec.c b/exec.c
index a0494c7..8fec680 100644
--- a/exec.c
+++ b/exec.c
@@ -2618,6 +2618,43 @@ void qemu_ram_set_idstr(ram_addr_t addr, const char
*name, DeviceState *dev)
}
}
+/*
+ * lets make sure that we dont have the old s390x limitations regarding
+ * guest mappings
+ */
+static int legacy_s390x_mem_layout(void)
+{
+#if defined(TARGET_S390X)
+return kvm_has_legacy_s390x_memlayout();
+#else
+return 0;
+#endif
+}
+
+/*
+ * Legacy layout for s390:
+ * Older S390 KVM requires the topmost vma of the RAM to be
+ * smaller than an system defined value, which is at least 256GB.
+ * Larger systems have larger values. We put the guest between
+ * the end of data segment (system break) and this value. We
+ * use 32GB as a base to have enough room for the system break
+ * to grow. We also have to use MAP parameters that avoid
+ * read-only mapping of guest pages.
+ */
+static void *legacy_s390_alloc(ram_addr_t size)
+{
+void *mem;
+
+mem = mmap((void *) 0x8ULL, size,
+ PROT_EXEC|PROT_READ|PROT_WRITE,
+ MAP_SHARED | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
+if (mem == MAP_FAILED) {
+fprintf(stderr, Allocating RAM failed\n);
+abort();
+}
+return mem;
+}
+
ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size, void *host,
MemoryRegion *mr)
{
@@ -2644,26 +2681,13 @@ ram_addr_t qemu_ram_alloc_from_ptr(ram_addr_t size,
void *host,
exit(1);
#endif
} else {
-#if defined(TARGET_S390X) defined(CONFIG_KVM)
-/* S390 KVM requires the topmost vma of the RAM to be smaller than
- an system defined value, which is at least 256GB. Larger systems
- have larger values. We put the guest between the end of data
- segment (system break) and this value. We use 32GB as a base to
- have enough room for the system break to grow. */
-new_block-host = mmap((void*)0x8, size,
- PROT_EXEC|PROT_READ|PROT_WRITE,
- MAP_SHARED | MAP_ANONYMOUS | MAP_FIXED, -1,
0);
-if (new_block-host == MAP_FAILED) {
-fprintf(stderr, Allocating RAM failed\n);
-abort();
-}
-#else
if (xen_enabled()) {
xen_ram_alloc(new_block-offset, size, mr);
+} else if (legacy_s390x_mem_layout()) {
+new_block-host = legacy_s390_alloc(size);
} else {
new_block-host = qemu_vmalloc(size);
}
-#endif
qemu_madvise(new_block-host, size, QEMU_MADV_MERGEABLE);
}
}
diff --git a/kvm.h b/kvm.h
index 9c7b0ea..ca0557e 100644
--- a/kvm.h
+++ b/kvm.h
@@ -62,6 +62,15 @@ int kvm_has_pit_state2(void);
int kvm_has_many_ioeventfds(void);
int kvm_has_gsi_routing(void);
+#ifndef CONFIG_KVM
+static inline int kvm_has_legacy_s390x_memlayout(void)
+{
+return 0;
+}
+#else
+int kvm_has_legacy_s390x_memlayout(void);
+#endif
+
int kvm_allows_irq0_override(void);
#ifdef NEED_CPU_H
diff --git a/oslib-posix.c b/oslib-posix.c
index b6a3c7f..93902ac 100644
--- a/oslib-posix.c
+++ b/oslib-posix.c
@@ -41,6 +41,9 @@ extern int daemon(int, int);
therefore we need special code which handles running on Valgrind. */
# define QEMU_VMALLOC_ALIGN (512 * 4096)
# define CONFIG_VALGRIND
+#elif defined(__linux__) defined(__s390x__)
+ /* Use 1 MiB (segment size) alignment so gmap can be used by KVM. */
+# define QEMU_VMALLOC_ALIGN (256 * 4096)
#else
# define QEMU_VMALLOC_ALIGN getpagesize()
#endif
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 90aad61..93a8431 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -135,6 +135,12 @@ int kvm_arch_get_registers(CPUS390XState *env)
return 0;
}
+int kvm_has_legacy_s390x_memlayout(void)
+{
+return !kvm_check_extension(kvm_state, KVM_CAP_S390_GMAP) ||
+ !kvm_check_extension(kvm_state, KVM_CAP_S390_COW);
+}
+
int kvm_arch_insert_sw_breakpoint(CPUS390XState *env, struct
[Qemu-devel] [PATCH 0/8] s390: SCLP console and misc
From: Jens Freimann jf...@linux.vnet.ibm.com Some patches for s390. The biggest chunk is the SCLP (console) implementation. Christian Borntraeger (3): s390: autodetect map private s390: stop target cpu on sigp initial reset s390: Cleanup sclp functions Heinz Graalfs (2): s390: sclp event facility and signal quiesce support via system_powerdown s390: Add SCLP vt220 console support Jens Freimann (2): s390: add new define for KVM_CAP_S390_COW s390: make kvm_stat work on s390 Nick Wang (1): s390: Fix the storage increment size calculation Makefile.target |3 +- exec.c| 54 -- hw/s390-event-facility.c | 441 ++ hw/s390-event-facility.h | 62 ++ hw/s390-sclp.c| 463 + hw/s390-sclp.h| 148 +++ hw/s390-virtio.c | 17 +- kvm.h |9 + linux-headers/linux/kvm.h |1 + oslib-posix.c |3 + scripts/kvm/kvm_stat | 26 ++- sysemu.h |1 + target-s390x/cpu.h| 11 -- target-s390x/kvm.c| 12 +- target-s390x/op_helper.c | 48 ++--- vl.c | 41 16 files changed, 1283 insertions(+), 57 deletions(-) create mode 100644 hw/s390-event-facility.c create mode 100644 hw/s390-event-facility.h create mode 100644 hw/s390-sclp.c create mode 100644 hw/s390-sclp.h -- 1.7.10.4
[Qemu-devel] [PATCH 5/8] s390: Cleanup sclp functions
From: Christian Borntraeger borntrae...@de.ibm.com
The sclp facility on s390 is a hardware that is external to the cpu.
Lets cleanup the definitions and move the functionality into a separate
file under hw/.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
Signed-off-by: Jens Freimann jf...@de.ibm.com
---
Makefile.target |2 +-
hw/s390-sclp.c | 42 ++
hw/s390-sclp.h | 34 ++
target-s390x/cpu.h | 11 ---
target-s390x/kvm.c |5 ++---
target-s390x/op_helper.c | 39 +--
6 files changed, 96 insertions(+), 37 deletions(-)
create mode 100644 hw/s390-sclp.c
create mode 100644 hw/s390-sclp.h
diff --git a/Makefile.target b/Makefile.target
index 1582904..fed2d72 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -374,7 +374,7 @@ obj-sh4-y += ide/mmio.o
obj-m68k-y = an5206.o mcf5206.o mcf_uart.o mcf_intc.o mcf5208.o mcf_fec.o
obj-m68k-y += m68k-semi.o dummy_m68k.o
-obj-s390x-y = s390-virtio-bus.o s390-virtio.o
+obj-s390x-y = s390-virtio-bus.o s390-virtio.o s390-sclp.o
obj-alpha-y = mc146818rtc.o
obj-alpha-y += alpha_pci.o alpha_dp264.o alpha_typhoon.o
diff --git a/hw/s390-sclp.c b/hw/s390-sclp.c
new file mode 100644
index 000..c046441
--- /dev/null
+++ b/hw/s390-sclp.c
@@ -0,0 +1,42 @@
+/*
+ * sclp facility
+ * Copyright IBM Corp. 2012
+ * Author: Christian Borntraeger borntrae...@de.ibm.com
+ *
+ */
+
+#include cpu.h
+#include kvm.h
+#include hw/s390-sclp.h
+
+int sclp_read_info(CPUS390XState *env, struct sccb *sccb)
+{
+int shift = 0;
+
+while ((ram_size (20 + shift)) 65535) {
+shift++;
+}
+sccb-c.read_info.rnmax = cpu_to_be16(ram_size (20 + shift));
+sccb-c.read_info.rnsize = 1 shift;
+sccb-h.response_code = cpu_to_be16(0x10);
+
+return 0;
+}
+
+void sclp_service_interrupt(CPUS390XState *env, uint32_t sccb)
+{
+if (!sccb) {
+return;
+}
+
+if (kvm_enabled()) {
+#ifdef CONFIG_KVM
+kvm_s390_interrupt_internal(env, KVM_S390_INT_SERVICE,
+(sccb ~3), 0, 1);
+#endif
+} else {
+env-psw.addr += 4;
+cpu_inject_ext(env, EXT_SERVICE, (sccb ~3), 0);
+}
+}
+
diff --git a/hw/s390-sclp.h b/hw/s390-sclp.h
new file mode 100644
index 000..e335b21
--- /dev/null
+++ b/hw/s390-sclp.h
@@ -0,0 +1,34 @@
+#include stdint.h
+#include qemu-common.h
+
+
+/* SCLP command codes */
+#define SCLP_CMDW_READ_SCP_INFO 0x00020001
+#define SCLP_CMDW_READ_SCP_INFO_FORCED 0x00120001
+
+/* SCLP response codes */
+#define SCLP_RC_SCCB_RESOURCE_INSUFFICENT 0x07f0
+
+struct sccb_header {
+uint16_t length;
+#define SCLP_FC_NORMAL_WRITE0
+uint8_t function_code;
+uint8_t control_mask[3];
+uint16_t response_code;
+} __attribute__((packed));
+
+struct read_info_sccb {
+uint16_t rnmax;
+uint8_t rnsize;
+} __attribute__((packed));
+
+struct sccb {
+struct sccb_header h;
+union {
+struct read_info_sccb read_info;
+char data[4088];
+} c;
+ } __attribute__((packed));
+
+int sclp_read_info(CPUS390XState *env, struct sccb *sccb);
+void sclp_service_interrupt(CPUS390XState *env, uint32_t sccb);
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 2f3f394..d0199d7 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -591,17 +591,6 @@ static inline const char *cc_name(int cc_op)
return cc_names[cc_op];
}
-/* SCLP PV interface defines */
-#define SCLP_CMDW_READ_SCP_INFO 0x00020001
-#define SCLP_CMDW_READ_SCP_INFO_FORCED 0x00120001
-
-#define SCP_LENGTH 0x00
-#define SCP_FUNCTION_CODE 0x02
-#define SCP_CONTROL_MASK0x03
-#define SCP_RESPONSE_CODE 0x06
-#define SCP_MEM_CODE0x08
-#define SCP_INCREMENT 0x0a
-
typedef struct LowCore
{
/* prefix area: defined by architecture */
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 73cfd1f..7a7604b 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -60,9 +60,6 @@
#define SIGP_STORE_STATUS_ADDR 0x0e
#define SIGP_SET_ARCH 0x12
-#define SCLP_CMDW_READ_SCP_INFO 0x00020001
-#define SCLP_CMDW_READ_SCP_INFO_FORCED 0x00120001
-
const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
KVM_CAP_LAST_INFO
};
@@ -246,6 +243,8 @@ static int kvm_sclp_service_call(CPUS390XState *env, struct
kvm_run *run,
r = sclp_service_call(env, sccb, code);
if (r) {
setcc(env, 3);
+} else {
+setcc(env, 0);
}
return 0;
diff --git a/target-s390x/op_helper.c b/target-s390x/op_helper.c
index 7b72473..74bd9ad 100644
--- a/target-s390x/op_helper.c
+++ b/target-s390x/op_helper.c
@@ -31,6 +31,7 @@
#if !defined (CONFIG_USER_ONLY)
#include sysemu.h
+#include hw/s390-sclp.h
#endif
[Qemu-devel] [PATCH 4/8] s390: stop target cpu on sigp initial reset
From: Christian Borntraeger borntrae...@de.ibm.com
We must not run the target cpu after an initial reset. This makes
system_reset more reliable for smp guests.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
---
target-s390x/kvm.c |1 +
1 file changed, 1 insertion(+)
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 93a8431..73cfd1f 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -318,6 +318,7 @@ static int s390_cpu_initial_reset(CPUS390XState *env)
{
int i;
+s390_del_running_cpu(env);
if (kvm_vcpu_ioctl(env, KVM_S390_INITIAL_RESET, NULL) 0) {
perror(cannot init reset vcpu);
}
--
1.7.10.4
[Qemu-devel] [PATCH 1/8] s390: add new define for KVM_CAP_S390_COW
From: Jens Freimann jf...@linux.vnet.ibm.com
Add new define for capability KVM_CAP_S390_COW
This patch should be replaced by a current kernel kvm.h header file.
Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com
Signed-off-by: Jens Freimann jf...@de.ibm.com
---
linux-headers/linux/kvm.h |1 +
1 file changed, 1 insertion(+)
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index c4426ec..5a9d4e3 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -616,6 +616,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_KVMCLOCK_CTRL 76
#define KVM_CAP_SIGNAL_MSI 77
#define KVM_CAP_PPC_GET_SMMU_INFO 78
+#define KVM_CAP_S390_COW 79
#ifdef KVM_CAP_IRQ_ROUTING
--
1.7.10.4
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
On 06/06/2012 08:01 PM, Yonit Halperin wrote: On 06/06/2012 12:22 PM, Anthony Liguori wrote: So send a QMP event and call it a day. Using a QMP event is making spice seamless migration dependent on libvirt version. That is not an acceptable justification. Delaying the status change to migration completed, (1) doesn't affect qemu migration time, the migration has already completed, and (2) will allow spice to seamlessly migrate, no matter which libvirt version is used. (1) libvirt starts the destination with -S and starts it manually IIUC. It waits for the migration completed event to do this. Seriously, just add the event. Async notifiers are not an option. Regards, Anthony Liguori Yonit. Regards, Anthony Liguori Yonit. Very short version: The requirement is simply to not kill qemu on the source side until the source spice-server has finished session handover to the target spice-server. Long version: spice-client connects automatically to the target machine, so the user ideally doesn't notice that his virtual machine was just migrated over to another host. Today this happens via switch-host, which is a simple message asking the spice client to connect to the new host. We want move to seamless migration model where we don't start over from scratch, but hand over the session from the source to the target. Advantage is that various state cached in spice-client will stay valid and doesn't need to be retransmitted. It also requires a handshake between spice-servers on source and target. libvirt killing qemu on the source host before the handshake is done isn't exactly helpful. [ Side note: In theory this issue exists even today: in case the data pipe to the client is full spice-server will queue up the switch-host message and qemu might be killed before it is sent out. In practice it doesn't happen though because it goes through the low-traffic main channel so the socket buffers usually have enougth space. ] So, the big question is how to tackle the issue? Option (1): Wait until spice-server is done before signaling completion to libvirt. This is what this patch series implements. Advantage is that it is completely transparent for libvirt, thats why I like it. Disadvantage is that it indeed adds a small delay for the spice-server handshake. The target qemu doesn't process main loop events while the incoming migration is running, and because of that the spice-server handshake doesn't run in parallel with the final stage of vm migration, which it could in theory. BTW: There will be no arbitrary amounts of downtime. Seamless spice client migration is pretty pointless if it doesn't finish within a fraction of a second, so we can go with a very short timeout there. Option (2): Add a new QMP event which is emmitted when spice-server is done, then make libvirt wait for it before killing qemu. Obvious disadvantage is that it requires libvirt changes. Option (3): Your suggestion? thanks, Gerd
Re: [Qemu-devel] [patch v8 0/5] i.MX31 support
Hello Peter, Am 06.06.2012 05:47, schrieb Peter Chubb: There are no major changes since last time, just rebased to current tip now that QEMU 1.2 is open. For those who have come into the story late, this is a series of patches to allow QEMU to emulate a Freescale i.MX31 on a Kyoto Microsystems evaluation board. It's pretty bare-bones, but runs Linux and seL4 nicely. Something is wrong with the patch submission, they are shown as attachments and Thunderbird doesn't let me comment inline. Please use git-send-email to submit. Also the diffstat doesn't match the patch wrt file ordering, so it would be advisable to use git-format-patch. Our concept of topics in the subject seems to be troubling you, you have added support since v7 (still readable, so I'm okay) whereas what we usually use is a lower-case tag as described here plus an active description of what it's doing (e.g., foo: Add/Introduce bar): https://live.gnome.org/Git/CommitMessages On patch 5: Please use cpu_arm_init() in place of cpu_init() and prefer ARMCPU. This is already in qemu.git and many more conversions are in the QOM CPUState part 3 PULL and on qom-next. Also note that arm_pic_init_cpu() and arm_load_kernel() are being changed to take that ARMCPU, so this needs to be coordinated. Please remove the semicolon after machine_init() and check the indentation. After sysbus_create_varargs() for instance I spot one space too few and below for imx_serial_create() there's a double space. Please also make all your TypeInfos static const, probably same for QEMUMachine. The description sounds misleading: In qemu-system-arm all boards are ARM architecture, and your wording may sound as if the board were from ARM (Holdings plc) when it is from Kyoto Micro and uses a Freescale SoC. Maybe also mention the exact board name from the commit message and mention i.MX31? s/I.MX31/i.MX31/ in the header? On patch 4: There's an empty line after type_init(), please remove. On patch 3: In IMXTimerGState you're saving DeviceState *ccm. That should probably become a QOM link property, possibly after the initial submission. CC'ing Paolo. What should be considered as a second step is factoring out all the devices individually added to the board into an i.MX31 SoC, which has implications on how the devices are initialized (compare my recent prep_pci and Anthony's i440fx patches). For a less sophisticated way using functions check out exynos4210. The way it's done right now there's no distinction of what is on the SoC and what is on the board, so it needs to be done by you. Missing is an entry to MAINTAINERS for this board and its exclusive devices, naming who is to be cc'ed on patches. Regards, 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] [PATCH 15/16] convert net_init_bridge() to NetClientOptions
On 06/05/12 23:05, Paolo Bonzini wrote:
Il 22/05/2012 12:45, Laszlo Ersek ha scritto:
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
net/tap.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/net/tap.c b/net/tap.c
index 7501eba..fdaab2b 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -512,21 +512,22 @@ static int net_bridge_run_helper(const char *helper,
const char *bridge)
return -1;
}
-int net_init_bridge(QemuOpts *opts, const NetClientOptions *new_opts,
+int net_init_bridge(QemuOpts *old_opts, const NetClientOptions *opts,
const char *name, VLANState *vlan)
{
+const NetdevBridgeOptions *bridge;
+const char *helper, *br;
+
TAPState *s;
int fd, vnet_hdr;
-if (!qemu_opt_get(opts, br)) {
-qemu_opt_set(opts, br, DEFAULT_BRIDGE_INTERFACE);
-}
-if (!qemu_opt_get(opts, helper)) {
-qemu_opt_set(opts, helper, DEFAULT_BRIDGE_HELPER);
-}
+assert(opts-kind == NET_CLIENT_OPTIONS_KIND_BRIDGE);
+bridge = opts-bridge;
+
+helper = bridge-has_helper ? bridge-helper : DEFAULT_BRIDGE_HELPER;
+br = bridge-has_br ? bridge-br : DEFAULT_BRIDGE_INTERFACE;
Don't hate me for this, but why not do the same for strdup calls?
foo = bar-has_foo ? g_strdup(bar-foo) : NULL;
earlier in the series?
(I think you mean net_init_nic() in [PATCH 09/16] convert
net_init_nic() to NetClientOptions.)
I didn't deliberately avoid the conditional operator there. The
net_init_nic() structure seemed OK; it sets all such pointers to
all-bits-zero in a batch (memset()) and only changes those whose
corresponding optarg (QemuOpt) is set. It seemed natural and didn't
summon ?: to my mind.
net_init_bridge() OTOH sets the defaults too on a case-by-case basis,
and it was screaming after ?:.
... No hate whatsoever :)
Laszlo
Re: [Qemu-devel] [PATCH 0/2] Two small fixes to the streaming test case.
A real patch series is preferable, having the patches as part of your
signature makes quoting them a bit harder with Thunderbird...
Oops. Unintended, sorry.
From 644fda4d6da1a5babfc8884f255d87ebaf847616 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Wed, 23 May 2012 13:07:56 +0200
Subject: [PATCH 1/2] qemu-iotests: fill streaming test image with data
This avoids that the job completes too fast when the file system
reports the hole to QEMU (via FIEMAP or SEEK_HOLE).
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Does this really fix the cause or just a symptom? The commit message
sounds like a race and now we happen to win it again. But maybe it's
just a bad wording that gives the impression.
No, unfortunately that's exactly the case. The whole TestStreamStop
test case is racy.
If the job completes before we can cancel it, it fails. If we remove
the sleep the job will be canceled before it has even started, and the
test succeeds but I'm not sure it is testing anything worthwhile.
But if the image is left sparse, then the job has really nothing to do
except reading one L2-table. You're pretty much guaranteed to complete
the job too soon, and the test fails.
---
tests/qemu-iotests/030 | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index eb7bf99..4ab7d62 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -21,6 +21,7 @@
import os
import iotests
from iotests import qemu_img, qemu_io
+import struct
backing_img = os.path.join(iotests.test_dir, 'backing.img')
mid_img = os.path.join(iotests.test_dir, 'mid.img')
@@ -48,11 +49,21 @@ class ImageStreamingTestCase(iotests.QMPTestCase):
self.assert_no_active_streams()
+def create_image(self, name, size):
+file = open(name, 'w')
+i = 0
+while i size:
+sector = struct.pack('l504xl', i / 512, i / 512)
+file.write(sector)
+i = i + 512
+file.close()
+
+
class TestSingleDrive(ImageStreamingTestCase):
image_len = 1 * 1024 * 1024 # MB
def setUp(self):
-qemu_img('create', backing_img, str(TestSingleDrive.image_len))
+self.create_image(backing_img, TestSingleDrive.image_len)
How about just adding a qemu_io call instead? Looks a bit nicer to me
than reimplementing it, and would also work if we decided to use a
different backing file format later.
We do not test the content of the file, but we should and for that
purpose you need to write a separate pattern to each sector (the
struct.pack call above).
qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
backing_img, mid_img)
qemu_img('create', '-f', iotests.imgfmt, '-o', 'backing_file=%s' %
mid_img, test_img)
self.vm = iotests.VM().add_drive(test_img)
--
1.7.10.1
From 3ba5810860b2eaba1f01c257aa13e28c6f9e2b3f Mon Sep 17 00:00:00 2001
From: Paolo Bonzini pbonz...@redhat.com
Date: Wed, 23 May 2012 12:52:07 +0200
Subject: [PATCH 2/2] qemu-iotests: start vms in qtest mode
This way, they will not execute any code at all. However, right now
one test is relying on being slowed down by TCG executing random
crap, so change the timeouts there.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
BIOS code is random crap? :-)
Didn't mean to insult SeaBIOS in any way, but for the purposes of
qemu-iotests it is. :)
But I like the idea of using the qtest mode here.
---
tests/qemu-iotests/030|2 +-
tests/qemu-iotests/iotests.py |4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030
index 4ab7d62..cc671dd 100755
--- a/tests/qemu-iotests/030
+++ b/tests/qemu-iotests/030
@@ -147,7 +147,7 @@ class TestStreamStop(ImageStreamingTestCase):
result = self.vm.qmp('block-stream', device='drive0')
self.assert_qmp(result, 'return', {})
-time.sleep(1)
+time.sleep(0.1)
events = self.vm.get_qmp_events(wait=False)
self.assertEqual(events, [], 'unexpected QMP event: %s' % events)
Why is waiting for too _long_ a problem? I would understand if we waited
too short so that the QMP event hasn't arrived yet. But shouldn't you
still get all QMP events if you wait one more second before you fetch them?
If the BLOCK_JOB_COMPLETED event has already come, you cannot cancel the
job anymore. The next line in the context is:
self.cancel_and_wait()
Paolo
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index e27b40e..e05b1d6 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -54,7 +54,9 @@ class VM(object):
self._qemu_log_path = os.path.join(test_dir, 'qemu-log.%d' %
os.getpid())
self._args = qemu_args + ['-chardev',
Re: [Qemu-devel] [RFC PATCH 0/5] asynchronous migration state change handlers
On Wed, Jun 06, 2012 at 08:08:40PM +0800, Anthony Liguori wrote: On 06/06/2012 08:01 PM, Yonit Halperin wrote: On 06/06/2012 12:22 PM, Anthony Liguori wrote: So send a QMP event and call it a day. Using a QMP event is making spice seamless migration dependent on libvirt version. That is not an acceptable justification. To let spice know that libvirt doesn't support the new event would require libvirt capabilities advertisement to qemu. Is that acceptable? Delaying the status change to migration completed, (1) doesn't affect qemu migration time, the migration has already completed, and (2) will allow spice to seamlessly migrate, no matter which libvirt version is used. (1) libvirt starts the destination with -S and starts it manually IIUC. It waits for the migration completed event to do this. Seriously, just add the event. Async notifiers are not an option. Regards, Anthony Liguori Yonit. Regards, Anthony Liguori Yonit. Very short version: The requirement is simply to not kill qemu on the source side until the source spice-server has finished session handover to the target spice-server. Long version: spice-client connects automatically to the target machine, so the user ideally doesn't notice that his virtual machine was just migrated over to another host. Today this happens via switch-host, which is a simple message asking the spice client to connect to the new host. We want move to seamless migration model where we don't start over from scratch, but hand over the session from the source to the target. Advantage is that various state cached in spice-client will stay valid and doesn't need to be retransmitted. It also requires a handshake between spice-servers on source and target. libvirt killing qemu on the source host before the handshake is done isn't exactly helpful. [ Side note: In theory this issue exists even today: in case the data pipe to the client is full spice-server will queue up the switch-host message and qemu might be killed before it is sent out. In practice it doesn't happen though because it goes through the low-traffic main channel so the socket buffers usually have enougth space. ] So, the big question is how to tackle the issue? Option (1): Wait until spice-server is done before signaling completion to libvirt. This is what this patch series implements. Advantage is that it is completely transparent for libvirt, thats why I like it. Disadvantage is that it indeed adds a small delay for the spice-server handshake. The target qemu doesn't process main loop events while the incoming migration is running, and because of that the spice-server handshake doesn't run in parallel with the final stage of vm migration, which it could in theory. BTW: There will be no arbitrary amounts of downtime. Seamless spice client migration is pretty pointless if it doesn't finish within a fraction of a second, so we can go with a very short timeout there. Option (2): Add a new QMP event which is emmitted when spice-server is done, then make libvirt wait for it before killing qemu. Obvious disadvantage is that it requires libvirt changes. Option (3): Your suggestion? thanks, Gerd
