Re: [Qemu-devel] [patch 2/7] Add blkmirror block driver
On 05/24/2011 12:31 AM, Marcelo Tosatti wrote:
Mirrored writes are used by live block copy.
+
+typedef struct {
+BlockDriverState *bs[2];
+} BdrvMirrorState;
Can be generalized one day to N.
+
+/* Valid blkmirror filenames look like blkmirror:path/to/image1:path/to/image2
*/
+static int blkmirror_open(BlockDriverState *bs, const char *filename, int
flags)
+{
+BdrvMirrorState *m = bs->opaque;
+int ret;
+char *raw, *c;
+
+/* Parse the blkmirror: prefix */
+if (strncmp(filename, "blkmirror:", strlen("blkmirror:"))) {
Actual format should be documented somewhere.
+return -EINVAL;
+}
+filename += strlen("blkmirror:");
+
+/* Parse the raw image filename */
+c = strchr(filename, ':');
+if (c == NULL) {
+return -EINVAL;
+}
+
+raw = strdup(filename);
+raw[c - filename] = '\0';
+ret = bdrv_file_open(&m->bs[0], raw, flags);
+free(raw);
+if (ret< 0) {
+return ret;
+}
+filename = c + 1;
+
+ret = bdrv_file_open(&m->bs[1], filename, flags);
+if (ret< 0) {
+bdrv_delete(m->bs[0]);
+return ret;
+}
+
+return 0;
+}
+
+
+static BlockDriverAIOCB *blkmirror_aio_readv(BlockDriverState *bs,
+ int64_t sector_num,
+ QEMUIOVector *qiov,
+ int nb_sectors,
+ BlockDriverCompletionFunc *cb,
+ void *opaque)
+{
+BdrvMirrorState *m = bs->opaque;
+return bdrv_aio_readv(m->bs[0], sector_num, qiov, nb_sectors, cb, opaque);
We could one day be clever and round-robin once we're synced.
+}
+
+typedef struct DupAIOCB {
+BlockDriverAIOCB common;
+int count;
+
+BlockDriverCompletionFunc *cb;
+void *opaque;
+
+BlockDriverAIOCB *src_aiocb;
+BlockDriverAIOCB *dest_aiocb;
+
+int ret;
+} DupAIOCB;
+
+static void dup_aio_cancel(BlockDriverAIOCB *blockacb)
+{
+DupAIOCB *acb = container_of(blockacb, DupAIOCB, common);
+
+bdrv_aio_cancel(acb->src_aiocb);
+bdrv_aio_cancel(acb->dest_aiocb);
Shouldn't we cancel just the ones that haven't completed yet?
+qemu_aio_release(acb);
+}
+
+static AIOPool dup_aio_pool = {
+.aiocb_size = sizeof(DupAIOCB),
+.cancel = dup_aio_cancel,
+};
+
+static void blkmirror_aio_cb(void *opaque, int ret)
+{
+DupAIOCB *dcb = opaque;
+
+dcb->count--;
+assert(dcb->count>= 0);
+if (dcb->count == 0) {
+if (dcb->ret< 0) {
+ret = dcb->ret;
+}
+dcb->common.cb(dcb->opaque, ret);
+qemu_aio_release(dcb);
+}
+dcb->ret = ret;
+}
It would be nicer to do
if (ret < 0) {
dcb->ret = ret;
}
unconditionally. The current code works, but only for N=2, and is a
little obfuscated.
I see you aren't keeping sync/unsync state here. Will read on.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [patch 6/7] QEMU live block copy
On 05/24/2011 12:31 AM, Marcelo Tosatti wrote: Support live image copy + switch. That is, copy an image backing a guest hard disk to a destination image (destination image must be created separately), and switch to this copy. Command syntax: block_copy device filename [-i] -- live block copy device to image -i for incremental copy (base image shared between src and destination) Please refer to qmp-commands diff for more details. IMO it would have been nicer to use the mirror driver for all copying; there would be no STAGE_DIRTY; simply a background process that copies over all blocks, taking care not to conflict with ongoing writes. It would also remove the conflict with migration. But that's an implementation detail and can be changed later. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [patch 7/7] do not allow migration if block copy in progress
On 05/24/2011 12:31 AM, Marcelo Tosatti wrote:
Signed-off-by: Marcelo Tosatti
Index: qemu-block-copy/migration.c
===
--- qemu-block-copy.orig/migration.c
+++ qemu-block-copy/migration.c
@@ -19,6 +19,7 @@
#include "block.h"
#include "qemu_socket.h"
#include "block-migration.h"
+#include "block-copy.h"
#include "qemu-objects.h"
//#define DEBUG_MIGRATION
@@ -95,6 +96,11 @@ int do_migrate(Monitor *mon, const QDict
return -1;
}
+if (block_copy_active()) {
+monitor_printf(mon, "block copy in progress\n");
+return -1;
+}
+
Changelog should state why the conflict exists.
--
error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Booting custom kernel in qemu
Am 28.05.2011 um 22:05 schrieb Apelete Seketeli: On 27-May-11, Amit Shah wrote: On (Thu) 26 May 2011 [21:59:01], Apelete Seketeli wrote: I wanted to launch the kernel in a terminal for practical purposes, so I tried: qemu -kernel bzImage -append console=ttyS0 Add -serial stdio to get those logs. [...] For the time being I'm using qemu -kernel bzImage -append console=ttyS0 -S -nographic in order to launch gdbserver in the monitor and attach a gdb in the host; [...] You can use -S -s or -S -gdb ... for that. $ qemu -S -kernel arch/x86/boot/bzImage -append console=ttyS0 - nographic -serial stdio chardev: opening backend "stdio" failed qemu: could not open serial device 'stdio': No such file or directory Why do I get an error since stdio is (according to the manual) the standard device in non graphical mode ? -nographic implies -serial stdio, so it's redundant. When using SDL or Cocoa, -serial stdio gives you serial on the console in addition to the graphical window. -nographic just gives you the console output. HTH, Andreas
Re: [Qemu-devel] [Bug 739785] Re: qemu-i386 user mode on ARMv5 host fails (bash: fork: Invalid argument)
Peter, Am 29.03.2011 um 00:09 schrieb Peter Maydell: Short answer: looks like QEMU doesn't currently work on ARMv5 hosts (although ARMv7 are fine). I'll look into this if I can manage to scare up some suitable hardware. I noticed that configure prints any ARM host as "armv4l". As an interim measure, should we bump that to armv6l if armv5l is known broken? Andreas
Re: [Qemu-devel] [PATCH v2 6/9] target-i386: use floatx80 constants in helper_fld*_ST0()
Am 23.05.2011 um 23:42 schrieb Aurelien Jarno:
Instead of using a table which doesn't correspond to anything from
physical in the CPU, use directly the constants in helper_fld*_ST0().
Cc: Andreas Färber
Signed-off-by: Aurelien Jarno
Tested-by: Andreas Färber
I'm still wondering *why* the table doesn't work though... cf. reply
to Peter. I'll try some simplified sample code.
Andreas
---
target-i386/op_helper.c | 27 ---
1 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/target-i386/op_helper.c b/target-i386/op_helper.c
index 4d309ab..cec0c76 100644
--- a/target-i386/op_helper.c
+++ b/target-i386/op_helper.c
@@ -99,17 +99,6 @@ static const uint8_t rclb_table[32] = {
#define floatx80_l2e make_floatx80( 0x3fff, 0xb8aa3b295c17f0bcLL )
#define floatx80_l2t make_floatx80( 0x4000, 0xd49a784bcd1b8afeLL )
-static const floatx80 f15rk[7] =
-{
-floatx80_zero,
-floatx80_one,
-floatx80_pi,
-floatx80_lg2,
-floatx80_ln2,
-floatx80_l2e,
-floatx80_l2t,
-};
-
/* broken thread support */
static spinlock_t global_cpu_lock = SPIN_LOCK_UNLOCKED;
@@ -3816,42 +3805,42 @@ void helper_fabs_ST0(void)
void helper_fld1_ST0(void)
{
-ST0 = f15rk[1];
+ST0 = floatx80_one;
}
void helper_fldl2t_ST0(void)
{
-ST0 = f15rk[6];
+ST0 = floatx80_l2t;
}
void helper_fldl2e_ST0(void)
{
-ST0 = f15rk[5];
+ST0 = floatx80_l2e;
}
void helper_fldpi_ST0(void)
{
-ST0 = f15rk[2];
+ST0 = floatx80_pi;
}
void helper_fldlg2_ST0(void)
{
-ST0 = f15rk[3];
+ST0 = floatx80_lg2;
}
void helper_fldln2_ST0(void)
{
-ST0 = f15rk[4];
+ST0 = floatx80_ln2;
}
void helper_fldz_ST0(void)
{
-ST0 = f15rk[0];
+ST0 = floatx80_zero;
}
void helper_fldz_FT0(void)
{
-FT0 = f15rk[0];
+FT0 = floatx80_zero;
}
uint32_t helper_fnstsw(void)
--
1.7.5.1
[Qemu-devel] [Bug 789831] [NEW] kvm locks up when out of disk space
Public bug reported: Running a VM using raw sparse disk image on kvm 0.14 on Debian. When disk writes use up all disk space kvm locks up. if it cannot handle this situation gracefully (eg suspend the VM until space becomes available) it should at the very least report an error and exit, not keep sitting there. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/789831 Title: kvm locks up when out of disk space Status in QEMU: New Bug description: Running a VM using raw sparse disk image on kvm 0.14 on Debian. When disk writes use up all disk space kvm locks up. if it cannot handle this situation gracefully (eg suspend the VM until space becomes available) it should at the very least report an error and exit, not keep sitting there.
Re: [Qemu-devel] [PATCH v2 1/9] target-ppc: remove old CONFIG_SOFTFLOAT #ifdef
Am 23.05.2011 um 23:42 schrieb Aurelien Jarno:
target-ppc has been switched to softfloat only long ago, but a
few #ifdef CONFIG_SOFTFLOAT have been forgotten. Remove them.
Cc: Alexander Graf
Reviewed-by: Peter Maydell
Signed-off-by: Aurelien Jarno
Only removes now-useless #ifdefs and dead code. The dead code in
helper_float_check_status() differs from the softfloat code path in
that the softfloat path also evaluations the softfloat status and
calls some exception helpers. So we're not losing anything.
Acked-by: Andreas Färber
---
target-ppc/helper.h|2 --
target-ppc/op_helper.c | 11 ---
target-ppc/translate.c |2 --
3 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/target-ppc/helper.h b/target-ppc/helper.h
index 51c99c8..470e42f 100644
--- a/target-ppc/helper.h
+++ b/target-ppc/helper.h
@@ -51,9 +51,7 @@ DEF_HELPER_FLAGS_1(cntlzw32, TCG_CALL_CONST |
TCG_CALL_PURE, i32, i32)
DEF_HELPER_FLAGS_2(brinc, TCG_CALL_CONST | TCG_CALL_PURE, tl, tl, tl)
DEF_HELPER_0(float_check_status, void)
-#ifdef CONFIG_SOFTFLOAT
DEF_HELPER_0(reset_fpstatus, void)
-#endif
DEF_HELPER_2(compute_fprf, i32, i64, i32)
DEF_HELPER_2(store_fpscr, void, i64, i32)
DEF_HELPER_1(fpscr_clrbit, void, i32)
diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
index c6cb448..fe66f14 100644
--- a/target-ppc/op_helper.c
+++ b/target-ppc/op_helper.c
@@ -971,7 +971,6 @@ void helper_store_fpscr (uint64_t arg, uint32_t
mask)
void helper_float_check_status (void)
{
-#ifdef CONFIG_SOFTFLOAT
if (env->exception_index == POWERPC_EXCP_PROGRAM &&
(env->error_code & POWERPC_EXCP_FP)) {
/* Differred floating-point exception after target FPR
update */
@@ -989,22 +988,12 @@ void helper_float_check_status (void)
float_inexact_excp();
}
}
-#else
-if (env->exception_index == POWERPC_EXCP_PROGRAM &&
-(env->error_code & POWERPC_EXCP_FP)) {
-/* Differred floating-point exception after target FPR
update */
-if (msr_fe0 != 0 || msr_fe1 != 0)
-helper_raise_exception_err(env->exception_index, env-
>error_code);
-}
-#endif
}
-#ifdef CONFIG_SOFTFLOAT
void helper_reset_fpstatus (void)
{
set_float_exception_flags(0, &env->fp_status);
}
-#endif
/* fadd - fadd. */
uint64_t helper_fadd (uint64_t arg1, uint64_t arg2)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 9b3f90c..59aef85 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -215,9 +215,7 @@ struct opc_handler_t {
static inline void gen_reset_fpstatus(void)
{
-#ifdef CONFIG_SOFTFLOAT
gen_helper_reset_fpstatus();
-#endif
}
static inline void gen_compute_fprf(TCGv_i64 arg, int set_fprf, int
set_rc)
--
1.7.5.1
Re: [Qemu-devel] [PATCH v2 2/9] target-mips/gdbstub: remove old CONFIG_SOFTFLOAT #ifndef
Am 23.05.2011 um 23:42 schrieb Aurelien Jarno: target-mips has been switched to softfloat only long ago, but a #ifndef CONFIG_SOFTFLOAT has been forgotten. Remove it. Signed-off-by: Aurelien Jarno Reviewed-by: Andreas Färber --- gdbstub.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/gdbstub.c b/gdbstub.c index ae856f9..b9ae30d 100644 --- a/gdbstub.c +++ b/gdbstub.c @@ -1105,10 +1105,6 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t *mem_buf, int n) env->active_fpu.fcr31 = tmp & 0xFF83; /* set rounding mode */ RESTORE_ROUNDING_MODE; -#ifndef CONFIG_SOFTFLOAT -/* no floating point exception for native float */ -SET_FP_ENABLE(env->active_fpu.fcr31, 0); -#endif break; case 71: env->active_fpu.fcr0 = tmp; break; } -- 1.7.5.1
Re: [Qemu-devel] [Bug 789831] [NEW] kvm locks up when out of disk space
On Sun, May 29, 2011 at 11:48 AM, Michal Suchanek wrote: > Public bug reported: > > Running a VM using raw sparse disk image on kvm 0.14 on Debian. > > When disk writes use up all disk space kvm locks up. > > if it cannot handle this situation gracefully (eg suspend the VM until > space becomes available) it should at the very least report an error and > exit, not keep sitting there. Actually it should pause the VM - are you sure that KVM is "locking up"? If you run with SDL the window title says "[Stopped]" and you can resume the VM with the "c" (continue) QEMU monitor command once you've rectified the storage shortage. Are you using libvirt (virsh/virt-manager)? What makes you think that KVM is locked up? How much CPU is the qemu-kvm process consuming? Stefan
[Qemu-devel] [Bug 789831] Re: kvm locks up when out of disk space
I already replied to the OP in the Debian bug tracking system, and closed his bug there, see http://bugs.debian.org/628152 . ** Bug watch added: Debian Bug tracker #628152 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628152 ** Also affects: qemu-kvm (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628152 Importance: Unknown Status: Unknown ** Changed in: qemu Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/789831 Title: kvm locks up when out of disk space Status in QEMU: Invalid Status in “qemu-kvm” package in Debian: Unknown Bug description: Running a VM using raw sparse disk image on kvm 0.14 on Debian. When disk writes use up all disk space kvm locks up. if it cannot handle this situation gracefully (eg suspend the VM until space becomes available) it should at the very least report an error and exit, not keep sitting there.
[Qemu-devel] [PULL] Trivial patches for May 22 to May 29 2011
The following changes since commit 2eb9f241824d000fcd90bd7f4b49e40b88e62975: bitbang_i2c: Fix spurious slave read after NACK (2011-05-28 16:20:43 +0200) are available in the git repository at: ssh://repo.or.cz/srv/git/qemu/stefanha.git trivial-patches Stefan Weil (2): pflash_cfi02: Fix a typo in debug code (TARGET_FMT_pld -> TARGET_FMT_plx) Fix spelling in comment (additon -> addition) hw/pflash_cfi02.c |2 +- tcg/tcg.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 1.7.4.4
[Qemu-devel] [PATCH 1/2] pflash_cfi02: Fix a typo in debug code (TARGET_FMT_pld -> TARGET_FMT_plx)
From: Stefan Weil
Thanks to Tobias Hoffmann for this patch.
Signed-off-by: Stefan Weil
Signed-off-by: Stefan Hajnoczi
---
hw/pflash_cfi02.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/pflash_cfi02.c b/hw/pflash_cfi02.c
index 8fdafe6..725cd1e 100644
--- a/hw/pflash_cfi02.c
+++ b/hw/pflash_cfi02.c
@@ -188,7 +188,7 @@ static uint32_t pflash_read (pflash_t *pfl,
target_phys_addr_t offset,
default:
goto flash_read;
}
-DPRINTF("%s: ID " TARGET_FMT_pld " %x\n", __func__, boff, ret);
+DPRINTF("%s: ID " TARGET_FMT_plx " %x\n", __func__, boff, ret);
break;
case 0xA0:
case 0x10:
--
1.7.4.4
[Qemu-devel] [PATCH 2/2] Fix spelling in comment (additon -> addition)
From: Stefan Weil Signed-off-by: Stefan Weil Signed-off-by: Stefan Hajnoczi --- tcg/tcg.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tcg/tcg.h b/tcg/tcg.h index 2b985ac..746378a 100644 --- a/tcg/tcg.h +++ b/tcg/tcg.h @@ -129,7 +129,7 @@ typedef tcg_target_ulong TCGArg; We use plain int by default to avoid this runtime overhead. Users of tcg_gen_* don't need to know about any of this, and should treat TCGv as an opaque type. - In additon we do typechecking for different types of variables. TCGv_i32 + In addition we do typechecking for different types of variables. TCGv_i32 and TCGv_i64 are 32/64-bit variables respectively. TCGv and TCGv_ptr are aliases for target_ulong and host pointer sized values respectively. */ -- 1.7.4.4
Re: [Qemu-devel] [PATCH 06/11] target-i386: use floatx80 constants in helper_fld*_ST0()
Am 21.05.11 11:35, schrieb Andreas Färber:
Am 20.05.2011 um 12:32 schrieb Peter Maydell:
On 15 May 2011 15:13, Aurelien Jarno wrote:
Instead of using a table which doesn't correspond to anything from
physical in the CPU, use directly the constants in helper_fld*_ST0().
Actually I rather suspect there is effectively a table in the CPU
indexed by the last 3 bits of the FLD* opcode... It would be
possible to implement this group of insns in QEMU with a single
helper function that took the index into the array, but since the
array seems to be causing weird compilation problems we might
as well stick with the lots-of-helpers approach, at which point
this is a sensible cleanup.
In OpenBIOS we once ran into a similar error on ppc64 where a cast
would've resulted in the truncation of a static pointer ... could this
be an alignment issue here, that it's being truncated by the floatx80
cast? I tried using __attribute__((packed)) on the floatx80 type
without luck.
Or maybe the constant width is being handled weird, with LL being 128
bits rather than the expected 64 bits? ;)
Some more info:
The issue only pops up with -std=c99 or -std=gnu99, with both gcc 3.4.3
and 4.3.2. That's reproducible on Darwin gcc 4.0.1 and 4.2 as well.
The following trivial sample program triggers it, there's no magic
Solaris headers involved:
#include
// on OpenSolaris:
// typedef unsigned short uint16_t;
// typedef unsigned long long uint64_t;
typedef struct {
uint64_t low;
uint16_t high;
} floatx80;
#define make_floatx80(exp, mant) ((floatx80) { mant, exp })
#define floatx80_l2t make_floatx80( 0x4000, 0xd49a784bcd1b8afeLL )
static const floatx80 mine[1] = {
floatx80_l2t,
};
int main(void)
{
}
Any thoughts?
Andreas
Re: [Qemu-devel] [Bug 739785] Re: qemu-i386 user mode on ARMv5 host fails (bash: fork: Invalid argument)
On 29 May 2011 11:19, Andreas Färber wrote: > Am 29.03.2011 um 00:09 schrieb Peter Maydell: >> Short answer: looks like QEMU doesn't currently work on ARMv5 hosts >> (although ARMv7 are fine). I'll look into this if I can manage to >> scare up some suitable hardware. > > I noticed that configure prints any ARM host as "armv4l". As an interim > measure, should we bump that to armv6l if armv5l is known broken? It's only user-mode that doesn't work, I think, so making configure barf on earlier systems would be a little harsh (and that still wouldn't handle the case where you build on one kind of ARM box and then try to run it on an older one). It would probably be easier just to fix the bug than figure out what to do with configure :-) -- PMM
Re: [Qemu-devel] [PATCH] s390x: free tmp explicitly in every opcode for disas_a5()
Am 26.05.2011 um 21:53 schrieb Alexander Graf:
The disas_a5() function provided a TCG tmp variable which was
populated
by the respective opcode implementations, but freed at the end of the
function in generic code.
That makes it really hard for code review, so let's move the freeing
to the same scope as the actual allocation.
Signed-off-by: Alexander Graf
Please explain how this is related to Stefan's series: Instead? On
top? Prerequisite? :)
Cc'ing Stefan.
Andreas
---
target-s390x/translate.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/target-s390x/translate.c b/target-s390x/translate.c
index 5828b5f..afeb5e6 100644
--- a/target-s390x/translate.c
+++ b/target-s390x/translate.c
@@ -2334,18 +2334,22 @@ static void disas_a5(DisasContext *s, int
op, int r1, int i2)
case 0x0: /* IIHH R1,I2 [RI] */
tmp = tcg_const_i64(i2);
tcg_gen_deposit_i64(regs[r1], regs[r1], tmp, 48, 16);
+tcg_temp_free_i64(tmp);
break;
case 0x1: /* IIHL R1,I2 [RI] */
tmp = tcg_const_i64(i2);
tcg_gen_deposit_i64(regs[r1], regs[r1], tmp, 32, 16);
+tcg_temp_free_i64(tmp);
break;
case 0x2: /* IILH R1,I2 [RI] */
tmp = tcg_const_i64(i2);
tcg_gen_deposit_i64(regs[r1], regs[r1], tmp, 16, 16);
+tcg_temp_free_i64(tmp);
break;
case 0x3: /* IILL R1,I2 [RI] */
tmp = tcg_const_i64(i2);
tcg_gen_deposit_i64(regs[r1], regs[r1], tmp, 0, 16);
+tcg_temp_free_i64(tmp);
break;
case 0x4: /* NIHH R1,I2 [RI] */
case 0x8: /* OIHH R1,I2 [RI] */
@@ -2370,6 +2374,7 @@ static void disas_a5(DisasContext *s, int op,
int r1, int i2)
set_cc_nz_u32(s, tmp32);
tcg_temp_free_i64(tmp2);
tcg_temp_free_i32(tmp32);
+tcg_temp_free_i64(tmp);
break;
case 0x5: /* NIHL R1,I2 [RI] */
case 0x9: /* OIHL R1,I2 [RI] */
@@ -2395,6 +2400,7 @@ static void disas_a5(DisasContext *s, int op,
int r1, int i2)
set_cc_nz_u32(s, tmp32);
tcg_temp_free_i64(tmp2);
tcg_temp_free_i32(tmp32);
+tcg_temp_free_i64(tmp);
break;
case 0x6: /* NILH R1,I2 [RI] */
case 0xa: /* OILH R1,I2 [RI] */
@@ -2420,6 +2426,7 @@ static void disas_a5(DisasContext *s, int op,
int r1, int i2)
set_cc_nz_u32(s, tmp32);
tcg_temp_free_i64(tmp2);
tcg_temp_free_i32(tmp32);
+tcg_temp_free_i64(tmp);
break;
case 0x7: /* NILL R1,I2 [RI] */
case 0xb: /* OILL R1,I2 [RI] */
@@ -2443,29 +2450,33 @@ static void disas_a5(DisasContext *s, int
op, int r1, int i2)
set_cc_nz_u32(s, tmp32);/* signedness should not
matter here */
tcg_temp_free_i64(tmp2);
tcg_temp_free_i32(tmp32);
+tcg_temp_free_i64(tmp);
break;
case 0xc: /* LLIHH R1,I2 [RI] */
tmp = tcg_const_i64( ((uint64_t)i2) << 48 );
store_reg(r1, tmp);
+tcg_temp_free_i64(tmp);
break;
case 0xd: /* LLIHL R1,I2 [RI] */
tmp = tcg_const_i64( ((uint64_t)i2) << 32 );
store_reg(r1, tmp);
+tcg_temp_free_i64(tmp);
break;
case 0xe: /* LLILH R1,I2 [RI] */
tmp = tcg_const_i64( ((uint64_t)i2) << 16 );
store_reg(r1, tmp);
+tcg_temp_free_i64(tmp);
break;
case 0xf: /* LLILL R1,I2 [RI] */
tmp = tcg_const_i64(i2);
store_reg(r1, tmp);
+tcg_temp_free_i64(tmp);
break;
default:
LOG_DISAS("illegal a5 operation 0x%x\n", op);
gen_illegal_opcode(s, 2);
return;
}
-tcg_temp_free_i64(tmp);
}
static void disas_a7(DisasContext *s, int op, int r1, int i2)
--
1.6.0.2
[Qemu-devel] Webcams under KVM and Linux
Hello, I had asked a question of some of your Sourceforge contacts for KVM - Qemu on addition of webcam support, specifically the following - and was given the following interesting answer. I would indeed like to hear more about what the project is adding to KVM - Qemu to allow video to work with webcams (currently I run Fedora 15 as host and Fedora 11 under KVM and while the webcam driver and video device shows up in the guest I get no video. Also there is confusion for me if the host is supposed to have its webcam driver loaded and device enabled or not). I was told I could try to add a complete host controller to the guest, but am not entirely sure I understand what that means? Looking for specifics? Is there a suggestion for doing this during install of the KVM guest, or can this be done while the guest is running, or otherwise? Many thanks, Peter --- > You need to ask to KVM guys. You should notice that it is not just adding > ISOC and USB 2.0 support, but also to prioritize the processing of isoc > packets on a virtual environment, and to provide enough throughput for > video streams > > Can you tell me if KVM will be implementing Webcam support as > described above - the components missing that need to be > implemented for webcams to work - in any upcoming version of KVM ? It's work in progress, but not by me. Please check the qemu-devel mailing list archive, specifically regarding recent discussions about EHCI (USB 2.0). Some of those threads address isochronous transfer as well. In the meantime, you could also try to assign a complete host controller to the guest to get a webcam working. I tried this a while ago, though the result was only moderately well working here. --
[Qemu-devel] VMDK development plan for Summer of Code 2011
Hi all, As a project of Google Summer of Code 2011, I'm now working on improving VMDK image support. There are many subformats of VMDK virtual disk, some of which have separate descriptor file and others don't, some allocate space at once and some others grow dynamically, some have optional data compression. The current support of VMDK format is very limited, i.e. qemu now supports single file images, but couldn't recognize the widely used multi-file types. We have planned to add such support to VMDK block driver and enable more image types, and the working timeline is set in weeks (#1 to #7) as: [#1] Monolithic flat layout support [#2] Implement compression and Stream-Optimized Compressed Sparse Extents support. [#3] Improve ESX Server Sparse Extents support. [#4] Debug and test. Collect virtual disks with various versions and options, test qemu-img with them. By now some patches may be ready to deliver. [#5, 6] Add multi-file support (2GB extent formats) [#7] Clean up and midterm evaluation. According to the above schedule, several formats will be added till mid-term evaluation of GSoC. The development has been in progress for a week, and we'll soon have a patch ready for monolithic flat format. I have also created a project blog for progress update: http://warm.la/soc The project code is found at: https://github.com/famousz/qemu-vmdk And my mentor is Stefan Hajnoczi, who is doing a great job give the guidance. Any suggestion or problem report about the development or using VMDK image with qemu is welcome. Thanks. -- Best regards! Fam Zheng
[Qemu-devel] [ARM] Incomplete check for accept4
Hello,
The configure test for accept4() fails on armv7l host.
# check if accept4 is there
accept4=no
cat > $TMPC << EOF
#include
#include
int main(void)
{
accept4(0, NULL, NULL, SOCK_CLOEXEC);
return 0;
}
EOF
if compile_prog "" "" ; then
accept4=yes
fi
It succeeds and sets CONFIG_ACCEPT4, but linking against it generates
warnings:
osdep.o: In function `qemu_accept':
/.../osdep.c:157: warning: warning: accept4 is not implemented and
will always fail
IIUC it should drop back to accept()+qemu_set_cloexec() in that case,
so it's not critical, but if someone happens to know how to fix the
test that would be appreciated.
Regards,
Andreas
[Qemu-devel] [PATCH] Fixed BASEPRI, BASEPRI_MAX, and FAULTMASK access.
From: Sebastian Huber According to "ARMv7-M Architecture Reference Manual" issue D section "B5.2.3 MRS" and "B5.2.3 MSR". Signed-off-by: Sebastian Huber --- target-arm/helper.c | 24 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/target-arm/helper.c b/target-arm/helper.c index 1cc492d..a4a6597 100644 --- a/target-arm/helper.c +++ b/target-arm/helper.c @@ -1994,11 +1994,11 @@ uint32_t HELPER(v7m_mrs)(CPUState *env, uint32_t reg) return env->v7m.current_sp ? env->regs[13] : env->v7m.other_sp; case 16: /* PRIMASK */ return (env->uncached_cpsr & CPSR_I) != 0; -case 17: /* FAULTMASK */ -return (env->uncached_cpsr & CPSR_F) != 0; -case 18: /* BASEPRI */ -case 19: /* BASEPRI_MAX */ +case 17: /* BASEPRI */ +case 18: /* BASEPRI_MAX */ return env->v7m.basepri; +case 19: /* FAULTMASK */ +return (env->uncached_cpsr & CPSR_F) != 0; case 20: /* CONTROL */ return env->v7m.control; default: @@ -2050,20 +2050,20 @@ void HELPER(v7m_msr)(CPUState *env, uint32_t reg, uint32_t val) else env->uncached_cpsr &= ~CPSR_I; break; -case 17: /* FAULTMASK */ -if (val & 1) -env->uncached_cpsr |= CPSR_F; -else -env->uncached_cpsr &= ~CPSR_F; -break; -case 18: /* BASEPRI */ +case 17: /* BASEPRI */ env->v7m.basepri = val & 0xff; break; -case 19: /* BASEPRI_MAX */ +case 18: /* BASEPRI_MAX */ val &= 0xff; if (val != 0 && (val < env->v7m.basepri || env->v7m.basepri == 0)) env->v7m.basepri = val; break; +case 19: /* FAULTMASK */ +if (val & 1) +env->uncached_cpsr |= CPSR_F; +else +env->uncached_cpsr &= ~CPSR_F; +break; case 20: /* CONTROL */ env->v7m.control = val & 3; switch_v7m_sp(env, (val & 2) != 0); -- 1.7.1
Re: [Qemu-devel] [PATCH] Fix libfdt warnings on Darwin
Am 28.05.2011 um 16:01 schrieb Andreas Färber: Building with libfdt results in the following warnings on Mac OS X: CCppc-softmmu/device_tree.o In file included from /Users/andreas/QEMU/latest64/include/libfdt.h: 54, from /Users/andreas/QEMU/qemu/device_tree.c:26: /Users/andreas/QEMU/qemu/libfdt_env.h:25:20: warning: endian.h: No such file or directory /Users/andreas/QEMU/qemu/libfdt_env.h:26:22: warning: byteswap.h: No such file or directory /Users/andreas/QEMU/qemu/libfdt_env.h:28:5: warning: "__BYTE_ORDER" is not defined /Users/andreas/QEMU/qemu/libfdt_env.h:28:21: warning: "__BIG_ENDIAN" is not defined Since QEMU's copy of libfdt_env.h only uses bswap_32() and bswap_64(), let QEMU's bswap.h take care of the headers and use its endianness define. Cc: Hollis Blanchard Cc: Alexander Graf Signed-off-by: Andreas Färber --- Tested on Darwin/ppc64 host. More specifically, compile-tested on Darwin/ppc64 and now on Linux/ armv7l host. libfdt_env.h |8 ++-- 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/libfdt_env.h b/libfdt_env.h index ee0419f..90d7f3b 100644 --- a/libfdt_env.h +++ b/libfdt_env.h @@ -19,13 +19,9 @@ #ifndef _LIBFDT_ENV_H #define _LIBFDT_ENV_H -#include -#include -#include -#include -#include +#include "bswap.h" -#if __BYTE_ORDER == __BIG_ENDIAN +#ifdef HOST_WORDS_BIGENDIAN #define fdt32_to_cpu(x) (x) #define cpu_to_fdt32(x) (x) #define fdt64_to_cpu(x) (x) -- 1.7.3.4
Re: [Qemu-devel] Webcams under KVM and Linux
Hello, Am 29.05.2011 um 15:01 schrieb Peter Baitz: [...] You should notice that it is not just adding ISOC and USB 2.0 support, but also to prioritize the processing of isoc packets on a virtual environment, and to provide enough throughput for video streams [...] Please check the qemu-devel mailing list archive, specifically regarding recent discussions about EHCI (USB 2.0). Some of those threads address isochronous transfer as well. In the meantime, you could also try to assign a complete host controller to the guest to get a webcam working. I tried this a while ago, though the result was only moderately well working here. [...] I would indeed like to hear more about what the project is adding to KVM - Qemu to allow video to work with webcams [...] I was told I could try to add a complete host controller to the guest, but am not entirely sure I understand what that means? Looking for specifics? Is there a suggestion for doing this during install of the KVM guest, or can this be done while the guest is running, or otherwise? Independent of the ongoing EHCI work, I remember a patch specifically for webcams a while ago, try searching the archives for V4L. Andreas
Re: [Qemu-devel] Webcams under KVM and Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 More concretely search for patches sent by me. Even when EHCI is finished still is the problem of isochronous transfer not working well because of timing issues on QEMU. My patches overcome the need for ISO transfer and EHCI controllers completely, as well as providing an universal device to the guest that works with every Windows >XP, every Linux and even Mac OS X. El 29/05/2011, a las 14:37, Andreas Färber escribió: > Hello, > > Am 29.05.2011 um 15:01 schrieb Peter Baitz: > >> >>> [...] You should notice that it is not just adding >>> ISOC and USB 2.0 support, but also to prioritize the processing of isoc >>> packets on a virtual environment, and to provide enough throughput for >>> video streams >> >> [...] Please check the qemu-devel mailing list archive, specifically >> regarding recent discussions about EHCI (USB 2.0). Some of those threads >> address isochronous transfer as well. >> >> In the meantime, you could also try to assign a complete host controller to >> the guest to get a webcam working. I tried this a while ago, though the >> result was only moderately well working here. > >> [...] I would indeed like to hear more about what the project is adding to >> KVM - Qemu to allow video to work with webcams > [...] >> I was told I could try to add a complete host controller to the guest, but >> am not entirely sure I understand what that means? Looking for specifics? >> Is there a suggestion for doing this during install of the KVM guest, or can >> this be done while the guest is running, or otherwise? > > Independent of the ongoing EHCI work, I remember a patch specifically for > webcams a while ago, try searching the archives for V4L. > > Andreas -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAk3iT+QACgkQv/wfOsykIRTtxQD+KCTGZhuzrZMzmYDvY5NFO0+F QQwdE0aYVntQWpHMG5YBAJsFT5wd7/8FxOIt3aL1lwFqXtKc9y9TrrNog95gnoVh =n0hn -END PGP SIGNATURE-
Re: [Qemu-devel] [Bug 789831] [NEW] kvm locks up when out of disk space
On 29 May 2011 13:33, Stefan Hajnoczi wrote: > On Sun, May 29, 2011 at 11:48 AM, Michal Suchanek wrote: >> Public bug reported: >> >> Running a VM using raw sparse disk image on kvm 0.14 on Debian. >> >> When disk writes use up all disk space kvm locks up. >> >> if it cannot handle this situation gracefully (eg suspend the VM until >> space becomes available) it should at the very least report an error and >> exit, not keep sitting there. > > Actually it should pause the VM - are you sure that KVM is "locking > up"? If you run with SDL the window title says "[Stopped]" and you Unfortunately, the window title is not visible at all times so even if it says [Stopped] it is not useful indication of the VM state. > can resume the VM with the "c" (continue) QEMU monitor command once > you've rectified the storage shortage. > > Are you using libvirt (virsh/virt-manager)? No. > > What makes you think that KVM is locked up? Nothing apparent happens. eg. the VM mouse cursor does not move, no messages printed in the terminal from which kvm was started. > > How much CPU is the qemu-kvm process consuming? Did not check. Thanks Michal
Re: [Qemu-devel] Webcams under KVM and Linux
Hello Natalia and Andreas, Thank you for the replies and suggestions. I will lookup V4L. Natalia, So your patch creates a generic webcam under KVM/Qemu to allow many webcams to work? My only concern is the following: I use specific Philips webcams, and one in particular has a long exposure modification that the PWC driver (Fedora 11 guest on Fedora 15 host) coupled with Qastrocam-G2 (v4.9) allows the "shutter" to remain open through USB control of the LED. If the guest restorts to using a generic webcam driver, I think this would preclude functionality that the native driver supports ? Also, can you tell me - when KVM is running my guest, should the PWC webcam driver be loaded and/or the /dev/video0 on the HOST (F15), versus the guest (F11) ? I am confused as to which components are supposed to be enabled or disabled while running the guest webcam. What I see is when I enable the webcam USB device in KVM, it appears to disable the /dev/video0 on the host an brings it up in the guest. And the pwc driver loads and remains on both host and guest. Peter --- On Sun, 5/29/11, Natalia Portillo wrote: From: Natalia Portillo Subject: Re: [Qemu-devel] Webcams under KVM and Linux To: "Andreas Färber" Cc: "Peter Baitz" , "QEMU Developers" Date: Sunday, May 29, 2011, 1:53 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 More concretely search for patches sent by me. Even when EHCI is finished still is the problem of isochronous transfer not working well because of timing issues on QEMU. My patches overcome the need for ISO transfer and EHCI controllers completely, as well as providing an universal device to the guest that works with every Windows >XP, every Linux and even Mac OS X. El 29/05/2011, a las 14:37, Andreas Färber escribió: > Hello, > > Am 29.05.2011 um 15:01 schrieb Peter Baitz: > >> >>> [...] You should notice that it is not just adding >>> ISOC and USB 2.0 support, but also to prioritize the processing of isoc >>> packets on a virtual environment, and to provide enough throughput for >>> video streams >> >> [...] Please check the qemu-devel mailing list archive, specifically >> regarding recent discussions about EHCI (USB 2.0). Some of those threads >> address isochronous transfer as well. >> >> In the meantime, you could also try to assign a complete host controller to >> the guest to get a webcam working. I tried this a while ago, though the >> result was only moderately well working here. > >> [...] I would indeed like to hear more about what the project is adding to >> KVM - Qemu to allow video to work with webcams > [...] >> I was told I could try to add a complete host controller to the guest, but >> am not entirely sure I understand what that means? Looking for specifics? >> Is there a suggestion for doing this during install of the KVM guest, or can >> this be done while the guest is running, or otherwise? > > Independent of the ongoing EHCI work, I remember a patch specifically for > webcams a while ago, try searching the archives for V4L. > > Andreas -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iF4EAREIAAYFAk3iT+QACgkQv/wfOsykIRTtxQD+KCTGZhuzrZMzmYDvY5NFO0+F QQwdE0aYVntQWpHMG5YBAJsFT5wd7/8FxOIt3aL1lwFqXtKc9y9TrrNog95gnoVh =n0hn -END PGP SIGNATURE-
Re: [Qemu-devel] [PATCH 1/6] Fix incorrect check for fdatasync() in configure
Am 27.05.2011 um 19:22 schrieb Alexandre Raymond:
For some reason, darwin provides a symbol for fdatasync(), but
doesn't officially support it.
The manpage for fdatasync on Linux states the following:
"On POSIX systems on which fdatasync() is available,
_POSIX_SYNCHRONIZED_IO is defined in to a value greater
than 0."
The Open Group Base Specification Issue 7 says this on fdatasync():
"The functionality shall be equivalent to fsync() with the symbol
_POSIX_SYNCHRONIZED_IO defined, with the exception that all I/O
operations shall be completed as defined for synchronized I/O data
integrity completion."
On unistd.h it goes on to say:
"_POSIX_SYNCHRONIZED_IO
[SIO]
The implementation supports the Synchronized Input and Output option.
If this symbol is defined in , it shall be defined to be -1,
0, or 200809L."
The change history has nothing on that define and its value -1, so I'm
not convinced that this really is The Right Way to check.
In fact, unistd.h defines this value to "-1", at least on OSX 10.6.7.
Add this check to the configure file.
Signed-off-by: Alexandre Raymond
Andreas
---
configure |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index a318d37..b21ef75 100755
--- a/configure
+++ b/configure
@@ -2477,7 +2477,13 @@ fi
fdatasync=no
cat > $TMPC << EOF
#include
-int main(void) { return fdatasync(0); }
+int main(void) {
+#if defined(_POSIX_SYNCHRONIZED_IO) && _POSIX_SYNCHRONIZED_IO > 0
+return fdatasync(0);
+#else
+#abort Not supported
+#endif
+}
EOF
if compile_prog "" "" ; then
fdatasync=yes
--
1.7.5
Re: [Qemu-devel] [PATCH 3/6] Fix compilation warning due to incorrectly specified type
Am 27.05.2011 um 19:42 schrieb Stefan Weil:
Am 27.05.2011 19:22, schrieb Alexandre Raymond:
In audio/coreaudio.c, a variable named "str" was assigned "const
char" values,
which resulted in the following warnings:
-8<-
audio/coreaudio.c: In function ‘coreaudio_logstatus’:
audio/coreaudio.c:59: warning: initialization discards qualifiers
from pointer target type
audio/coreaudio.c:63: warning: assignment discards qualifiers from
pointer target type
(...)
-8<-
Signed-off-by: Alexandre Raymond
---
audio/coreaudio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/audio/coreaudio.c b/audio/coreaudio.c
index 0a26413..3bd75cd 100644
--- a/audio/coreaudio.c
+++ b/audio/coreaudio.c
@@ -56,7 +56,7 @@ typedef struct coreaudioVoiceOut {
static void coreaudio_logstatus (OSStatus status)
{
-char *str = "BUG";
+const char *str = "BUG";
switch(status) {
case kAudioHardwareNoError:
Acked-by: Stefan Weil
Thanks, applied to the cocoa branch.
Andreas
Re: [Qemu-devel] [PATCH 4/6] Fix missing prototype under cocoa for qemu_main
Am 27.05.2011 um 19:22 schrieb Alexandre Raymond: The following error message was encountered when compiling with cocoa support because qemu_main did not have a prototype. -8<- qemu/vl.c:2037: warning: no previous prototype for ‘qemu_main’ -8<- Add its prototype in the COCOA ifdef, similar to what is done for SDL. Signed-off-by: Alexandre Raymond --- vl.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/vl.c b/vl.c index b362871..b983646 100644 --- a/vl.c +++ b/vl.c @@ -107,6 +107,7 @@ int main(int argc, char **argv) #endif /* CONFIG_SDL */ #ifdef CONFIG_COCOA +int qemu_main(int argc, char **argv, char **envp); #undef main #define main qemu_main #endif /* CONFIG_COCOA */ We've seen at least two different ways of fixing this. I believe my last one was forgotten, waiting for someone to test with SDL. The idea was to have the prototype in a header shared between vl.c and cocoa.m, so that we don't have to duplicate the prototype. I'll see if I can dig it out or will post a new patch. Andreas
[Qemu-devel] [Bug 788881] Re: i386-bsd-user and similar don't build on Mac OS X
** Summary changed: - i386-bsd-user and similar crash on Mac OS X + i386-bsd-user and similar don't build on Mac OS X -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/71 Title: i386-bsd-user and similar don't build on Mac OS X Status in QEMU: New Bug description: 0.14.1 crashes on Mac OS X 64bit with some targets (*-bsd-user): CCi386-bsd-user/cpu-exec.o /Users/michael/Downloads/qemu-0.14.1/cpu-exec.c: In function ‘cpu_x86_signal_handler’: /Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: dereferencing pointer to incomplete type /Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: ‘REG_RIP’ undeclared (first use in this function) /Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: (Each undeclared identifier is reported only once /Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: for each function it appears in.) /Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:897: error: dereferencing pointer to incomplete type /Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:897: error: ‘REG_TRAPNO’ undeclared (first use in this function) /Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:898: error: dereferencing pointer to incomplete type /Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:898: error: ‘REG_ERR’ undeclared (first use in this function) /Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:899: error: dereferencing pointer to incomplete type make[1]: *** [cpu-exec.o] Error 1
Re: [Qemu-devel] [PATCH 1/6] Fix incorrect check for fdatasync() in configure
Hi Andreas,
According to this excerpt from The Open Group Base Specifications
Issue 6 (http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html),
'>0' indeed means that the functionality is implemented and can be
used.
8<
The following symbolic constants, if defined in , shall have
a value of -1, 0, or greater, unless otherwise specified below. If
these are undefined, the fpathconf(), pathconf(), or sysconf()
functions can be used to determine whether the option is provided for
a particular invocation of the application.
If a symbolic constant is defined with the value -1, the option is not
supported. Headers, data types, and function interfaces required only
for the option need not be supplied. An application that attempts to
use anything associated only with the option is considered to be
requiring an extension.
If a symbolic constant is defined with a value greater than zero, the
option shall always be supported when the application is executed. All
headers, data types, and functions shall be present and shall operate
as specified.
If a symbolic constant is defined with the value zero, all headers,
data types, and functions shall be present. The application can check
at runtime to see whether the option is supported by calling
fpathconf(), pathconf(), or sysconf() with the indicated name
parameter.
8<
Alexandre
On Sun, May 29, 2011 at 10:50 AM, Andreas Färber wrote:
> Am 27.05.2011 um 19:22 schrieb Alexandre Raymond:
>
>> For some reason, darwin provides a symbol for fdatasync(), but
>> doesn't officially support it.
>>
>> The manpage for fdatasync on Linux states the following:
>>
>> "On POSIX systems on which fdatasync() is available,
>> _POSIX_SYNCHRONIZED_IO is defined in to a value greater than
>> 0."
>
> The Open Group Base Specification Issue 7 says this on fdatasync():
>
> "The functionality shall be equivalent to fsync() with the symbol
> _POSIX_SYNCHRONIZED_IO defined, with the exception that all I/O operations
> shall be completed as defined for synchronized I/O data integrity
> completion."
>
> On unistd.h it goes on to say:
>
> "_POSIX_SYNCHRONIZED_IO
> [SIO]
> The implementation supports the Synchronized Input and Output option. If
> this symbol is defined in , it shall be defined to be -1, 0, or
> 200809L."
>
> The change history has nothing on that define and its value -1, so I'm not
> convinced that this really is The Right Way to check.
>
>> In fact, unistd.h defines this value to "-1", at least on OSX 10.6.7.
>>
>> Add this check to the configure file.
>>
>> Signed-off-by: Alexandre Raymond
>
> Andreas
>
>> ---
>> configure | 8 +++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/configure b/configure
>> index a318d37..b21ef75 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2477,7 +2477,13 @@ fi
>> fdatasync=no
>> cat > $TMPC << EOF
>> #include
>> -int main(void) { return fdatasync(0); }
>> +int main(void) {
>> +#if defined(_POSIX_SYNCHRONIZED_IO) && _POSIX_SYNCHRONIZED_IO > 0
>> +return fdatasync(0);
>> +#else
>> +#abort Not supported
>> +#endif
>> +}
>> EOF
>> if compile_prog "" "" ; then
>> fdatasync=yes
>> --
>> 1.7.5
>
>
Re: [Qemu-devel] [Bug 726962] Re: darwin user i386 no such directory
Am 28.05.2011 um 17:40 schrieb Karl-Michael Schindler: Am 28.05.2011 um 16:48 schrieb Andreas Färber: If you're willing to invest time on this, have a look at: http://repo.or.cz/w/qemu/afaerber.git/shortlog/refs/heads/darwin-user [...] Don't bother with 0.14.1, it'll need to be rebased against git master. hm, fink is based on tarballs with fixed checksums. Usually, this means release tarballs. Maybe I was too brief: darwin-user is broken since at least 0.9.0 four years ago, so there's no reason to believe that it'll be fixed in this or some upcoming tarball just by filing a bug ticket. If you do want to create patches to fix this, you'll need to use the git version and its master branch. Cf. http://wiki.qemu.org/Contribute/SubmitAPatch Compilation works very well without Fink btw, we currently have zero hard dependencies. Andreas
Re: [Qemu-devel] Add option to disable Cocoa on Mac OS X
Am 16.05.2011 um 12:57 schrieb Ben Leslie: On Wed, May 11, 2011 at 23:54, Peter Maydell wrote: On 7 May 2011 12:40, Alexander Graf wrote: So I suppose the only thing missing is a --disable-cocoa option, yup. I've just noticed that some of the code in block/raw-posix.c uses the CONFIG_COCOA #define to gate whether to do MacOSX specific handling of CDROMs and so on. I'm not a MacOS expert but maybe that needs to be changed to some other ifdef -- I'm guessing we don't want to have cdrom handling randomly change behaviour just because the user tried to disable Cocoa graphics handling... These seems to be a good point. Potentially checking for __APPLE__ and __MACH__ makes more sense? (See: http://predef.sourceforge.net/preos.html#sec20) Any update on this? IIUC without digging further, today, Cocoa not only means displaying the graphical window but also has impact on which libraries are linked to, such as IOKit and CoreAudio. So simply replacing CONFIG_COCOA with __APPLE__ would seem not to be enough. Tristan, if your patch takes care of everything, mind to resend or to provide a Patchwork link please? Andreas
Re: [Qemu-devel] [PATCH] #include cleanliness
On 05/19/2011 05:17 PM, Avi Kivity wrote: My mother always told me to explicitly #include any headers need to compile a file, instead of relying on other #includes to bring them in. This patch fixes up targphys.h and cpu-common.h in this regard. Can some qemu maintainer review this patch? Stefan? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [RFC] darwin: work around sigfd
Am 08.05.2011 um 11:15 schrieb Andreas Färber: Am 05.05.2011 um 15:15 schrieb Alexander Graf: On 05.05.2011, at 14:56, Paolo Bonzini wrote: On 05/05/2011 11:36 AM, Alexander Graf wrote: When running qemu-system on Darwin, the vcpu processes guest code, but I don't get to see anything on the cocoa screen. Out of curiosity, does it work with iothread? Seems to work with -nographic, yes. With cocoa it doesn't seem as happy :o. It certainly gets a lot further than without. -nographic has issues with --enable-io-thread, too. Ping?
Re: [Qemu-devel] [PATCH 1/3] Add ppc_init_cacheline_sizes() function for OpenBSD.
On 26/05/11 8:20 PM, malc wrote:
On Thu, 26 May 2011, Brad wrote:
On 26/05/11 9:15 AM, malc wrote:
On Thu, 26 May 2011, Brad wrote:
- Original message -
On Wed, 25 May 2011, Brad wrote:
Add ppc_init_cacheline_sizes() function for OpenBSD to fix compilation
of PowerPC host support for OpenBSD/powerpc based architectures.
Signed-off-by: Brad Smith
[..snip..]
Well this is the behavior of our kernel no matter what the CPU type is.
from sys/arch/powerpc/cpu.h..
#define CACHELINE 32 /* Note that this value is really
hardwired */
[..snip..]
I sure hope that OpenBSD doesn't use this value for dcbz/a's on ppc's with
less than 32 bytes per cache line and am not sure i want to take this
patch even if the kernel itself does this, not without some nagging printf
in the init cache line function urging OpenBSD kernel developers to fix
things..
USE_DCBZ is not defined.
/*
* Fill the given physical page with zeros.
*/
void
pmap_zero_page(struct vm_page *pg)
{
paddr_t pa = VM_PAGE_TO_PHYS(pg);
#ifdef USE_DCBZ
int i;
paddr_t addr = zero_page;
#endif
/* simple_lock(&pmap_zero_page_lock); */
pmap_kenter_pa(zero_page, pa, VM_PROT_READ|VM_PROT_WRITE);
#ifdef USE_DCBZ
for (i = PAGE_SIZE/CACHELINESIZE; i>0; i--) {
__asm volatile ("dcbz 0,%0" :: "r"(addr));
addr += CACHELINESIZE;
}
#else
bzero((void *)zero_page, PAGE_SIZE);
#endif
pmap_kremove_pg(zero_page);
/* simple_unlock(&pmap_zero_page_lock); */
}
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: [Qemu-devel] [PATCH 1/6] Fix incorrect check for fdatasync() in configure
Hi Alexandre, Am 29.05.2011 um 17:46 schrieb Alexandre Raymond: According to this excerpt from The Open Group Base Specifications Issue 6 (http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html ), '>0' indeed means that the functionality is implemented and can be used. 8< The following symbolic constants, if defined in , shall have a value of -1, 0, or greater, unless otherwise specified below. If these are undefined, the fpathconf(), pathconf(), or sysconf() functions can be used to determine whether the option is provided for a particular invocation of the application. If a symbolic constant is defined with the value -1, the option is not supported. Headers, data types, and function interfaces required only for the option need not be supplied. An application that attempts to use anything associated only with the option is considered to be requiring an extension. If a symbolic constant is defined with a value greater than zero, the option shall always be supported when the application is executed. All headers, data types, and functions shall be present and shall operate as specified. If a symbolic constant is defined with the value zero, all headers, data types, and functions shall be present. The application can check at runtime to see whether the option is supported by calling fpathconf(), pathconf(), or sysconf() with the indicated name parameter. 8< Indeed, confirmed in Issue 7, thanks a lot. Could you please provide me with an updated commit message saying so? Then I'll apply it. Andreas
[Qemu-devel] [PATCH] cocoa: Provide central qemu_main() prototype
This fixes a missing prototype warning in vl.c and obsoletes
the prototype in cocoa.m. Adjust callers in cocoa.m to supply
third argument, which is currently only used on Linux/ppc.
The prototype is designed so that it could be shared with SDL
and other frontends, if desired.
Cc: Alexandre Raymond
Signed-off-by: Andreas Färber
---
qemu-common.h |5 +
ui/cocoa.m|6 +++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/qemu-common.h b/qemu-common.h
index b851b20..218289c 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -131,6 +131,11 @@ static inline char *realpath(const char *path, char
*resolved_path)
#endif /* !defined(NEED_CPU_H) */
+/* main function, renamed */
+#if defined(CONFIG_COCOA)
+int qemu_main(int argc, char **argv, char **envp);
+#endif
+
/* bottom halves */
typedef void QEMUBHFunc(void *opaque);
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 1ff1ac6..6566e46 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -23,6 +23,7 @@
*/
#import
+#include
#include "qemu-common.h"
#include "console.h"
@@ -61,7 +62,6 @@ typedef struct {
int bitsPerPixel;
} QEMUScreen;
-int qemu_main(int argc, char **argv); // main defined in qemu/vl.c
NSWindow *normalWindow;
id cocoaView;
static DisplayChangeListener *dcl;
@@ -794,7 +794,7 @@ static int cocoa_keycode_to_qemu(int keycode)
COCOA_DEBUG("QemuCocoaAppController: startEmulationWithArgc\n");
int status;
-status = qemu_main(argc, argv);
+status = qemu_main(argc, argv, *_NSGetEnviron());
exit(status);
}
@@ -876,7 +876,7 @@ int main (int argc, const char * argv[]) {
!strcmp(opt, "-nographic") ||
!strcmp(opt, "-version") ||
!strcmp(opt, "-curses")) {
-return qemu_main(gArgc, gArgv);
+return qemu_main(gArgc, gArgv, *_NSGetEnviron());
}
}
}
--
1.7.5.3
Re: [Qemu-devel] [PATCH] host-pcc: enable building with -m32 or -m64
Am 27.05.2011 um 00:25 schrieb Stefan Berger: On 05/26/2011 05:24 PM, Andreas Färber wrote: Am 26.05.2011 um 22:31 schrieb Stefan Berger: On 05/26/2011 04:20 PM, Andreas Färber wrote: Am 26.05.2011 um 21:00 schrieb Stefan Berger: With the below patch I can build either ppc (-m32) or ppc64 (- m64) versions of Qemu (on a ppc64 host) when passing these compiler flags via 'configure ... --extra-cflags="-m32"'. You probably meant "without passing"? Nack. Please don't hardcode -mXX in configure, it's -arch ppc vs. -arch ppc64 on my host/gcc. What's wrong with passing --extra- cflags? I posted the following patch today for compiling libcacard with - m32 on a 64 bit machine. http://lists.nongnu.org/archive/html/qemu-devel/2011-05/ msg02909.html It adds LDFLAGS. This works fine on x86-64. Then trying this out on ppc64 with -m32 in extra-cflags I find the following in config- host.mak [...] HELPER_CFLAGS= LDFLAGS=-Wl,--warn-common -g ARLIBS_BEGIN= [...] The -m32 doesn't make it into LDFLAGS. The below patch fixed it for me following the pattern of x86-64 and i686 a bit further up in the case statement in configure. Erm, you did try --extra-ldflags for LDFLAGS, did you? That --extra- cflags doesn't end up there is intentional! No, I didn't. Here's what happened. On x86_64 host I used to be able to compile 32bit executables with --extra-cflags="-m32". That stopped working when libcacard showed up -- I posted a patch today -- only the linking of vscclient in libcacard/ didn't work. The "work-around" before the patch was --disable-smartcard. Now taking that same habit of passing --extra-cflags="-m32" to the ppc64 machine again didn't work, but was broken somewhere else. So this is where this is all coming from. Stefan, I rather care about where this is going, and my unanswered question is: Does it work if you use --extra-cflags=-m32 --extra- ldflags=-m32? If yes, then we can drop this patch and be good. Otherwise we need to think about a better solution. Andreas
[Qemu-devel] [PATCH] Use SIGIO with caution
BeOS and Haiku don't define SIGIO. When undefined, it won't arrive and doesn't need to be blocked. Signed-off-by: Andreas Färber --- cpus.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/cpus.c b/cpus.c index 1fc34b7..42af291 100644 --- a/cpus.c +++ b/cpus.c @@ -395,7 +395,9 @@ static int qemu_signal_init(void) pthread_sigmask(SIG_UNBLOCK, &set, NULL); sigemptyset(&set); +#ifdef SIGIO sigaddset(&set, SIGIO); +#endif sigaddset(&set, SIGALRM); sigaddset(&set, SIG_IPI); sigaddset(&set, SIGBUS); @@ -408,7 +410,9 @@ static int qemu_signal_init(void) * We need to process timer signals synchronously to avoid a race * between exit_request check and KVM vcpu entry. */ +#ifdef SIGIO sigaddset(&set, SIGIO); +#endif sigaddset(&set, SIGALRM); } #endif @@ -449,12 +453,16 @@ static void qemu_kvm_init_cpu_signals(CPUState *env) #else sigemptyset(&set); sigaddset(&set, SIG_IPI); +#ifdef SIGIO sigaddset(&set, SIGIO); +#endif sigaddset(&set, SIGALRM); pthread_sigmask(SIG_BLOCK, &set, NULL); pthread_sigmask(SIG_BLOCK, NULL, &set); +#ifdef SIGIO sigdelset(&set, SIGIO); +#endif sigdelset(&set, SIGALRM); #endif sigdelset(&set, SIG_IPI); -- 1.7.5.3
Re: [Qemu-devel] [PATCH] #include cleanliness
On 05/19/2011 09:17 AM, Avi Kivity wrote:
My mother always told me to explicitly #include any headers need to compile
a file, instead of relying on other #includes to bring them in. This patch
fixes up targphys.h and cpu-common.h in this regard.
Signed-off-by: Avi Kivity
---
cpu-common.h |4
targphys.h |2 ++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/cpu-common.h b/cpu-common.h
index 151c32c..2009adc 100644
--- a/cpu-common.h
+++ b/cpu-common.h
@@ -18,6 +18,10 @@
#include "bswap.h"
#include "qemu-queue.h"
+#include "qemu-common.h"
+
+#include
qemu-common.h should include stdbool.
The idea behind qemu-common.h is to avoid direct includes to help with
portability.
Regards,
Anthony Liguori
+
#if !defined(CONFIG_USER_ONLY)
enum device_endian {
diff --git a/targphys.h b/targphys.h
index 95648d6..501add2 100644
--- a/targphys.h
+++ b/targphys.h
@@ -3,6 +3,8 @@
#ifndef TARGPHYS_H
#define TARGPHYS_H
+#include
+
#ifdef TARGET_PHYS_ADDR_BITS
/* target_phys_addr_t is the type of a physical address (its size can
be different from 'target_ulong'). */
Re: [Qemu-devel] [PATCH] host-pcc: enable building with -m32 or -m64
On 05/29/2011 05:09 PM, Andreas Färber wrote: Am 27.05.2011 um 00:25 schrieb Stefan Berger: On 05/26/2011 05:24 PM, Andreas Färber wrote: Am 26.05.2011 um 22:31 schrieb Stefan Berger: On 05/26/2011 04:20 PM, Andreas Färber wrote: Am 26.05.2011 um 21:00 schrieb Stefan Berger: With the below patch I can build either ppc (-m32) or ppc64 (-m64) versions of Qemu (on a ppc64 host) when passing these compiler flags via 'configure ... --extra-cflags="-m32"'. You probably meant "without passing"? Nack. Please don't hardcode -mXX in configure, it's -arch ppc vs. -arch ppc64 on my host/gcc. What's wrong with passing --extra-cflags? I posted the following patch today for compiling libcacard with -m32 on a 64 bit machine. http://lists.nongnu.org/archive/html/qemu-devel/2011-05/msg02909.html It adds LDFLAGS. This works fine on x86-64. Then trying this out on ppc64 with -m32 in extra-cflags I find the following in config-host.mak [...] HELPER_CFLAGS= LDFLAGS=-Wl,--warn-common -g ARLIBS_BEGIN= [...] The -m32 doesn't make it into LDFLAGS. The below patch fixed it for me following the pattern of x86-64 and i686 a bit further up in the case statement in configure. Erm, you did try --extra-ldflags for LDFLAGS, did you? That --extra-cflags doesn't end up there is intentional! No, I didn't. Here's what happened. On x86_64 host I used to be able to compile 32bit executables with --extra-cflags="-m32". That stopped working when libcacard showed up -- I posted a patch today -- only the linking of vscclient in libcacard/ didn't work. The "work-around" before the patch was --disable-smartcard. Now taking that same habit of passing --extra-cflags="-m32" to the ppc64 machine again didn't work, but was broken somewhere else. So this is where this is all coming from. Stefan, I rather care about where this is going, and my unanswered question is: Does it work if you use --extra-cflags=-m32 --extra-ldflags=-m32? If yes, then we can drop this patch and be good. Otherwise we need to think about a better solution. It works as you show above once this patch here has been applied: http://lists.nongnu.org/archive/html/qemu-devel/2011-05/msg02909.html Stefan
[Qemu-devel] [PATCH V2 1/3] Darwin: Fix incorrect check for fdatasync() in configure
Under darwin (OS X 10.6.7), a symbol exists for the fdatasync() method
but it is not supported because _POSIX_SYNCHRONIZED_IO is set to '-1'.
Enable fdatasync() only if _POSIX_SYNCHRONIZED_IO is '>0', as per
The Open Group Base Specifications Issue 7.
Signed-off-by: Alexandre Raymond
---
configure |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index a318d37..b21ef75 100755
--- a/configure
+++ b/configure
@@ -2477,7 +2477,13 @@ fi
fdatasync=no
cat > $TMPC << EOF
#include
-int main(void) { return fdatasync(0); }
+int main(void) {
+#if defined(_POSIX_SYNCHRONIZED_IO) && _POSIX_SYNCHRONIZED_IO > 0
+return fdatasync(0);
+#else
+#abort Not supported
+#endif
+}
EOF
if compile_prog "" "" ; then
fdatasync=yes
--
1.7.5
[Qemu-devel] [PATCH V2 3/3] Remove warning in printf due to type mismatch
8<
qemu/target-lm32/translate.c: In function ‘gen_intermediate_code_internal’:
qemu/target-lm32/translate.c:1135: warning: format ‘%zd’ expects type ‘signed
size_t’, but argument 4 has type ‘int’
8<
Both gen_opc_ptr and gen_opc_buf are "uint16_t *". The difference between
pointers is a ptrdiff_t so printf needs '%td'.
Signed-off-by: Alexandre Raymond
---
target-lm32/translate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/target-lm32/translate.c b/target-lm32/translate.c
index eb21158..5e19725 100644
--- a/target-lm32/translate.c
+++ b/target-lm32/translate.c
@@ -1132,7 +1132,7 @@ static void gen_intermediate_code_internal(CPUState *env,
if (qemu_loglevel_mask(CPU_LOG_TB_IN_ASM)) {
qemu_log("\n");
log_target_disas(pc_start, dc->pc - pc_start, 0);
-qemu_log("\nisize=%d osize=%zd\n",
+qemu_log("\nisize=%d osize=%td\n",
dc->pc - pc_start, gen_opc_ptr - gen_opc_buf);
}
#endif
--
1.7.5
[Qemu-devel] [PATCH V2 2/3] Cocoa: avoid displaying window when command-line contains '-h' or '-help'
There was already a check in place to avoid displaying a window
in certain modes such as vnc, nographic or curses.
Add a check for '-h' and '-help' to avoid displaying a window for a split-
second before showing the usage information.
Signed-off-by: Alexandre Raymond
---
ui/cocoa.m |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 1ff1ac6..e1312d3 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -872,7 +872,8 @@ int main (int argc, const char * argv[]) {
if (opt[1] == '-') {
opt++;
}
-if (!strcmp(opt, "-vnc") ||
+if (!strcmp(opt, "-h") || !strcmp(opt, "-help") ||
+!strcmp(opt, "-vnc") ||
!strcmp(opt, "-nographic") ||
!strcmp(opt, "-version") ||
!strcmp(opt, "-curses")) {
--
1.7.5
[Qemu-devel] [PATCH V2 0/3] Fix compilation issues under darwin
I have rebased this series on top of afaerber/cocoa-for-upstream, since Andreas will be handling it. Changes since V1: * reword commit message of patch 1 * add '-help' cli switch to patch 2 * remove patch 3; has already been taken into account by Andreas * remove patch 4; will be fixed by Andreas * use '%td' in patch 5 instead of '%d' * remove patch 6; has already been taken into account by Stefan W. Thanks everyone for your feedback. Alexandre Alexandre Raymond (3): Darwin: Fix incorrect check for fdatasync() in configure Cocoa: avoid displaying window when command-line contains '-h' or '-help' Remove warning in printf due to type mismatch configure |8 +++- target-lm32/translate.c |2 +- ui/cocoa.m |5 +++-- 3 files changed, 11 insertions(+), 4 deletions(-) -- 1.7.5
Re: [Qemu-devel] Add option to disable Cocoa on Mac OS X
On Mon, May 30, 2011 at 02:17, Andreas Färber wrote:
> Am 16.05.2011 um 12:57 schrieb Ben Leslie:
>
>> On Wed, May 11, 2011 at 23:54, Peter Maydell
>> wrote:
>>>
>>> On 7 May 2011 12:40, Alexander Graf wrote:
So I suppose the only thing missing is a --disable-cocoa option, yup.
>>>
>>> I've just noticed that some of the code in block/raw-posix.c
>>> uses the CONFIG_COCOA #define to gate whether to do MacOSX
>>> specific handling of CDROMs and so on. I'm not a MacOS expert
>>> but maybe that needs to be changed to some other ifdef -- I'm
>>> guessing we don't want to have cdrom handling randomly change
>>> behaviour just because the user tried to disable Cocoa graphics
>>> handling...
>>
>> These seems to be a good point. Potentially checking for __APPLE__ and
>> __MACH__ makes more sense? (See:
>> http://predef.sourceforge.net/preos.html#sec20)
>
> Any update on this?
>
> IIUC without digging further, today, Cocoa not only means displaying the
> graphical window but also has impact on which libraries are linked to, such
> as IOKit and CoreAudio. So simply replacing CONFIG_COCOA with __APPLE__
> would seem not to be enough.
>
> Tristan, if your patch takes care of everything, mind to resend or to
> provide a Patchwork link please?
Replacing with CONFIG_COCOA with __APPLE__ seemed to be enough for me, but
I might have missed something. Here is the patch if someone else could
try it out:
Signed-off-by: Ben Leslie
---
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 6b72470..1f61a7f 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -29,7 +29,7 @@
#include "module.h"
#include "block/raw-posix-aio.h"
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__) && (__MACH__)
#include
#include
#include
@@ -235,7 +235,7 @@ static int raw_open(BlockDriverState *bs, const
char *filename, int flags)
bufsize = sectorsize;
}
#endif
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__) && defined(__MACH__)
uint32_t blockSize = 512;
if ( !ioctl( fd, DKIOCGETBLOCKSIZE, &blockSize ) && blockSize
> bufsize) {
bufsize = blockSize;
@@ -680,7 +680,7 @@ again:
}
if (size == 0)
#endif
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__) && defined(__MACH__)
size = LONG_LONG_MAX;
#else
size = lseek(fd, 0LL, SEEK_END);
@@ -820,7 +820,7 @@ static BlockDriver bdrv_file = {
/***/
/* host device */
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__) && defined(__MACH__)
static kern_return_t FindEjectableCDMedia( io_iterator_t *mediaIterator );
static kern_return_t GetBSDPath( io_iterator_t mediaIterator, char
*bsdPath, CFIndex maxPathSize );
@@ -898,7 +898,7 @@ static int hdev_open(BlockDriverState *bs, const
char *filename, int flags)
{
BDRVRawState *s = bs->opaque;
-#ifdef CONFIG_COCOA
+#if defined(__APPLE__) && defined(__MACH__)
if (strstart(filename, "/dev/cdrom", NULL)) {
kern_return_t kernResult;
io_iterator_t mediaIterator;
diff --git a/configure b/configure
index d7dba5d..6a5864f 100755
--- a/configure
+++ b/configure
@@ -635,6 +635,8 @@ for opt do
;;
--enable-profiler) profiler="yes"
;;
+ --disable-cocoa) cocoa="no"
+ ;;
--enable-cocoa)
cocoa="yes" ;
sdl="no" ;
@@ -932,6 +934,7 @@ echo " --disable-sdldisable SDL"
echo " --enable-sdl enable SDL"
echo " --disable-vncdisable VNC"
echo " --enable-vnc enable VNC"
+echo " --disable-cocoa disable COCOA"
echo " --enable-cocoa enable COCOA (Mac OS X only)"
echo " --audio-drv-list=LISTset audio drivers list:"
echo " Available drivers: $audio_possible_drivers"
Re: [Qemu-devel] [PATCH V2 2/3] Cocoa: avoid displaying window when command-line contains '-h' or '-help'
On 29 May 2011 23:22, Alexandre Raymond wrote:
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index 1ff1ac6..e1312d3 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -872,7 +872,8 @@ int main (int argc, const char * argv[]) {
> if (opt[1] == '-') {
> opt++;
> }
> - if (!strcmp(opt, "-vnc") ||
> + if (!strcmp(opt, "-h") || !strcmp(opt, "-help") ||
> + !strcmp(opt, "-vnc") ||
> !strcmp(opt, "-nographic") ||
> !strcmp(opt, "-version") ||
> !strcmp(opt, "-curses")) {
(1) presumably this doesn't work if you disable the display
with "-display none" ?
(2) it's pretty ugly and not very maintainable -- is there
some restructuring possible to avoid having to hardcode
information about qemu options into the ui code here?
(It also doesn't catch other cases where qemu prints some
information and exits immediately, like "-cpu ?".)
-- PMM
[Qemu-devel] [PATCH] Cocoa: avoid warning related to multiple method definitions
This fix forces a message to be sent to the handleEvent method
of the QemuCocoaView class instead of letting the system determine
the right method.
This is caused by the fact that the cocoaView variable is a generic 'id'.
8<
ui/cocoa.m: In function ‘cocoa_refresh’:
ui/cocoa.m:997: warning: multiple methods named ‘-handleEvent:’ found
/System/Library/Frameworks/AppKit.framework/Headers/NSTextInputContext.h:84:
warning: using ‘-(BOOL)handleEvent:(NSEvent *)theEvent’
ui/cocoa.m:272: warning: also found ‘-(void)handleEvent:(NSEvent *)event’
8<---
Signed-off-by: Alexandre Raymond
---
ui/cocoa.m |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index e1312d3..1975011 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -994,7 +994,7 @@ static void cocoa_refresh(DisplayState *ds)
event = [NSApp nextEventMatchingMask:NSAnyEventMask
untilDate:distantPast
inMode: NSDefaultRunLoopMode dequeue:YES];
if (event != nil) {
-[cocoaView handleEvent:event];
+[(QemuCocoaView *) cocoaView handleEvent:event];
}
} while(event != nil);
vga_hw_update();
--
1.7.5
Re: [Qemu-devel] [PATCH V2 2/3] Cocoa: avoid displaying window when command-line contains '-h' or '-help'
I agree that this is not the best way to handle all cases not requiring a GUI.
However, due to the current structure of the code, it was a simple way
to cover a very common case without having to refactor the whole cocoa
code.
Alexandre
On Sun, May 29, 2011 at 6:32 PM, Peter Maydell wrote:
> On 29 May 2011 23:22, Alexandre Raymond wrote:
>> diff --git a/ui/cocoa.m b/ui/cocoa.m
>> index 1ff1ac6..e1312d3 100644
>> --- a/ui/cocoa.m
>> +++ b/ui/cocoa.m
>> @@ -872,7 +872,8 @@ int main (int argc, const char * argv[]) {
>> if (opt[1] == '-') {
>> opt++;
>> }
>> - if (!strcmp(opt, "-vnc") ||
>> + if (!strcmp(opt, "-h") || !strcmp(opt, "-help") ||
>> + !strcmp(opt, "-vnc") ||
>> !strcmp(opt, "-nographic") ||
>> !strcmp(opt, "-version") ||
>> !strcmp(opt, "-curses")) {
>
> (1) presumably this doesn't work if you disable the display
> with "-display none" ?
> (2) it's pretty ugly and not very maintainable -- is there
> some restructuring possible to avoid having to hardcode
> information about qemu options into the ui code here?
>
> (It also doesn't catch other cases where qemu prints some
> information and exits immediately, like "-cpu ?".)
>
> -- PMM
>
Re: [Qemu-devel] [PATCH V2 1/3] Darwin: Fix incorrect check for fdatasync() in configure
Am 30.05.2011 um 00:22 schrieb Alexandre Raymond:
Under darwin (OS X 10.6.7), a symbol exists for the fdatasync() method
but it is not supported because _POSIX_SYNCHRONIZED_IO is set to '-1'.
Question: How did you notice? Did anything break that we could
mention, or did you just review the code?
Enable fdatasync() only if _POSIX_SYNCHRONIZED_IO is '>0', as per
The Open Group Base Specifications Issue 7.
Not quite what I meant. ;) Would you be okay with the following:
configure: Fix check for fdatasync()
Under Darwin, a symbol exists for the fdatasync() function, but it is
not supported. Yada yada. _POSIX_SYNCHRONIZED_IO is set to '-1'.
According to POSIX:2008, a value of -1 means the feature is not
supported.
A value of 0 means supported at compilation time, and a value greater 0
means supported at both compilation and run time.
Enable fdatasync() only if _POSIX_SYNCHRONIZED_IO is '>0'.
Andreas
Signed-off-by: Alexandre Raymond
---
configure |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index a318d37..b21ef75 100755
--- a/configure
+++ b/configure
@@ -2477,7 +2477,13 @@ fi
fdatasync=no
cat > $TMPC << EOF
#include
-int main(void) { return fdatasync(0); }
+int main(void) {
+#if defined(_POSIX_SYNCHRONIZED_IO) && _POSIX_SYNCHRONIZED_IO > 0
+return fdatasync(0);
+#else
+#abort Not supported
+#endif
+}
EOF
if compile_prog "" "" ; then
fdatasync=yes
--
1.7.5
Re: [Qemu-devel] [PATCH] cocoa: Provide central qemu_main() prototype
Hi Andreas,
Just thinking out loud here : wouldn't it make more sense to put the
main() of each gui framework directly in its corresponding file and
select the right one in the makefile using the configure options?
so you'd have
-no gui -> ui/no_gui.c:main() -> qemu_main()=== compile with no_gui.c + vl.c
-sdl -> ui/sdl.c:main() -> qemu_main() === compile with sdl.c + vl.c
-cocoa -> ui/cocoa.m:main() -> qemu_main() === compile with cocoa.m + vl.c
with ui/no_gui.c, ui/sdl.c and ui/cocoa.m each having their own main():
8<
...
int main(...) {
return qemu_main();
}
...
8<
and definitively rename main() to qemu_main() in vl.c ?
Alexandre
On Sun, May 29, 2011 at 3:58 PM, Andreas Färber wrote:
> This fixes a missing prototype warning in vl.c and obsoletes
> the prototype in cocoa.m. Adjust callers in cocoa.m to supply
> third argument, which is currently only used on Linux/ppc.
>
> The prototype is designed so that it could be shared with SDL
> and other frontends, if desired.
>
> Cc: Alexandre Raymond
> Signed-off-by: Andreas Färber
> ---
> qemu-common.h | 5 +
> ui/cocoa.m | 6 +++---
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/qemu-common.h b/qemu-common.h
> index b851b20..218289c 100644
> --- a/qemu-common.h
> +++ b/qemu-common.h
> @@ -131,6 +131,11 @@ static inline char *realpath(const char *path, char
> *resolved_path)
>
> #endif /* !defined(NEED_CPU_H) */
>
> +/* main function, renamed */
> +#if defined(CONFIG_COCOA)
> +int qemu_main(int argc, char **argv, char **envp);
> +#endif
> +
> /* bottom halves */
> typedef void QEMUBHFunc(void *opaque);
>
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index 1ff1ac6..6566e46 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -23,6 +23,7 @@
> */
>
> #import
> +#include
>
> #include "qemu-common.h"
> #include "console.h"
> @@ -61,7 +62,6 @@ typedef struct {
> int bitsPerPixel;
> } QEMUScreen;
>
> -int qemu_main(int argc, char **argv); // main defined in qemu/vl.c
> NSWindow *normalWindow;
> id cocoaView;
> static DisplayChangeListener *dcl;
> @@ -794,7 +794,7 @@ static int cocoa_keycode_to_qemu(int keycode)
> COCOA_DEBUG("QemuCocoaAppController: startEmulationWithArgc\n");
>
> int status;
> - status = qemu_main(argc, argv);
> + status = qemu_main(argc, argv, *_NSGetEnviron());
> exit(status);
> }
>
> @@ -876,7 +876,7 @@ int main (int argc, const char * argv[]) {
> !strcmp(opt, "-nographic") ||
> !strcmp(opt, "-version") ||
> !strcmp(opt, "-curses")) {
> - return qemu_main(gArgc, gArgv);
> + return qemu_main(gArgc, gArgv, *_NSGetEnviron());
> }
> }
> }
> --
> 1.7.5.3
>
>
Re: [Qemu-devel] [PATCH V2 1/3] Darwin: Fix incorrect check for fdatasync() in configure
Sure, I'm fine with that. I wasn't sure how much detail you actually
wanted in this commit message :)
Alexandre
On Sun, May 29, 2011 at 7:36 PM, Andreas Färber wrote:
> Am 30.05.2011 um 00:22 schrieb Alexandre Raymond:
>
>> Under darwin (OS X 10.6.7), a symbol exists for the fdatasync() method
>> but it is not supported because _POSIX_SYNCHRONIZED_IO is set to '-1'.
>
> Question: How did you notice? Did anything break that we could mention, or
> did you just review the code?
>
>> Enable fdatasync() only if _POSIX_SYNCHRONIZED_IO is '>0', as per
>> The Open Group Base Specifications Issue 7.
>
> Not quite what I meant. ;) Would you be okay with the following:
>
> configure: Fix check for fdatasync()
>
> Under Darwin, a symbol exists for the fdatasync() function, but it is
> not supported. Yada yada. _POSIX_SYNCHRONIZED_IO is set to '-1'.
>
> According to POSIX:2008, a value of -1 means the feature is not supported.
> A value of 0 means supported at compilation time, and a value greater 0
> means supported at both compilation and run time.
>
> Enable fdatasync() only if _POSIX_SYNCHRONIZED_IO is '>0'.
>
> Andreas
>
>> Signed-off-by: Alexandre Raymond
>> ---
>> configure | 8 +++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/configure b/configure
>> index a318d37..b21ef75 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2477,7 +2477,13 @@ fi
>> fdatasync=no
>> cat > $TMPC << EOF
>> #include
>> -int main(void) { return fdatasync(0); }
>> +int main(void) {
>> +#if defined(_POSIX_SYNCHRONIZED_IO) && _POSIX_SYNCHRONIZED_IO > 0
>> +return fdatasync(0);
>> +#else
>> +#abort Not supported
>> +#endif
>> +}
>> EOF
>> if compile_prog "" "" ; then
>> fdatasync=yes
>> --
>> 1.7.5
>>
>
>
Re: [Qemu-devel] [patch 1/7] add migration_active function
On 05/24/11 06:31, Marcelo Tosatti wrote: > To query whether migration is active. > > Signed-off-by: Marcelo Tosatti ACK Jes
Re: [Qemu-devel] [PATCH V2 1/3] Darwin: Fix incorrect check for fdatasync() in configure
I didn't notice anything broken. I just stumbled upon this bug while
reviewing the code.
Alexandre
On Sun, May 29, 2011 at 8:09 PM, Alexandre Raymond wrote:
> Sure, I'm fine with that. I wasn't sure how much detail you actually
> wanted in this commit message :)
>
> Alexandre
>
> On Sun, May 29, 2011 at 7:36 PM, Andreas Färber
> wrote:
>> Am 30.05.2011 um 00:22 schrieb Alexandre Raymond:
>>
>>> Under darwin (OS X 10.6.7), a symbol exists for the fdatasync() method
>>> but it is not supported because _POSIX_SYNCHRONIZED_IO is set to '-1'.
>>
>> Question: How did you notice? Did anything break that we could mention, or
>> did you just review the code?
>>
>>> Enable fdatasync() only if _POSIX_SYNCHRONIZED_IO is '>0', as per
>>> The Open Group Base Specifications Issue 7.
>>
>> Not quite what I meant. ;) Would you be okay with the following:
>>
>> configure: Fix check for fdatasync()
>>
>> Under Darwin, a symbol exists for the fdatasync() function, but it is
>> not supported. Yada yada. _POSIX_SYNCHRONIZED_IO is set to '-1'.
>>
>> According to POSIX:2008, a value of -1 means the feature is not supported.
>> A value of 0 means supported at compilation time, and a value greater 0
>> means supported at both compilation and run time.
>>
>> Enable fdatasync() only if _POSIX_SYNCHRONIZED_IO is '>0'.
>>
>> Andreas
>>
>>> Signed-off-by: Alexandre Raymond
>>> ---
>>> configure | 8 +++-
>>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index a318d37..b21ef75 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -2477,7 +2477,13 @@ fi
>>> fdatasync=no
>>> cat > $TMPC << EOF
>>> #include
>>> -int main(void) { return fdatasync(0); }
>>> +int main(void) {
>>> +#if defined(_POSIX_SYNCHRONIZED_IO) && _POSIX_SYNCHRONIZED_IO > 0
>>> +return fdatasync(0);
>>> +#else
>>> +#abort Not supported
>>> +#endif
>>> +}
>>> EOF
>>> if compile_prog "" "" ; then
>>> fdatasync=yes
>>> --
>>> 1.7.5
>>>
>>
>>
>
Re: [Qemu-devel] [PATCH 3/3] spapr: make irq customizable via qdev
On Wed, May 25, 2011 at 09:30:22AM +0200, Paolo Bonzini wrote: > On 05/25/2011 12:14 AM, David Gibson wrote: > >I don't see what the point of this is. Absolute irq numbers have no > >special meaning in the XICS context, and the guest kernel will remap > >them to virtual irqs anyway. > > It allows you to see the irq in "info qtree" for example. Hm, I see. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCH 3/3] spapr: make irq customizable via qdev
On Wed, May 25, 2011 at 05:13:40PM +0200, Markus Armbruster wrote:
> David Gibson writes:
>
> > On Tue, May 24, 2011 at 01:45:07PM +0200, Paolo Bonzini wrote:
> >> Signed-off-by: Paolo Bonzini
> >> Cc: Alexander Graf
> >> Cc: David Gibson
> >> ---
> >> hw/spapr_vio.c |8 +++-
> >> 1 files changed, 7 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c
> >> index be535d6..fee4c46 100644
> >> --- a/hw/spapr_vio.c
> >> +++ b/hw/spapr_vio.c
> >> @@ -52,6 +52,10 @@
> >> static struct BusInfo spapr_vio_bus_info = {
> >> .name = "spapr-vio",
> >> .size = sizeof(VIOsPAPRBus),
> >> +.props = (Property[]) {
> >> +DEFINE_PROP_UINT32("irq", VIOsPAPRDevice, vio_irq_num, 0), \
> >> +DEFINE_PROP_END_OF_LIST(),
> >> +},
> >> };
> >
> > I don't see what the point of this is. Absolute irq numbers have no
> > special meaning in the XICS context, and the guest kernel will remap
> > them to virtual irqs anyway.
>
> Are the irq numbers guest-visible?
Yes.
> If yes, a property may be required
> to keep them stable across migration. Especially when hot-plug comes
> into play.
Ah, yes, that's a point.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCH 1/3] spapr: allow creating devices with -device
On Wed, May 25, 2011 at 09:29:26AM +0200, Paolo Bonzini wrote: > On 05/25/2011 12:12 AM, David Gibson wrote: > >>@@ -602,6 +604,8 @@ static int spapr_vio_busdev_init(DeviceState *qdev, > >>DeviceInfo *qinfo) > >> } > >> > >> dev->qdev.id = id; > >>+dev->vio_irq_num = bus->irq++; > >>+dev->qirq = xics_find_qirq(spapr->icp, dev->vio_irq_num); > > > >I'd prefer to see an spapr_allocate_irq() function, rather than open > >coding this multiple times. > > I don't understand. This is the only call to xics_find_qirq, unlike > before this patch. It's not open coded multiple times. Uh, sorry, I wasn't thinking it through when I assumed it was duplicated. Actually, in any case I wouldn't mind multiple calls to xics_find_qirq(), it's the actual allocation - the irq++ - being potentially duplicated which bothers me. It's not now, but with this approach it would need to be when we add non VIO devices to the system which is coming (PCI, virtio, ..). > I can surely add a spapr_allocate_irq() function that would keep the > code independent of the particular interrupt controller. Would you > prefer something that gives back the virtual IRQ number as well: > > qemu_irq *spapr_allocate_irq(uint32_t *p_vio_irq_num) > > or should I keep that in the VIOsPAPRBus, like this: > > qemu_irq *spapr_allocate_irq(uint32_t p_vio_irq_num) In fact just returning the xics irq num and using xics_find_qirq() on that would be ok by me. The point is that I don't want the policy for irq allocation on the global interrupt controller to be open coded here at the bus level. > ? Should I pass a sPAPREnvironment too, or should it just use the global? Passing it would be preferable. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [Qemu-devel] [PATCH uq/master V2] kvm: Add CPUID support for VIA CPU
Hi, Jan
>
> > @@ -855,6 +870,8 @@ int cpu_x86_register (CPUX86State *env,
> > env->cpuid_xlevel = def->xlevel;
> > env->cpuid_kvm_features = def->kvm_features;
> > env->cpuid_svm_features = def->svm_features;
> > +env->cpuid_ext4_features = def->ext4_features;
> > +env->cpuid_xlevel2 = def->xlevel2;
> > if (!kvm_enabled()) {
> > env->cpuid_features &= TCG_FEATURES;
> > env->cpuid_ext_features &= TCG_EXT_FEATURES; @@ -1034,7
> > +1051,12 @@ void cpu_x86_cpuid(CPUX86State *env, uin
> > uint32_t *ecx, uint32_t *edx) {
> > /* test if maximum index reached */
> > -if (index & 0x8000) {
> > +if ((index & 0xC00f) == index) {
>
> This condition can't be correct. It triggers on every index <= 15 and
> breaks qemu.
I'm so sorry to make such a stupid mistake. Thank you very for your revieview.
>
> > +/* Handle the Centaur's CPUID instruction. */
> > +if (index > env->cpuid_xlevel2) {
> > +index = env->cpuid_xlevel2;
> > +}
> > +} else if (index & 0x8000) {
>
> Your very first version looked like this:
The first version has some problem, so you could ignore it.
>
> -if (index & 0x8000) {
> +if ((index & 0xC000) == 0xC000) {
> + /* Handle the Centaur's CPUID instruction.*
> + * If cpuid_xlevel2 is "0", then put into the*
> + * default case. */
> + if (env->cpuid_xlevel2 == 0)
> + index = 0xF000;
> + else if (index > env->cpuid_xlevel2)
> + index = env->cpuid_xlevel2;
> +} else if (index & 0x8000) {
>
> Something went wrong here, please re-validate the patch carefully.
Ok, I will check it soon.
[Qemu-devel] Hello Would You Like To Earn
Hello qemu-devel Would you like to earn an extra $200 everyday?, for just 45 minutes work? You could quit your job and make double the money at home working for yourself. visit->http:tinyurl.com/3brnlpx Regards, Sharon Burns Survey Human Resources Dept.
[Qemu-devel] Hello Would You Like To Earn
Hello qemu-devel Would you like to earn an extra $200 everyday?, for just 45 minutes work? You could quit your job and make double the money at home working for yourself. visit->http:tinyurl.com/3brnlpx Regards, Sharon Burns Survey Human Resources Dept.
[Qemu-devel] [RFC]QEMU disk I/O limits
Hello, all, I have prepared to work on a feature called "Disk I/O limits" for qemu-kvm projeect. This feature will enable the user to cap disk I/O amount performed by a VM.It is important for some storage resources to be shared among multi-VMs. As you've known, if some of VMs are doing excessive disk I/O, they will hurt the performance of other VMs. More detail is available here: http://wiki.qemu.org/Features/DiskIOLimits 1.) Why we need per-drive disk I/O limits As you've known, for linux, cgroup blkio-controller has supported I/O throttling on block devices. More importantly, there is no single mechanism for disk I/O throttling across all underlying storage types (image file, LVM, NFS, Ceph) and for some types there is no way to throttle at all. Disk I/O limits feature introduces QEMU block layer I/O limits together with command-line and QMP interfaces for configuring limits. This allows I/O limits to be imposed across all underlying storage types using a single interface. 2.) How disk I/O limits will be implemented QEMU block layer will introduce a per-drive disk I/O request queue for those disks whose "disk I/O limits" feature is enabled. It can control disk I/O limits individually for each disk when multiple disks are attached to a VM, and enable use cases like unlimited local disk access but shared storage access with limits. In mutliple I/O threads scenario, when an application in a VM issues a block I/O request, this request will be intercepted by QEMU block layer, then it will calculate disk runtime I/O rate and determine if it has go beyond its limits. If yes, this I/O request will enqueue to that introduced queue; otherwise it will be serviced. 3.) How the users enable and play with it QEMU -drive option will be extended so that disk I/O limits can be specified on its command line, such as -drive [iops=xxx,][throughput=xxx] or -drive [iops_rd=xxx,][iops_wr=xxx,][throughput=xxx] etc. When this argument is specified, it means that "disk I/O limits" feature is enabled for this drive disk. The feature will also provide users with the ability to change per-drive disk I/O limits at runtime using QMP commands. Regards, Zhiyong Wu
[Qemu-devel] Hello Would You Like To Earn
Hello qemu-devel Would you like to earn an extra $200 everyday?, for just 45 minutes work? You could quit your job and make double the money at home working for yourself. visit->http:tinyurl.com/3brnlpx Regards, Sharon Burns Survey Human Resources Dept.
Re: [Qemu-devel] [RESEND][PATCH 1/2] Fix USB mouse Set_Protocol behavior
On 05/28/11 17:47, Kevin O'Connor wrote: The QEMU USB mouse claims to support the "boot" protocol (bInterfaceSubClass is 1). However, the mouse rejects the Set_Protocol command. The qemu mouse does support the "boot" protocol specification, so a simple fix is to enable the Set_Protocol request. Added to the usb patch queue (both). thanks, Gerd
