[Qemu-devel] [PATCH V18 03/10] libqblock: build: add configure support
Rule for libqblock.la will be included if it is enabled, and will be added to 'all' to be automatically built. Only support Linux now, to save trouble in building on windows. Signed-off-by: Wenchao Xia --- Makefile |3 +++ configure | 32 libqblock/Makefile |4 3 files changed, 39 insertions(+), 0 deletions(-) create mode 100644 libqblock/Makefile diff --git a/Makefile b/Makefile index b2d7798..a472fd3 100644 --- a/Makefile +++ b/Makefile @@ -114,6 +114,9 @@ endif ifeq ($(CONFIG_SMARTCARD_NSS),y) include $(SRC_PATH)/libcacard/Makefile endif +ifeq ($(CONFIG_LIBQBLOCK),y) +include $(SRC_PATH)/libqblock/Makefile +endif all: $(DOCS) $(TOOLS) $(HELPERS-y) recurse-all diff --git a/configure b/configure index aa347cc..e8a119e 100755 --- a/configure +++ b/configure @@ -226,6 +226,8 @@ coroutine="" seccomp="" glusterfs="" virtio_blk_data_plane="" +libqblock="" +libqblock_requires_y="" # parse CC options first for opt do @@ -898,6 +900,10 @@ for opt do ;; --enable-virtio-blk-data-plane) virtio_blk_data_plane="yes" ;; + --disable-libqblock) libqblock="no" + ;; + --enable-libqblock) libqblock="yes" + ;; *) echo "ERROR: unknown option $opt"; show_help="yes" ;; esac @@ -1147,6 +1153,8 @@ echo " --enable-glusterfs enable GlusterFS backend" echo " --disable-glusterfs disable GlusterFS backend" echo " --enable-gcovenable test coverage analysis with gcov" echo " --gcov=GCOV use specified gcov [$gcov_tool]" +echo " --enable-libqblock enable shared library libqblock" +echo " --disable-libqblock disable shared library libqblock" echo "" echo "NOTE: The object files are built at the place where configure is launched" exit 1 @@ -2445,6 +2453,23 @@ EOF fi fi +## +# libqblock probe +if test "$libqblock" != "no"; then +if test -n "$libtool" && test -n "$glib_libs" && \ +test "$linux" = "yes" \ +; then +# Only support Linux now, check for librt and libz are missing, add it later. +libqblock="yes" +libqblock_requires_y="gthread-2.0 glib-2.0 rt z" +else +if test "$libqblock" = "yes"; then +feature_not_found "libqblock" +fi +libqblock="no" +fi +fi + # # Check for xxxat() functions when we are building linux-user # emulator. This is done because older glibc versions don't @@ -3361,6 +3386,7 @@ echo "GlusterFS support $glusterfs" echo "virtio-blk-data-plane $virtio_blk_data_plane" echo "gcov $gcov_tool" echo "gcov enabled $gcov" +echo "libqblock support $libqblock" if test "$sdl_too_old" = "yes"; then echo "-> Your SDL version is too old - please upgrade to have SDL support" @@ -3717,6 +3743,11 @@ if test "$virtio_blk_data_plane" = "yes" ; then echo "CONFIG_VIRTIO_BLK_DATA_PLANE=y" >> $config_host_mak fi +if test "$libqblock" = "yes" ; then + echo "CONFIG_LIBQBLOCK=y" >> $config_host_mak + echo "libqblock-requires-y=$libqblock_requires_y" >> $config_host_mak +fi + # USB host support case "$usb" in linux) @@ -4301,6 +4332,7 @@ DIRS="tests tests/tcg tests/tcg/cris tests/tcg/lm32" DIRS="$DIRS pc-bios/optionrom pc-bios/spapr-rtas" DIRS="$DIRS roms/seabios roms/vgabios" DIRS="$DIRS qapi-generated" +DIRS="$DIRS libqblock" FILES="Makefile tests/tcg/Makefile qdict-test-data.txt" FILES="$FILES tests/tcg/cris/Makefile tests/tcg/cris/.gdbinit" FILES="$FILES tests/tcg/lm32/Makefile" diff --git a/libqblock/Makefile b/libqblock/Makefile new file mode 100644 index 000..8173da7 --- /dev/null +++ b/libqblock/Makefile @@ -0,0 +1,4 @@ +all: libqblock.la + +libqblock.la: + @true -- 1.7.1
[Qemu-devel] [PATCH V18 08/10] libqblock: libqblock API implement
This patch contains implemention for APIs. Basically it is a layer
above qemu block general layer now.
qb_image_new() will try do init for this library.
Signed-off-by: Wenchao Xia
---
libqblock/libqblock-error.c | 49 +++
libqblock/libqblock.c | 991 +++
2 files changed, 1040 insertions(+), 0 deletions(-)
diff --git a/libqblock/libqblock-error.c b/libqblock/libqblock-error.c
index e69de29..2367ab4 100644
--- a/libqblock/libqblock-error.c
+++ b/libqblock/libqblock-error.c
@@ -0,0 +1,49 @@
+/*
+ * QEMU block layer library
+ *
+ * Copyright IBM, Corp. 2013
+ *
+ * Authors:
+ * Wenchao Xia
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include "libqblock-error.h"
+#include "libqblock-internal.h"
+
+char *qb_error_get_human_str(QBlockImage *image)
+{
+char *ret = NULL;
+QBlockContext *ctx = image->ctx;
+const char *str;
+switch (ctx->err_ret) {
+case QB_ERR_INTERNAL_ERR:
+str = "Internal error.";
+break;
+case QB_ERR_FATAL_ERR:
+str = "Fatal error.";
+break;
+case QB_ERR_INVALID_PARAM:
+str = "Invalid param.";
+break;
+case QB_ERR_BLOCK_OUT_OF_RANGE:
+str = "request is out of image's range.";
+break;
+default:
+str = "Unknown error.";
+break;
+}
+
+if (ctx->err_ret == QB_ERR_INTERNAL_ERR) {
+ret = g_strdup_printf("%s %s errno [%d]. strerror [%s].",
+ str, ctx->g_error->message,
+ ctx->err_no, strerror(-ctx->err_no));
+} else {
+ret = g_strdup_printf("%s %s",
+ str, ctx->g_error->message);
+}
+return ret;
+}
diff --git a/libqblock/libqblock.c b/libqblock/libqblock.c
index e69de29..d7b6ee5 100644
--- a/libqblock/libqblock.c
+++ b/libqblock/libqblock.c
@@ -0,0 +1,991 @@
+/*
+ * QEMU block layer library
+ *
+ * Copyright IBM, Corp. 2013
+ *
+ * Authors:
+ * Wenchao Xia
+ *
+ * This work is licensed under the terms of the GNU LGPL, version 2 or later.
+ * See the COPYING.LIB file in the top-level directory.
+ *
+ */
+
+#include
+#include
+#include
+
+#include "libqblock.h"
+#include "libqblock-internal.h"
+
+#include "block/block_int.h"
+
+#define LIBQB_FILENAME_MAX 4096
+
+typedef struct LibqblockGlobalData {
+int init_flag;
+pthread_mutex_t mutex;
+} LibqblockGlobalData;
+
+LibqblockGlobalData libqb_global_data;
+
+typedef struct LibqbFormatStrMapping {
+const char *fmt_str;
+QBlockFormat fmt_type;
+} LibqbFormatStrMapping;
+
+LibqbFormatStrMapping libqb_formatstr_table[] = {
+{"cow", QB_FORMAT_COW},
+{"qed", QB_FORMAT_QED},
+{"qcow", QB_FORMAT_QCOW},
+{"qcow2", QB_FORMAT_QCOW2},
+{"raw", QB_FORMAT_RAW},
+{"rbd", QB_FORMAT_RBD},
+{"sheepdog", QB_FORMAT_SHEEPDOG},
+{"vdi", QB_FORMAT_VDI},
+{"vmdk", QB_FORMAT_VMDK},
+{"vpc", QB_FORMAT_VPC},
+{NULL, 0},
+};
+
+__attribute__((constructor))
+static void libqblock_init(void)
+{
+/* Todo: add an assertion about the ABI. */
+libqb_global_data.init_flag = 0;
+pthread_mutex_init(&libqb_global_data.mutex, NULL);
+}
+
+const char *qb_formattype2str(QBlockFormat fmt_type)
+{
+int i = 0;
+LibqbFormatStrMapping *tb = libqb_formatstr_table;
+
+if ((fmt_type <= QB_FORMAT_NONE) || (fmt_type >= QB_FORMAT_MAX)) {
+return NULL;
+}
+while (tb[i].fmt_str != NULL) {
+if (tb[i].fmt_type == fmt_type) {
+return tb[i].fmt_str;
+}
+i++;
+}
+return NULL;
+}
+
+QBlockFormat qb_str2fmttype(const char *fmt_str)
+{
+int i = 0;
+LibqbFormatStrMapping *tb = libqb_formatstr_table;
+
+if (fmt_str == NULL) {
+return QB_FORMAT_NONE;
+}
+while (tb[i].fmt_str != NULL) {
+if ((strcmp(fmt_str, tb[i].fmt_str) == 0)) {
+return tb[i].fmt_type;
+}
+i++;
+}
+return QB_FORMAT_NONE;
+}
+
+static void set_context_err(QBlockContext *context, int err_ret,
+const char *fmt, ...)
+{
+va_list ap;
+
+if (context->g_error != NULL) {
+g_error_free(context->g_error);
+}
+
+va_start(ap, fmt);
+context->g_error = g_error_new_valist(qb_error_quark(), err_ret, fmt, ap);
+va_end(ap);
+
+context->err_ret = err_ret;
+if (err_ret == QB_ERR_INTERNAL_ERR) {
+context->err_no = -errno;
+} else {
+context->err_no = 0;
+}
+}
+
+static int create_context(QBlockContext **p_context)
+{
+/*
+ * library init comes here, to make sure block_init is called before with
+ * flag __attribute__((constructor)).
+ */
+if (pthread_mutex_lock(&libqb_global_data.mutex)) {
+return QB_ERR_FATAL_ERR;
+}
+if (libqb_global_data.init_flag == 0) {
+qemu_init_main_loop();
+bdrv_init();
+libqb_global_data.init_flag = 1;
+
[Qemu-devel] [PATCH V18 04/10] libqblock: build: add rule for libqblock.la
Now libqblock.la can be built with neccessary object files, and can be automatically cleaned by make clean in root directory. make libqblock-clean also clean it. -fvisibility=hidden was used to hide symbols, and a special macro was introduced to export symbols that marked as public. Signed-off-by: Wenchao Xia --- libqblock/Makefile | 30 -- 1 files changed, 28 insertions(+), 2 deletions(-) create mode 100644 libqblock/libqblock-error.c create mode 100644 libqblock/libqblock.c diff --git a/libqblock/Makefile b/libqblock/Makefile index 8173da7..4965dd6 100644 --- a/libqblock/Makefile +++ b/libqblock/Makefile @@ -1,4 +1,30 @@ all: libqblock.la -libqblock.la: - @true +# objects linked into a shared library, built with libtool with -fPIC if required +libqblock-obj-y = libqblock/libqblock.o libqblock/libqblock-error.o +# qemu_set_fd_handler2() exist both in iohandler.o and stubs/set-fd-handler.o, so filter it out. +libqblock-obj-y += $(filter-out stubs/set-fd-handler.o, $(stub-obj-y)) +libqblock-obj-y += $(util-obj-y) $(block-obj-y) + +libqblock-lobj-y=$(patsubst %.o, %.lo, $(libqblock-obj-y)) + +# libtool will build the .o files, too +$(libqblock-obj-y): | $(libqblock-lobj-y) + +all: libqblock.la + +# +# Rules for building libqblock standalone library + +libqblock.la: LDFLAGS += -rpath $(libdir) -no-undefined \ + -export-syms $(SRC_PATH)/libqblock/libqblock.syms +libqblock.la: $(libqblock-lobj-y) + $(call LINK,$^) + + +.PHONY: libqblock-clean + +libqblock-clean: + rm -rf $(libqblock-lobj-y) libqblock.la libqblock/.libs + +clean: libqblock-clean diff --git a/libqblock/libqblock-error.c b/libqblock/libqblock-error.c new file mode 100644 index 000..e69de29 diff --git a/libqblock/libqblock.c b/libqblock/libqblock.c new file mode 100644 index 000..e69de29 -- 1.7.1
[Qemu-devel] [PATCH V18 06/10] block: export function path_has_protocol()
libqblock need to use it.
Signed-off-by: Wenchao Xia
---
block.c |2 +-
include/block/block.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/block.c b/block.c
index 50dab8e..0736cce 100644
--- a/block.c
+++ b/block.c
@@ -195,7 +195,7 @@ static void bdrv_io_limits_intercept(BlockDriverState *bs,
}
/* check if the path starts with ":" */
-static int path_has_protocol(const char *path)
+int path_has_protocol(const char *path)
{
const char *p;
diff --git a/include/block/block.h b/include/block/block.h
index 5c3b911..40b63b1 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -395,6 +395,8 @@ void bdrv_acct_start(BlockDriverState *bs, BlockAcctCookie
*cookie,
int64_t bytes, enum BlockAcctType type);
void bdrv_acct_done(BlockDriverState *bs, BlockAcctCookie *cookie);
+int path_has_protocol(const char *path);
+
typedef enum {
BLKDBG_L1_UPDATE,
--
1.7.1
[Qemu-devel] [PATCH V18 09/10] libqblock: build: add rules for test case
Libtool will be used for final link, the rules do nothing if libqblock was disabled. Temp directory was used to store image created in test, which will be deleted in clean. Signed-off-by: Wenchao Xia --- tests/Makefile |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index 8e7a854..79d01cf 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -140,6 +140,15 @@ qtest-obj-y = tests/libqtest.o libqemuutil.a libqemustub.a qtest-obj-y += tests/libi2c.o tests/libi2c-omap.o $(check-qtest-y): $(qtest-obj-y) +#libqblock build rules + +$(check-libqblock-y): QEMU_INCLUDES += -I$(SRC_PATH)/tests -I$(SRC_PATH)/libqblock + +$(check-libqblock-y): %$(EXESUF): %.o libqblock.la + $(call LINK, $^) + +check-unit-$(CONFIG_LIBQBLOCK) += $(check-libqblock-y) + .PHONY: check-help check-help: @echo "Regression testing targets:" -- 1.7.1
[Qemu-devel] [PATCH V18 00/10] libqblock qemu block layer library
These patches introduce libqblock API, make subdir-libqblock and make check-libqblock could build this library. Functionalities: 1 create a new image. 2 sync access of an image. 3 basic image information retrieving such as backing file. 4 detect if a sector is allocated in an image. Supported Formats: ALL using file protocols. Patch 1 to 3 prepares qemu to accept libqblock. v2: Insert reserved bytes into union. Use uint64_t instead of size_t, offset. Use const char * in filename pointer. Initialization function removed and it was automatically executed when library is loaded. Added compile flag visibility=hidden, to avoid name space pollution. Structure naming style changed. Using byte unit instead of sector for every API. Added a member in image static information structure, to report logical sector size, which is always 512 now. Read and write API can take request not aligned to 512 now. It returns the byte number that have succeed in operation, but now either negative value or the number requested would be returned, because qemu block sync I/O API would not return such number. Typo fix due to comments and improved documents. v3: Removed the code about OOM error, introduced GError. Used a table to map from string to enum types about format. Use typedef for every structure. Improved the gcc compiler macro to warn if gcc was not used. Global variable name changed with prefix libqb_. The struct QBlockStaticInfo was changed to folder full format related information inside, and a new member with pointers pointing to the mostly used members, such as backing file, virt size, was added. This would allow the user to get full information about how it is created in the future. Each patch in the serial can work with qemu now. Typo fixes. v4: Renamed QBroker to QBlockContext. Removed tool objs out of libqblock. Added a check in initialization about structure size for ABI. Added a new helper API to duplicate protocol information, helps to open files in a backing file chain. Check-libqblock will not rebuild libqblock every time now. Test case file renamed to "libqblock-[FMT].c". Test use gtest framework now. Test do random creation of test file now, added check for information API in it. Test do random sync io instead of fixed offset io now. Test accept one parameter about where to place the test image, now it is ./tests/libqblock/test_images. v5: Makefile of libqblock was adjusted to be similar as libcacard, added spec file and install section. Removed warning when GCC was not found. Structure names were changed to better ones. Removed the union typedef that contain reserved bytes to reduce the folder depth. Some format related enum options was changed to better name. Added accessors about image static information, hide indirect accessing member detail in the structure. Test Makefile do not create diretory now, test case create it themself. Test build system do not use libtool now, and removed qtest-obj-y in its dependency, make check will automatically execute test anyway now. Removed "ifeq ($(LIBTOOL),)" in Makefile. v6: Remove address pointer member in image static info structure. v7: Support out of tree building. v8: Fix a bug in out of tree building. v9: Rebase and splitted out small fix patch for qemu. v10: Rebased to upstream, adjusted libqblock build system according to Paolo's comments. v11: Adjusting code in patch 4 to 7, details are in the child patch's commit message. v12: Split a patch to add a function in stubs, other change are in patch 4 to 7 commit messages. v13: Moved another function into stubs, added xml rule in tests/makefile, little changes in patch 4, 6, 7. v14: all: Rebased. 1/10, 2/10: automatically call subdir's clean command if subdir's Makefile added $SUBDIR_CLEAN_RULES, so tests/Makefile do not need to be always included, libqblock's rule can also use it. 3/10: seperated patch for configure support, modified as libcacard's style. 4/10: modifed as libcacard's rule. 5/10: seperated patch, also changed a bit to be a mirror as libcacard's rule. 8/10: use bdrv_pread/bdrv_pwrite, instead of handling the buf allignment by libqblock itself. Removed libqblock-aio.c because most function are in block-obj-y now. 9/10: seperated patch, use LINK instead of custom LT_LINK rule, and now libqblock.la is a dependence in the link rule of test program, to make LINK invoke libtool. v15: 1/9: merged from 1/10, 2/10 of previous version, and use dependce of "clean" in sub Makefile instead of a intermedia variable. 2/9: drop $TOOLS adding in libqblock's Makefile, the rule is added in "all". 3/9: drop libqblock-y in Makefile.objs, directly add them in libqblock's Makfile. 6/9: use __visibility__ in special public marking macro, change macro name to LIBQB_DLL_PUBLIC to avoid confilict in name space, use sizeof(uint64_t) instead of magic number 8 in reserved member, spelling fix. Da
Re: [Qemu-devel] [PATCH V21 1/7] Support for TPM command line options
On 02/08/2013 05:01 PM, Eric Blake wrote:
On 02/08/2013 02:42 PM, Stefan Berger wrote:
This patch adds support for TPM command line options.
The command line options supported here are
./qemu-... -tpmdev passthrough,path=,id=
-device tpm-tis,tpmdev=
and
./qemu-... -tpmdev ?
I though we preferred '-tpmdev help' instead of '-tpmdev ?' these days,
as that doesn't need shell quoting.
Will fix it. I only used this syntax because the existing '-soundhw ?'.
where the latter works similar to -soundhw ? and shows a list of
available TPM backends (for example 'passthrough').
What is the QMP counterpart command for listing all possible TPM
backends? Libvirt refuses to use command-line probing since qemu 1.3,
so we need some way for libvirt to get at the same list from QMP without
having to use '-tpmdev ?'.
Now added query-tpm-models and query-tpm-types listing the below shown
enumerations.
+++ b/qapi-schema.json
@@ -3184,3 +3184,59 @@
# Since: 1.4
##
{ 'command': 'chardev-remove', 'data': {'id': 'str'} }
+
+##
+# @TpmModel
+#
+# An enumeration of TPM models.
+#
+# @tpm-tis: TPM TIS model
+#
+# Since: 1.5
+##
+{ 'enum': 'TpmModel',
+ 'data': [ 'tpm-tis' ] }
+
+##
+# @TpmType
+#
+# An enumeration of TPM types.
+#
+# @passthrough: TPM passthrough
+#
+# Since: 1.5
+##
+{ 'enum': 'TpmType',
+ 'data': [ 'passthrough' ] }
+
+##
+# @TpmInfo:
+#
+# Information about the TPM
+#
+# @model: The TPM frontend model, i.e., tpm-tis
+#
+# @id: The ID of the TPM
+#
+# @type: The type of TPM backend, i.e., passthrough
+#
+# @path: #optional Path to the TPM backend device
+#
+# @cancel_path: #optional Path to TPM backend device's cancel sysfs entry
Prefer '-' over '_' in QMP; this should be cancel-path.
Fine, I changed it and also changed it for the command line (6/7). I
looked around in this file and searched for '_' versus '-' and found
both, rolled the dice afterwards...
+#
+# Since: 1.5
+##
+{ 'type': 'TPMInfo',
+ 'data': {'model': 'TpmModel', 'id': 'str', 'type': 'TpmType', '*path': 'str',
+ '*cancel_path': 'str' } }
Is this a case where the choice of which optional parameters are present
depends on which model was in use? That is, if we add a new model that
uses a new field, would it be better to have a union type, something like:
{ 'type': 'TPMTis', 'data': {'path':'str', '*cancel-path':'str'} }
{ 'union': 'TPMBackend',
'data': { 'tpm-tis' : 'TPMTis',
'tpm-future': 'TPMFUture' } }
{ 'type': 'TPMInfo',
'data': { 'id': 'str', 'type': 'TpmType', 'model': 'TPMBackend' } }
so that the user sees:
{ 'id': 'tpm0', 'type':'passthrough',
'model': { 'type':'tpm-tis', 'data':{'path':'/dev/tpm'} } }
not necessarily better, just food for thought.
Above is not entirely reflecting the real world. What about the following?
The backend:
{ 'type': 'TPMPassthrough', 'data': { 'type' : 'TpmType', 'path':'str',
'*cancel-path':'str'} }
{ 'union': 'TPMBE',
'data': { 'tpm-passthrough' : 'TPMPassthrough',
'tpm-future-backend': 'TPMFutureBackend' } }
The hardware device 'model' (frontend):
{ 'type' : 'TPMTis', 'data' : { model : 'TpmModel' }
{ 'union': 'TPMFE',
'data': { 'tpm-tis' : 'TPMTis',
'tpm-future-model': 'TPMFutureModel' } }
{ 'type' : 'TPMInfo'
'data' : { 'id' : 'str', 'model' : 'TPMFE', 'type' : 'TPMBE' }
The user should then see:
{ 'id': 'tpm0',
'model' : { 'model' : 'tpm-tis'},
'type' : { 'type' : 'passthrough', 'path' : '/dev/tpm0' , 'cancel-path' =
'/dev/fdset/2' } }
Stefan
[Qemu-devel] [Bug 1119861] [NEW] Poor console performance in Windows 7
Public bug reported: As part of its conformance test suite, Wine tests the behavior of the Windows console API. Part of this test involves opening a test console and scrolling things around. The test probably does not need to perform that many scroll operations to achieve its goal. However as is it illustrates a significant performance issue in QEmu. Unfortunately it does so by timing out (the tests must run in less than 2 minutes). Here are the run times on a few configurations: 10s - QEmu 1.4 + Q9450@2.6GHz + Windows XP + QXL + QXL driver 8s - QEmu 1.12 + Opteron 6128 + Windows XP + QXL + QXL driver 127s - QEmu 1.12 + Opteron 6128 + Windows 7 + cirrus + vga driver 127s - QEmu 1.12 + Opteron 6128 + Windows 7 + QXL + QXL driver 147s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vga driver 145s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vmware driver (xpdm, no better with all graphics effects disabled) 10s - Metal + Atom N270 + Windows XP + GMA 950 + Intel driver 6s - Metal + i5-3317U + Windows 8 + HD4000 + Intel driver 3s - VMware + Q9450@2.6GHz + Windows XP + vmvga + vmware driver 65s - VMware + Q9450@2.6GHz + Windows 7 + vmvga + vmware driver So when running on the bare metal all versions of Windows are about as fast. However in QEmu Windows 7 is almost 16 times slower than Windows XP! VMware is impacted too but it's still maintains a good lead in performance. Disabling all graphics effects did not help so it's not clear that the fault lies with Windows 7's compositing desktop window manager. Maybe it has to do with the lack of a proper wddm driver? ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "Test executable and source" https://bugs.launchpad.net/bugs/1119861/+attachment/3521476/+files/console.tar.bz2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1119861 Title: Poor console performance in Windows 7 Status in QEMU: New Bug description: As part of its conformance test suite, Wine tests the behavior of the Windows console API. Part of this test involves opening a test console and scrolling things around. The test probably does not need to perform that many scroll operations to achieve its goal. However as is it illustrates a significant performance issue in QEmu. Unfortunately it does so by timing out (the tests must run in less than 2 minutes). Here are the run times on a few configurations: 10s - QEmu 1.4 + Q9450@2.6GHz + Windows XP + QXL + QXL driver 8s - QEmu 1.12 + Opteron 6128 + Windows XP + QXL + QXL driver 127s - QEmu 1.12 + Opteron 6128 + Windows 7 + cirrus + vga driver 127s - QEmu 1.12 + Opteron 6128 + Windows 7 + QXL + QXL driver 147s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vga driver 145s - QEmu 1.12 + Opteron 6128 + Windows 7 + vmvga + vmware driver (xpdm, no better with all graphics effects disabled) 10s - Metal + Atom N270 + Windows XP + GMA 950 + Intel driver 6s - Metal + i5-3317U + Windows 8 + HD4000 + Intel driver 3s - VMware + Q9450@2.6GHz + Windows XP + vmvga + vmware driver 65s - VMware + Q9450@2.6GHz + Windows 7 + vmvga + vmware driver So when running on the bare metal all versions of Windows are about as fast. However in QEmu Windows 7 is almost 16 times slower than Windows XP! VMware is impacted too but it's still maintains a good lead in performance. Disabling all graphics effects did not help so it's not clear that the fault lies with Windows 7's compositing desktop window manager. Maybe it has to do with the lack of a proper wddm driver? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1119861/+subscriptions
[Qemu-devel] Invalid data memory access on qemu-ppc
I'm using the ppc-linux-user target to run processes in a Debian Wheezy filesystem I built using multistrap. I built qemu from yesterday's head of the git tree. When I try to run a Python JSON database called jsonstore, I qemu-ppc barfs with an "Invalid data memory access", with the invalid address always being the lower 32 bits of guest_base (which I take to mean 0). Here is an excerpt of qemu.log with in_asm enabled. I've included the top and bottom, as well as a chunk from the middle where the guest tries to execute the fcfid instruction (with no ill effects, at least until the crash later on). real_start=0x7f0468307000 real_size=0xf700 Reserved 0xf700 bytes of guest address space host mmap_min_addr=0x1 guest_base 0x7f0468307000 startend size prot 1000-1022e000 0022e000 r-x 1023d000-1029a000 0005d000 rw- f678b000-f67ab000 0002 r-x f67ab000-f67ac000 1000 --- f67ac000-f67ae000 2000 rw- f67ae000-f67af000 1000 --- f67af000-f700 00851000 rw- start_brk 0x end_code0x1022d238 start_code 0x1000 start_data 0x1023ded4 end_data0x1028d99c start_stack 0xf6fffa68 brk 0x10299da0 entry 0xf67a2f94 IN: 0xf67a2f94: mr r3,r1 0xf67a2f98: li r4,0 0xf67a2f9c: addir1,r1,-16 0xf67a2fa0: stw r4,0(r1) 0xf67a2fa4: bl 0xf678d2e0 ... IN: 0x0fa89a54: cmpwi cr7,r3,0 0x0fa89a58: beq-cr7,0xfa89a94 IN: 0x0fa89a94: bl 0xfa89690 invalid/unsupported opcode: 3f - 0e - 1a (fc200e9c) 0fa89690 0 IN: 0x0fa89690: fcfid f1,f1 Invalid instruction NIP 0fa89694 LR 0fa89a98 CTR 0fd28508 XER 2000 MSR 02006040 HID0 HF 02006000 idx 0 TB GPR00 0fa89a54 f6ffe3c0 f678b4a0 GPR04 0fc0ae34 0008 0020 GPR08 ffc0 1028d968 0fd28508 GPR12 22282464 10295894 1033acf0 GPR16 102f6fc0 1033acf0 0063 1028d968 GPR20 1033c780 1029 f65077b8 1029da90 GPR24 00a4 0029 f66fd0c0 103578f0 GPR28 0fcaaa64 0fc0aec4 0fc08b08 0fc0ac70 CR 22282462 [ E E E L E G G E ] RES FPR00 4018 4008 43308002 43308003 FPR04 fff80233 41d44526a340 4330d1149a8d 4330 FPR08 40c0e380 433021c7 fff821c7 40c0 FPR12 43308006 4018 FPR16 FPR20 FPR24 FPR28 FPSCR 2000 IN: 0x0fa89810: stwur1,-32(r1) 0x0fa89814: mflrr0 0x0fa89818: bcl-20,4*cr7+so,0xfa8981c ... IN: 0x0f6de328: li r0,0 0x0f6de32c: stw r0,12(r27) 0x0f6de330: lwz r0,36(r1) 0x0f6de334: lwz r26,8(r1) 0x0f6de338: mtlrr0 0x0f6de33c: lwz r27,12(r1) 0x0f6de340: lwz r28,16(r1) 0x0f6de344: lwz r29,20(r1) 0x0f6de348: lwz r30,24(r1) 0x0f6de34c: lwz r31,28(r1) 0x0f6de350: addir1,r1,32 0x0f6de354: blr IN: 0x0f6dcda8: lwz r3,16(r29) 0x0f6dcdac: bl 0xf6de860 IN: 0x0f6de860: lwz r11,-32304(r30) 0x0f6de864: mtctr r11 0x0f6de868: bctr Invalid data memory access: 0x68307000 NIP LR 0f6dcdb0 CTR XER 2000 MSR 02006040 HID0 HF 02006000 idx 0 TB GPR00 0f6dcda8 f6ffe210 f678b4a0 103cb648 GPR04 0016 0002 100eb470 0f6de0c4 GPR08 0001 0002 0002 GPR12 4848 10295894 1029a0b8 GPR16 107b1190 f66e6110 1028d968 GPR20 10774548 1029 10782b60 107a2b40 GPR24 1029a0b8 1031cc58 0790 GPR28 10779830 0f6f77c4 0f6ef9b4 CR 24482422 [ E G G L E G E E ] RES FPR00 43308000 4330d1158120 FPR04 4330800f18b7 41d44526a5c0 4330d1149a97 4330 FPR08 4330 3f320b5c2700 43308000 FPR12 43308001 FPR16 FPR20 FPR24 FPR28 FPSCR 82002000 Any
[Qemu-devel] Support for 1366x768 (720p) resolution?
Late last year, I saw a patch go by adding support for the unfortunately common 1366x768 resolution. Some discussion in the resulting thread suggested some possible improvements to the patch that needed to occur before merging; however, I haven't seen a newer version go by. Just wanted to check back about the status of that patch to make sure it didn't get lost. See also the Launchpad bug about this: https://bugs.launchpad.net/qemu/+bug/1054558 - Josh Triplett
[Qemu-devel] [PATCH V21 6/7] Add support for cancelling of a TPM command
This patch adds support for cancelling an executing TPM command.
In Linux for example a user can cancel a command through the TPM's
sysfs 'cancel' entry using
echo "1" > /sysfs/class/misc/tpm0/device/cancel
This patch propagates the cancellation of a command inside a VM
to the host TPM's sysfs entry.
It also uses the possibility to cancel the command before QEMU VM
shutdown or reboot, which helps in preventing QEMU from hanging while
waiting for the completion of the command.
To relieve higher layers or users from having to determine the TPM's
cancel sysfs entry, the driver searches for the entry in well known
locations.
Signed-off-by: Stefan Berger
---
qemu-options.hx | 9 ++-
tpm/tpm_passthrough.c | 165 ++
vl.c | 5 ++
3 files changed, 164 insertions(+), 15 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index e7e868e..c533c29 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2193,7 +2193,7 @@ DEFHEADING()
DEFHEADING(TPM device options:)
DEF("tpmdev", HAS_ARG, QEMU_OPTION_tpmdev, \
-"-tpmdev passthrough,id=id[,path=path]\n"
+"-tpmdev passthrough,id=id[,path=path][,cancel_path=path]\n"
"use path to provide path to a character device; default
is /dev/tpm0\n",
QEMU_ARCH_ALL)
STEXI
@@ -2216,7 +2216,7 @@ Use ? to print all available TPM backend types.
qemu -tpmdev ?
@end example
-@item -tpmdev passthrough, id=@var{id}, path=@var{path}
+@item -tpmdev passthrough, id=@var{id}, path=@var{path}, path=@var{cancel_path}
(Linux-host only) Enable access to the host's TPM using the passthrough
driver.
@@ -2225,6 +2225,11 @@ driver.
a Linux host this would be @code{/dev/tpm0}.
@option{path} is optional and by default @code{/dev/tpm0} is used.
+@option{cancel_path} specifies the path to the host TPM device's sysfs
+entry allowing for cancellation of an ongoing TPM command.
+@option{cancel_path} is optional and by default QEMU will search for the
+sysfs entry to use.
+
Some notes about using the host's TPM with the passthrough driver:
The TPM device accessed by the passthrough driver must not be
diff --git a/tpm/tpm_passthrough.c b/tpm/tpm_passthrough.c
index 7d5de8e..baca21f 100644
--- a/tpm/tpm_passthrough.c
+++ b/tpm/tpm_passthrough.c
@@ -22,6 +22,8 @@
* License along with this library; if not, see
Re: [Qemu-devel] [PATCH V21 7/7] Introduce --enable-tpm-passthrough configure option
Stefan Berger writes: > Introduce --enable-tpm-passthrough configure option. You're duplicating the subject line here. Regards, Anthony Liguori > > Signed-off-by: Stefan Berger > --- > configure | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/configure b/configure > index b7359aa..b4f0a82 100755 > --- a/configure > +++ b/configure > @@ -227,6 +227,7 @@ seccomp="" > glusterfs="" > virtio_blk_data_plane="" > tpm="no" > +tpm_passthrough="no" > > # parse CC options first > for opt do > @@ -900,11 +901,20 @@ for opt do >;; >--enable-tpm) tpm="yes" >;; > + --enable-tpm-passthrough) tpm_passthrough="yes" > + ;; >*) echo "ERROR: unknown option $opt"; show_help="yes" >;; >esac > done > > +if test "$tpm" = "no" ; then > +if test "$tpm_passthrough" = "yes"; then > +echo "ERROR: --enable-tpm-passthrough requires --enable-tpm" > +exit 1 > +fi > +fi > + > case "$cpu" in > sparc) > LDFLAGS="-m32 $LDFLAGS" > @@ -1150,6 +1160,7 @@ echo " --disable-glusterfs disable GlusterFS > backend" > echo " --enable-gcovenable test coverage analysis with gcov" > echo " --gcov=GCOV use specified gcov [$gcov_tool]" > echo " --enable-tpm enable TPM support" > +echo " --enable-tpm-passthrough enable TPM passthrough driver" > echo "" > echo "NOTE: The object files are built at the place where configure is > launched" > exit 1 > @@ -3349,6 +3360,7 @@ echo "virtio-blk-data-plane $virtio_blk_data_plane" > echo "gcov $gcov_tool" > echo "gcov enabled $gcov" > echo "TPM support $tpm" > +echo "TPM passthrough $tpm_passthrough" > > if test "$sdl_too_old" = "yes"; then > echo "-> Your SDL version is too old - please upgrade to have SDL support" > @@ -4258,6 +4270,11 @@ fi > > if test "$tpm" = "yes"; then >if test "$target_softmmu" = "yes" ; then > +if test "$linux" = "yes" ; then > + if test "$tpm_passthrough" = "yes" ; then > +echo "CONFIG_TPM_PASSTHROUGH=y" >> $config_host_mak > + fi > +fi > echo "CONFIG_TPM=y" >> $config_host_mak >fi > fi > -- > 1.7.11.7
[Qemu-devel] [Bug 1054558] Re: 1366x768 resolution missing
** Bug watch added: Debian Bug tracker #700055 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700055 ** Also affects: debian via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700055 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1054558 Title: 1366x768 resolution missing Status in QEMU: New Status in Debian GNU/Linux: Unknown Bug description: I use ArchLinux with QEMU 1.2.0. I found that 1366x768 resolution is missing, even if I use -vga std or -vga vmware. I think that it is necessary to patch it into the source. Also, why not add a command-line option to specify custom resolutions without patching the source? (I know that VirtualBox has a hidden option to add any resolution.) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1054558/+subscriptions
[Qemu-devel] [PATCH V21 2/7] Add TPM (frontend) hardware interface (TPM TIS) to QEMU
This patch adds the main code of the TPM frontend driver, the TPM TIS
interface, to QEMU. The code is largely based on the previous implementation
for Xen but has been significantly extended to meet the standard's
requirements, such as the support for changing of localities and all the
functionality of the available flags.
Communication with the backend (i.e., for Xen or the libtpms-based one)
is cleanly separated through an interface which the backend driver needs
to implement.
The TPM TIS driver's backend was previously chosen in the code added
to arch_init. The frontend holds a pointer to the chosen backend (interface).
Communication with the backend is based on thread pools.
Whenever the frontend has collected a complete packet, it will submit
a task to the backend, which then starts processing the command. Once
the result has been returned, the backend invokes a callback function
(tpm_tis_receive_cb()).
Testing the proper functioning of the different flags and localities
cannot be done from user space when running in Linux for example, since
access to the address space of the TPM TIS interface is not possible. Also
the Linux driver itself does not exercise all functionality. So, for
testing there is a fairly extensive test suite as part of the SeaBIOS patches
since from within the BIOS one can have full access to all the TPM's registers.
Signed-off-by: Stefan Berger
---
tpm/tpm_tis.c | 857 ++
1 file changed, 857 insertions(+)
create mode 100644 tpm/tpm_tis.c
diff --git a/tpm/tpm_tis.c b/tpm/tpm_tis.c
new file mode 100644
index 000..565e28d
--- /dev/null
+++ b/tpm/tpm_tis.c
@@ -0,0 +1,857 @@
+/*
+ * tpm_tis.c - QEMU's TPM TIS interface emulator
+ *
+ * Copyright (C) 2006,2010-2013 IBM Corporation
+ *
+ * Authors:
+ * Stefan Berger
+ * David Safford
+ *
+ * Xen 4 support: Andrease Niederl
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ * Implementation of the TIS interface according to specs found at
+ * http://www.trustedcomputiggroup.org. This implementation currently
+ * supports version 1.21, revision 1.0.
+ * In the developers menu choose the PC Client section then find the TIS
+ * specification.
+ */
+
+#include "tpm_int.h"
+#include "block/block.h"
+#include "exec/address-spaces.h"
+#include "hw/hw.h"
+#include "hw/pc.h"
+#include "hw/pci/pci_ids.h"
+#include "tpm/tpm_tis.h"
+#include "qemu-common.h"
+
+/*#define DEBUG_TIS */
+
+#ifdef DEBUG_TIS
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
+/* whether the STS interrupt is supported */
+#define RAISE_STS_IRQ
+
+/* tis registers */
+#define TPM_TIS_REG_ACCESS0x00
+#define TPM_TIS_REG_INT_ENABLE0x08
+#define TPM_TIS_REG_INT_VECTOR0x0c
+#define TPM_TIS_REG_INT_STATUS0x10
+#define TPM_TIS_REG_INTF_CAPABILITY 0x14
+#define TPM_TIS_REG_STS 0x18
+#define TPM_TIS_REG_DATA_FIFO 0x24
+#define TPM_TIS_REG_DID_VID 0xf00
+#define TPM_TIS_REG_RID 0xf04
+
+#define TPM_TIS_STS_VALID (1 << 7)
+#define TPM_TIS_STS_COMMAND_READY (1 << 6)
+#define TPM_TIS_STS_TPM_GO(1 << 5)
+#define TPM_TIS_STS_DATA_AVAILABLE(1 << 4)
+#define TPM_TIS_STS_EXPECT(1 << 3)
+#define TPM_TIS_STS_RESPONSE_RETRY(1 << 1)
+
+#define TPM_TIS_BURST_COUNT_SHIFT 8
+#define TPM_TIS_BURST_COUNT(X) \
+((X) << TPM_TIS_BURST_COUNT_SHIFT)
+
+#define TPM_TIS_ACCESS_TPM_REG_VALID_STS (1 << 7)
+#define TPM_TIS_ACCESS_ACTIVE_LOCALITY(1 << 5)
+#define TPM_TIS_ACCESS_BEEN_SEIZED(1 << 4)
+#define TPM_TIS_ACCESS_SEIZE (1 << 3)
+#define TPM_TIS_ACCESS_PENDING_REQUEST(1 << 2)
+#define TPM_TIS_ACCESS_REQUEST_USE(1 << 1)
+#define TPM_TIS_ACCESS_TPM_ESTABLISHMENT (1 << 0)
+
+#define TPM_TIS_INT_ENABLED (1 << 31)
+#define TPM_TIS_INT_DATA_AVAILABLE(1 << 0)
+#define TPM_TIS_INT_STS_VALID (1 << 1)
+#define TPM_TIS_INT_LOCALITY_CHANGED (1 << 2)
+#define TPM_TIS_INT_COMMAND_READY (1 << 7)
+
+#define TPM_TIS_INT_POLARITY_MASK (3 << 3)
+#define TPM_TIS_INT_POLARITY_LOW_LEVEL(1 << 3)
+
+#ifndef RAISE_STS_IRQ
+
+#define TPM_TIS_INTERRUPTS_SUPPORTED (TPM_TIS_INT_LOCALITY_CHANGED | \
+ TPM_TIS_INT_DATA_AVAILABLE | \
+ TPM_TIS_INT_COMMAND_READY)
+
+#else
+
+#define TPM_TIS_INTERRUPTS_SUPPORTED (TPM_TIS_INT_LOCALITY_CHANGED | \
+ TPM_TIS_INT_DATA_AVAILABLE | \
+ TPM_TIS_INT_STS_VALID | \
+ TPM_TIS_INT_COMMAND_READY)
+
+#endif
+
+#define TPM_TIS_CAP_INTERRUPT_LOW_LEVEL (1
[Qemu-devel] [Bug 939443] Re: qemu-system-x86_64 can no support 1366x768
*** This bug is a duplicate of bug 1054558 *** https://bugs.launchpad.net/bugs/1054558 ** This bug has been marked a duplicate of bug 1054558 1366x768 resolution missing -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/939443 Title: qemu-system-x86_64 can no support 1366x768 Status in QEMU: New Bug description: My laptop resolution is 1366x768, but can not support at -vga vmware the -vga std. $ kvm -version QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/939443/+subscriptions
[Qemu-devel] [PATCH V21 7/7] Introduce --enable-tpm-passthrough configure option
Introduce --enable-tpm-passthrough configure option. Signed-off-by: Stefan Berger --- configure | 17 + 1 file changed, 17 insertions(+) diff --git a/configure b/configure index b7359aa..b4f0a82 100755 --- a/configure +++ b/configure @@ -227,6 +227,7 @@ seccomp="" glusterfs="" virtio_blk_data_plane="" tpm="no" +tpm_passthrough="no" # parse CC options first for opt do @@ -900,11 +901,20 @@ for opt do ;; --enable-tpm) tpm="yes" ;; + --enable-tpm-passthrough) tpm_passthrough="yes" + ;; *) echo "ERROR: unknown option $opt"; show_help="yes" ;; esac done +if test "$tpm" = "no" ; then +if test "$tpm_passthrough" = "yes"; then +echo "ERROR: --enable-tpm-passthrough requires --enable-tpm" +exit 1 +fi +fi + case "$cpu" in sparc) LDFLAGS="-m32 $LDFLAGS" @@ -1150,6 +1160,7 @@ echo " --disable-glusterfs disable GlusterFS backend" echo " --enable-gcovenable test coverage analysis with gcov" echo " --gcov=GCOV use specified gcov [$gcov_tool]" echo " --enable-tpm enable TPM support" +echo " --enable-tpm-passthrough enable TPM passthrough driver" echo "" echo "NOTE: The object files are built at the place where configure is launched" exit 1 @@ -3349,6 +3360,7 @@ echo "virtio-blk-data-plane $virtio_blk_data_plane" echo "gcov $gcov_tool" echo "gcov enabled $gcov" echo "TPM support $tpm" +echo "TPM passthrough $tpm_passthrough" if test "$sdl_too_old" = "yes"; then echo "-> Your SDL version is too old - please upgrade to have SDL support" @@ -4258,6 +4270,11 @@ fi if test "$tpm" = "yes"; then if test "$target_softmmu" = "yes" ; then +if test "$linux" = "yes" ; then + if test "$tpm_passthrough" = "yes" ; then +echo "CONFIG_TPM_PASSTHROUGH=y" >> $config_host_mak + fi +fi echo "CONFIG_TPM=y" >> $config_host_mak fi fi -- 1.7.11.7
Re: [Qemu-devel] [PATCH V21 1/7] Support for TPM command line options
On 02/08/2013 02:42 PM, Stefan Berger wrote:
> This patch adds support for TPM command line options.
> The command line options supported here are
>
> ./qemu-... -tpmdev passthrough,path=,id=
>-device tpm-tis,tpmdev=
>
> and
>
> ./qemu-... -tpmdev ?
I though we preferred '-tpmdev help' instead of '-tpmdev ?' these days,
as that doesn't need shell quoting.
>
> where the latter works similar to -soundhw ? and shows a list of
> available TPM backends (for example 'passthrough').
What is the QMP counterpart command for listing all possible TPM
backends? Libvirt refuses to use command-line probing since qemu 1.3,
so we need some way for libvirt to get at the same list from QMP without
having to use '-tpmdev ?'.
> +++ b/qapi-schema.json
> @@ -3184,3 +3184,59 @@
> # Since: 1.4
> ##
> { 'command': 'chardev-remove', 'data': {'id': 'str'} }
> +
> +##
> +# @TpmModel
> +#
> +# An enumeration of TPM models.
> +#
> +# @tpm-tis: TPM TIS model
> +#
> +# Since: 1.5
> +##
> +{ 'enum': 'TpmModel',
> + 'data': [ 'tpm-tis' ] }
> +
> +##
> +# @TpmType
> +#
> +# An enumeration of TPM types.
> +#
> +# @passthrough: TPM passthrough
> +#
> +# Since: 1.5
> +##
> +{ 'enum': 'TpmType',
> + 'data': [ 'passthrough' ] }
> +
> +##
> +# @TpmInfo:
> +#
> +# Information about the TPM
> +#
> +# @model: The TPM frontend model, i.e., tpm-tis
> +#
> +# @id: The ID of the TPM
> +#
> +# @type: The type of TPM backend, i.e., passthrough
> +#
> +# @path: #optional Path to the TPM backend device
> +#
> +# @cancel_path: #optional Path to TPM backend device's cancel sysfs entry
Prefer '-' over '_' in QMP; this should be cancel-path.
> +#
> +# Since: 1.5
> +##
> +{ 'type': 'TPMInfo',
> + 'data': {'model': 'TpmModel', 'id': 'str', 'type': 'TpmType', '*path':
> 'str',
> + '*cancel_path': 'str' } }
Is this a case where the choice of which optional parameters are present
depends on which model was in use? That is, if we add a new model that
uses a new field, would it be better to have a union type, something like:
{ 'type': 'TPMTis', 'data': {'path':'str', '*cancel-path':'str'} }
{ 'union': 'TPMBackend',
'data': { 'tpm-tis' : 'TPMTis',
'tpm-future': 'TPMFUture' } }
{ 'type': 'TPMInfo',
'data': { 'id': 'str', 'type': 'TpmType', 'model': 'TPMBackend' } }
so that the user sees:
{ 'id': 'tpm0', 'type':'passthrough',
'model': { 'type':'tpm-tis', 'data':{'path':'/dev/tpm'} } }
not necessarily better, just food for thought.
> +Options to each backend are described below.
> +
> +Use ? to print all available TPM backend types.
> +@example
> +qemu -tpmdev ?
Again, new code should prefer 'help' rather than '?' from the command line.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
On Fri, Feb 08, 2013 at 04:23:04PM -0200, Eduardo Habkost wrote: > If you don't have the implementation of MOVBE working (and included on > TCG_EXT_FEATURES), neither your patch or "+movbe" can help you. Yes, running -cpu n270,+movbe with Richard's patchset merged works. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Re: [Qemu-devel] [RFC v2 5/5] qtest: Add MMIO support
Andreas Färber writes:
> Introduce [qtest_]{read,write}[bwlq]() libqtest functions and
> corresponding QTest protocol commands to replace local versions in
> libi2c-omap.c.
>
> Signed-off-by: Andreas Färber
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
> ---
> qtest.c | 53 +
> tests/libi2c-omap.c | 23
> tests/libqtest.c| 60
> +++
> tests/libqtest.h| 56 +++
> 4 Dateien geändert, 169 Zeilen hinzugefügt(+), 23 Zeilen entfernt(-)
>
> diff --git a/qtest.c b/qtest.c
> index 4663a38..9a2f9aa 100644
> --- a/qtest.c
> +++ b/qtest.c
> @@ -277,6 +277,59 @@ static void qtest_process_command(CharDriverState *chr,
> gchar **words)
> }
> qtest_send_prefix(chr);
> qtest_send(chr, "OK 0x%04x\n", value);
> +} else if (strcmp(words[0], "writeb") == 0 ||
> + strcmp(words[0], "writew") == 0 ||
> + strcmp(words[0], "writel") == 0 ||
> + strcmp(words[0], "writeq") == 0) {
> +uint64_t addr;
> +uint64_t value;
> +
> +g_assert(words[1] && words[2]);
> +addr = strtoull(words[1], NULL, 0);
> +value = strtoull(words[2], NULL, 0);
> +
> +if (words[0][5] == 'b') {
> +uint8_t data = value;
> +cpu_physical_memory_write(addr, &data, 1);
> +} else if (words[0][5] == 'w') {
> +uint16_t data = value;
> +cpu_physical_memory_write(addr, &data, 2);
> +} else if (words[0][5] == 'l') {
> +uint32_t data = value;
> +cpu_physical_memory_write(addr, &data, 4);
> +} else if (words[0][5] == 'q') {
> +uint64_t data = value;
> +cpu_physical_memory_write(addr, &data, 8);
> +}
> +qtest_send_prefix(chr);
> +qtest_send(chr, "OK\n");
> +} else if (strcmp(words[0], "readb") == 0 ||
> +strcmp(words[0], "readw") == 0 ||
> +strcmp(words[0], "readl") == 0 ||
> +strcmp(words[0], "readq") == 0) {
> +uint64_t addr;
> +uint64_t value = UINT64_C(-1);
> +
> +g_assert(words[1]);
> +addr = strtoull(words[1], NULL, 0);
> +
> +if (words[0][4] == 'b') {
> +uint8_t data;
> +cpu_physical_memory_read(addr, &data, 1);
> +value = data;
> +} else if (words[0][4] == 'w') {
> +uint16_t data;
> +cpu_physical_memory_read(addr, &data, 2);
> +value = data;
> +} else if (words[0][4] == 'l') {
> +uint32_t data;
> +cpu_physical_memory_read(addr, &data, 4);
> +value = data;
> +} else if (words[0][4] == 'q') {
> +cpu_physical_memory_read(addr, &value, 8);
> +}
> +qtest_send_prefix(chr);
> +qtest_send(chr, "OK 0x%016" PRIx64 "\n", value);
> } else if (strcmp(words[0], "read") == 0) {
> uint64_t addr, len, i;
> uint8_t *data;
> diff --git a/tests/libi2c-omap.c b/tests/libi2c-omap.c
> index b7b10b5..c52458c 100644
> --- a/tests/libi2c-omap.c
> +++ b/tests/libi2c-omap.c
> @@ -49,29 +49,6 @@ typedef struct OMAPI2C {
> } OMAPI2C;
>
>
> -/* FIXME Use TBD readw qtest API */
> -static inline uint16_t readw(uint64_t addr)
> -{
> -uint16_t data;
> -
> -memread(addr, &data, 2);
> -return le16_to_cpu(data);
> -}
> -
> -/* FIXME Use TBD writew qtest API */
> -static inline void writew(uint64_t addr, uint16_t data)
> -{
> -data = cpu_to_le16(data);
> -memwrite(addr, &data, 2);
> -}
> -
> -#ifdef __GNUC__
> -#undef memread
> -#undef memwrite
> -#pragma GCC poison memread
> -#pragma GCC poison memwrite
> -#endif
> -
> static void omap_i2c_set_slave_addr(OMAPI2C *s, uint8_t addr)
> {
> uint16_t data = addr;
> diff --git a/tests/libqtest.c b/tests/libqtest.c
> index 762dec4..5a627d3 100644
> --- a/tests/libqtest.c
> +++ b/tests/libqtest.c
> @@ -431,6 +431,66 @@ uint32_t qtest_inl(QTestState *s, uint16_t addr)
> return qtest_in(s, "inl", addr);
> }
>
> +static void qtest_write(QTestState *s, const char *cmd, uint64_t addr,
> +uint64_t value)
> +{
> +qtest_sendf(s, "%s 0x%" PRIx64 " 0x%" PRIx64 "\n", cmd, addr, value);
> +qtest_rsp(s, 0);
> +}
> +
> +void qtest_writeb(QTestState *s, uint64_t addr, uint8_t value)
> +{
> +qtest_write(s, "writeb", addr, value);
> +}
> +
> +void qtest_writew(QTestState *s, uint64_t addr, uint16_t value)
> +{
> +qtest_write(s, "writew", addr, value);
> +}
> +
> +void qtest_writel(QTestState *s, uint64_t addr, uint32_t value)
> +{
> +qtest_write(s, "writel", addr, value);
> +}
> +
> +void qtest_writeq(QTestState *s, uint64_t addr, uint64_t value)
> +{
> +qtest_write(s, "writeq", addr, value);
> +}
> +
> +static uint64_t qtest_read(QTestState *s, const char *cmd, uint64_t addr)
> +{
[Qemu-devel] [PATCH V21 3/7] Add a debug register
This patch uses the possibility to add a vendor-specific register and
adds a debug register useful for dumping the TIS's internal state. This
register is only active in a debug build (#define DEBUG_TIS).
Signed-off-by: Stefan Berger
---
tpm/tpm_tis.c | 70 +++
1 file changed, 70 insertions(+)
diff --git a/tpm/tpm_tis.c b/tpm/tpm_tis.c
index 565e28d..ff5cd6a 100644
--- a/tpm/tpm_tis.c
+++ b/tpm/tpm_tis.c
@@ -52,6 +52,9 @@
#define TPM_TIS_REG_DID_VID 0xf00
#define TPM_TIS_REG_RID 0xf04
+/* vendor-specific registers */
+#define TPM_TIS_REG_DEBUG 0xf90
+
#define TPM_TIS_STS_VALID (1 << 7)
#define TPM_TIS_STS_COMMAND_READY (1 << 6)
#define TPM_TIS_STS_TPM_GO(1 << 5)
@@ -105,6 +108,11 @@
#define TPM_TIS_NO_DATA_BYTE 0xff
+/* local prototypes */
+
+static uint64_t tpm_tis_mmio_read(void *opaque, hwaddr addr,
+ unsigned size);
+
/* utility functions */
static uint8_t tpm_tis_locality_from_addr(hwaddr addr)
@@ -346,6 +354,63 @@ static uint32_t tpm_tis_data_read(TPMState *s, uint8_t
locty)
return ret;
}
+#ifdef DEBUG_TIS
+static void tpm_tis_dump_state(void *opaque, hwaddr addr)
+{
+static const unsigned regs[] = {
+TPM_TIS_REG_ACCESS,
+TPM_TIS_REG_INT_ENABLE,
+TPM_TIS_REG_INT_VECTOR,
+TPM_TIS_REG_INT_STATUS,
+TPM_TIS_REG_INTF_CAPABILITY,
+TPM_TIS_REG_STS,
+TPM_TIS_REG_DID_VID,
+TPM_TIS_REG_RID,
+0xfff};
+int idx;
+uint8_t locty = tpm_tis_locality_from_addr(addr);
+hwaddr base = addr & ~0xfff;
+TPMState *s = opaque;
+TPMTISEmuState *tis = &s->s.tis;
+
+DPRINTF("tpm_tis: active locality : %d\n"
+"tpm_tis: state of locality %d : %d\n"
+"tpm_tis: register dump:\n",
+tis->active_locty,
+locty, tis->loc[locty].state);
+
+for (idx = 0; regs[idx] != 0xfff; idx++) {
+DPRINTF("tpm_tis: 0x%04x : 0x%08x\n", regs[idx],
+(uint32_t)tpm_tis_mmio_read(opaque, base + regs[idx], 4));
+}
+
+DPRINTF("tpm_tis: read offset : %d\n"
+"tpm_tis: result buffer : ",
+tis->loc[locty].r_offset);
+for (idx = 0;
+ idx < tpm_tis_get_size_from_buffer(&tis->loc[locty].r_buffer);
+ idx++) {
+DPRINTF("%c%02x%s",
+tis->loc[locty].r_offset == idx ? '>' : ' ',
+tis->loc[locty].r_buffer.buffer[idx],
+((idx & 0xf) == 0xf) ? "\ntpm_tis: " : "");
+}
+DPRINTF("\n"
+"tpm_tis: write offset : %d\n"
+"tpm_tis: request buffer: ",
+tis->loc[locty].w_offset);
+for (idx = 0;
+ idx < tpm_tis_get_size_from_buffer(&tis->loc[locty].w_buffer);
+ idx++) {
+DPRINTF("%c%02x%s",
+tis->loc[locty].w_offset == idx ? '>' : ' ',
+tis->loc[locty].w_buffer.buffer[idx],
+((idx & 0xf) == 0xf) ? "\ntpm_tis: " : "");
+}
+DPRINTF("\n");
+}
+#endif
+
/*
* Read a register of the TIS interface
* See specs pages 33-63 for description of the registers
@@ -425,6 +490,11 @@ static uint64_t tpm_tis_mmio_read(void *opaque, hwaddr
addr,
case TPM_TIS_REG_RID:
val = TPM_TIS_TPM_RID;
break;
+#ifdef DEBUG_TIS
+case TPM_TIS_REG_DEBUG:
+tpm_tis_dump_state(opaque, addr);
+break;
+#endif
}
if (shift) {
--
1.7.11.7
[Qemu-devel] [PATCH V21 5/7] Add a TPM Passthrough backend driver implementation
>From Andreas Niederl's original posting with adaptations where necessary:
This patch is based of off version 9 of Stefan Berger's patch series
"QEMU Trusted Platform Module (TPM) integration"
and adds a new backend driver for it.
This patch adds a passthrough backend driver for passing commands sent to the
emulated TPM device directly to a TPM device opened on the host machine.
Thus it is possible to use a hardware TPM device in a system running on QEMU,
providing the ability to access a TPM in a special state (e.g. after a Trusted
Boot).
This functionality is being used in the acTvSM Trusted Virtualization Platform
which is available on [1].
Usage example:
qemu-system-x86_64 -tpmdev passthrough,id=tpm0,path=/dev/tpm0 \
-device tpm-tis,tpmdev=tpm0 \
-cdrom test.iso -boot d
Some notes about the host TPM:
The TPM needs to be enabled and activated. If that's not the case one
has to go through the BIOS/UEFI and enable and activate that TPM for TPM
commands to work as expected.
It may be necessary to boot the kernel using tpm_tis.force=1 in the boot
command line or 'modprobe tpm_tis force=1' in case of using it as a module.
Regards,
Andreas Niederl, Stefan Berger
[1] http://trustedjava.sourceforge.net/
Signed-off-by: Andreas Niederl
Signed-off-by: Stefan Berger
---
include/qemu/sockets.h | 1 +
qemu-char.c| 24
qemu-options.hx| 38 -
tpm/Makefile.objs | 3 +-
tpm/tpm.c | 17 +++
tpm/tpm_backend.c | 58
tpm/tpm_backend.h | 45 ++
tpm/tpm_int.h | 33 +
tpm/tpm_passthrough.c | 378 +
vl.c | 2 +
10 files changed, 597 insertions(+), 2 deletions(-)
create mode 100644 tpm/tpm_backend.c
create mode 100644 tpm/tpm_backend.h
create mode 100644 tpm/tpm_passthrough.c
diff --git a/include/qemu/sockets.h b/include/qemu/sockets.h
index 803ae17..16569e2 100644
--- a/include/qemu/sockets.h
+++ b/include/qemu/sockets.h
@@ -37,6 +37,7 @@ int socket_set_cork(int fd, int v);
void socket_set_block(int fd);
void socket_set_nonblock(int fd);
int send_all(int fd, const void *buf, int len1);
+int recv_all(int fd, void *buf, int len1, bool single_read);
/* callback function for nonblocking connect
* valid fd on success, negative error code on failure
diff --git a/qemu-char.c b/qemu-char.c
index a3ba021..cbf1466 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -537,6 +537,30 @@ int send_all(int fd, const void *_buf, int len1)
}
return len1 - len;
}
+
+int recv_all(int fd, void *_buf, int len1, bool single_read)
+{
+int ret, len;
+uint8_t *buf = _buf;
+
+len = len1;
+while ((len > 0) && (ret = read(fd, buf, len)) != 0) {
+if (ret < 0) {
+if (errno != EINTR && errno != EAGAIN) {
+return -1;
+}
+continue;
+} else {
+if (single_read) {
+return ret;
+}
+buf += ret;
+len -= ret;
+}
+}
+return len1 - len;
+}
+
#endif /* !_WIN32 */
#define STDIO_MAX_CLIENTS 1
diff --git a/qemu-options.hx b/qemu-options.hx
index a5cb56a..e7e868e 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2189,10 +2189,12 @@ ETEXI
DEFHEADING()
#ifdef CONFIG_TPM
+# ifdef CONFIG_TPM_PASSTHROUGH
DEFHEADING(TPM device options:)
DEF("tpmdev", HAS_ARG, QEMU_OPTION_tpmdev, \
-"-tpmdev [],id=str[,option][,option][,...]\n",
+"-tpmdev passthrough,id=id[,path=path]\n"
+"use path to provide path to a character device; default
is /dev/tpm0\n",
QEMU_ARCH_ALL)
STEXI
@@ -2202,6 +2204,7 @@ The general form of a TPM device option is:
@item -tpmdev @var{backend} ,id=@var{id} [,@var{options}]
@findex -tpmdev
Backend type must be:
+@option{passthrough}.
The specific backend type will determine the applicable options.
The @code{-tpmdev} options requires a @code{-device} option.
@@ -2213,12 +2216,45 @@ Use ? to print all available TPM backend types.
qemu -tpmdev ?
@end example
+@item -tpmdev passthrough, id=@var{id}, path=@var{path}
+
+(Linux-host only) Enable access to the host's TPM using the passthrough
+driver.
+
+@option{path} specifies the path to the host's TPM device, i.e., on
+a Linux host this would be @code{/dev/tpm0}.
+@option{path} is optional and by default @code{/dev/tpm0} is used.
+
+Some notes about using the host's TPM with the passthrough driver:
+
+The TPM device accessed by the passthrough driver must not be
+used by any other application on the host.
+
+Since the host's firmware (BIOS/UEFI) has already initialized the TPM,
+the VM's firmware (BIOS/UEFI) will not be able to initialize the
+TPM again and may therefore not show a TPM-specific menu that would
+otherwise allow the user to configure the TPM, e.g., allow the user to
+enable/disable or activate/deactivate the TPM.
+Further, if TPM ownership is released fro
[Qemu-devel] [PATCH V21 4/7] Build the TPM frontend code
Build the TPM frontend code that has been added so far. Signed-off-by: Stefan Berger --- configure | 11 +++ tpm/Makefile.objs | 1 + 2 files changed, 12 insertions(+) diff --git a/configure b/configure index 8789324..b7359aa 100755 --- a/configure +++ b/configure @@ -226,6 +226,7 @@ coroutine="" seccomp="" glusterfs="" virtio_blk_data_plane="" +tpm="no" # parse CC options first for opt do @@ -897,6 +898,8 @@ for opt do ;; --enable-virtio-blk-data-plane) virtio_blk_data_plane="yes" ;; + --enable-tpm) tpm="yes" + ;; *) echo "ERROR: unknown option $opt"; show_help="yes" ;; esac @@ -1146,6 +1149,7 @@ echo " --enable-glusterfs enable GlusterFS backend" echo " --disable-glusterfs disable GlusterFS backend" echo " --enable-gcovenable test coverage analysis with gcov" echo " --gcov=GCOV use specified gcov [$gcov_tool]" +echo " --enable-tpm enable TPM support" echo "" echo "NOTE: The object files are built at the place where configure is launched" exit 1 @@ -3344,6 +3348,7 @@ echo "GlusterFS support $glusterfs" echo "virtio-blk-data-plane $virtio_blk_data_plane" echo "gcov $gcov_tool" echo "gcov enabled $gcov" +echo "TPM support $tpm" if test "$sdl_too_old" = "yes"; then echo "-> Your SDL version is too old - please upgrade to have SDL support" @@ -4251,6 +4256,12 @@ if test "$gprof" = "yes" ; then fi fi +if test "$tpm" = "yes"; then + if test "$target_softmmu" = "yes" ; then +echo "CONFIG_TPM=y" >> $config_host_mak + fi +fi + if test "$ARCH" = "tci"; then linker_script="" else diff --git a/tpm/Makefile.objs b/tpm/Makefile.objs index dffb567..63bfcea 100644 --- a/tpm/Makefile.objs +++ b/tpm/Makefile.objs @@ -1 +1,2 @@ common-obj-y = tpm.o +common-obj-$(CONFIG_TPM) += tpm_tis.o -- 1.7.11.7
[Qemu-devel] [PATCH V21 1/7] Support for TPM command line options
This patch adds support for TPM command line options.
The command line options supported here are
./qemu-... -tpmdev passthrough,path=,id=
-device tpm-tis,tpmdev=
and
./qemu-... -tpmdev ?
where the latter works similar to -soundhw ? and shows a list of
available TPM backends (for example 'passthrough').
Using the type parameter, the backend is chosen, i.e., 'passthrough' for the
passthrough driver. The interpretation of the other parameters along
with determining whether enough parameters were provided is pushed into
the backend driver, which needs to implement the interface function
'create' and return a TPMDriver structure if the VM can be started or 'NULL'
if not enough or bad parameters were provided.
Monitor support for 'info tpm' has been added. It for example prints the
following:
(qemu) info tpm
TPM devices:
tpm0: model=tpm-tis
\ tpm0: type=passthrough,path=/dev/tpm0
Signed-off-by: Stefan Berger
---
Makefile.objs | 1 +
hmp-commands.hx | 2 +
hmp.c | 31
hmp.h | 1 +
include/tpm/tpm.h | 21 ++
monitor.c | 8 ++
qapi-schema.json | 56 ++
qemu-options.hx | 33 +
qmp-commands.hx | 6 ++
tpm/Makefile.objs | 1 +
tpm/tpm.c | 218 ++
tpm/tpm_int.h | 79
tpm/tpm_tis.h | 78 +++
vl.c | 37 +
14 files changed, 572 insertions(+)
create mode 100644 include/tpm/tpm.h
create mode 100644 tpm/Makefile.objs
create mode 100644 tpm/tpm.c
create mode 100644 tpm/tpm_int.h
create mode 100644 tpm/tpm_tis.h
diff --git a/Makefile.objs b/Makefile.objs
index 21e9c91..d52ea49 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -74,6 +74,7 @@ common-obj-y += bt-host.o bt-vhci.o
common-obj-y += dma-helpers.o
common-obj-y += qtest.o
common-obj-y += vl.o
+common-obj-y += tpm/
common-obj-$(CONFIG_SLIRP) += slirp/
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 64008a9..a952fd1 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1642,6 +1642,8 @@ show device tree
show qdev device model list
@item info roms
show roms
+@item info tpm
+show the TPM device
@end table
ETEXI
diff --git a/hmp.c b/hmp.c
index 420d48b..84fe6a4 100644
--- a/hmp.c
+++ b/hmp.c
@@ -607,6 +607,37 @@ void hmp_info_block_jobs(Monitor *mon, const QDict *qdict)
}
}
+void hmp_info_tpm(Monitor *mon, const QDict *qdict)
+{
+TPMInfoList *info_list, *info;
+Error *err = NULL;
+unsigned int c = 0;
+
+info_list = qmp_query_tpm(&err);
+if (err) {
+monitor_printf(mon, "TPM device not supported\n");
+error_free(err);
+return;
+}
+
+if (info_list)
+monitor_printf(mon, "TPM device:\n");
+
+for (info = info_list; info; info = info->next) {
+TPMInfo *ti = info->value;
+monitor_printf(mon, " tpm%d: model=%s\n",
+ c, TpmModel_lookup[ti->model]);
+monitor_printf(mon, " \\ %s: type=%s%s%s%s%s\n",
+ ti->id, TpmType_lookup[ti->type],
+ ti->has_path ? ",path=" : "",
+ ti->has_path ? ti->path : "",
+ ti->has_cancel_path ? ",cancel_path=" : "",
+ ti->has_cancel_path ? ti->cancel_path : "");
+c++;
+}
+qapi_free_TPMInfoList(info_list);
+}
+
void hmp_quit(Monitor *mon, const QDict *qdict)
{
monitor_suspend(mon);
diff --git a/hmp.h b/hmp.h
index 30b3c20..95fe76e 100644
--- a/hmp.h
+++ b/hmp.h
@@ -36,6 +36,7 @@ void hmp_info_spice(Monitor *mon, const QDict *qdict);
void hmp_info_balloon(Monitor *mon, const QDict *qdict);
void hmp_info_pci(Monitor *mon, const QDict *qdict);
void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
+void hmp_info_tpm(Monitor *mon, const QDict *qdict);
void hmp_quit(Monitor *mon, const QDict *qdict);
void hmp_stop(Monitor *mon, const QDict *qdict);
void hmp_system_reset(Monitor *mon, const QDict *qdict);
diff --git a/include/tpm/tpm.h b/include/tpm/tpm.h
new file mode 100644
index 000..cc8f20e
--- /dev/null
+++ b/include/tpm/tpm.h
@@ -0,0 +1,21 @@
+/*
+ * Public TPM functions
+ *
+ * Copyright (C) 2011-2013 IBM Corporation
+ *
+ * Authors:
+ * Stefan Berger
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#ifndef QEMU_TPM_H
+#define QEMU_TPM_H
+
+#include "qemu/option.h"
+
+int tpm_config_parse(QemuOptsList *opts_list, const char *optarg);
+int tpm_init(void);
+void tpm_cleanup(void);
+
+#endif /* QEMU_TPM_H */
diff --git a/monitor.c b/monitor.c
index 20bd19b..71fbdda 100644
--- a/monitor.c
+++ b/monitor.c
@@ -47,6 +47,7 @@
#include "migration/migration.h"
#include "sysemu/kvm.h"
#include "qemu/acl.h"
+#include "tpm/tpm.h"
#include "qapi/qmp/qint.h"
#include "qapi/qmp/qfloat.h"
#include "qapi/qmp/qlist.h"
@@ -2722,6 +2723,13 @@ static
[Qemu-devel] [PATCH V21 0/7] QEMU Trusted Platform Module (TPM) integration
From: root The following series of patches adds TPM (Trusted Platform Module) support to QEMU. An emulator for the TIS (TPM Interface Spec) interface is added that provides the basis for accessing a 'backend' implementing the actual TPM functionality. The TIS emulator serves as a 'frontend' enabling for example Linux's TPM TIS (tpm_tis) driver. In this series I am posting a backend implementation that makes use of the host's TPM through a passthrough driver, which on Linux is accessed using /dev/tpm0. v21: - applies to checkout of 70ef6a5b7 (Feb. 7) - addressed comments from Corey Bryant and Luiz Capitulino on v20 - adapted code to new directory structure: - split tpm.h into public part in include/tpm/tpm.h and private part in tpm/tpm_int.h - all TPM code is now in tpm/ directory v20: - applies to checkout of v1.3.0 (6d6c9f59, Dec. 3) - addressed comments from Corey Bryant on v19 - introduced support for canceling commands v19: - applies to checkout of 8cc9b43 (Jun 4) v18: - applies to checkout of 563987d (May 1) - removed some dead variable in 7/7 v17: - applies to checkout of 6507470 (Apr 30) - split up path and fd into two optional parameters v16: - applied to checkout of 42fe1c2 (Apr 27) - followed Anthony's suggestions for v15 - changed qemu-options.hx and vl.c to not show anything TPM-related if --enable-tpm-passthrough was not used on configure line v15: - applies to checkout of 8a22565 (Mar 27) - replacing g_malloc's with g_new; no more checks for NULL after allocs - introducing usage of bottom half in TIS frontend to deliver responses - get rid of locks since global lock is held by all threads entering TIS code - cleanups v14: - applies to checkout of da5361c (Dec 12) - implemented Anthony Liguori's suggestions - dropping the version log on individual patches v13: - applies to checkout of 61a5872 (Dec 12) - only allowing character devices as fd parameter - fixing error path in tpm_tis_init v12: - applies to checkout of ebffe2a (Oct 11) - added documentation for fd parameter - nits v11: - applies to checkout of 46f3069 (Sep 28) - some filing on the documentation - small nits fixed v10: - applies to checkout of 1ce9ce6 (Sep 27) - addressed Michael Tsirkin's comments on v9 v9: - addressed Michael Tsirkin's and other reviewers' comments - only posting Andreas Niederl's passthrough driver as the backend driver v8: - applies to checkout of f0fb8b7 (Aug 30) - fixing compilation error pointed out by Andreas Niederl - adding patch that allows to feed an initial state into the libtpms TPM - following memory API changes (glib) where necessary v7: - applies to checkout of b9c6cbf (Aug 9) - measuring the modules if multiboot is used - coding style fixes v6: - applies to checkout of 75ef849 (July 2nd) - some fixes and improvements to existing patches; see individual patches - added a patch with a null driver responding to all TPM requests with a response indicating failure; this backend has no dependencies and can alwayy be built; - added a patch to support the hashing of kernel, ramfs and command line if those were passed to Qemu using -kernel, -initrd and -append respectively. Measurements are taken, logged, and passed to SeaBIOS using the firmware interface. - libtpms revision 7 now requires 83kb of block storage due to having more NVRAM space v5: - applies to checkout of 1fddfba1 - adding support for split command line using the -tpmdev ... -device ... options while keeping the -tpm option - support for querying the device models using -tpm model=? - support for monitor 'info tpm' - adding documentation of command line options for man page and web page - increasing room for ACPI tables that qemu reserves to 128kb (from 64kb) - adding (experimental) support for block migration - adding (experimental) support for taking measurements when kernel, initrd and kernel command line are directly passed to Qemu v4: - applies to checkout of d2d979c6 - more coding style fixes - adding patch for supporting blob encryption (in addition to the existing QCoW2-level encryption) - this allows for graceful termination of a migration if the target is detected to have a wrong key - tested with big and little endian hosts - main thread releases mutex while checking for work to do on behalf of backend - introducing file locking (fcntl) on the block layer for serializing access to shared (QCoW2) files (used during migration) v3: - Building a null driver at patch 5/8 that responds to all requests with an error response; subsequently this driver is transformed to the libtpms-based driver for real TPM functionality - Reworked the threading; dropped the patch for qemu_thread_join; the main thread synchronizing with the TPM thread termination may need to write data to the block storage while waiting for the thread to terminate; did not previously show a problem but is safer -
Re: [Qemu-devel] [RFC v2 5/5] qtest: Add MMIO support
Am 08.02.2013 22:37, schrieb Anthony Liguori:
> Andreas Färber writes:
>
>> Introduce [qtest_]{read,write}[bwlq]() libqtest functions and
>> corresponding QTest protocol commands to replace local versions in
>> libi2c-omap.c.
>>
>> Signed-off-by: Andreas Färber
>
> Reviewed-by: Anthony Liguori
Thanks, but it is broken for Big Endian just like memread/memwrite.
Please do not apply.
The v2 I came up with is compiling qtest.c per target, upcoming. That
will also help with implementing target-specific hypercall support.
Regards,
Andreas
>
> Regards,
>
> Anthony Liguori
>
>> ---
>> qtest.c | 53 +
>> tests/libi2c-omap.c | 23
>> tests/libqtest.c| 60
>> +++
>> tests/libqtest.h| 56 +++
>> 4 Dateien geändert, 169 Zeilen hinzugefügt(+), 23 Zeilen entfernt(-)
>>
>> diff --git a/qtest.c b/qtest.c
>> index 4663a38..9a2f9aa 100644
>> --- a/qtest.c
>> +++ b/qtest.c
>> @@ -277,6 +277,59 @@ static void qtest_process_command(CharDriverState *chr,
>> gchar **words)
>> }
>> qtest_send_prefix(chr);
>> qtest_send(chr, "OK 0x%04x\n", value);
>> +} else if (strcmp(words[0], "writeb") == 0 ||
>> + strcmp(words[0], "writew") == 0 ||
>> + strcmp(words[0], "writel") == 0 ||
>> + strcmp(words[0], "writeq") == 0) {
>> +uint64_t addr;
>> +uint64_t value;
>> +
>> +g_assert(words[1] && words[2]);
>> +addr = strtoull(words[1], NULL, 0);
>> +value = strtoull(words[2], NULL, 0);
>> +
>> +if (words[0][5] == 'b') {
>> +uint8_t data = value;
>> +cpu_physical_memory_write(addr, &data, 1);
>> +} else if (words[0][5] == 'w') {
>> +uint16_t data = value;
>> +cpu_physical_memory_write(addr, &data, 2);
>> +} else if (words[0][5] == 'l') {
>> +uint32_t data = value;
>> +cpu_physical_memory_write(addr, &data, 4);
>> +} else if (words[0][5] == 'q') {
>> +uint64_t data = value;
>> +cpu_physical_memory_write(addr, &data, 8);
>> +}
>> +qtest_send_prefix(chr);
>> +qtest_send(chr, "OK\n");
>> +} else if (strcmp(words[0], "readb") == 0 ||
>> +strcmp(words[0], "readw") == 0 ||
>> +strcmp(words[0], "readl") == 0 ||
>> +strcmp(words[0], "readq") == 0) {
>> +uint64_t addr;
>> +uint64_t value = UINT64_C(-1);
>> +
>> +g_assert(words[1]);
>> +addr = strtoull(words[1], NULL, 0);
>> +
>> +if (words[0][4] == 'b') {
>> +uint8_t data;
>> +cpu_physical_memory_read(addr, &data, 1);
>> +value = data;
>> +} else if (words[0][4] == 'w') {
>> +uint16_t data;
>> +cpu_physical_memory_read(addr, &data, 2);
>> +value = data;
>> +} else if (words[0][4] == 'l') {
>> +uint32_t data;
>> +cpu_physical_memory_read(addr, &data, 4);
>> +value = data;
>> +} else if (words[0][4] == 'q') {
>> +cpu_physical_memory_read(addr, &value, 8);
>> +}
>> +qtest_send_prefix(chr);
>> +qtest_send(chr, "OK 0x%016" PRIx64 "\n", value);
>> } else if (strcmp(words[0], "read") == 0) {
>> uint64_t addr, len, i;
>> uint8_t *data;
>> diff --git a/tests/libi2c-omap.c b/tests/libi2c-omap.c
>> index b7b10b5..c52458c 100644
>> --- a/tests/libi2c-omap.c
>> +++ b/tests/libi2c-omap.c
>> @@ -49,29 +49,6 @@ typedef struct OMAPI2C {
>> } OMAPI2C;
>>
>>
>> -/* FIXME Use TBD readw qtest API */
>> -static inline uint16_t readw(uint64_t addr)
>> -{
>> -uint16_t data;
>> -
>> -memread(addr, &data, 2);
>> -return le16_to_cpu(data);
>> -}
>> -
>> -/* FIXME Use TBD writew qtest API */
>> -static inline void writew(uint64_t addr, uint16_t data)
>> -{
>> -data = cpu_to_le16(data);
>> -memwrite(addr, &data, 2);
>> -}
>> -
>> -#ifdef __GNUC__
>> -#undef memread
>> -#undef memwrite
>> -#pragma GCC poison memread
>> -#pragma GCC poison memwrite
>> -#endif
>> -
>> static void omap_i2c_set_slave_addr(OMAPI2C *s, uint8_t addr)
>> {
>> uint16_t data = addr;
>> diff --git a/tests/libqtest.c b/tests/libqtest.c
>> index 762dec4..5a627d3 100644
>> --- a/tests/libqtest.c
>> +++ b/tests/libqtest.c
>> @@ -431,6 +431,66 @@ uint32_t qtest_inl(QTestState *s, uint16_t addr)
>> return qtest_in(s, "inl", addr);
>> }
>>
>> +static void qtest_write(QTestState *s, const char *cmd, uint64_t addr,
>> +uint64_t value)
>> +{
>> +qtest_sendf(s, "%s 0x%" PRIx64 " 0x%" PRIx64 "\n", cmd, addr, value);
>> +qtest_rsp(s, 0);
>> +}
>> +
>> +void qtest_writeb(QTestState *s, uint64_t addr, uint8_t value)
>> +{
>> +qtest_write(s, "writeb", addr, value);
>> +}
>> +
>> +void qtest_wri
Re: [Qemu-devel] [PATCH for-1.4 v2 1/5] qtest: Use strtoull() for uint64_t
Andreas Färber writes:
> On 32-bit hosts, unsigned long may be uint32_t and uint64_t may be
> unsigned long long. Account for this by always using strtoull().
> We were already using strtoll() for int64_t.
>
> Signed-off-by: Andreas Färber
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
> ---
> qtest.c |8
> 1 Datei geändert, 4 Zeilen hinzugefügt(+), 4 Zeilen entfernt(-)
>
> diff --git a/qtest.c b/qtest.c
> index b7a3821..4663a38 100644
> --- a/qtest.c
> +++ b/qtest.c
> @@ -282,8 +282,8 @@ static void qtest_process_command(CharDriverState *chr,
> gchar **words)
> uint8_t *data;
>
> g_assert(words[1] && words[2]);
> -addr = strtoul(words[1], NULL, 0);
> -len = strtoul(words[2], NULL, 0);
> +addr = strtoull(words[1], NULL, 0);
> +len = strtoull(words[2], NULL, 0);
>
> data = g_malloc(len);
> cpu_physical_memory_read(addr, data, len);
> @@ -302,8 +302,8 @@ static void qtest_process_command(CharDriverState *chr,
> gchar **words)
> size_t data_len;
>
> g_assert(words[1] && words[2] && words[3]);
> -addr = strtoul(words[1], NULL, 0);
> -len = strtoul(words[2], NULL, 0);
> +addr = strtoull(words[1], NULL, 0);
> +len = strtoull(words[2], NULL, 0);
>
> data_len = strlen(words[3]);
> if (data_len < 3) {
> --
> 1.7.10.4
[Qemu-devel] [PATCH for-1.4 v3 2/6] error: Clean up abuse of error_report() for help
Use error_printf() instead, so the help gets presented more nicely.
Signed-off-by: Markus Armbruster
---
hw/vfio_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/vfio_pci.c b/hw/vfio_pci.c
index 66537b7..a934f13 100644
--- a/hw/vfio_pci.c
+++ b/hw/vfio_pci.c
@@ -1806,9 +1806,9 @@ static int vfio_get_device(VFIOGroup *group, const char
*name, VFIODevice *vdev)
ret = ioctl(group->fd, VFIO_GROUP_GET_DEVICE_FD, name);
if (ret < 0) {
-error_report("vfio: error getting device %s from group %d: %m\n",
+error_report("vfio: error getting device %s from group %d: %m",
name, group->groupid);
-error_report("Verify all devices in group %d are bound to vfio-pci "
+error_printf("Verify all devices in group %d are bound to vfio-pci "
"or pci-stub and not already in use\n", group->groupid);
return ret;
}
--
1.7.11.7
[Qemu-devel] [PATCH for-1.4 v3 0/6] Error reporting fixes
I tagged this for 1.4 because the patches improve the user experience a bit, and are all low risk. v3: * Fix another instance of the bug in PATCH 06 (Luiz Capitulino) v2: * Clean up messages touched by PATCH 01 some more (Peter Maydell) * The other patches are unchanged Markus Armbruster (6): error: Clean up error strings with embedded newlines error: Clean up abuse of error_report() for help error: Strip trailing '\n' from error string arguments (again) qemu-option: Disable two helpful messages that got broken recently vl: Drop redundant "parse error" reports vl: Exit unsuccessfully on option argument syntax error block/gluster.c | 2 +- hmp.c | 2 +- hw/9pfs/virtio-9p-proxy.c | 2 +- hw/kvm/pci-assign.c | 12 ++--- hw/pci/pci.c| 2 +- hw/qdev.c | 4 +- hw/qxl.c| 2 +- hw/vfio_pci.c | 114 ++-- hw/vhost_net.c | 4 +- migration.c | 2 +- qemu-char.c | 8 ++-- target-i386/cpu.c | 10 ++-- target-ppc/translate_init.c | 2 +- ui/console.c| 2 +- ui/input.c | 2 +- util/qemu-config.c | 6 +-- util/qemu-option.c | 4 ++ util/qemu-sockets.c | 6 +-- vl.c| 20 19 files changed, 107 insertions(+), 99 deletions(-) -- 1.7.11.7
[Qemu-devel] [PATCH for-1.4 v3 3/6] error: Strip trailing '\n' from error string arguments (again)
Commit 6daf194d and be62a2eb got rid of a bunch, but they keep coming
back. Tracked down with this Coccinelle semantic patch:
@r@
expression err, eno, cls, fmt;
position p;
@@
(
error_report(fmt, ...)@p
|
error_set(err, cls, fmt, ...)@p
|
error_set_errno(err, eno, cls, fmt, ...)@p
|
error_setg(err, fmt, ...)@p
|
error_setg_errno(err, eno, fmt, ...)@p
)
@script:python@
fmt << r.fmt;
p << r.p;
@@
if "\\n" in str(fmt):
print "%s:%s:%s:%s" % (p[0].file, p[0].line, p[0].column, fmt)
Signed-off-by: Markus Armbruster
---
block/gluster.c | 2 +-
hmp.c | 2 +-
hw/9pfs/virtio-9p-proxy.c | 2 +-
hw/pci/pci.c| 2 +-
hw/qdev.c | 4 +-
hw/qxl.c| 2 +-
hw/vfio_pci.c | 110 ++--
hw/vhost_net.c | 4 +-
migration.c | 2 +-
qemu-char.c | 8 ++--
target-i386/cpu.c | 10 ++--
target-ppc/translate_init.c | 2 +-
ui/console.c| 2 +-
ui/input.c | 2 +-
util/qemu-config.c | 6 +--
util/qemu-sockets.c | 6 +--
16 files changed, 83 insertions(+), 83 deletions(-)
diff --git a/block/gluster.c b/block/gluster.c
index 0f2c32a..ccd684d 100644
--- a/block/gluster.c
+++ b/block/gluster.c
@@ -217,7 +217,7 @@ static struct glfs *qemu_gluster_init(GlusterConf *gconf,
const char *filename)
ret = glfs_init(glfs);
if (ret) {
error_report("Gluster connection failed for server=%s port=%d "
- "volume=%s image=%s transport=%s\n", gconf->server, gconf->port,
+ "volume=%s image=%s transport=%s", gconf->server, gconf->port,
gconf->volname, gconf->image, gconf->transport);
goto out;
}
diff --git a/hmp.c b/hmp.c
index 420d48b..2f47a8a 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1365,7 +1365,7 @@ void hmp_chardev_add(Monitor *mon, const QDict *qdict)
opts = qemu_opts_parse(qemu_find_opts("chardev"), args, 1);
if (opts == NULL) {
-error_setg(&err, "Parsing chardev args failed\n");
+error_setg(&err, "Parsing chardev args failed");
} else {
qemu_chr_new_from_opts(opts, NULL, &err);
}
diff --git a/hw/9pfs/virtio-9p-proxy.c b/hw/9pfs/virtio-9p-proxy.c
index d5ad208..54e9875 100644
--- a/hw/9pfs/virtio-9p-proxy.c
+++ b/hw/9pfs/virtio-9p-proxy.c
@@ -521,7 +521,7 @@ static int v9fs_request(V9fsProxy *proxy, int type,
}
break;
default:
-error_report("Invalid type %d\n", type);
+error_report("Invalid type %d", type);
retval = -EINVAL;
break;
}
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 905dc4a..2f45c8f 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1132,7 +1132,7 @@ PCIINTxRoute pci_device_route_intx_to_irq(PCIDevice *dev,
int pin)
} while (dev);
if (!bus->route_intx_to_irq) {
-error_report("PCI: Bug - unimplemented PCI INTx routing (%s)\n",
+error_report("PCI: Bug - unimplemented PCI INTx routing (%s)",
object_get_typename(OBJECT(bus->qbus.parent)));
return (PCIINTxRoute) { PCI_INTX_DISABLED, -1 };
}
diff --git a/hw/qdev.c b/hw/qdev.c
index 8258757..689cd54 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -114,11 +114,11 @@ DeviceState *qdev_create(BusState *bus, const char *name)
dev = qdev_try_create(bus, name);
if (!dev) {
if (bus) {
-error_report("Unknown device '%s' for bus '%s'\n", name,
+error_report("Unknown device '%s' for bus '%s'", name,
object_get_typename(OBJECT(bus)));
abort();
} else {
-error_report("Unknown device '%s' for default sysbus\n", name);
+error_report("Unknown device '%s' for default sysbus", name);
abort();
}
}
diff --git a/hw/qxl.c b/hw/qxl.c
index a125e29..2e1c5e2 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -2036,7 +2036,7 @@ static int qxl_init_common(PCIQXLDevice *qxl)
qxl->ssd.qxl.base.sif = &qxl_interface.base;
qxl->ssd.qxl.id = qxl->id;
if (qemu_spice_add_interface(&qxl->ssd.qxl.base) != 0) {
-error_report("qxl interface %d.%d not supported by spice-server\n",
+error_report("qxl interface %d.%d not supported by spice-server",
SPICE_INTERFACE_QXL_MAJOR, SPICE_INTERFACE_QXL_MINOR);
return -1;
}
diff --git a/hw/vfio_pci.c b/hw/vfio_pci.c
index a934f13..ad9ae36 100644
--- a/hw/vfio_pci.c
+++ b/hw/vfio_pci.c
@@ -289,7 +289,7 @@ static void vfio_enable_intx_kvm(VFIODevice *vdev)
/* Get an eventfd for resample/unmask */
if (event_notifier_init(&vdev->intx.unmask, 0)) {
-error_report("vfio: Error: event_notifier_init failed eoi\n");
+error_report("vfio: Error: event_notifier_in
[Qemu-devel] [Bug 1119686] [NEW] Incorrect handling of icebp
Public bug reported: Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: exception.c:202: exception 0: 8004 flags:0 addr:003F exception.c:208: Test failed: 0: Wrong exception address 003F/003F0001 exception.c:214: this is the last test seen before the exception exception: unhandled exception 8004 at 003F exception.c:202: exception 0: c027 flags:2 addr:7C80E0B9 exception.c:205: Test failed: 0: Wrong exception code c027/8004 exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental). ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "Test executable and source" https://bugs.launchpad.net/bugs/1119686/+attachment/3521163/+files/exception.tar.bz2 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1119686 Title: Incorrect handling of icebp Status in QEMU: New Bug description: Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: exception.c:202: exception 0: 8004 flags:0 addr:003F exception.c:208: Test failed: 0: Wrong exception address 003F/003F0001 exception.c:214: this is the last test seen before the exception exception: unhandled exception 8004 at 003F exception.c:202: exception 0: c027 flags:2 addr:7C80E0B9 exception.c:205: Test failed: 0: Wrong exception code c027/8004 exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1119686/+subscriptions
[Qemu-devel] [PATCH for-1.4 v3 5/6] vl: Drop redundant "parse error" reports
qemu_opts_parse() reports the error already, and in a much more useful
way.
Signed-off-by: Markus Armbruster
---
vl.c | 4
1 file changed, 4 deletions(-)
diff --git a/vl.c b/vl.c
index a8dc73d..73122d8 100644
--- a/vl.c
+++ b/vl.c
@@ -3334,7 +3334,6 @@ int main(int argc, char **argv, char **envp)
}
opts = qemu_opts_parse(olist, optarg, 1);
if (!opts) {
-fprintf(stderr, "parse error: %s\n", optarg);
exit(1);
}
break;
@@ -3350,7 +3349,6 @@ int main(int argc, char **argv, char **envp)
}
opts = qemu_opts_parse(olist, optarg, 1);
if (!opts) {
-fprintf(stderr, "parse error: %s\n", optarg);
exit(1);
}
@@ -3521,7 +3519,6 @@ int main(int argc, char **argv, char **envp)
olist = qemu_find_opts("machine");
opts = qemu_opts_parse(olist, optarg, 1);
if (!opts) {
-fprintf(stderr, "parse error: %s\n", optarg);
exit(1);
}
optarg = qemu_opt_get(opts, "type");
@@ -3755,7 +3752,6 @@ int main(int argc, char **argv, char **envp)
}
opts = qemu_opts_parse(olist, optarg, 0);
if (!opts) {
-fprintf(stderr, "parse error: %s\n", optarg);
exit(1);
}
break;
--
1.7.11.7
Re: [Qemu-devel] [PATCH] linux-user: make bogus negative iovec lengths fail EINVAL
On 2013-02-08 09:58, Peter Maydell wrote: If the guest passes us a bogus negative length for an iovec, fail EINVAL rather than proceeding blindly forward. This fixes some of the error cases tests for readv and writev in the LTP. Signed-off-by: Peter Maydell --- I guess I'll resend this mixed bag of linux-user patches as a single series after the trunk reopens; feel free to review in the meantime :-) linux-user/syscall.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH] linux-user: Implement sendfile and sendfile64
On 2013-02-08 09:31, Peter Maydell wrote: Implement the sendfile and sendfile64 syscalls. This implementation passes all the LTP test cases for these syscalls. Signed-off-by: Peter Maydell --- This test-driven-development thing is fun :-) configure| 17 linux-user/syscall.c | 53 ++ 2 files changed, 70 insertions(+) Reviewed-by: Richard Henderson r~
[Qemu-devel] [PATCH for-1.4 v3 4/6] qemu-option: Disable two helpful messages that got broken recently
commit 8be7e7e4 and commit ec7b2ccb messed up the ordering of error
message and the helpful explanation that should follow it, like this:
$ qemu-system-x86_64 --nodefaults -S --vnc :0 --chardev null,id=,
Identifiers consist of letters, digits, '-', '.', '_', starting with a
letter.
qemu-system-x86_64: -chardev null,id=,: Parameter 'id' expects an identifier
$ qemu-system-x86_64 --nodefaults -S --vnc :0 --machine kvm_shadow_mem=dunno
You may use k, M, G or T suffixes for kilobytes, megabytes, gigabytes and
terabytes.
qemu-system-x86_64: -machine kvm_shadow_mem=dunno: Parameter
'kvm_shadow_mem' expects a size
Pity. Disable them for now.
Signed-off-by: Markus Armbruster
---
util/qemu-option.c | 4
1 file changed, 4 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index c12e724..5a1d03c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -231,8 +231,10 @@ static void parse_option_size(const char *name, const char
*value,
break;
default:
error_set(errp, QERR_INVALID_PARAMETER_VALUE, name, "a size");
+#if 0 /* conversion from qerror_report() to error_set() broke this: */
error_printf_unless_qmp("You may use k, M, G or T suffixes for "
"kilobytes, megabytes, gigabytes and terabytes.\n");
+#endif
return;
}
} else {
@@ -771,7 +773,9 @@ QemuOpts *qemu_opts_create(QemuOptsList *list, const char
*id,
if (id) {
if (!id_wellformed(id)) {
error_set(errp,QERR_INVALID_PARAMETER_VALUE, "id", "an
identifier");
+#if 0 /* conversion from qerror_report() to error_set() broke this: */
error_printf_unless_qmp("Identifiers consist of letters, digits,
'-', '.', '_', starting with a letter.\n");
+#endif
return NULL;
}
opts = qemu_opts_find(list, id);
--
1.7.11.7
[Qemu-devel] [PATCH for-1.4 v3 6/6] vl: Exit unsuccessfully on option argument syntax error
We exit successfully after reporting syntax error for argument of
--sandbox and --add-fd.
We continue undaunted after reporting it for argument of -boot,
--option-rom and --object.
Change all five to exit unsuccessfully, like the other options.
Signed-off-by: Markus Armbruster
---
vl.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/vl.c b/vl.c
index 73122d8..1355f69 100644
--- a/vl.c
+++ b/vl.c
@@ -3135,8 +3135,10 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
}
-qemu_opts_parse(qemu_find_opts("boot-opts"),
-optarg, 0);
+if (!qemu_opts_parse(qemu_find_opts("boot-opts"),
+ optarg, 0)) {
+exit(1);
+}
}
}
break;
@@ -3623,6 +3625,9 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
opts = qemu_opts_parse(qemu_find_opts("option-rom"), optarg,
1);
+if (!opts) {
+exit(1);
+}
option_rom[nb_option_roms].name = qemu_opt_get(opts,
"romfile");
option_rom[nb_option_roms].bootindex =
qemu_opt_get_number(opts, "bootindex", -1);
@@ -3780,14 +3785,14 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_sandbox:
opts = qemu_opts_parse(qemu_find_opts("sandbox"), optarg, 1);
if (!opts) {
-exit(0);
+exit(1);
}
break;
case QEMU_OPTION_add_fd:
#ifndef _WIN32
opts = qemu_opts_parse(qemu_find_opts("add-fd"), optarg, 0);
if (!opts) {
-exit(0);
+exit(1);
}
#else
error_report("File descriptor passing is disabled on this "
@@ -3797,6 +3802,9 @@ int main(int argc, char **argv, char **envp)
break;
case QEMU_OPTION_object:
opts = qemu_opts_parse(qemu_find_opts("object"), optarg, 1);
+if (!opts) {
+exit(1);
+}
break;
default:
os_parse_cmd_args(popt->index, optarg);
--
1.7.11.7
[Qemu-devel] [PATCH for-1.4 v3 1/6] error: Clean up error strings with embedded newlines
The arguments of error_report() should yield a short error string
without newlines.
A few places try to print additional help after the error message by
embedding newlines in the error string. That's nice, but let's do it
the right way.
Since I'm touching these lines anyway, drop a stray preposition and
some tabs. We don't use tabs for similar messages elsewhere.
Signed-off-by: Markus Armbruster
---
hw/kvm/pci-assign.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 896cfe8..da64b5b 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -936,8 +936,8 @@ retry:
/* Retry with host-side MSI. There might be an IRQ conflict and
* either the kernel or the device doesn't support sharing. */
error_report("Host-side INTx sharing not supported, "
- "using MSI instead.\n"
- "Some devices do not to work properly in this mode.");
+ "using MSI instead");
+error_printf("Some devices do not work properly in this mode.\n");
dev->features |= ASSIGNED_DEVICE_PREFER_MSI_MASK;
goto retry;
}
@@ -1903,10 +1903,10 @@ static void assigned_dev_load_option_rom(AssignedDevice
*dev)
memset(ptr, 0xff, st.st_size);
if (!fread(ptr, 1, st.st_size, fp)) {
-error_report("pci-assign: Cannot read from host %s\n"
- "\tDevice option ROM contents are probably invalid "
- "(check dmesg).\n\tSkip option ROM probe with rombar=0, "
- "or load from file with romfile=", rom_file);
+error_report("pci-assign: Cannot read from host %s", rom_file);
+error_printf("Device option ROM contents are probably invalid "
+ "(check dmesg).\nSkip option ROM probe with rombar=0, "
+ "or load from file with romfile=\n");
memory_region_destroy(&dev->dev.rom);
goto close_rom;
}
--
1.7.11.7
Re: [Qemu-devel] [PATCH] linux-user: Implement accept4
On 2013-02-08 06:35, Peter Maydell wrote: Implement the accept4 syscall (which is identical to accept but has an additional flags argument). Signed-off-by: Peter Maydell --- Passes all the LTP accept and accept4 tests... linux-user/syscall.c | 39 +++ 1 file changed, 31 insertions(+), 8 deletions(-) Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH] linux-user/syscall.c: Don't warn about unimplemented get_robust_list
On 2013-02-08 06:34, Peter Maydell wrote: The nature of the kernel ABI for the get_robust_list and set_robust_list syscalls means we cannot implement them in QEMU. Make get_robust_list silently return ENOSYS rather than using the default "print message and then fail ENOSYS" code path, in the same way we already do for set_robust_list, and add a comment documenting why we do this. This silences warnings which were being produced for emulating even trivial programs like 'ls' in x86-64-on-x86-64. Signed-off-by: Peter Maydell --- linux-user/syscall.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH for-1.4 v2 1/6] error: Clean up error strings with embedded newlines
Luiz Capitulino writes:
> On Fri, 08 Feb 2013 19:56:17 +0100
> Markus Armbruster wrote:
>
>> Luiz Capitulino writes:
>>
>> > On Fri, 8 Feb 2013 17:17:07 +0100
>> > Markus Armbruster wrote:
>> >
>> >> The arguments of error_report() should yield a short error string
>> >> without newlines.
>> >>
>> >> A few places try to print additional help after the error message by
>> >> embedding newlines in the error string. That's nice, but let's do it
>> >> the right way.
>> >>
>> >> Since I'm touching these lines anyway, drop a stray preposition and
>> >> some tabs. We don't use tabs for similar messages elsewhere.
>> >>
>> >> Signed-off-by: Markus Armbruster
>> >> ---
>> >> hw/kvm/pci-assign.c | 12 ++--
>> >> 1 file changed, 6 insertions(+), 6 deletions(-)
>> >>
>> >> diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
>> >> index 896cfe8..da64b5b 100644
>> >> --- a/hw/kvm/pci-assign.c
>> >> +++ b/hw/kvm/pci-assign.c
>> >> @@ -936,8 +936,8 @@ retry:
>> >> /* Retry with host-side MSI. There might be an IRQ conflict
>> >> and
>> >> * either the kernel or the device doesn't support sharing.
>> >> */
>> >> error_report("Host-side INTx sharing not supported, "
>> >> - "using MSI instead.\n"
>> >> - "Some devices do not to work properly in this
>> >> mode.");
>> >> + "using MSI instead");
>> >> +error_printf("Some devices do not work properly in this
>> >> mode.\n");
>> >
>> > This is fixing command-line, right?
>>
>> Whatever made assign_intx() run. I'm not familiar with this code, and I
>> don't know how to trigger the error.
>>
>> Hmm, one call chain is via PCIDeviceClass init method assigned_initfn().
>> So it could also be device_add.
>>
>> > I honestly don't know which is less worse, the current code or having
>> > to call two different functions in the correct order to report an
>> > error :(
>>
>> You call one function to report the error. In the rare case that you
>> want to add some explanation or hint to the error message, you use
>> another function to print to the error destination. Big deal :)
>
> I think the important point is not whether or not this is a big deal,
> but that this is a bad API which will break from time to time (as it's
> more or less the case now).
See the discussion we're having under PATCH 4/6.
>> Explanations and hints are *not* error messages. Sticking them into the
>> error string like the code does before my patch happens to work due to
>> the way error_report() formats the error message. Relying on that is
>> unclean. Besides, error_report()'s function comment clearly stipulates
>> "no newlines".
>
> I agree.
>
> But regarding this patch, we first have to decide whether or not this is
> good for 1.4 and then we have to come with a better solution for this
> (post 1.4).
>
> Regarding the first point, I have to questions:
>
> 1. Were the additional newlines added in 1.4?
Both offending calls were added in commit c3ebd3ba during 1.3
development.
> 2. What's the worse case here?
"worse"?
It's a cleanup. It's only user-visible effect is getting rid of an
extra newline on stderr. I'm fixing those globally. Tiny improvement
in user experience, but next to no risk, thus proposed for 1.4. Since I
need to touch this call anyway for that, I can just as well clean up the
API abuse. The alternative is to leave the abuse alone and just strip
the final newline. That would make me sad.
If you hate the API, fix it. Don't make me not fix abuses of it :)
Re: [Qemu-devel] [PATCH for-1.4 v2 4/6] qemu-option: Disable two helpful messages that got broken recently
Luiz Capitulino writes: > On Fri, 08 Feb 2013 19:58:42 +0100 > Markus Armbruster wrote: > >> Luiz Capitulino writes: >> >> > On Fri, 8 Feb 2013 17:17:10 +0100 >> > Markus Armbruster wrote: >> > >> >> commit 8be7e7e4 and commit ec7b2ccb messed up the ordering of error >> >> message and the helpful explanation that should follow it, like this: >> >> >> >> $ qemu-system-x86_64 --nodefaults -S --vnc :0 --chardev null,id=, >> >> Identifiers consist of letters, digits, '-', '.', '_', starting >> >> with a letter. >> >> qemu-system-x86_64: -chardev null,id=,: Parameter 'id' expects >> >> an identifier >> >> >> >> $ qemu-system-x86_64 --nodefaults -S --vnc :0 --machine >> >> kvm_shadow_mem=dunno >> >> You may use k, M, G or T suffixes for kilobytes, megabytes, >> >> gigabytes and terabytes. >> >> qemu-system-x86_64: -machine kvm_shadow_mem=dunno: Parameter >> >> kvm_shadow_mem' expects a size >> >> >> >> Pity. Disable them for now. >> > >> > Oops, sorry. I think I'd prefer to drop them, but as this fixes the >> > problem: >> > >> > Reviewed-by: Luiz Capitulino >> > >> > Also, the real problem here is that general functions like >> > parse_option_size() >> > should never assume/try to guess in which context they're running. So, the >> > best solution here is either to have a general enough error message that's >> > not tied to any context, or let up layers (say vl.c) concatenate the >> > context-dependent part of the error message. >> >> I'm open to suggestions on how to better code the pattern "report an >> error (a short string without newlines) together with some explanation >> or hint (possibly longer string, newlines okay). > > The real problem here is that the k, M, G suffixes, for example, are not > good to be reported by QMP. So maybe we should refactor the code in a way > that we separate what's done in QMP from what is done in HMP/command-line. Isn't it separated already? parse_option_size() is used when parsing key=value,... Such strings should not exist in QMP. If they do, it's a design bug.
Re: [Qemu-devel] [PATCH for-1.4 v2 4/6] qemu-option: Disable two helpful messages that got broken recently
Luiz Capitulino writes: > On Fri, 8 Feb 2013 17:17:10 +0100 > Markus Armbruster wrote: > >> commit 8be7e7e4 and commit ec7b2ccb messed up the ordering of error >> message and the helpful explanation that should follow it, like this: >> >> $ qemu-system-x86_64 --nodefaults -S --vnc :0 --chardev null,id=, >> Identifiers consist of letters, digits, '-', '.', '_', starting >> with a letter. >> qemu-system-x86_64: -chardev null,id=,: Parameter 'id' expects >> an identifier >> >> $ qemu-system-x86_64 --nodefaults -S --vnc :0 --machine >> kvm_shadow_mem=dunno >> You may use k, M, G or T suffixes for kilobytes, megabytes, >> gigabytes and terabytes. >> qemu-system-x86_64: -machine kvm_shadow_mem=dunno: Parameter >> kvm_shadow_mem' expects a size >> >> Pity. Disable them for now. > > Oops, sorry. I think I'd prefer to drop them, but as this fixes the problem: > > Reviewed-by: Luiz Capitulino > > Also, the real problem here is that general functions like parse_option_size() > should never assume/try to guess in which context they're running. So, the > best solution here is either to have a general enough error message that's > not tied to any context, or let up layers (say vl.c) concatenate the > context-dependent part of the error message. I'm open to suggestions on how to better code the pattern "report an error (a short string without newlines) together with some explanation or hint (possibly longer string, newlines okay).
Re: [Qemu-devel] [PATCH for-1.4 stable] block/curl: disable extra protocols to prevent CVE-2013-0249
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 3/4] This patch adds new qemu-img subcommand that compares content of two disk images.
On 02/08/2013 01:33 AM, Miroslav Rezanina wrote:
> This patch adds new qemu-img subcommand that compares content of two disk
> images.
>
> +static int64_t sectors_to_process(int64_t total, int64_t from)
> +{
> +return MIN((total - from), (IO_BUF_SIZE >> BDRV_SECTOR_BITS));
Why the spurious ()? This can be written:
return MIN(total - from, IO_BUF_SIZE >> BDRV_SECTOR_BITS);
unless the definition of MIN() is horribly busted (in which case, fix
the broken macro, don't make callers suffer).
> +/*
> + * Compares two images. Exit codes:
> + *
> + * 0 - Images are identical
> + * 1 - Images differ
> + * <0 - Error occurred
> + */
> +static int img_compare(int argc, char **argv)
> +{
> +const char *fmt1 = NULL, *fmt2 = NULL, *filename1, *filename2;
> +BlockDriverState *bs1, *bs2;
> +int64_t total_sectors1, total_sectors2;
> +uint8_t *buf1 = NULL, *buf2 = NULL;
> +int pnum1, pnum2;
> +int allocated1, allocated2;
> +int ret = 0; /* return value - 0 Ident, 1 Different, 2 Error */
This comment disagrees with the comment at the top of the function. I
would just delete the comment here, instead of trying to keep them in sync.
> Commit the changes recorded in @var{filename} in its base image.
>
> +@item compare [-f @var{fmt}] [-F @var{fmt}] [-p] [-s] [-q] @var{filename1}
> @var{filename2}
While this line is okay long...
> +
> +Check if two images have the same content. You can compare images with
> +different format or settings.
> +
> +The format is probed unless you specify it by @var{-f} (used for
> @var{filename1}) and/or @var{-F} (used for @var{filename2}) option.
...this line should be wrapped.
> +
> +Compare exits with @code{0} in case the images are equal and with @code{1}
> +in case the images differ. Negative exit code means an error occured during
s/occured/occurred/
There's no such thing as a negative exit in shell. Rather, you should
document that an exit code > 1 indicates an error during execution.
> +execution and standard error output should contain an error message.
> +Error exit codes are:
> +
> +@table @option
> +
> +@item -1
> +Error on opening an image
> +@item -2
> +Error on cheking a sector allorcation
s/cheking/checking/
s/allorcation/allocation/
> +@item -3
> +Error on reading data
Does it make sense to be this fine-grained in exit reporting? I'd be
okay with blindly using exit status 2 for all failures. But if you
really do want to call out this many different statuses, I'd list a
single table for ALL possible exits, rather than prose about success and
table for failure, as in:
0 - images are identical
1 - images differ
2 - error opening an image
3 - error checking sector allocation
4 - error reading from an image
Isn't failure to determine sector allocation a subset of failure to read
from an image?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for-1.4 v2 0/6] Error reporting fixes
On Fri, 08 Feb 2013 19:59:55 +0100 Markus Armbruster wrote: > Luiz, would you like to take v3 through your tree? In that case I'd > drop qemu-trivial. Yes, I can do it.
Re: [Qemu-devel] [PATCH for-1.4 v2 4/6] qemu-option: Disable two helpful messages that got broken recently
On Fri, 08 Feb 2013 19:58:42 +0100 Markus Armbruster wrote: > Luiz Capitulino writes: > > > On Fri, 8 Feb 2013 17:17:10 +0100 > > Markus Armbruster wrote: > > > >> commit 8be7e7e4 and commit ec7b2ccb messed up the ordering of error > >> message and the helpful explanation that should follow it, like this: > >> > >> $ qemu-system-x86_64 --nodefaults -S --vnc :0 --chardev null,id=, > >> Identifiers consist of letters, digits, '-', '.', '_', starting > >> with a letter. > >> qemu-system-x86_64: -chardev null,id=,: Parameter 'id' expects > >> an identifier > >> > >> $ qemu-system-x86_64 --nodefaults -S --vnc :0 --machine > >> kvm_shadow_mem=dunno > >> You may use k, M, G or T suffixes for kilobytes, megabytes, > >> gigabytes and terabytes. > >> qemu-system-x86_64: -machine kvm_shadow_mem=dunno: Parameter > >> kvm_shadow_mem' expects a size > >> > >> Pity. Disable them for now. > > > > Oops, sorry. I think I'd prefer to drop them, but as this fixes the problem: > > > > Reviewed-by: Luiz Capitulino > > > > Also, the real problem here is that general functions like > > parse_option_size() > > should never assume/try to guess in which context they're running. So, the > > best solution here is either to have a general enough error message that's > > not tied to any context, or let up layers (say vl.c) concatenate the > > context-dependent part of the error message. > > I'm open to suggestions on how to better code the pattern "report an > error (a short string without newlines) together with some explanation > or hint (possibly longer string, newlines okay). The real problem here is that the k, M, G suffixes, for example, are not good to be reported by QMP. So maybe we should refactor the code in a way that we separate what's done in QMP from what is done in HMP/command-line.
Re: [Qemu-devel] [PATCH for-1.4] net: fix infinite loop on exit
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.4 v2 1/6] error: Clean up error strings with embedded newlines
On Fri, 08 Feb 2013 19:56:17 +0100
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > On Fri, 8 Feb 2013 17:17:07 +0100
> > Markus Armbruster wrote:
> >
> >> The arguments of error_report() should yield a short error string
> >> without newlines.
> >>
> >> A few places try to print additional help after the error message by
> >> embedding newlines in the error string. That's nice, but let's do it
> >> the right way.
> >>
> >> Since I'm touching these lines anyway, drop a stray preposition and
> >> some tabs. We don't use tabs for similar messages elsewhere.
> >>
> >> Signed-off-by: Markus Armbruster
> >> ---
> >> hw/kvm/pci-assign.c | 12 ++--
> >> 1 file changed, 6 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
> >> index 896cfe8..da64b5b 100644
> >> --- a/hw/kvm/pci-assign.c
> >> +++ b/hw/kvm/pci-assign.c
> >> @@ -936,8 +936,8 @@ retry:
> >> /* Retry with host-side MSI. There might be an IRQ conflict
> >> and
> >> * either the kernel or the device doesn't support sharing. */
> >> error_report("Host-side INTx sharing not supported, "
> >> - "using MSI instead.\n"
> >> - "Some devices do not to work properly in this
> >> mode.");
> >> + "using MSI instead");
> >> +error_printf("Some devices do not work properly in this
> >> mode.\n");
> >
> > This is fixing command-line, right?
>
> Whatever made assign_intx() run. I'm not familiar with this code, and I
> don't know how to trigger the error.
>
> Hmm, one call chain is via PCIDeviceClass init method assigned_initfn().
> So it could also be device_add.
>
> > I honestly don't know which is less worse, the current code or having
> > to call two different functions in the correct order to report an
> > error :(
>
> You call one function to report the error. In the rare case that you
> want to add some explanation or hint to the error message, you use
> another function to print to the error destination. Big deal :)
I think the important point is not whether or not this is a big deal,
but that this is a bad API which will break from time to time (as it's
more or less the case now).
> Explanations and hints are *not* error messages. Sticking them into the
> error string like the code does before my patch happens to work due to
> the way error_report() formats the error message. Relying on that is
> unclean. Besides, error_report()'s function comment clearly stipulates
> "no newlines".
I agree.
But regarding this patch, we first have to decide whether or not this is
good for 1.4 and then we have to come with a better solution for this
(post 1.4).
Regarding the first point, I have to questions:
1. Were the additional newlines added in 1.4?
2. What's the worse case here?
Re: [Qemu-devel] [PATCH V2 0/3] set config size using available features
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH 0/2] virtio-net: fix config size for older guests
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.4 v2 0/6] Error reporting fixes
Luiz, would you like to take v3 through your tree? In that case I'd drop qemu-trivial.
Re: [Qemu-devel] [PATCH for-1.4] xilinx_zynq: Fix wrong IRQ number of the second EHCI controller
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for 1.4] qemu-nbd: document --cache and --aio options
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.4 v2 1/6] error: Clean up error strings with embedded newlines
Luiz Capitulino writes:
> On Fri, 8 Feb 2013 17:17:07 +0100
> Markus Armbruster wrote:
>
>> The arguments of error_report() should yield a short error string
>> without newlines.
>>
>> A few places try to print additional help after the error message by
>> embedding newlines in the error string. That's nice, but let's do it
>> the right way.
>>
>> Since I'm touching these lines anyway, drop a stray preposition and
>> some tabs. We don't use tabs for similar messages elsewhere.
>>
>> Signed-off-by: Markus Armbruster
>> ---
>> hw/kvm/pci-assign.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
>> index 896cfe8..da64b5b 100644
>> --- a/hw/kvm/pci-assign.c
>> +++ b/hw/kvm/pci-assign.c
>> @@ -936,8 +936,8 @@ retry:
>> /* Retry with host-side MSI. There might be an IRQ conflict and
>> * either the kernel or the device doesn't support sharing. */
>> error_report("Host-side INTx sharing not supported, "
>> - "using MSI instead.\n"
>> - "Some devices do not to work properly in this
>> mode.");
>> + "using MSI instead");
>> +error_printf("Some devices do not work properly in this
>> mode.\n");
>
> This is fixing command-line, right?
Whatever made assign_intx() run. I'm not familiar with this code, and I
don't know how to trigger the error.
Hmm, one call chain is via PCIDeviceClass init method assigned_initfn().
So it could also be device_add.
> I honestly don't know which is less worse, the current code or having
> to call two different functions in the correct order to report an
> error :(
You call one function to report the error. In the rare case that you
want to add some explanation or hint to the error message, you use
another function to print to the error destination. Big deal :)
Explanations and hints are *not* error messages. Sticking them into the
error string like the code does before my patch happens to work due to
the way error_report() formats the error message. Relying on that is
unclean. Besides, error_report()'s function comment clearly stipulates
"no newlines".
> I'd say the best solution for this would be to propagate errors, but this
> will loose LOC support.
I'm unwilling to degrade error message quality even further.
Re: [Qemu-devel] [PATCH for-1.4 v2 6/6] vl: Exit unsuccessfully on option argument syntax error
Luiz Capitulino writes: > On Fri, 8 Feb 2013 17:17:12 +0100 > Markus Armbruster wrote: > >> We exit successfully after reporting syntax error for argument of >> --sandbox and --add-fd. >> >> We continue undaunted after reporting it for argument of --option-rom >> and --object then. >> >> Change all four to exit unsuccessfully, like the other options. >> >> Signed-off-by: Markus Armbruster > > Reviewed-by: Luiz Capitulino > > What about qemu_opts_parse() call in QEMU_OPTION_boot? You're right! I fixed in my tree, but then the fix hid in a not-for-1.4 commit. Will extract it for 1.4.
Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
On Fri, Feb 08, 2013 at 06:35:56PM +0100, Borislav Petkov wrote: > On Fri, Feb 08, 2013 at 01:58:58PM -0200, Eduardo Habkost wrote: > > [ … ] > > > As we don't have a decent method to do that today, we are using static > > variables and compatibility-setup functions called from the machine init > > function. See disable_kvm_pv_eoi() for example. > > > > One day we will be able to do that using properties on the machine-type > > compat_props tables, but we can't do that yet. > > Ok, understood. > > > People can easily work around the lack of the feature today, using > > "-cpu n270,+movbe", > > Are you sure? > > $ qemu-system-i386 -snapshot ... -cpu n270,+movbe ... Using TCG, right? > > from latest qemu master doesn't seem to work here. We still don't see > bit 22 in ECX of CPUID.EAX(1) advertized to the guest. Replace "the lack of the feature" with "the lack of this specific patch" on my message above. For either your patch or the "+movbe" workaround to work, you first need the feature to be working. > > But that's not the big problem - we still need the actual implementation > of MOVBE in qemu otherwise the guest kernel #GPs when trying to execute > that instruction. If you don't have the implementation of MOVBE working (and included on TCG_EXT_FEATURES), neither your patch or "+movbe" can help you. -- Eduardo
Re: [Qemu-devel] [PATCH 3/5] target-i386: Slim conversion to X86CPU subclasses
On Fri, Feb 08, 2013 at 05:54:50PM +0100, Andreas Färber wrote:
> Am 08.02.2013 15:52, schrieb Eduardo Habkost:
> > On Fri, Feb 08, 2013 at 01:58:42PM +0100, Igor Mammedov wrote:
> >> On Fri, 08 Feb 2013 12:16:17 +0100
> >> Andreas Färber wrote:
> >>> Am 08.02.2013 10:03, schrieb Igor Mammedov:
> On Thu, 7 Feb 2013 13:08:19 -0200
> Eduardo Habkost wrote:
>
> > On Tue, Feb 05, 2013 at 05:39:22PM +0100, Igor Mammedov wrote:
> >> @@ -2236,6 +2083,44 @@ static void x86_cpu_initfn(Object *obj)
> >> }
> >> }
> >>
> >> +static void x86_cpu_def_class_init(ObjectClass *oc, void *data)
> >> +{
> >> +X86CPUClass *xcc = X86_CPU_CLASS(oc);
> >> +ObjectClass *hoc = object_class_by_name(TYPE_HOST_X86_CPU);
> >> +X86CPUClass *hostcc;
> >> +x86_def_t *def = data;
> >> +int i;
> >> +static const char *versioned_models[] = { "qemu32", "qemu64",
> >> "athlon" };
> >> +
> >> +memcpy(&xcc->info, def, sizeof(x86_def_t));
> >> +
> >> +/* host cpu class is available if KVM is enabled,
> >> + * get kvm overrides from it */
> >> +if (hoc) {
> >> +hostcc = X86_CPU_CLASS(hoc);
> >> +/* sysenter isn't supported in compatibility mode on AMD,
> >> + * syscall isn't supported in compatibility mode on Intel.
> >> + * Normally we advertise the actual CPU vendor, but you can
> >> + * override this using the 'vendor' property if you want to
> >> use
> >> + * KVM's sysenter/syscall emulation in compatibility mode and
> >> + * when doing cross vendor migration
> >> + */
> >> +memcpy(xcc->info.vendor, hostcc->info.vendor,
> >> + sizeof(xcc->info.vendor));
> >> +}
> >
> > Again, we have the same problem we had before, but now in the non-host
> > classes. What if class_init is called before KVM is initialized? I
> > believe we will be forced to move this hack to the instance init
> > function.
> I believe, the in the case where non-host CPU classes might be
> initialized
> before KVM "-cpu ?" we do not care what their defaults are, since we only
> would use class names there and then exit.
>
> For case where classes could be inspected over QMP, OQM, KVM would be
> already
> initialized if enabled and we would get proper initialization order
> without
> hack.
> >
> > Who guarantees that KVM will be already initialized when we get a QMP
> > monitor? We can't do that today because of limitations in the QEMU main
> > code, but I believe we want to get rid of this limitation eventually,
> > instead of making it harder to get rid of.
> >
> > If we could initialize KVM before QMP is initialized, we could simply
> > initialize KVM before class_init is called, instead. It would be easier
> > to reason about, and it would make the limitations of our code very
> > clear to anybody reading the code in main().
>
> That wouldn't work (currently) due to -device and -object being command
> line options just like -enable-kvm, -disable-kvm and -machine accel=.
Well, we could loop over the command-line options twice.
It is just an alternative that would be better than making class_init
unreliable. I don't think it would be a great solution anyway.
>
> >>>
> >>> I think you're missing Eduardo's and my point:
> >>>
> >>> diff --git a/vl.c b/vl.c
> >>> index a8dc73d..6b9378e 100644
> >>> --- a/vl.c
> >>> +++ b/vl.c
> >>> @@ -2844,6 +2844,7 @@ int main(int argc, char **argv, char **envp)
> >>> }
> >>>
> >>> module_call_init(MODULE_INIT_QOM);
> >>> +object_class_foreach(walkerfn, TYPE_OBJECT, false, NULL);
> >>>
> >>> qemu_add_opts(&qemu_drive_opts);
> >>> qemu_add_opts(&qemu_chardev_opts);
> >>>
> >>> Anyone may iterate over QOM classes at any time after their type
> >>> registration, which is before the first round of option parsing.
> >>> Sometime later, after option parsing, there's the -cpu ? handling in
> >>> vl.c:3854, then vl.c:4018:configure_accelerator().
> >>>
> >>> Like I said, mostly a theoretical issue today.
> >> Question is if we should drop this theoretical issue for 1.5?
> >
> > I wouldn't call it just theoretical. It is something that will surely
> > hit us back. The people working on QMP or on the main() code 6 months
> > from now will no idea that our class_init code is broken and will
> > explode if class_init is called too early.
>
> We should try to find a reliable solution here or at least add
> appropriate comments to the module_call_init() call in vl.c.
Agreed. But I believe there are tons of other solutions that don't
require making class_init broken.
>
> >>> Originally I had considered making kvm_init() re-entrant and calling it
> >>> from the offending class_init. But we must support the distro case of
> >>> compiling with CONFIG_KVM but the user's hardw
Re: [Qemu-devel] [PATCH 4/4] qemu-iotests: Add qemu-img compare test
On 02/08/2013 01:33 AM, Miroslav Rezanina wrote: > Simple test for qemu-img compare to check it's working correctly. > > Signed-off-by: Miroslav Rezanina > --- > tests/qemu-iotests/048 | 77 > > tests/qemu-iotests/048.out | 25 ++ > tests/qemu-iotests/group |1 + > 3 files changed, 103 insertions(+), 0 deletions(-) > create mode 100755 tests/qemu-iotests/048 > create mode 100644 tests/qemu-iotests/048.out > > diff --git a/tests/qemu-iotests/048 b/tests/qemu-iotests/048 > new file mode 100755 > index 000..1264446 > --- /dev/null > +++ b/tests/qemu-iotests/048 > @@ -0,0 +1,77 @@ > +#!/bin/bash > +## > +## qemu-img compare test > +## > +## > +## Copyright (C) 2009 Red Hat, Inc. It's 2013 (prior years can be listed also, if you were substantially cribbing content from other tests). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for-1.4 v2 6/6] vl: Exit unsuccessfully on option argument syntax error
On Fri, 8 Feb 2013 17:17:12 +0100
Markus Armbruster wrote:
> We exit successfully after reporting syntax error for argument of
> --sandbox and --add-fd.
>
> We continue undaunted after reporting it for argument of --option-rom
> and --object then.
>
> Change all four to exit unsuccessfully, like the other options.
>
> Signed-off-by: Markus Armbruster
Reviewed-by: Luiz Capitulino
What about qemu_opts_parse() call in QEMU_OPTION_boot?
> ---
> vl.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index 73122d8..4245ccc 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3623,6 +3623,9 @@ int main(int argc, char **argv, char **envp)
> exit(1);
> }
> opts = qemu_opts_parse(qemu_find_opts("option-rom"), optarg,
> 1);
> +if (!opts) {
> +exit(1);
> +}
> option_rom[nb_option_roms].name = qemu_opt_get(opts,
> "romfile");
> option_rom[nb_option_roms].bootindex =
> qemu_opt_get_number(opts, "bootindex", -1);
> @@ -3780,14 +3783,14 @@ int main(int argc, char **argv, char **envp)
> case QEMU_OPTION_sandbox:
> opts = qemu_opts_parse(qemu_find_opts("sandbox"), optarg, 1);
> if (!opts) {
> -exit(0);
> +exit(1);
> }
> break;
> case QEMU_OPTION_add_fd:
> #ifndef _WIN32
> opts = qemu_opts_parse(qemu_find_opts("add-fd"), optarg, 0);
> if (!opts) {
> -exit(0);
> +exit(1);
> }
> #else
> error_report("File descriptor passing is disabled on this "
> @@ -3797,6 +3800,9 @@ int main(int argc, char **argv, char **envp)
> break;
> case QEMU_OPTION_object:
> opts = qemu_opts_parse(qemu_find_opts("object"), optarg, 1);
> +if (!opts) {
> +exit(1);
> +}
> break;
> default:
> os_parse_cmd_args(popt->index, optarg);
[Qemu-devel] [PATCH] linux-user: make bogus negative iovec lengths fail EINVAL
If the guest passes us a bogus negative length for an iovec, fail
EINVAL rather than proceeding blindly forward. This fixes some of
the error cases tests for readv and writev in the LTP.
Signed-off-by: Peter Maydell
---
I guess I'll resend this mixed bag of linux-user patches as a single
series after the trunk reopens; feel free to review in the meantime :-)
linux-user/syscall.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 35df073..d38eb24 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -1779,7 +1779,7 @@ static struct iovec *lock_iovec(int type, abi_ulong
target_addr,
errno = 0;
return NULL;
}
-if (count > IOV_MAX) {
+if (count < 0 || count > IOV_MAX) {
errno = EINVAL;
return NULL;
}
--
1.7.9.5
Re: [Qemu-devel] [PATCH for-1.4 v2 5/6] vl: Drop redundant "parse error" reports
On Fri, 8 Feb 2013 17:17:11 +0100
Markus Armbruster wrote:
> qemu_opts_parse() reports the error already, and in a much more useful
> way.
>
> Signed-off-by: Markus Armbruster
Reviewed-by: Luiz Capitulino
> ---
> vl.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index a8dc73d..73122d8 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3334,7 +3334,6 @@ int main(int argc, char **argv, char **envp)
> }
> opts = qemu_opts_parse(olist, optarg, 1);
> if (!opts) {
> -fprintf(stderr, "parse error: %s\n", optarg);
> exit(1);
> }
> break;
> @@ -3350,7 +3349,6 @@ int main(int argc, char **argv, char **envp)
> }
> opts = qemu_opts_parse(olist, optarg, 1);
> if (!opts) {
> -fprintf(stderr, "parse error: %s\n", optarg);
> exit(1);
> }
>
> @@ -3521,7 +3519,6 @@ int main(int argc, char **argv, char **envp)
> olist = qemu_find_opts("machine");
> opts = qemu_opts_parse(olist, optarg, 1);
> if (!opts) {
> -fprintf(stderr, "parse error: %s\n", optarg);
> exit(1);
> }
> optarg = qemu_opt_get(opts, "type");
> @@ -3755,7 +3752,6 @@ int main(int argc, char **argv, char **envp)
> }
> opts = qemu_opts_parse(olist, optarg, 0);
> if (!opts) {
> -fprintf(stderr, "parse error: %s\n", optarg);
> exit(1);
> }
> break;
Re: [Qemu-devel] [RFC qom-cpu v2 03/28] target-arm: Update ARMCPU to QOM realizefn
Am 08.02.2013 18:35, schrieb Peter Maydell: > On 8 February 2013 17:31, Andreas Färber wrote: >> Am 07.02.2013 19:56, schrieb Peter Maydell: >>> An idle thought: I wonder if we could rearrange things so that >>> the target-specific TCG init is called via tcg_init(), to >>> parallel the way that target-specific KVM init is called >>> via kvm_init()? > >> I think that would be counter-productive. KVM is a host technology, it >> depends on whether you're running the right target arch and whether it's >> available/usable on your host. Since you're running on a single host, >> there's only one KVM init to call. >> >> The reason we made it conditional to tcg_enabled() is QTest, which >> doesn't need it. Nor will KVM on ARM. >> >> For TCG I'm hoping to enable multiple targets coexisting at some point, >> so consolidating things into *CPUClass and instance_init seems better. >> There's no ugly #ifdef'ery involved for TCG. > > That would suggest that some of the KVM init should also go > via the CPU object; consider a system with one KVM-accelerated > core and one TCG core of a different architecture. Yes, I had considered such a mixed scenario but pushed it aside for now because most kvm_enabled() and tcg_enabled() checks would need to get refactored then, which would be quite invasive for a not yet supported and hard to verify constellation. If someone with a use case wanted to send patches I would certainly help with review. ;-) For the current x86 subclasses discussion this thought would mean that we should try to keep KVM/no-KVM decisions to object instances. 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 for-1.4 v2 4/6] qemu-option: Disable two helpful messages that got broken recently
On Fri, 8 Feb 2013 17:17:10 +0100
Markus Armbruster wrote:
> commit 8be7e7e4 and commit ec7b2ccb messed up the ordering of error
> message and the helpful explanation that should follow it, like this:
>
> $ qemu-system-x86_64 --nodefaults -S --vnc :0 --chardev null,id=,
> Identifiers consist of letters, digits, '-', '.', '_', starting with a
> letter.
> qemu-system-x86_64: -chardev null,id=,: Parameter 'id' expects an
> identifier
>
> $ qemu-system-x86_64 --nodefaults -S --vnc :0 --machine
> kvm_shadow_mem=dunno
> You may use k, M, G or T suffixes for kilobytes, megabytes, gigabytes and
> terabytes.
> qemu-system-x86_64: -machine kvm_shadow_mem=dunno: Parameter
> 'kvm_shadow_mem' expects a size
>
> Pity. Disable them for now.
Oops, sorry. I think I'd prefer to drop them, but as this fixes the problem:
Reviewed-by: Luiz Capitulino
Also, the real problem here is that general functions like parse_option_size()
should never assume/try to guess in which context they're running. So, the
best solution here is either to have a general enough error message that's
not tied to any context, or let up layers (say vl.c) concatenate the
context-dependent part of the error message.
>
> Signed-off-by: Markus Armbruster
> ---
> util/qemu-option.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/util/qemu-option.c b/util/qemu-option.c
> index c12e724..5a1d03c 100644
> --- a/util/qemu-option.c
> +++ b/util/qemu-option.c
> @@ -231,8 +231,10 @@ static void parse_option_size(const char *name, const
> char *value,
> break;
> default:
> error_set(errp, QERR_INVALID_PARAMETER_VALUE, name, "a size");
> +#if 0 /* conversion from qerror_report() to error_set() broke this: */
> error_printf_unless_qmp("You may use k, M, G or T suffixes for "
> "kilobytes, megabytes, gigabytes and terabytes.\n");
> +#endif
> return;
> }
> } else {
> @@ -771,7 +773,9 @@ QemuOpts *qemu_opts_create(QemuOptsList *list, const char
> *id,
> if (id) {
> if (!id_wellformed(id)) {
> error_set(errp,QERR_INVALID_PARAMETER_VALUE, "id", "an
> identifier");
> +#if 0 /* conversion from qerror_report() to error_set() broke this: */
> error_printf_unless_qmp("Identifiers consist of letters, digits,
> '-', '.', '_', starting with a letter.\n");
> +#endif
> return NULL;
> }
> opts = qemu_opts_find(list, id);
Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation
Am 08.02.2013 13:14, schrieb Jeff Cody:
> On Fri, Feb 08, 2013 at 09:38:47AM +0100, Kevin Wolf wrote:
>> Am 07.02.2013 20:26, schrieb Stefan Weil:
>>> From: Stefan Weil
>>>
>>> The size calculated from the CHS values is not the real image (disk) size,
>>> but usually a smaller value. This is caused by rounding effects.
>>>
>>> Only older operating systems use CHS. Such guests won't be able to use
>>> the whole disk. All modern operating systems use the real size.
>>>
>>> This patch fixes https://bugs.launchpad.net/qemu/+bug/1105670/.
>>>
>>> Signed-off-by: Stefan Weil
>>> ---
>>>
>>> This is a rebased extract from my patch series for block/vpc.c.
>>> It's the minimum needed to fix the open bug for QEMU 1.4.
>>>
>>> The rest of the series can be discussed and applied after 1.4.
>>>
>>> Regards
>>>
>>> Stefan W.
>>>
>>> PS. Please excuse a previous personal mail which I had sent
>>> with a wrong signature and without addressing qemu-devel.
>>>
>>> block/vpc.c | 14 +-
>>> 1 file changed, 9 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/block/vpc.c b/block/vpc.c
>>> index 82229ef..b4ff564 100644
>>> --- a/block/vpc.c
>>> +++ b/block/vpc.c
>>> @@ -34,6 +34,8 @@
>>>
>>> #define HEADER_SIZE 512
>>>
>>> +#define VHD_SECTOR_SIZE 512
>>> +
>>> //#define CACHE
>>>
>>> enum vhd_type {
>>> @@ -204,11 +206,13 @@ static int vpc_open(BlockDriverState *bs, int flags)
>>> /* Write 'checksum' back to footer, or else will leave it with zero. */
>>> footer->checksum = be32_to_cpu(checksum);
>>>
>>> -// The visible size of a image in Virtual PC depends on the geometry
>>> -// rather than on the size stored in the footer (the size in the footer
>>> -// is too large usually)
>>> -bs->total_sectors = (int64_t)
>>> -be16_to_cpu(footer->cyls) * footer->heads * footer->secs_per_cyl;
>>> +/* The visible size of a image in Virtual PC depends on the guest:
>>> + * QEMU and other emulators report the real size (here in sectors).
>>> + * All modern operating systems use this real size.
>>> + * Very old operating systems use CHS values to calculate the total
>>> size.
>>> + * This calculated size is usually smaller than the real size.
>>> + */
>>> +bs->total_sectors = be64_to_cpu(footer->size) / VHD_SECTOR_SIZE;
>> It's unfortunate that I don't have my old Virtual PC installation around
>> any more so I could prove that you're wrong for at least some versions.
>> Or does a Linux of 2009 already count as "very old"?
Linux is a modern OS per definition :-)
I made an additional test with Knoppix (from December 2006),
and it worked as expected.
>>
>> If we want to commit this - and I still feel uncomfortable about it -
>> then maybe it's best to remove the comment altogether instead of making
>> such claims. The new code is the intuitively expected one anyway.
>>
>> Kevin
> Kevin,
>
> I can test this on Virtual PC on a Win 7 install, as well as
> Hyper-V (I've already tested the equivalent of this patch on Hyper-V
> on Windows Server 2012). I'll do some testing today with this - if
> you have anything in particular you want me to look at, just let me
> know.
>
> Stefan, did you test if this behaves the same for all disk sizes, or
> only for larger disk sizes of 127G and up?
This behaves the same in a test with a small (16 MiB) image.
Regards,
Stefan W.
Re: [Qemu-devel] [PATCH for-1.4 v2 3/6] error: Strip trailing '\n' from error string arguments (again)
On Fri, 8 Feb 2013 17:17:09 +0100
Markus Armbruster wrote:
> Commit 6daf194d and be62a2eb got rid of a bunch, but they keep coming
> back. Tracked down with this Coccinelle semantic patch:
>
> @r@
> expression err, eno, cls, fmt;
> position p;
> @@
> (
> error_report(fmt, ...)@p
> |
> error_set(err, cls, fmt, ...)@p
> |
> error_set_errno(err, eno, cls, fmt, ...)@p
> |
> error_setg(err, fmt, ...)@p
> |
> error_setg_errno(err, eno, fmt, ...)@p
> )
> @script:python@
> fmt << r.fmt;
> p << r.p;
> @@
> if "\\n" in str(fmt):
> print "%s:%s:%s:%s" % (p[0].file, p[0].line, p[0].column, fmt)
>
> Signed-off-by: Markus Armbruster
Reviewed-by: Luiz Capitulino
> ---
> block/gluster.c | 2 +-
> hmp.c | 2 +-
> hw/9pfs/virtio-9p-proxy.c | 2 +-
> hw/pci/pci.c| 2 +-
> hw/qdev.c | 4 +-
> hw/qxl.c| 2 +-
> hw/vfio_pci.c | 110
> ++--
> hw/vhost_net.c | 4 +-
> migration.c | 2 +-
> qemu-char.c | 8 ++--
> target-i386/cpu.c | 10 ++--
> target-ppc/translate_init.c | 2 +-
> ui/console.c| 2 +-
> ui/input.c | 2 +-
> util/qemu-config.c | 6 +--
> util/qemu-sockets.c | 6 +--
> 16 files changed, 83 insertions(+), 83 deletions(-)
>
> diff --git a/block/gluster.c b/block/gluster.c
> index 0f2c32a..ccd684d 100644
> --- a/block/gluster.c
> +++ b/block/gluster.c
> @@ -217,7 +217,7 @@ static struct glfs *qemu_gluster_init(GlusterConf *gconf,
> const char *filename)
> ret = glfs_init(glfs);
> if (ret) {
> error_report("Gluster connection failed for server=%s port=%d "
> - "volume=%s image=%s transport=%s\n", gconf->server, gconf->port,
> + "volume=%s image=%s transport=%s", gconf->server, gconf->port,
> gconf->volname, gconf->image, gconf->transport);
> goto out;
> }
> diff --git a/hmp.c b/hmp.c
> index 420d48b..2f47a8a 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -1365,7 +1365,7 @@ void hmp_chardev_add(Monitor *mon, const QDict *qdict)
>
> opts = qemu_opts_parse(qemu_find_opts("chardev"), args, 1);
> if (opts == NULL) {
> -error_setg(&err, "Parsing chardev args failed\n");
> +error_setg(&err, "Parsing chardev args failed");
> } else {
> qemu_chr_new_from_opts(opts, NULL, &err);
> }
> diff --git a/hw/9pfs/virtio-9p-proxy.c b/hw/9pfs/virtio-9p-proxy.c
> index d5ad208..54e9875 100644
> --- a/hw/9pfs/virtio-9p-proxy.c
> +++ b/hw/9pfs/virtio-9p-proxy.c
> @@ -521,7 +521,7 @@ static int v9fs_request(V9fsProxy *proxy, int type,
> }
> break;
> default:
> -error_report("Invalid type %d\n", type);
> +error_report("Invalid type %d", type);
> retval = -EINVAL;
> break;
> }
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 905dc4a..2f45c8f 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -1132,7 +1132,7 @@ PCIINTxRoute pci_device_route_intx_to_irq(PCIDevice
> *dev, int pin)
> } while (dev);
>
> if (!bus->route_intx_to_irq) {
> -error_report("PCI: Bug - unimplemented PCI INTx routing (%s)\n",
> +error_report("PCI: Bug - unimplemented PCI INTx routing (%s)",
> object_get_typename(OBJECT(bus->qbus.parent)));
> return (PCIINTxRoute) { PCI_INTX_DISABLED, -1 };
> }
> diff --git a/hw/qdev.c b/hw/qdev.c
> index 8258757..689cd54 100644
> --- a/hw/qdev.c
> +++ b/hw/qdev.c
> @@ -114,11 +114,11 @@ DeviceState *qdev_create(BusState *bus, const char
> *name)
> dev = qdev_try_create(bus, name);
> if (!dev) {
> if (bus) {
> -error_report("Unknown device '%s' for bus '%s'\n", name,
> +error_report("Unknown device '%s' for bus '%s'", name,
> object_get_typename(OBJECT(bus)));
> abort();
> } else {
> -error_report("Unknown device '%s' for default sysbus\n", name);
> +error_report("Unknown device '%s' for default sysbus", name);
> abort();
> }
> }
> diff --git a/hw/qxl.c b/hw/qxl.c
> index a125e29..2e1c5e2 100644
> --- a/hw/qxl.c
> +++ b/hw/qxl.c
> @@ -2036,7 +2036,7 @@ static int qxl_init_common(PCIQXLDevice *qxl)
> qxl->ssd.qxl.base.sif = &qxl_interface.base;
> qxl->ssd.qxl.id = qxl->id;
> if (qemu_spice_add_interface(&qxl->ssd.qxl.base) != 0) {
> -error_report("qxl interface %d.%d not supported by spice-server\n",
> +error_report("qxl interface %d.%d not supported by spice-server",
> SPICE_INTERFACE_QXL_MAJOR, SPICE_INTERFACE_QXL_MINOR);
> return -1;
> }
> diff --git a/hw/vfio_pci.c b/hw/vfio_pci.c
> index a934f13..ad9ae36 10
Re: [Qemu-devel] [PATCH for-1.4 v2 1/6] error: Clean up error strings with embedded newlines
On Fri, 8 Feb 2013 17:17:07 +0100
Markus Armbruster wrote:
> The arguments of error_report() should yield a short error string
> without newlines.
>
> A few places try to print additional help after the error message by
> embedding newlines in the error string. That's nice, but let's do it
> the right way.
>
> Since I'm touching these lines anyway, drop a stray preposition and
> some tabs. We don't use tabs for similar messages elsewhere.
>
> Signed-off-by: Markus Armbruster
> ---
> hw/kvm/pci-assign.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
> index 896cfe8..da64b5b 100644
> --- a/hw/kvm/pci-assign.c
> +++ b/hw/kvm/pci-assign.c
> @@ -936,8 +936,8 @@ retry:
> /* Retry with host-side MSI. There might be an IRQ conflict and
> * either the kernel or the device doesn't support sharing. */
> error_report("Host-side INTx sharing not supported, "
> - "using MSI instead.\n"
> - "Some devices do not to work properly in this
> mode.");
> + "using MSI instead");
> +error_printf("Some devices do not work properly in this
> mode.\n");
This is fixing command-line, right?
I honestly don't know which is less worse, the current code or having
to call two different functions in the correct order to report an
error :(
I'd say the best solution for this would be to propagate errors, but this
will loose LOC support.
> dev->features |= ASSIGNED_DEVICE_PREFER_MSI_MASK;
> goto retry;
> }
> @@ -1903,10 +1903,10 @@ static void
> assigned_dev_load_option_rom(AssignedDevice *dev)
> memset(ptr, 0xff, st.st_size);
>
> if (!fread(ptr, 1, st.st_size, fp)) {
> -error_report("pci-assign: Cannot read from host %s\n"
> - "\tDevice option ROM contents are probably invalid "
> - "(check dmesg).\n\tSkip option ROM probe with rombar=0,
> "
> - "or load from file with romfile=", rom_file);
> +error_report("pci-assign: Cannot read from host %s", rom_file);
> +error_printf("Device option ROM contents are probably invalid "
> + "(check dmesg).\nSkip option ROM probe with rombar=0, "
> + "or load from file with romfile=\n");
> memory_region_destroy(&dev->dev.rom);
> goto close_rom;
> }
Re: [Qemu-devel] [PATCH] target-mips: fix for sign-issue in MULQ_W helper
On 2013-02-07 10:36, Petar Jovanovic wrote: From: Petar Jovanovic Correct sign-propagation before multiplication in MULQ_W helper. The change also fixes previously incorrect expected values in the tests for MULQ_RS.W and MULQ_S.W. Signed-off-by: Petar Jovanovic --- target-mips/dsp_helper.c|2 +- tests/tcg/mips/mips32-dspr2/mulq_rs_w.c |2 +- tests/tcg/mips/mips32-dspr2/mulq_s_w.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
On Fri, Feb 08, 2013 at 01:58:58PM -0200, Eduardo Habkost wrote: [ … ] > As we don't have a decent method to do that today, we are using static > variables and compatibility-setup functions called from the machine init > function. See disable_kvm_pv_eoi() for example. > > One day we will be able to do that using properties on the machine-type > compat_props tables, but we can't do that yet. Ok, understood. > People can easily work around the lack of the feature today, using > "-cpu n270,+movbe", Are you sure? $ qemu-system-i386 -snapshot ... -cpu n270,+movbe ... from latest qemu master doesn't seem to work here. We still don't see bit 22 in ECX of CPUID.EAX(1) advertized to the guest. But that's not the big problem - we still need the actual implementation of MOVBE in qemu otherwise the guest kernel #GPs when trying to execute that instruction. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Re: [Qemu-devel] [RFC qom-cpu v2 03/28] target-arm: Update ARMCPU to QOM realizefn
On 8 February 2013 17:31, Andreas Färber wrote: > Am 07.02.2013 19:56, schrieb Peter Maydell: >> An idle thought: I wonder if we could rearrange things so that >> the target-specific TCG init is called via tcg_init(), to >> parallel the way that target-specific KVM init is called >> via kvm_init()? > I think that would be counter-productive. KVM is a host technology, it > depends on whether you're running the right target arch and whether it's > available/usable on your host. Since you're running on a single host, > there's only one KVM init to call. > > The reason we made it conditional to tcg_enabled() is QTest, which > doesn't need it. Nor will KVM on ARM. > > For TCG I'm hoping to enable multiple targets coexisting at some point, > so consolidating things into *CPUClass and instance_init seems better. > There's no ugly #ifdef'ery involved for TCG. That would suggest that some of the KVM init should also go via the CPU object; consider a system with one KVM-accelerated core and one TCG core of a different architecture. Anyway, it was just an idle thought, as I said. -- PMM
[Qemu-devel] [PATCH] linux-user: Implement sendfile and sendfile64
Implement the sendfile and sendfile64 syscalls. This implementation
passes all the LTP test cases for these syscalls.
Signed-off-by: Peter Maydell
---
This test-driven-development thing is fun :-)
configure| 17
linux-user/syscall.c | 53 ++
2 files changed, 70 insertions(+)
diff --git a/configure b/configure
index 8789324..fd64e82 100755
--- a/configure
+++ b/configure
@@ -2715,6 +2715,20 @@ if compile_prog "" "" ; then
epoll_pwait=yes
fi
+# check for sendfile support
+sendfile=no
+cat > $TMPC << EOF
+#include
+
+int main(void)
+{
+return sendfile(0, 0, 0, 0);
+}
+EOF
+if compile_prog "" "" ; then
+ sendfile=yes
+fi
+
# Check if tools are available to build documentation.
if test "$docs" != "no" ; then
if has makeinfo && has pod2man; then
@@ -3551,6 +3565,9 @@ fi
if test "$epoll_pwait" = "yes" ; then
echo "CONFIG_EPOLL_PWAIT=y" >> $config_host_mak
fi
+if test "$sendfile" = "yes" ; then
+ echo "CONFIG_SENDFILE=y" >> $config_host_mak
+fi
if test "$inotify" = "yes" ; then
echo "CONFIG_INOTIFY=y" >> $config_host_mak
fi
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index fcdccfa..35df073 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -78,6 +78,9 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
#ifdef CONFIG_ATTR
#include "qemu/xattr.h"
#endif
+#ifdef CONFIG_SENDFILE
+#include
+#endif
#define termios host_termios
#define winsize host_winsize
@@ -7551,8 +7554,58 @@ abi_long do_syscall(void *cpu_env, int num, abi_long
arg1,
#else
goto unimplemented;
#endif
+
+#ifdef CONFIG_SENDFILE
+case TARGET_NR_sendfile:
+{
+off_t *offp = NULL;
+off_t off;
+if (arg3) {
+ret = get_user_sal(off, arg3);
+if (is_error(ret)) {
+break;
+}
+offp = &off;
+}
+ret = get_errno(sendfile(arg1, arg2, offp, arg4));
+if (!is_error(ret) && arg3) {
+abi_long ret2 = put_user_sal(off, arg3);
+if (is_error(ret2)) {
+ret = ret2;
+}
+}
+break;
+}
+#ifdef TARGET_NR_sendfile64
+case TARGET_NR_sendfile64:
+{
+off_t *offp = NULL;
+off_t off;
+if (arg3) {
+ret = get_user_s64(off, arg3);
+if (is_error(ret)) {
+break;
+}
+offp = &off;
+}
+ret = get_errno(sendfile(arg1, arg2, offp, arg4));
+if (!is_error(ret) && arg3) {
+abi_long ret2 = put_user_s64(off, arg3);
+if (is_error(ret2)) {
+ret = ret2;
+}
+}
+break;
+}
+#endif
+#else
case TARGET_NR_sendfile:
+#ifdef TARGET_NR_sendfile64:
+case TARGET_NR_sendfile64:
+#endif
goto unimplemented;
+#endif
+
#ifdef TARGET_NR_getpmsg
case TARGET_NR_getpmsg:
goto unimplemented;
--
1.7.9.5
Re: [Qemu-devel] [RFC qom-cpu v2 03/28] target-arm: Update ARMCPU to QOM realizefn
Am 07.02.2013 19:56, schrieb Peter Maydell: > On 7 February 2013 18:44, Andreas Färber wrote: >> Am 07.02.2013 17:31, schrieb Eduardo Habkost: >>> My first question I had when I saw this was: are you really sure it is >>> safe to call cpu_reset() and qemu_init_vcpu() before >>> arm_translate_init()? >>> >>> But I see that you change this on commit 092028dbf1. So now I have the >>> opposite question: are you really sure it is safe to call >>> arm_translate_init() before arm_cpu_realizefn()? >> >> The answer to either is yes. TCG initialization functions themselves >> (after this series latest) don't depend on CPU state and only calculate >> static field offsets (in one or two cases depending on CPU versions that >> I have inlined as part of the series). ARM's doesn't. If you spot any >> remaining exception to that rule, please shout. > > An idle thought: I wonder if we could rearrange things so that > the target-specific TCG init is called via tcg_init(), to > parallel the way that target-specific KVM init is called > via kvm_init()? That would avoid the slight oddity that > cpu_arm_init() &c have tcg_enabled()-specific code but not > kvm_enabled()-specific or other accelerator-specific init. > > I'm not sure it would be worth the effort to make that change, > though. I think that would be counter-productive. KVM is a host technology, it depends on whether you're running the right target arch and whether it's available/usable on your host. Since you're running on a single host, there's only one KVM init to call. The reason we made it conditional to tcg_enabled() is QTest, which doesn't need it. Nor will KVM on ARM. For TCG I'm hoping to enable multiple targets coexisting at some point, so consolidating things into *CPUClass and instance_init seems better. There's no ugly #ifdef'ery involved for TCG. I am still thinking about how to restructure TCG code - for one whether I can make TCG helpers optionally use CPUState at some point and for another how to consolidate the various global variables. We'd need only one cpu_env, I think - might go into CPUClass or as global into qom/cpu.c then. Cheers, 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 v2 00/15] propagate Errors to do_device_add()
On Tue, 5 Feb 2013 21:39:13 +0100 Laszlo Ersek wrote: > In v2, I'm mostly attempting to address Luiz's comments for v1: Apart from minor comments, looks good to me. Not sure if I did a good job on trying to suggest you a better splitting though. Also, I think it's a good idea for someone more familiar with qdev/QOM to review this too. Markus, maybe.
[Qemu-devel] [PATCH for-1.4 v2 1/6] error: Clean up error strings with embedded newlines
The arguments of error_report() should yield a short error string
without newlines.
A few places try to print additional help after the error message by
embedding newlines in the error string. That's nice, but let's do it
the right way.
Since I'm touching these lines anyway, drop a stray preposition and
some tabs. We don't use tabs for similar messages elsewhere.
Signed-off-by: Markus Armbruster
---
hw/kvm/pci-assign.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/kvm/pci-assign.c b/hw/kvm/pci-assign.c
index 896cfe8..da64b5b 100644
--- a/hw/kvm/pci-assign.c
+++ b/hw/kvm/pci-assign.c
@@ -936,8 +936,8 @@ retry:
/* Retry with host-side MSI. There might be an IRQ conflict and
* either the kernel or the device doesn't support sharing. */
error_report("Host-side INTx sharing not supported, "
- "using MSI instead.\n"
- "Some devices do not to work properly in this mode.");
+ "using MSI instead");
+error_printf("Some devices do not work properly in this mode.\n");
dev->features |= ASSIGNED_DEVICE_PREFER_MSI_MASK;
goto retry;
}
@@ -1903,10 +1903,10 @@ static void assigned_dev_load_option_rom(AssignedDevice
*dev)
memset(ptr, 0xff, st.st_size);
if (!fread(ptr, 1, st.st_size, fp)) {
-error_report("pci-assign: Cannot read from host %s\n"
- "\tDevice option ROM contents are probably invalid "
- "(check dmesg).\n\tSkip option ROM probe with rombar=0, "
- "or load from file with romfile=", rom_file);
+error_report("pci-assign: Cannot read from host %s", rom_file);
+error_printf("Device option ROM contents are probably invalid "
+ "(check dmesg).\nSkip option ROM probe with rombar=0, "
+ "or load from file with romfile=\n");
memory_region_destroy(&dev->dev.rom);
goto close_rom;
}
--
1.7.11.7
[Qemu-devel] [PATCH for-1.4 v2 2/6] error: Clean up abuse of error_report() for help
Use error_printf() instead, so the help gets presented more nicely.
Signed-off-by: Markus Armbruster
---
hw/vfio_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/vfio_pci.c b/hw/vfio_pci.c
index 66537b7..a934f13 100644
--- a/hw/vfio_pci.c
+++ b/hw/vfio_pci.c
@@ -1806,9 +1806,9 @@ static int vfio_get_device(VFIOGroup *group, const char
*name, VFIODevice *vdev)
ret = ioctl(group->fd, VFIO_GROUP_GET_DEVICE_FD, name);
if (ret < 0) {
-error_report("vfio: error getting device %s from group %d: %m\n",
+error_report("vfio: error getting device %s from group %d: %m",
name, group->groupid);
-error_report("Verify all devices in group %d are bound to vfio-pci "
+error_printf("Verify all devices in group %d are bound to vfio-pci "
"or pci-stub and not already in use\n", group->groupid);
return ret;
}
--
1.7.11.7
Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
This is problematic since the n270 qemu model won't boot a real kernel compiled
for that box.
Eduardo Habkost wrote:
>On Fri, Feb 08, 2013 at 10:30:02AM +0100, Borislav Petkov wrote:
>> From: Borislav Petkov
>>
>> The Atom core (cpu name "n270" in QEMU speak) supports MOVBE. This is
>> needed when booting 3.8 and later linux kernels built with the MATOM
>> target because we require MOVBE in order to boot properly now.
>>
>> Cc: "H. Peter Anvin"
>> Cc: Richard Henderson
>> Signed-off-by: Borislav Petkov
>> ---
>>
>> Right, so I was playing with booting MATOM kernels in QEMU.
>> As it turns out, QEMU's n270 model doesn't advertize MOVBE
>> although the real hardware supports it. Quick search pointed me to
>> http://lists.nongnu.org/archive/html/qemu-devel/2013-01/msg04317.html
>> which adds that support, among other things. I've merged Richard's
>> patchset with qemu's current master and after applying this patch
>below,
>> I can report success booting an MATOM kernel with QEMU. The same
>kernel
>> boots on the real n270 hardware, btw.
>>
>> target-i386/cpu.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> index 9f38e4435e53..83816edd8410 100644
>> --- a/target-i386/cpu.c
>> +++ b/target-i386/cpu.c
>> @@ -610,7 +610,8 @@ static x86_def_t builtin_x86_defs[] = {
>> CPUID_ACPI | CPUID_SS | CPUID_HT | CPUID_TM | CPUID_PBE,
>> /* Some CPUs got no CPUID_SEP */
>> .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR |
>CPUID_EXT_SSSE3 |
>> -CPUID_EXT_DSCPL | CPUID_EXT_EST | CPUID_EXT_TM2 |
>CPUID_EXT_XTPR,
>> +CPUID_EXT_DSCPL | CPUID_EXT_EST | CPUID_EXT_TM2 |
>CPUID_EXT_XTPR |
>> +CPUID_EXT_MOVBE,
>> .ext2_features = (PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES) |
>
>
>"-machine pc-1.3 -cpu n270" (and older machine-types) needs to keep
>MOVBE disabled, or you will break live migration.
>
>Personally I wouldn't mind declaring n270 as a non-migratable CPU
>model.
>But libvirt supports n270, so it already expects n270 to expose a
>stable
>ABI on each machine-type.
>
>
>> CPUID_EXT2_NX,
>> .ext3_features = CPUID_EXT3_LAHF_LM,
>> --
>> 1.8.1.2.422.g08c0e7f
>>
>>
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
Re: [Qemu-devel] [PATCH 2/2] qxl: change rom size to 8192
On 02/08/2013 04:36 AM, Gerd Hoffmann wrote: > Hi, > >>> foo.img generated with stock qemu 1.3.1, migration fails with git >>> head, still >>> fails after reverting the seabios 1.7.2 update which supposedly >>> causes other >>> migrate issues (commit 3588185b8396eb97fd9efd41c2b97775465f67c4) >> >> So this is by design - that patch changes the rom size for revision 4 (which >> is the default for qemu 1.3.1) from 16384 bytes to 8192. This breaks >> migration from previously created revision 4 images... But it unbreaks >> migration from other revisions. Different things that could be done: do a >> special migration hook to copy from src 16384 byte rom bar to dst 8192 byte >> rom bar. Gerd, what do you think? > > So the change making the rpm 16k was before 1.3, the fix thereafter, and > now we have migration 1.2 -> 1.3 broken (maybe masked by -M 1.2 > defaulting to qxl rev 3), 1.3 -> 1.4 broken and 1.2 -> 1.4 working, correct? > > So a compat property changing the rom size to 16k for pc-1.3 should do > the trick I think. > The example commands I gave were using -M pc-1.0, I can't tell if you're solution factors that in. Thanks, Cole
Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation
Am 08.02.2013 09:18, schrieb Stefan Hajnoczi: > On Thu, Feb 07, 2013 at 08:26:52PM +0100, Stefan Weil wrote: >> From: Stefan Weil > Should be "From: Stefan Weil "? Yes, of course. Maybe whoever applies the patch can fix this, please. Thanks, Stefan W.
Re: [Qemu-devel] [PATCH 2/4] qemu-img: Add "Quiet mode" option
On 02/08/2013 01:33 AM, Miroslav Rezanina wrote:
> There can be a need to turn output to stdout off. This patch adds a -q option
> that enable "Quiet mode". In Quiet mode, only errors are printed out.
>
> Signed-off-by: Miroslav Rezanina
> ---
>
> if (result.bfi.total_clusters != 0 && result.bfi.allocated_clusters !=
> 0) {
> -printf("%" PRId64 "/%" PRId64 "= %0.2f%% allocated, %0.2f%%
> fragmented\n",
> +/* BEWARE: parameter list not indented due to long expressions */
This code is being touched in an independent patch, with a solution much
nicer than adding a BEWARE comment:
https://lists.gnu.org/archive/html/qemu-devel/2013-02/msg01101.html
> +qprintf(quiet,
> +"%" PRId64 "/%" PRId64 "= %0.2f%% allocated, %0.2f%% fragmented\n",
> result.bfi.allocated_clusters, result.bfi.total_clusters,
> result.bfi.allocated_clusters * 100.0 / result.bfi.total_clusters,
> result.bfi.fragmented_clusters * 100.0 /
> result.bfi.allocated_clusters);
> +/* end of parameter list */
> }
This /* end of parameter list */ comment is bogus.
> @@ -742,9 +775,16 @@ static int img_convert(int argc, char **argv)
> case 't':
> cache = optarg;
> break;
> +case 'q':
> +quiet = true;
> +break;
> }
> }
>
> +if (quiet) {
> +progress = 0;
> +}
I'm still not sure I buy this. Since '-p' normally adds output, and
'-q' normally removes output, I'm wondering if it is better to follow
conventions of other apps like ls, when when faced with mutually
competing options will favor the last one specified. Something like:
qemu-img convert -p -q => turns off -p with quiet results
qemu-img convert -q -p => turns off -q, with progress bar results
Or, it might be worth actually erroring out if both -p and -q are
present, in any order.
> +++ b/qemu-img.texi
> @@ -54,6 +54,9 @@ indicates that target image must be compressed (qcow format
> only)
> with or without a command shows help and lists the supported formats
> @item -p
> display progress bar (convert and rebase commands only)
> +@item -q
> +Quiet mode - do not print any output (except errors). There's no progress bar
> +in case both @var{-q} and @var{-p} options are used.
But at least your documentation matches your code, so I guess I can live
with your choice that -q is always more powerful than -p, no matter what
order they appear in.
You have an extra space before the second @var.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH for-1.4 v2 4/6] qemu-option: Disable two helpful messages that got broken recently
commit 8be7e7e4 and commit ec7b2ccb messed up the ordering of error
message and the helpful explanation that should follow it, like this:
$ qemu-system-x86_64 --nodefaults -S --vnc :0 --chardev null,id=,
Identifiers consist of letters, digits, '-', '.', '_', starting with a
letter.
qemu-system-x86_64: -chardev null,id=,: Parameter 'id' expects an identifier
$ qemu-system-x86_64 --nodefaults -S --vnc :0 --machine kvm_shadow_mem=dunno
You may use k, M, G or T suffixes for kilobytes, megabytes, gigabytes and
terabytes.
qemu-system-x86_64: -machine kvm_shadow_mem=dunno: Parameter
'kvm_shadow_mem' expects a size
Pity. Disable them for now.
Signed-off-by: Markus Armbruster
---
util/qemu-option.c | 4
1 file changed, 4 insertions(+)
diff --git a/util/qemu-option.c b/util/qemu-option.c
index c12e724..5a1d03c 100644
--- a/util/qemu-option.c
+++ b/util/qemu-option.c
@@ -231,8 +231,10 @@ static void parse_option_size(const char *name, const char
*value,
break;
default:
error_set(errp, QERR_INVALID_PARAMETER_VALUE, name, "a size");
+#if 0 /* conversion from qerror_report() to error_set() broke this: */
error_printf_unless_qmp("You may use k, M, G or T suffixes for "
"kilobytes, megabytes, gigabytes and terabytes.\n");
+#endif
return;
}
} else {
@@ -771,7 +773,9 @@ QemuOpts *qemu_opts_create(QemuOptsList *list, const char
*id,
if (id) {
if (!id_wellformed(id)) {
error_set(errp,QERR_INVALID_PARAMETER_VALUE, "id", "an
identifier");
+#if 0 /* conversion from qerror_report() to error_set() broke this: */
error_printf_unless_qmp("Identifiers consist of letters, digits,
'-', '.', '_', starting with a letter.\n");
+#endif
return NULL;
}
opts = qemu_opts_find(list, id);
--
1.7.11.7
[Qemu-devel] [PATCH for-1.4 v2 0/6] Error reporting fixes
I tagged this for 1.4 because the patches improve the user experience a bit, and are all low risk. v2: * Clean up messages touched by PATCH 01 some more (Peter Maydell) * The other patches are unchanged Markus Armbruster (6): error: Clean up error strings with embedded newlines error: Clean up abuse of error_report() for help error: Strip trailing '\n' from error string arguments (again) qemu-option: Disable two helpful messages that got broken recently vl: Drop redundant "parse error" reports vl: Exit unsuccessfully on option argument syntax error block/gluster.c | 2 +- hmp.c | 2 +- hw/9pfs/virtio-9p-proxy.c | 2 +- hw/kvm/pci-assign.c | 12 ++--- hw/pci/pci.c| 2 +- hw/qdev.c | 4 +- hw/qxl.c| 2 +- hw/vfio_pci.c | 114 ++-- hw/vhost_net.c | 4 +- migration.c | 2 +- qemu-char.c | 8 ++-- target-i386/cpu.c | 10 ++-- target-ppc/translate_init.c | 2 +- ui/console.c| 2 +- ui/input.c | 2 +- util/qemu-config.c | 6 +-- util/qemu-option.c | 4 ++ util/qemu-sockets.c | 6 +-- vl.c| 14 +++--- 19 files changed, 103 insertions(+), 97 deletions(-) -- 1.7.11.7
[Qemu-devel] [PATCH for-1.4 v2 5/6] vl: Drop redundant "parse error" reports
qemu_opts_parse() reports the error already, and in a much more useful
way.
Signed-off-by: Markus Armbruster
---
vl.c | 4
1 file changed, 4 deletions(-)
diff --git a/vl.c b/vl.c
index a8dc73d..73122d8 100644
--- a/vl.c
+++ b/vl.c
@@ -3334,7 +3334,6 @@ int main(int argc, char **argv, char **envp)
}
opts = qemu_opts_parse(olist, optarg, 1);
if (!opts) {
-fprintf(stderr, "parse error: %s\n", optarg);
exit(1);
}
break;
@@ -3350,7 +3349,6 @@ int main(int argc, char **argv, char **envp)
}
opts = qemu_opts_parse(olist, optarg, 1);
if (!opts) {
-fprintf(stderr, "parse error: %s\n", optarg);
exit(1);
}
@@ -3521,7 +3519,6 @@ int main(int argc, char **argv, char **envp)
olist = qemu_find_opts("machine");
opts = qemu_opts_parse(olist, optarg, 1);
if (!opts) {
-fprintf(stderr, "parse error: %s\n", optarg);
exit(1);
}
optarg = qemu_opt_get(opts, "type");
@@ -3755,7 +3752,6 @@ int main(int argc, char **argv, char **envp)
}
opts = qemu_opts_parse(olist, optarg, 0);
if (!opts) {
-fprintf(stderr, "parse error: %s\n", optarg);
exit(1);
}
break;
--
1.7.11.7
Re: [Qemu-devel] [PATCH 0/4] Add subcommand compare for qemu-img
On 02/08/2013 01:33 AM, Miroslav Rezanina wrote: > This is 9th version of patch adding compare subcommand that > compares two images. Compare has following criteria: > - only data part is compared > - unallocated sectors are not read > to be zeroed/unallocated to compare rest > - qemu-img returns: > - 0 if images are identical > - 1 if images differ > - negative value on error If this really is v9, then please send as a top-level thread rather than in-reply-to an older thread, and please fix the subject line (git send-email --subject-prefix=PATCHv9) to make it obvious. > > v9: > - Merged patch 3 and 4 (subcommmand implementation and documentation) of v8 > - Added basic test for qemu-img compare > - Fixed incorrect indentation > - add bdrv_is_allocated_above() return value check > - Add description of exit codes into the documentation > - minor non-functional changes > -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 3/5] target-i386: Slim conversion to X86CPU subclasses
Am 08.02.2013 15:52, schrieb Eduardo Habkost:
> On Fri, Feb 08, 2013 at 01:58:42PM +0100, Igor Mammedov wrote:
>> On Fri, 08 Feb 2013 12:16:17 +0100
>> Andreas Färber wrote:
>>> Am 08.02.2013 10:03, schrieb Igor Mammedov:
On Thu, 7 Feb 2013 13:08:19 -0200
Eduardo Habkost wrote:
> On Tue, Feb 05, 2013 at 05:39:22PM +0100, Igor Mammedov wrote:
>> @@ -2236,6 +2083,44 @@ static void x86_cpu_initfn(Object *obj)
>> }
>> }
>>
>> +static void x86_cpu_def_class_init(ObjectClass *oc, void *data)
>> +{
>> +X86CPUClass *xcc = X86_CPU_CLASS(oc);
>> +ObjectClass *hoc = object_class_by_name(TYPE_HOST_X86_CPU);
>> +X86CPUClass *hostcc;
>> +x86_def_t *def = data;
>> +int i;
>> +static const char *versioned_models[] = { "qemu32", "qemu64",
>> "athlon" };
>> +
>> +memcpy(&xcc->info, def, sizeof(x86_def_t));
>> +
>> +/* host cpu class is available if KVM is enabled,
>> + * get kvm overrides from it */
>> +if (hoc) {
>> +hostcc = X86_CPU_CLASS(hoc);
>> +/* sysenter isn't supported in compatibility mode on AMD,
>> + * syscall isn't supported in compatibility mode on Intel.
>> + * Normally we advertise the actual CPU vendor, but you can
>> + * override this using the 'vendor' property if you want to use
>> + * KVM's sysenter/syscall emulation in compatibility mode and
>> + * when doing cross vendor migration
>> + */
>> +memcpy(xcc->info.vendor, hostcc->info.vendor,
>> + sizeof(xcc->info.vendor));
>> +}
>
> Again, we have the same problem we had before, but now in the non-host
> classes. What if class_init is called before KVM is initialized? I
> believe we will be forced to move this hack to the instance init
> function.
I believe, the in the case where non-host CPU classes might be initialized
before KVM "-cpu ?" we do not care what their defaults are, since we only
would use class names there and then exit.
For case where classes could be inspected over QMP, OQM, KVM would be
already
initialized if enabled and we would get proper initialization order without
hack.
>
> Who guarantees that KVM will be already initialized when we get a QMP
> monitor? We can't do that today because of limitations in the QEMU main
> code, but I believe we want to get rid of this limitation eventually,
> instead of making it harder to get rid of.
>
> If we could initialize KVM before QMP is initialized, we could simply
> initialize KVM before class_init is called, instead. It would be easier
> to reason about, and it would make the limitations of our code very
> clear to anybody reading the code in main().
That wouldn't work (currently) due to -device and -object being command
line options just like -enable-kvm, -disable-kvm and -machine accel=.
>>>
>>> I think you're missing Eduardo's and my point:
>>>
>>> diff --git a/vl.c b/vl.c
>>> index a8dc73d..6b9378e 100644
>>> --- a/vl.c
>>> +++ b/vl.c
>>> @@ -2844,6 +2844,7 @@ int main(int argc, char **argv, char **envp)
>>> }
>>>
>>> module_call_init(MODULE_INIT_QOM);
>>> +object_class_foreach(walkerfn, TYPE_OBJECT, false, NULL);
>>>
>>> qemu_add_opts(&qemu_drive_opts);
>>> qemu_add_opts(&qemu_chardev_opts);
>>>
>>> Anyone may iterate over QOM classes at any time after their type
>>> registration, which is before the first round of option parsing.
>>> Sometime later, after option parsing, there's the -cpu ? handling in
>>> vl.c:3854, then vl.c:4018:configure_accelerator().
>>>
>>> Like I said, mostly a theoretical issue today.
>> Question is if we should drop this theoretical issue for 1.5?
>
> I wouldn't call it just theoretical. It is something that will surely
> hit us back. The people working on QMP or on the main() code 6 months
> from now will no idea that our class_init code is broken and will
> explode if class_init is called too early.
We should try to find a reliable solution here or at least add
appropriate comments to the module_call_init() call in vl.c.
>>> Originally I had considered making kvm_init() re-entrant and calling it
>>> from the offending class_init. But we must support the distro case of
>>> compiling with CONFIG_KVM but the user's hardware not supporting KVM or
>>> kvm module not being loaded or the user having insufficient priviledges
>>> to access /dev/kvm.
>> working without KVM is not issue, it just works with normal defaults.
>> Applying
>> KVM specific defaults to already initialized classes is.
Right, but applying KVM-specific defaults is much easier once KVM is
initialized. :)
>
> My big question is: why exactly we want to initialize this stuff inside
> class_init? Can't we (please!) put the KVM-specific logic inside
> instance_init?
Then we're pretty much back to my v3 plus Igor's error handling chan
Re: [Qemu-devel] Set Spice audio without envvar
On 02/08/13 16:19, Fabio Fantoni wrote: > Is possible to set spice audio without envvar but with qemu parameter? Should not be needed. With spice enabled qemu will automatically pick spice audio as default, without spice whatever else comes first in the list (alsa probably, but depends on which drivers you've compiled in of course). Of course you can still force something else with the envvars. cheers, Gerd
Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
On 2013-02-08 03:38, Andreas Färber wrote: Otherwise if someone can ack (or if you can point me to a manual), this looks like a good bugfix for v1.4. CC'ing some more CPU'ish people. It wouldn't be a bug fix without extracting the patch out of my x86-next tree that actually implements movbe. I don't think this can go into 1.4. r~
[Qemu-devel] [Bug 1119281] [NEW] The virtio network device breaks UuidCreateSequential()
Public bug reported:
UuidCreateSequential() usually creates version 1 UUIDs (1) which means
they contain the main network card's MAC address. However when using a
virtio network card and driver the UUIDs contain random data instead of
the guest's MAC address. Changing the network card to either the default
rtl8139 one or the e1000 one fixes the issue.
Here is the software I have tested this with:
* qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and
Experimental respectively)
* The 0.1-49 and 0.1-52 Windows virtio drivers from
https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
* Both a 32-bit Windows XP guest and a 64-bit Windows 7 one.
Here is how to test for this issue:
* Set up a Windows guest with a single network card(2), a virtio one and
install the corresponding driver.
* Boot the guest and copy the uuidtest.exe file (see attachement) to it
* On the command line, type 'ipconfig /all'. Give you the correct
network card's MAC address on a line like the one below:
Physical Address. . . . . . . . . : 52-54-00-C7-0E-97
* Run uuidtest.exe. It will show the VM returning a UUID with the wrong
MAC address, and quite possibly even a multicast MAC address! (3). In
the example below 'f75292c62787' should have been the MAC address. Note
that on Windows XP UuidCreateSequential() returns RPC_S_UUID_LOCAL_ONLY
for virtio cards but that on Windows 7 it returns 0.
UuidCreateSequential() returned 0
uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787}
Got a version 1 UUID
The UUID does not contain a non-multicast MAC address
* Reboot and notice uuidtest.exe now reports a different value where the
MAC address should be.
* Shut down the VM and switch the network card to rtl8139, install the
drivers, run uuidtest.exe and notice that the last group of digits
finally contains the correct MAC address.
(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
(2) Best do it with a single card to avoid confusion over which is the primary
one.
(3) If the first byte of the address is odd then this is a multicast address.
https://en.wikipedia.org/wiki/MAC_address#Address_details
** Affects: qemu
Importance: Undecided
Status: New
** Attachment added: "Test executable and source"
https://bugs.launchpad.net/bugs/1119281/+attachment/3520477/+files/uuidtest.tar.bz2
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1119281
Title:
The virtio network device breaks UuidCreateSequential()
Status in QEMU:
New
Bug description:
UuidCreateSequential() usually creates version 1 UUIDs (1) which means
they contain the main network card's MAC address. However when using a
virtio network card and driver the UUIDs contain random data instead
of the guest's MAC address. Changing the network card to either the
default rtl8139 one or the e1000 one fixes the issue.
Here is the software I have tested this with:
* qemu 1.1.2+dfsg-5 and 1.4.0~rc0+dfsg-1exp (from Debian Testing and
Experimental respectively)
* The 0.1-49 and 0.1-52 Windows virtio drivers from
https://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
* Both a 32-bit Windows XP guest and a 64-bit Windows 7 one.
Here is how to test for this issue:
* Set up a Windows guest with a single network card(2), a virtio one and
install the corresponding driver.
* Boot the guest and copy the uuidtest.exe file (see attachement) to
it
* On the command line, type 'ipconfig /all'. Give you the correct
network card's MAC address on a line like the one below:
Physical Address. . . . . . . . . : 52-54-00-C7-0E-97
* Run uuidtest.exe. It will show the VM returning a UUID with the
wrong MAC address, and quite possibly even a multicast MAC address!
(3). In the example below 'f75292c62787' should have been the MAC
address. Note that on Windows XP UuidCreateSequential() returns
RPC_S_UUID_LOCAL_ONLY for virtio cards but that on Windows 7 it
returns 0.
UuidCreateSequential() returned 0
uuid={56e1ffe4-71d8-11e2-b1cc-f75292c62787}
Got a version 1 UUID
The UUID does not contain a non-multicast MAC address
* Reboot and notice uuidtest.exe now reports a different value where
the MAC address should be.
* Shut down the VM and switch the network card to rtl8139, install the
drivers, run uuidtest.exe and notice that the last group of digits
finally contains the correct MAC address.
(1) https://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
(2) Best do it with a single card to avoid confusion over which is the
primary one.
(3) If the first byte of the address is odd then this is a multicast address.
https://en.wikipedia.org/wiki/MAC_address#Address_details
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1119281/+subsc
Re: [Qemu-devel] [RFC V6 00/33] QCOW2 deduplication core functionality
On 02/08/2013 06:49 AM, Stefan Hajnoczi wrote: > On Wed, Feb 06, 2013 at 01:31:33PM +0100, Benoît Canet wrote: >> This patchset create the core infrastructure for deduplication and enable it. > > Here is a high-level overview of qcow2 dedup for others reviewing this series: Awesome. Benoît, how much of this information should be added in either contents or commit messages of the various parts of your series? > > Data structures > --- > > Deduplication adds one new on-disk structure: the dedup hash table. Each > entry > contains: > * Hash value of a data cluster (32 bytes) > * Logical offset of the first cluster with these contents (8 bytes) > > Unallocated clusters have no hash value so the dedup hash table uses an L1 > table to allow sparse allocation of dedup hash table entries. Dedup hash > table > blocks are accessed through dedup_cluster_cache, a cache of the L2 blocks. > > The dedup hash table is indexed by physical offset, in other words it can be > used to look up the hash for a given offset into the image file. This means > it > cannot be used to find duplicate clusters. Or rather, that finding whether any other cluster has the same hash would require an expensive O(n) linear scan, if using only the on-disk table. > > This is solved by building an in-memory lookup tree when the file is opened. > The lookup tree maps hashes to the physical offset and first logical offset - > it is an inverse mapping. > > Since the dedup hash table is already scanned on startup, the forward mapping > (physical offset to hash) is also loaded into an in-memory lookup tree. > > Finally we have arrived at the two trees used for deduplication: > 1. dedup_tree_by_hash: hash -> > 2. dedup_tree_by_sect: physical offset -> > > dedup_tree_by_sect is the in-memory version of the dedup hash table on disk. > > Read operation > -- > > Reads are unaffected by dedup. > > Write operation > --- > > Writes must be cluster-aligned/cluster-sized or else they incur extra reads to > load the untouched sectors (similar to copy-on-write). This is necessary > because the hash is calculated for the entire cluster so we always work in > cluster units. > > When a duplicate is found the refcount of the existing cluster is incremented. > Since refcounts are 16-bit there is a risk of overflowing, for example with an > all-zero disk image. A threshold is set for breaking deduplication and > creating a new cluster for the sake of preventing refcount overflow. You probably also want to mention what happens when one of the clusters that previously map to a common hash is then modified, because it requires updating the lookup tables to reflect the new hash and a possible change in first logical offset associated with the old hash. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[Qemu-devel] request for mediawiki account / RDMA documentation
Hi, According to the website, I should ask here for someone to make a wiki account for me? I would like to post documentation of the RDMA patches I'm preparing. Thanks, - Michael R. Hines
[Qemu-devel] [PATCH for-1.4 v2 3/6] error: Strip trailing '\n' from error string arguments (again)
Commit 6daf194d and be62a2eb got rid of a bunch, but they keep coming
back. Tracked down with this Coccinelle semantic patch:
@r@
expression err, eno, cls, fmt;
position p;
@@
(
error_report(fmt, ...)@p
|
error_set(err, cls, fmt, ...)@p
|
error_set_errno(err, eno, cls, fmt, ...)@p
|
error_setg(err, fmt, ...)@p
|
error_setg_errno(err, eno, fmt, ...)@p
)
@script:python@
fmt << r.fmt;
p << r.p;
@@
if "\\n" in str(fmt):
print "%s:%s:%s:%s" % (p[0].file, p[0].line, p[0].column, fmt)
Signed-off-by: Markus Armbruster
---
block/gluster.c | 2 +-
hmp.c | 2 +-
hw/9pfs/virtio-9p-proxy.c | 2 +-
hw/pci/pci.c| 2 +-
hw/qdev.c | 4 +-
hw/qxl.c| 2 +-
hw/vfio_pci.c | 110 ++--
hw/vhost_net.c | 4 +-
migration.c | 2 +-
qemu-char.c | 8 ++--
target-i386/cpu.c | 10 ++--
target-ppc/translate_init.c | 2 +-
ui/console.c| 2 +-
ui/input.c | 2 +-
util/qemu-config.c | 6 +--
util/qemu-sockets.c | 6 +--
16 files changed, 83 insertions(+), 83 deletions(-)
diff --git a/block/gluster.c b/block/gluster.c
index 0f2c32a..ccd684d 100644
--- a/block/gluster.c
+++ b/block/gluster.c
@@ -217,7 +217,7 @@ static struct glfs *qemu_gluster_init(GlusterConf *gconf,
const char *filename)
ret = glfs_init(glfs);
if (ret) {
error_report("Gluster connection failed for server=%s port=%d "
- "volume=%s image=%s transport=%s\n", gconf->server, gconf->port,
+ "volume=%s image=%s transport=%s", gconf->server, gconf->port,
gconf->volname, gconf->image, gconf->transport);
goto out;
}
diff --git a/hmp.c b/hmp.c
index 420d48b..2f47a8a 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1365,7 +1365,7 @@ void hmp_chardev_add(Monitor *mon, const QDict *qdict)
opts = qemu_opts_parse(qemu_find_opts("chardev"), args, 1);
if (opts == NULL) {
-error_setg(&err, "Parsing chardev args failed\n");
+error_setg(&err, "Parsing chardev args failed");
} else {
qemu_chr_new_from_opts(opts, NULL, &err);
}
diff --git a/hw/9pfs/virtio-9p-proxy.c b/hw/9pfs/virtio-9p-proxy.c
index d5ad208..54e9875 100644
--- a/hw/9pfs/virtio-9p-proxy.c
+++ b/hw/9pfs/virtio-9p-proxy.c
@@ -521,7 +521,7 @@ static int v9fs_request(V9fsProxy *proxy, int type,
}
break;
default:
-error_report("Invalid type %d\n", type);
+error_report("Invalid type %d", type);
retval = -EINVAL;
break;
}
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 905dc4a..2f45c8f 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1132,7 +1132,7 @@ PCIINTxRoute pci_device_route_intx_to_irq(PCIDevice *dev,
int pin)
} while (dev);
if (!bus->route_intx_to_irq) {
-error_report("PCI: Bug - unimplemented PCI INTx routing (%s)\n",
+error_report("PCI: Bug - unimplemented PCI INTx routing (%s)",
object_get_typename(OBJECT(bus->qbus.parent)));
return (PCIINTxRoute) { PCI_INTX_DISABLED, -1 };
}
diff --git a/hw/qdev.c b/hw/qdev.c
index 8258757..689cd54 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -114,11 +114,11 @@ DeviceState *qdev_create(BusState *bus, const char *name)
dev = qdev_try_create(bus, name);
if (!dev) {
if (bus) {
-error_report("Unknown device '%s' for bus '%s'\n", name,
+error_report("Unknown device '%s' for bus '%s'", name,
object_get_typename(OBJECT(bus)));
abort();
} else {
-error_report("Unknown device '%s' for default sysbus\n", name);
+error_report("Unknown device '%s' for default sysbus", name);
abort();
}
}
diff --git a/hw/qxl.c b/hw/qxl.c
index a125e29..2e1c5e2 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -2036,7 +2036,7 @@ static int qxl_init_common(PCIQXLDevice *qxl)
qxl->ssd.qxl.base.sif = &qxl_interface.base;
qxl->ssd.qxl.id = qxl->id;
if (qemu_spice_add_interface(&qxl->ssd.qxl.base) != 0) {
-error_report("qxl interface %d.%d not supported by spice-server\n",
+error_report("qxl interface %d.%d not supported by spice-server",
SPICE_INTERFACE_QXL_MAJOR, SPICE_INTERFACE_QXL_MINOR);
return -1;
}
diff --git a/hw/vfio_pci.c b/hw/vfio_pci.c
index a934f13..ad9ae36 100644
--- a/hw/vfio_pci.c
+++ b/hw/vfio_pci.c
@@ -289,7 +289,7 @@ static void vfio_enable_intx_kvm(VFIODevice *vdev)
/* Get an eventfd for resample/unmask */
if (event_notifier_init(&vdev->intx.unmask, 0)) {
-error_report("vfio: Error: event_notifier_init failed eoi\n");
+error_report("vfio: Error: event_notifier_in
[Qemu-devel] [PATCH for-1.4 v2 6/6] vl: Exit unsuccessfully on option argument syntax error
We exit successfully after reporting syntax error for argument of
--sandbox and --add-fd.
We continue undaunted after reporting it for argument of --option-rom
and --object then.
Change all four to exit unsuccessfully, like the other options.
Signed-off-by: Markus Armbruster
---
vl.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/vl.c b/vl.c
index 73122d8..4245ccc 100644
--- a/vl.c
+++ b/vl.c
@@ -3623,6 +3623,9 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
opts = qemu_opts_parse(qemu_find_opts("option-rom"), optarg,
1);
+if (!opts) {
+exit(1);
+}
option_rom[nb_option_roms].name = qemu_opt_get(opts,
"romfile");
option_rom[nb_option_roms].bootindex =
qemu_opt_get_number(opts, "bootindex", -1);
@@ -3780,14 +3783,14 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_sandbox:
opts = qemu_opts_parse(qemu_find_opts("sandbox"), optarg, 1);
if (!opts) {
-exit(0);
+exit(1);
}
break;
case QEMU_OPTION_add_fd:
#ifndef _WIN32
opts = qemu_opts_parse(qemu_find_opts("add-fd"), optarg, 0);
if (!opts) {
-exit(0);
+exit(1);
}
#else
error_report("File descriptor passing is disabled on this "
@@ -3797,6 +3800,9 @@ int main(int argc, char **argv, char **envp)
break;
case QEMU_OPTION_object:
opts = qemu_opts_parse(qemu_find_opts("object"), optarg, 1);
+if (!opts) {
+exit(1);
+}
break;
default:
os_parse_cmd_args(popt->index, optarg);
--
1.7.11.7
Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
On Fri, Feb 08, 2013 at 04:34:58PM +0100, Borislav Petkov wrote: > On Fri, Feb 08, 2013 at 01:19:02PM -0200, Eduardo Habkost wrote: > > "-machine pc-1.3 -cpu n270" (and older machine-types) needs to keep > > MOVBE disabled, or you will break live migration. > > > > Personally I wouldn't mind declaring n270 as a non-migratable CPU > > model. But libvirt supports n270, so it already expects n270 to expose > > a stable ABI on each machine-type. > > From looking at the code - and I've never looked at qemu code before > last night - we could filter migration features in x86_cpu_realize() > when called down the pc_init1() path. x86_cpu_realize() is too late, as it would make "-cpu n270,-movbe" fail to disable the feature. The features need to be be initialized properly before cpu_x86_parse_featurestr(), on cpu_x86_register(). > > We simply need to look the QEMUMachine.is_default flag and leave the > feature on only if pc-1.4 which sets the is_default thing. is_default has nothing to do with it. If we enable MOVBE on pc-1.4, pc-1.4 will need to keep MOVBE enabled forever, it doesn't matter if it is the default machine-type or not. > > Or is there a more preferred way to do that? pc_init_pci_1_3() needs to ask the CPU code to disable MOVBE on n270. As we don't have a decent method to do that today, we are using static variables and compatibility-setup functions called from the machine init function. See disable_kvm_pv_eoi() for example. One day we will be able to do that using properties on the machine-type compat_props tables, but we can't do that yet. People can easily work around the lack of the feature today, using "-cpu n270,+movbe", so I believe it is worth waiting a little bit and fixing this on QEMU 1.5, when we will (hopefully) have a decent compatibility system based on compat_props. -- Eduardo
Re: [Qemu-devel] [PATCH v9 1/3] hw: introduce standard SD host controller
On 7 February 2013 06:50, Peter Crosthwaite wrote: > From: Igor Mitsyanko > > Device model for standard SD Host Controller Interface (SDHCI) compliant with > version 2.00 of SD association specification. > > Signed-off-by: Peter Crosthwaite > Signed-off-by: Igor Mitsyanko Reviewed-by: Peter Maydell -- PMM
Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
On Fri, Feb 08, 2013 at 01:19:02PM -0200, Eduardo Habkost wrote: > "-machine pc-1.3 -cpu n270" (and older machine-types) needs to keep > MOVBE disabled, or you will break live migration. > > Personally I wouldn't mind declaring n270 as a non-migratable CPU > model. But libvirt supports n270, so it already expects n270 to expose > a stable ABI on each machine-type. >From looking at the code - and I've never looked at qemu code before last night - we could filter migration features in x86_cpu_realize() when called down the pc_init1() path. We simply need to look the QEMUMachine.is_default flag and leave the feature on only if pc-1.4 which sets the is_default thing. Or is there a more preferred way to do that? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
[Qemu-devel] Set Spice audio without envvar
Is possible to set spice audio without envvar but with qemu parameter? I'm writing patch to add spice audio support to xen. Here is one reply from xen-devel: Setting envvars to configure qemu is a pretty crappy interface though, given that qemu supports both command line and configuration files for most other stuff. Perhaps this interface should be fixed upstream to use the standard mechanisms first? Thanks for any reply. smime.p7s Description: Firma crittografica S/MIME
Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
Il 08/02/2013 16:10, Eduardo Habkost ha scritto: > On Fri, Feb 08, 2013 at 02:59:25PM +0100, Paolo Bonzini wrote: >> Il 08/02/2013 14:44, Andreas Färber ha scritto: >>> Otherwise if someone can ack (or if you can point me to a manual), this >>> looks like a good bugfix for v1.4. > > Right, I don't know what v1.4 is >>> It's the QEMU release that we're about to make in a week. :-) >>> http://wiki.qemu.org/Planning/1.4 >>> > but this still needs Richard's patchset > enabling MOVBE dynamic translation in qemu to go in first before > enabling MOVBE for the n270 model. >>> OK, so this goes through Richard's queue then, no objections. >> >> I'm not sure I understand the relationship between QEMU CPUID bits and >> TCG/KVM, but perhaps this could go in 1.4 for KVM. >> >> Does TCG have a way to mask bits that aren't supported in the >> translator? For example AVX that is enabled by SandyBridge. > > TCG mode automatically masks the bits not supported by TCG, see how > x86_cpu_realizefn() uses TCG_FEATURES/TCG_EXT_FEATURES/etc. Uh, but n270 doesn't support vmx. :( Too bad. Then this patch indeed is not needed in 1.4. Paolo
Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
On Fri, Feb 08, 2013 at 10:30:02AM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> The Atom core (cpu name "n270" in QEMU speak) supports MOVBE. This is
> needed when booting 3.8 and later linux kernels built with the MATOM
> target because we require MOVBE in order to boot properly now.
>
> Cc: "H. Peter Anvin"
> Cc: Richard Henderson
> Signed-off-by: Borislav Petkov
> ---
>
> Right, so I was playing with booting MATOM kernels in QEMU.
> As it turns out, QEMU's n270 model doesn't advertize MOVBE
> although the real hardware supports it. Quick search pointed me to
> http://lists.nongnu.org/archive/html/qemu-devel/2013-01/msg04317.html
> which adds that support, among other things. I've merged Richard's
> patchset with qemu's current master and after applying this patch below,
> I can report success booting an MATOM kernel with QEMU. The same kernel
> boots on the real n270 hardware, btw.
>
> target-i386/cpu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
> index 9f38e4435e53..83816edd8410 100644
> --- a/target-i386/cpu.c
> +++ b/target-i386/cpu.c
> @@ -610,7 +610,8 @@ static x86_def_t builtin_x86_defs[] = {
> CPUID_ACPI | CPUID_SS | CPUID_HT | CPUID_TM | CPUID_PBE,
> /* Some CPUs got no CPUID_SEP */
> .ext_features = CPUID_EXT_SSE3 | CPUID_EXT_MONITOR | CPUID_EXT_SSSE3
> |
> -CPUID_EXT_DSCPL | CPUID_EXT_EST | CPUID_EXT_TM2 | CPUID_EXT_XTPR,
> +CPUID_EXT_DSCPL | CPUID_EXT_EST | CPUID_EXT_TM2 | CPUID_EXT_XTPR
> |
> + CPUID_EXT_MOVBE,
> .ext2_features = (PPRO_FEATURES & CPUID_EXT2_AMD_ALIASES) |
"-machine pc-1.3 -cpu n270" (and older machine-types) needs to keep
MOVBE disabled, or you will break live migration.
Personally I wouldn't mind declaring n270 as a non-migratable CPU model.
But libvirt supports n270, so it already expects n270 to expose a stable
ABI on each machine-type.
> CPUID_EXT2_NX,
> .ext3_features = CPUID_EXT3_LAHF_LM,
> --
> 1.8.1.2.422.g08c0e7f
>
>
--
Eduardo
Re: [Qemu-devel] [PATCH] target-i386: n270 can MOVBE
On Fri, Feb 08, 2013 at 02:59:25PM +0100, Paolo Bonzini wrote: > Il 08/02/2013 14:44, Andreas Färber ha scritto: > >>> >> Otherwise if someone can ack (or if you can point me to a manual), this > >>> >> looks like a good bugfix for v1.4. > >> > > >> > Right, I don't know what v1.4 is > > It's the QEMU release that we're about to make in a week. :-) > > http://wiki.qemu.org/Planning/1.4 > > > >> > but this still needs Richard's patchset > >> > enabling MOVBE dynamic translation in qemu to go in first before > >> > enabling MOVBE for the n270 model. > > OK, so this goes through Richard's queue then, no objections. > > I'm not sure I understand the relationship between QEMU CPUID bits and > TCG/KVM, but perhaps this could go in 1.4 for KVM. > > Does TCG have a way to mask bits that aren't supported in the > translator? For example AVX that is enabled by SandyBridge. TCG mode automatically masks the bits not supported by TCG, see how x86_cpu_realizefn() uses TCG_FEATURES/TCG_EXT_FEATURES/etc. -- Eduardo
Re: [Qemu-devel] [PATCH 3/5] target-i386: Slim conversion to X86CPU subclasses
On Fri, Feb 08, 2013 at 12:52:31PM -0200, Eduardo Habkost wrote: > On Fri, Feb 08, 2013 at 01:58:42PM +0100, Igor Mammedov wrote: [...] > > Continuing on theoretical issue: > > > We could add an inited field to X86CPUClass that gets checked at initfn > > > time (only ever getting set to true by the pre-defined models). Then it > > > would be per model. And if we add a prototype for the ..._class_init we > > > could even call it late as proposed for -cpu host if we take some > > is a tricky part, for global properties to work it > > would require, calling this hook after kvm_init() is succeeds and before > > any initfn() is called in general or as minimum before Device.initfn(). And > > it > > anyway will not make all CPU classes to have correct defaults in KVM mode, > > since only CPU class of created CPU instance will be fixed up. > > > > 1. One way to make sure that built-in CPU classes have fixed up defaults is > > to > > iterate over them in kvm_arch_init() and possibly calling their class_init() > > again to reinitialize. It's still hack (due fixing something up), but it > > would > > give at least correct KVM mode defaults, regardless of the order classes are > > initialized. > > Can't we do that more easily with the tcg-vendor/vendor properties? > > It looks we are burning too much brain cycles trying to force a model > that's really unintuitive to the outside, where the default-value of a > class property depends on the options given to the QEMU command-line. We > don't have to do that. > > The point of initializing stuff in class_init is to make introspection > easy. If we make the classes change how they look like depending on the > command-line configuration, the classes and the class introspection > system get less useful. > Sorry for replying to myself, but extending my answer: > > > > 2. But more correct way from POV of OOP would be one without any fixups, > > i.e. > > create extra KVM-builtin-CPU-classes that are derived from host class. > > and in object_class_by_name() lookup for them if kvm is enabled. But we > > could > > do this as follow-up to #1. Solution #2 would be 100% correct, strictly speaking, but isn't it overkill to create separate classes if we could just add one additional property in X86CPUClass, and let the CPU object choose which property is important for the CPUID setup, depending if KVM is enabled or not? -- Eduardo
[Qemu-devel] [PATCH V3 2/2] virtio-block: support auto-sensing of block sizes
Virtio-blk does not impose fixed block sizes for access to
backing devices. This patch introduces support for auto
lookup of the block sizes of the backing block device. This
automatic lookup needs to be enabled explicitly. Users may
do this by specifying (physical|logical)_block_size=0.
Machine types may do this for their defaults, too.
To achieve this, a new function blkconf_blocksizes is
implemented. If physical or logical block size are zero
a corresponding ioctl tries to find an appropriate value.
If this does not work, 512 is used. blkconf_blocksizes
is therefore only called w/in the virtio-blk context.
For s390-virtio, this patch configures auto lookup as
default. For virtio-ccw, this is already a default in
the existing upstream implementation.
Signed-off-by: Einar Lueck
---
hw/block-common.c | 23 +++
hw/block-common.h | 12 +---
hw/qdev-properties.c | 4 +++-
hw/s390x/s390-virtio-bus.c | 2 +-
hw/virtio-blk.c| 1 +
5 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/hw/block-common.c b/hw/block-common.c
index d21ec3a..7a040d1 100644
--- a/hw/block-common.c
+++ b/hw/block-common.c
@@ -10,6 +10,9 @@
#include "sysemu/blockdev.h"
#include "hw/block-common.h"
#include "qemu/error-report.h"
+#ifdef __linux__
+#include
+#endif
void blkconf_serial(BlockConf *conf, char **serial)
{
@@ -22,6 +25,26 @@ void blkconf_serial(BlockConf *conf, char **serial)
}
}
+void blkconf_blocksizes(BlockConf *conf)
+{
+int block_size;
+
+if (!conf->physical_block_size) {
+if (bdrv_ioctl(conf->bs, BLKPBSZGET, &block_size) == 0) {
+ conf->physical_block_size = (uint16_t) block_size;
+} else {
+conf->physical_block_size = BLOCK_PROPERTY_STD_BLKSIZE;
+}
+}
+if (!conf->logical_block_size) {
+if (bdrv_ioctl(conf->bs, BLKSSZGET, &block_size) == 0) {
+conf->logical_block_size = (uint16_t) block_size;
+} else {
+conf->logical_block_size = BLOCK_PROPERTY_STD_BLKSIZE;
+}
+}
+}
+
int blkconf_geometry(BlockConf *conf, int *ptrans,
unsigned cyls_max, unsigned heads_max, unsigned secs_max)
{
diff --git a/hw/block-common.h b/hw/block-common.h
index bb808f7..d593128 100644
--- a/hw/block-common.h
+++ b/hw/block-common.h
@@ -40,18 +40,23 @@ static inline unsigned int get_physical_block_exp(BlockConf
*conf)
return exp;
}
-#define DEFINE_BLOCK_PROPERTIES(_state, _conf) \
+#define BLOCK_PROPERTY_STD_BLKSIZE 512
+#define DEFINE_BLOCK_PROPERTIES_EXTENDED(_state, _conf, _blksize) \
DEFINE_PROP_DRIVE("drive", _state, _conf.bs), \
DEFINE_PROP_BLOCKSIZE("logical_block_size", _state, \
- _conf.logical_block_size, 512), \
+ _conf.logical_block_size, _blksize), \
DEFINE_PROP_BLOCKSIZE("physical_block_size", _state,\
- _conf.physical_block_size, 512), \
+ _conf.physical_block_size, _blksize), \
DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0), \
DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0),\
DEFINE_PROP_INT32("bootindex", _state, _conf.bootindex, -1),\
DEFINE_PROP_UINT32("discard_granularity", _state, \
_conf.discard_granularity, 0)
+#define DEFINE_BLOCK_PROPERTIES(_state, _conf) \
+DEFINE_BLOCK_PROPERTIES_EXTENDED(_state, _conf, \
+ BLOCK_PROPERTY_STD_BLKSIZE)
+
#define DEFINE_BLOCK_CHS_PROPERTIES(_state, _conf) \
DEFINE_PROP_UINT32("cyls", _state, _conf.cyls, 0), \
DEFINE_PROP_UINT32("heads", _state, _conf.heads, 0), \
@@ -60,6 +65,7 @@ static inline unsigned int get_physical_block_exp(BlockConf
*conf)
/* Configuration helpers */
void blkconf_serial(BlockConf *conf, char **serial);
+void blkconf_blocksizes(BlockConf *conf);
int blkconf_geometry(BlockConf *conf, int *trans,
unsigned cyls_max, unsigned heads_max, unsigned secs_max);
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index a8a31f5..73b6da0 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -650,7 +650,9 @@ static void set_blocksize(Object *obj, Visitor *v, void
*opaque,
error_propagate(errp, local_err);
return;
}
-if (value < min || value > max) {
+
+/* value == 0 indicates that block size should be sensed later on */
+if ((value < min || value > max) && value > 0) {
error_set(errp, QERR_PROPERTY_VALUE_OUT_OF_RANGE,
dev->id?:"", name, (int64_t)value, min, max);
return;
diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
index d467781..f403308 100644
--- a/hw/s390x/s390-virtio-bus.c
[Qemu-devel] [PATCH V3 1/2] hd-geometry.c: Integrate HDIO_GETGEO in guessing for target-s390x
This patch extends the function hd_geometry_guess. It introduces a
target specific hook. The default implementation for this target
specific hook is empty, has therefore no effect and the existing logic
works as before. For target-s390x, the behaviour is chosen as follows:
If no geo could be guessed via guess_disk_lchs, a new function called
guess_disk_pchs is called. The latter utilizes HDIO_GET_GEO ioctl to ask
the underlying disk for geometry.
If this is not successful (e.g. image files) geometry is derived
from the size of the disk (as before).
The new HDIO_GETGEO logic is required for two use cases:
a) Support for geometries of Direct Attached Storage Disks (DASD)
on s390x configured as backing of virtio block devices.
b) Support for FCP attached SCSI disks that do not yet have a
partition table. Without this patch, fdisk -l on the host would
return different results then fdisk -l in the guest.
Signed-off-by: Einar Lueck
Signed-off-by: Jens Freimann
Reviewed-by: Carsten Otte
Signed-off-by: Christian Borntraeger
---
hw/Makefile.objs | 6 -
hw/hd-geometry.c | 70 +++-
2 files changed, 74 insertions(+), 2 deletions(-)
diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 447e32a..7832d2c 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -178,7 +178,7 @@ 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 hd-geometry.o block-common.o
+common-obj-y += scsi-disk.o cdrom.o block-common.o
common-obj-y += scsi-generic.o scsi-bus.o
common-obj-y += hid.o
common-obj-$(CONFIG_SSI) += ssi.o
@@ -209,6 +209,10 @@ obj-$(CONFIG_VGA) += vga.o
obj-$(CONFIG_SOFTMMU) += device-hotplug.o
obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o
+# geometry is target/architecture dependent and therefore needs to be built
+# for every target platform
+obj-y += hd-geometry.o
+
# Inter-VM PCI shared memory & VFIO PCI device assignment
ifeq ($(CONFIG_PCI), y)
obj-$(CONFIG_KVM) += ivshmem.o
diff --git a/hw/hd-geometry.c b/hw/hd-geometry.c
index c305143..98253d7 100644
--- a/hw/hd-geometry.c
+++ b/hw/hd-geometry.c
@@ -33,6 +33,10 @@
#include "block/block.h"
#include "hw/block-common.h"
#include "trace.h"
+#ifdef __linux__
+#include
+#include
+#endif
struct partition {
uint8_t boot_ind; /* 0x80 - active */
@@ -47,6 +51,39 @@ struct partition {
uint32_t nr_sects; /* nr of sectors in partition */
} QEMU_PACKED;
+static void guess_chs_for_size(BlockDriverState *bs,
+uint32_t *pcyls, uint32_t *pheads, uint32_t *psecs);
+
+/* try to get geometry from disk via HDIO_GETGEO ioctl
+ Return 0 if OK, -1 if ioctl does not work (e.g. image file) */
+inline static int guess_disk_pchs(BlockDriverState *bs,
+uint32_t *pcylinders, uint32_t *pheads,
+uint32_t *psectors, int *ptranslation)
+{
+#ifdef __linux__
+struct hd_geometry geo;
+
+if (bdrv_ioctl(bs, HDIO_GETGEO, &geo)) {
+return -1;
+}
+
+/* HDIO_GETGEO may return success even though geo contains zeros
+ (e.g. certain multipath setups) */
+if (!geo.heads || !geo.sectors || !geo.cylinders) {
+return -1;
+}
+
+*pheads = geo.heads;
+*psectors = geo.sectors;
+*pcylinders = geo.cylinders;
+*ptranslation = BIOS_ATA_TRANSLATION_NONE;
+return 0;
+#else
+return -1;
+#endif
+}
+
+
/* try to guess the disk logical geometry from the MSDOS partition table.
Return 0 if OK, -1 if could not guess */
static int guess_disk_lchs(BlockDriverState *bs,
@@ -116,13 +153,43 @@ static void guess_chs_for_size(BlockDriverState *bs,
*psecs = 63;
}
+/* target specific geometry guessing hooks:
+ * return 0 if guess available, != 0 in any other case */
+#ifdef TARGET_S390X
+static inline int target_geometry_guess(BlockDriverState *bs,
+ uint32_t *pcyls, uint32_t *pheads,
+ uint32_t *psecs, int *ptranslation)
+{
+int cyls, heads, secs;
+if (!guess_disk_lchs(bs, &cyls, &heads, &secs)) {
+*pcyls = cyls;
+*pheads = heads;
+*psecs = secs;
+*ptranslation = BIOS_ATA_TRANSLATION_NONE;
+return 0;
+} else {
+return guess_disk_pchs(bs, pcyls, pheads, psecs, ptranslation);
+}
+}
+#else
+static inline int target_geometry_guess(BlockDriverState *bs,
+ uint32_t *pcyls, uint32_t *pheads,
+ uint32_t *psecs, int *ptranslation)
+{
+return -1;
+}
+#endif
+
void hd_geometry_guess(BlockDriverState *bs,
uint32_t *pcyls, uint32_t *pheads, uint32_t *psecs,
int *ptrans)
{
int cylinders, heads, secs, translation;
-if (guess_disk_lchs(bs, &cylinders, &heads, &secs) < 0) {
+if (!target_geometry_guess(bs, pcyls, pheads,
[Qemu-devel] [PATCH V3 0/2] hd-geometry.c: Integrate HDIO_GETGEO in guessing
Hi, here is a reworked version. V2->V3: * introduced a hook for target specific geoemtry guessing ** target-s390x: as suggested in previous patch ** all other: like before Einar Lueck (2): hd-geometry.c: Integrate HDIO_GETGEO in guessing for target-s390x virtio-block: support auto-sensing of block sizes hw/Makefile.objs | 6 +++- hw/block-common.c | 23 +++ hw/block-common.h | 12 ++-- hw/hd-geometry.c | 70 +- hw/qdev-properties.c | 4 ++- hw/s390x/s390-virtio-bus.c | 2 +- hw/virtio-blk.c| 1 + 7 files changed, 111 insertions(+), 7 deletions(-) -- 1.7.12.4
