Re: [Qemu-devel] [PATCH 03/22] tcg-i386: Tidy ext8u and ext16u operations.
On Thu, May 20, 2010 at 03:39:08PM +0200, Aurelien Jarno wrote: > On Wed, May 19, 2010 at 11:31:27AM -0700, Richard Henderson wrote: > > On 05/18/2010 11:47 PM, Aurelien Jarno wrote: > > > The reg allocator is able to issue move if needed, so the only > > > improvement this patch is for doing a ext8u on both "q" registers. > > > > > > OTOH the reg allocator knows this situation and will try to avoid this > > > situation during the allocation. Cheating on the reg allocator might > > > have some wrong effects, especially after your patch "Allocate > > > call-saved registers first". I am thinking of the scenario where the > > > value is in memory (which is likely to be the case given the limited > > > number of registers), it will be likely loaded in a "r" register (they > > > are now at the top priority), and then ext8u will be called, which will > > > issue "mov" + "and" instructions instead of a "movzbl" instruction. > > > > The case I was concerned with is the fact that if we have a value > > allocated to, say, %esi, and we need to to an ext8u, then the > > register allocator has been told that it must move the value to a > > "q" register in order to perform the movzbl. In this case, the > > new code will simply emit the andl. > > > > I.e. the real problem is that we've told the register allocator > > one way that the extend can be implemented, but not every way. > > > > > All of that is purely theoretical. Do you know how does it behave in > > > practice? > > > > Picking the i386 target since it seems to use more extensions than > > any other target, from linux-user-test -d op_opt,out_asm i386/ls: > > > > There are 176 instances of ext8u. > > Of those, 83 instances are in-place, i.e. "ext8u_i32 tmp0,tmp0" > > > > I examined the first 2 dozen appearances in the output assembly: > > > > There are several instances of the value being in an "r" register: > > > > shr_i32 tmp1,edx,tmp13 > > ext8u_i32 tmp1,tmp1 > > => > > 0x601c5468: shr$0x8,%edi > > 0x601c546b: and$0xff,%edi > > > > All of the instances that I looked at that were not in-place happened > > to already be using a "q" register -- usually %ebx. I assume that's > > because we place %ebx as the first allocation register and that's just > > how things happen to work out once we've flushed the registers before > > the qemu_ld. > > > > qemu_ld8u tmp0,tmp2,$0x > > ext8u_i32 tmp13,tmp0 > > => > > 0x601c82f9: movzbl (%esi),%ebx > > 0x601c82fc: movzbl %bl,%ebx > > > > Do you have tried to compare the generated code before and after your > patch? I expect a few cases where your patch has some drawbacks, so I > don't know if there is a net gain on the size of the translated code. > I have done a quick test on /bin/ls. | instr | size | +++ before | 101305 | 344770 | after | 101258 | 344829 | In short a small gain in the number of instructions, and a small loss in the size of the translated code. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH] QEMU: change default disk cache behavior
On Thu, May 20, 2010 at 2:49 PM, Jes Sorensen wrote: > On 05/20/10 15:40, Anthony Liguori wrote: >> On 05/20/2010 08:36 AM, Jes Sorensen wrote: And I strongly suspect that such a blanket change would be wrong but that a more targeted change like making cache=none default for physical devices would satisfy mostly everyone. >>> Is there any other thing than physical devices attached to the -drive >>> parameter? >> >> Image files which are the overwhelming more common use-case. > > For image files we certainly want it too, at least for proper ones (ie. > raw). It could be that it causes problems for qcow2. Qcow2 is safest with cache=writethrough because it doesn't order image updates: https://bugzilla.redhat.com/show_bug.cgi?id=572825 http://wiki.qemu.org/Features/Qcow2DataIntegrity Stefan
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On Thu, 20 May 2010 04:30:56 pm Avi Kivity wrote: > On 05/20/2010 08:01 AM, Rusty Russell wrote: > > > >> A device with out of order > >> completion (like virtio-blk) will quickly randomize the unused > >> descriptor indexes, so every descriptor fetch will require a bounce. > >> > >> In contrast, if the rings hold the descriptors themselves instead of > >> pointers, we bounce (sizeof(descriptor)/cache_line_size) cache lines for > >> every descriptor, amortized. > >> > > We already have indirect, this would be a logical next step. So let's > > think about it. The avail ring would contain 64 bit values, the used ring > > would contain indexes into the avail ring. > > Have just one ring, no indexes. The producer places descriptors into > the ring and updates the head, The consumer copies out descriptors to > be processed and copies back in completed descriptors. Chaining is > always linear. The descriptors contain a tag that allow the producer to > identify the completion. This could definitely work. The original reason for the page boundaries was for untrusted inter-guest communication: with appropriate page protections they could see each other's rings and a simply inter-guest copy hypercall could verify that the other guest really exposed that data via virtio ring. But, cute as that is, we never did that. And it's not clear that it wins much over simply having the hypervisor read both rings directly. > > Can we do better? The obvious idea is to try to get rid of last_used and > > used, and use the ring itself. We would use an invalid entry to mark the > > head of the ring. > > Interesting! So a peer will read until it hits a wall. But how to > update the wall atomically? > > Maybe we can have a flag in the descriptor indicate headness or > tailness. Update looks ugly though: write descriptor with head flag, > write next descriptor with head flag, remove flag from previous descriptor. I was thinking a separate magic "invalid" entry. To publish an 3 descriptor chain, you would write descriptors 2 and 3, write an invalid entry at 4, barrier, write entry 1. It is a bit ugly, yes, but not terrible. I think that a simple simulator for this is worth writing, which tracks cacheline moves under various fullness scenarios... Cheers, Rusty.
Re: [Qemu-devel] [PATCH 03/22] tcg-i386: Tidy ext8u and ext16u operations.
On 05/20/2010 07:04 AM, Aurelien Jarno wrote: >> Do you have tried to compare the generated code before and after your >> patch? I expect a few cases where your patch has some drawbacks, so I >> don't know if there is a net gain on the size of the translated code. >> > > I have done a quick test on /bin/ls. >| instr | size | >+++ > before | 101305 | 344770 | > after | 101258 | 344829 | > > In short a small gain in the number of instructions, and a small loss in > the size of the translated code. That was pretty much the test I would have done. So where are we? Is the patch acceptable as-is, or should I be re-writing it without the constraints change? r~
[Qemu-devel] [PATCH 2/2] qcow2: Fix error handling in l2_allocate
l2_allocate has some intermediate states in which the image is inconsistent.
Change the order to write to the L1 table only after the new L2 table has
successfully been initialized.
Also reset the L2 cache in failure case, it's very likely wrong.
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c | 23 +--
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index ed5c4b2..244b4a7 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -239,14 +239,6 @@ static int l2_allocate(BlockDriverState *bs, int l1_index,
uint64_t **table)
return l2_offset;
}
-/* update the L1 entry */
-
-s->l1_table[l1_index] = l2_offset | QCOW_OFLAG_COPIED;
-ret = write_l1_entry(bs, l1_index);
-if (ret < 0) {
-return ret;
-}
-
/* allocate a new entry in the l2 cache */
min_index = l2_cache_new_entry(bs);
@@ -261,7 +253,7 @@ static int l2_allocate(BlockDriverState *bs, int l1_index,
uint64_t **table)
ret = bdrv_pread(bs->file, old_l2_offset, l2_table,
s->l2_size * sizeof(uint64_t));
if (ret < 0) {
-return ret;
+goto fail;
}
}
/* write the l2 table to the file */
@@ -269,7 +261,14 @@ static int l2_allocate(BlockDriverState *bs, int l1_index,
uint64_t **table)
ret = bdrv_pwrite(bs->file, l2_offset, l2_table,
s->l2_size * sizeof(uint64_t));
if (ret < 0) {
-return ret;
+goto fail;
+}
+
+/* update the L1 entry */
+s->l1_table[l1_index] = l2_offset | QCOW_OFLAG_COPIED;
+ret = write_l1_entry(bs, l1_index);
+if (ret < 0) {
+goto fail;
}
/* update the l2 cache entry */
@@ -279,6 +278,10 @@ static int l2_allocate(BlockDriverState *bs, int l1_index,
uint64_t **table)
*table = l2_table;
return 0;
+
+fail:
+qcow2_l2_cache_reset(bs);
+return ret;
}
static int count_contiguous_clusters(uint64_t nb_clusters, int cluster_size,
--
1.6.6.1
[Qemu-devel] [PATCH 1/2] qcow2: Clear L2 table cache after write error
If the L2 table was already updated in cache, but writing it to disk has
failed, we must not continue using the changed version in the cache to stay
consistent with what's on the disk.
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index c11680d..ed5c4b2 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -696,6 +696,7 @@ int qcow2_alloc_cluster_link_l2(BlockDriverState *bs,
QCowL2Meta *m)
ret = write_l2_entries(bs, l2_table, l2_offset, l2_index, m->nb_clusters);
if (ret < 0) {
+qcow2_l2_cache_reset(bs);
goto err;
}
--
1.6.6.1
[Qemu-devel] [PATCH 02/10] target-mips: add microMIPS-specific bits to mips-defs.h
There's a new ASE_MICROMIPS instruction flag, and some extra CP0_Config3
fields. The ISA and ISA_ON_EXC fields are specific to microMIPS. The
DSP2P is for version 2 of the DSP ASE.
Signed-off-by: Nathan Froyd
---
target-mips/cpu.h |3 +++
target-mips/mips-defs.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 7285636..986d938 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -363,6 +363,9 @@ struct CPUMIPSState {
#define CP0C2_SA 0
int32_t CP0_Config3;
#define CP0C3_M31
+#define CP0C3_ISA_ON_EXC 16
+#define CP0C3_ISA 14
+#define CP0C3_DSP2P 11
#define CP0C3_DSPP 10
#define CP0C3_LPA 7
#define CP0C3_VEIC 6
diff --git a/target-mips/mips-defs.h b/target-mips/mips-defs.h
index c57de02..a7f4697 100644
--- a/target-mips/mips-defs.h
+++ b/target-mips/mips-defs.h
@@ -38,6 +38,7 @@
#defineASE_DSPR2 0x0001
#defineASE_MT 0x0002
#defineASE_SMARTMIPS 0x0004
+#defineASE_MICROMIPS 0x0008
/* Chip specific instructions. */
#defineINSN_VR54XX 0x8000
--
1.6.3.2
[Qemu-devel] [PATCH 10/10] hw: honor low bit in mipssim machine
Signed-off-by: Nathan Froyd --- hw/mips_mipssim.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/hw/mips_mipssim.c b/hw/mips_mipssim.c index a747de5..cd6c2be 100644 --- a/hw/mips_mipssim.c +++ b/hw/mips_mipssim.c @@ -106,7 +106,9 @@ static void main_cpu_reset(void *opaque) CPUState *env = s->env; cpu_reset(env); -env->active_tc.PC = s->vector; +env->active_tc.PC = s->vector & ~(target_ulong)1; +if (s->vector & 1) +env->hflags |= MIPS_HFLAG_M16; } static void -- 1.6.3.2
[Qemu-devel] [PATCH 00/10] target-mips: add microMIPS ASE support
This patch series adds support for the microMIPS ASE. microMIPS is a
new ASE similar to MIPS16, but re-encodes the entire instruction set
into 16-bit and 32-bit instructions--in contrast to MIPS16, which
re-encodes only integer instructions. The mechanisms for going in and
out of microMIPS mode are identical to those for MIPS16; a given chip
cannot support both ASEs simultaneously.
The first half of the series consists of small refactorings to make it
easier to delegate microMIPS instruction decoding to the usual gen_*
functions. The second half adds support for microMIPS in all the
necessary places.
The patch has been tested extensively in our QEMU tree; this patch has
been tested against our compilers (GNU/Linux emulation), which include
microMIPS support. We have obtained identical test results for MIPS32
and microMIPS testing. (The microMIPS patch for binutils has been
posted upstream; the microMIPS patch for GCC is forthcoming.) It is
possible to boot kernels compiled for microMIPS, but we have been
unsuccessful in consistently being able to do so, and have not yet
tracked down the root issue(s).
Nathan Froyd (10):
target-mips: break out [ls][wd]c1 and rdhwr insn generation
target-mips: add microMIPS-specific bits to mips-defs.h
target-mips: add enum constants for various invocations of FOP
target-mips: refactor {c,abs}.cond.fmt insns
target-mips: small changes to use new FMT_ enums
target-mips: add microMIPS ASE support
target-mips: add microMIPS CPUs
target-mips: add microMIPS exception handler support
linux-user: honor low bit of entry PC for MIPS
hw: honor low bit in mipssim machine
hw/mips_mipssim.c|4 +-
linux-user/main.c|4 +-
target-mips/cpu.h|3 +
target-mips/helper.c | 21 +-
target-mips/helper.h |9 +
target-mips/mips-defs.h |1 +
target-mips/op_helper.c | 136 ++
target-mips/translate.c | 3050 ++
target-mips/translate_init.c | 61 +
9 files changed, 3047 insertions(+), 242 deletions(-)
[Qemu-devel] [PATCH 07/10] target-mips: add microMIPS CPUs
Signed-off-by: Nathan Froyd
---
target-mips/translate_init.c | 61 ++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/target-mips/translate_init.c b/target-mips/translate_init.c
index b79ed56..8e17f4b 100644
--- a/target-mips/translate_init.c
+++ b/target-mips/translate_init.c
@@ -141,6 +141,25 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_FMT,
},
{
+.name = "4Km-micromips",
+.CP0_PRid = 0x00018300,
+/* Config1 implemented, fixed mapping MMU,
+ no virtual icache, uncached coherency. */
+.CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_FMT << CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 |
+ (0 << CP0C1_IS) | (3 << CP0C1_IL) | (1 << CP0C1_IA) |
+ (0 << CP0C1_DS) | (3 << CP0C1_DL) | (1 << CP0C1_DA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3,
+.SYNCI_Step = 32,
+.CCRes = 2,
+.CP0_Status_rw_bitmask = 0x1258FF17,
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
+.mmu_type = MMU_TYPE_FMT,
+},
+{
.name = "4KEcR1",
.CP0_PRid = 0x00018400,
.CP0_Config0 = MIPS_CONFIG0 | (MMU_TYPE_R4000 << CP0C0_MT),
@@ -245,6 +264,25 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_R4000,
},
{
+.name = "24Kc-micromips",
+.CP0_PRid = 0x00019300,
+.CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) |
+(MMU_TYPE_R4000 << CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 | (15 << CP0C1_MMU) |
+ (0 << CP0C1_IS) | (3 << CP0C1_IL) | (1 << CP0C1_IA) |
+ (0 << CP0C1_DS) | (3 << CP0C1_DL) | (1 << CP0C1_DA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3 | (0 << CP0C3_VInt),
+.SYNCI_Step = 32,
+.CCRes = 2,
+/* No DSP implemented. */
+.CP0_Status_rw_bitmask = 0x1278FF1F,
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
+.mmu_type = MMU_TYPE_R4000,
+},
+{
.name = "24Kf",
.CP0_PRid = 0x00019300,
.CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) |
@@ -269,6 +307,29 @@ static const mips_def_t mips_defs[] =
.mmu_type = MMU_TYPE_R4000,
},
{
+.name = "24Kf-micromips",
+.CP0_PRid = 0x00019300,
+.CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) |
+(MMU_TYPE_R4000 << CP0C0_MT),
+.CP0_Config1 = MIPS_CONFIG1 | (1 << CP0C1_FP) | (15 << CP0C1_MMU) |
+ (0 << CP0C1_IS) | (3 << CP0C1_IL) | (1 << CP0C1_IA) |
+ (0 << CP0C1_DS) | (3 << CP0C1_DL) | (1 << CP0C1_DA),
+.CP0_Config2 = MIPS_CONFIG2,
+.CP0_Config3 = MIPS_CONFIG3 | (0 << CP0C3_VInt),
+.CP0_LLAddr_rw_bitmask = 0,
+.CP0_LLAddr_shift = 4,
+.SYNCI_Step = 32,
+.CCRes = 2,
+/* No DSP implemented. */
+.CP0_Status_rw_bitmask = 0x3678FF1F,
+.CP1_fcr0 = (1 << FCR0_F64) | (1 << FCR0_L) | (1 << FCR0_W) |
+(1 << FCR0_D) | (1 << FCR0_S) | (0x93 << FCR0_PRID),
+.SEGBITS = 32,
+.PABITS = 32,
+.insn_flags = CPU_MIPS32R2 | ASE_MICROMIPS,
+.mmu_type = MMU_TYPE_R4000,
+},
+{
.name = "34Kf",
.CP0_PRid = 0x00019500,
.CP0_Config0 = MIPS_CONFIG0 | (0x1 << CP0C0_AR) |
--
1.6.3.2
[Qemu-devel] [PATCH 05/10] target-mips: small changes to use new FMT_ enums
Signed-off-by: Nathan Froyd
---
target-mips/translate.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 8a7f3e9..c42d8dd 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -359,7 +359,8 @@ enum {
/* 0 - 15 are reserved */
FMT_S = 16,
FMT_D = 17,
-/* 18 - 19 are reserved */
+FMT_E = 18,
+FMT_Q = 19,
FMT_W = 20,
FMT_L = 21,
FMT_PS = 22,
@@ -378,13 +379,13 @@ enum {
OPC_BC1 = (0x08 << 21) | OPC_CP1, /* bc */
OPC_BC1ANY2 = (0x09 << 21) | OPC_CP1,
OPC_BC1ANY4 = (0x0A << 21) | OPC_CP1,
-OPC_S_FMT= (0x10 << 21) | OPC_CP1, /* 16: fmt=single fp */
-OPC_D_FMT= (0x11 << 21) | OPC_CP1, /* 17: fmt=double fp */
-OPC_E_FMT= (0x12 << 21) | OPC_CP1, /* 18: fmt=extended fp */
-OPC_Q_FMT= (0x13 << 21) | OPC_CP1, /* 19: fmt=quad fp */
-OPC_W_FMT= (0x14 << 21) | OPC_CP1, /* 20: fmt=32bit fixed */
-OPC_L_FMT= (0x15 << 21) | OPC_CP1, /* 21: fmt=64bit fixed */
-OPC_PS_FMT = (0x16 << 21) | OPC_CP1, /* 22: fmt=paired single fp */
+OPC_S_FMT= (FMT_S << 21) | OPC_CP1, /* 16: fmt=single fp */
+OPC_D_FMT= (FMT_D << 21) | OPC_CP1, /* 17: fmt=double fp */
+OPC_E_FMT= (FMT_E << 21) | OPC_CP1, /* 18: fmt=extended fp */
+OPC_Q_FMT= (FMT_Q << 21) | OPC_CP1, /* 19: fmt=quad fp */
+OPC_W_FMT= (FMT_W << 21) | OPC_CP1, /* 20: fmt=32bit fixed */
+OPC_L_FMT= (FMT_L << 21) | OPC_CP1, /* 21: fmt=64bit fixed */
+OPC_PS_FMT = (FMT_PS << 21) | OPC_CP1, /* 22: fmt=paired single fp */
};
#define MASK_CP1_FUNC(op) MASK_CP1(op) | (op & 0x3F)
--
1.6.3.2
[Qemu-devel] [PATCH 01/10] target-mips: break out [ls][wd]c1 and rdhwr insn generation
Signed-off-by: Nathan Froyd
---
target-mips/translate.c | 106 ++-
1 files changed, 59 insertions(+), 47 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index c95ecb1..2075d09 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -1220,6 +1220,17 @@ static void gen_flt_ldst (DisasContext *ctx, uint32_t
opc, int ft,
tcg_temp_free(t0);
}
+static void gen_cop1_ldst(CPUState *env, DisasContext *ctx,
+ uint32_t op, int rt, int rs, int16_t imm)
+{
+if (env->CP0_Config1 & (1 << CP0C1_FP)) {
+check_cp1_enabled(ctx);
+gen_flt_ldst(ctx, op, rt, rs, imm);
+} else {
+generate_exception_err(ctx, EXCP_CpU, 1);
+}
+}
+
/* Arithmetic with immediate operand */
static void gen_arith_imm (CPUState *env, DisasContext *ctx, uint32_t opc,
int rt, int rs, int16_t imm)
@@ -7528,6 +7539,52 @@ static void gen_flt3_arith (DisasContext *ctx, uint32_t
opc,
fregnames[fs], fregnames[ft]);
}
+static void
+gen_rdhwr (CPUState *env, DisasContext *ctx, int rt, int rd)
+{
+TCGv t0;
+
+check_insn(env, ctx, ISA_MIPS32R2);
+t0 = tcg_temp_new();
+
+switch (rd) {
+case 0:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_cpunum(t0);
+gen_store_gpr(t0, rt);
+break;
+case 1:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_synci_step(t0);
+gen_store_gpr(t0, rt);
+break;
+case 2:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_cc(t0);
+gen_store_gpr(t0, rt);
+break;
+case 3:
+save_cpu_state(ctx, 1);
+gen_helper_rdhwr_ccres(t0);
+gen_store_gpr(t0, rt);
+break;
+case 29:
+#if defined(CONFIG_USER_ONLY)
+tcg_gen_ld_tl(t0, cpu_env, offsetof(CPUState, tls_value));
+gen_store_gpr(t0, rt);
+break;
+#else
+/* XXX: Some CPUs implement this in hardware.
+ Not supported yet. */
+#endif
+default:/* Invalid */
+MIPS_INVAL("rdhwr");
+generate_exception(ctx, EXCP_RI);
+break;
+}
+tcg_temp_free(t0);
+}
+
static void handle_delay_slot (CPUState *env, DisasContext *ctx,
int insn_bytes)
{
@@ -8999,47 +9056,7 @@ static void decode_opc (CPUState *env, DisasContext
*ctx, int *is_branch)
gen_bshfl(ctx, op2, rt, rd);
break;
case OPC_RDHWR:
-check_insn(env, ctx, ISA_MIPS32R2);
-{
-TCGv t0 = tcg_temp_new();
-
-switch (rd) {
-case 0:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_cpunum(t0);
-gen_store_gpr(t0, rt);
-break;
-case 1:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_synci_step(t0);
-gen_store_gpr(t0, rt);
-break;
-case 2:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_cc(t0);
-gen_store_gpr(t0, rt);
-break;
-case 3:
-save_cpu_state(ctx, 1);
-gen_helper_rdhwr_ccres(t0);
-gen_store_gpr(t0, rt);
-break;
-case 29:
-#if defined(CONFIG_USER_ONLY)
-tcg_gen_ld_tl(t0, cpu_env, offsetof(CPUState, tls_value));
-gen_store_gpr(t0, rt);
-break;
-#else
-/* XXX: Some CPUs implement this in hardware.
- Not supported yet. */
-#endif
-default:/* Invalid */
-MIPS_INVAL("rdhwr");
-generate_exception(ctx, EXCP_RI);
-break;
-}
-tcg_temp_free(t0);
-}
+gen_rdhwr(env, ctx, rt, rd);
break;
case OPC_FORK:
check_insn(env, ctx, ASE_MT);
@@ -9242,12 +9259,7 @@ static void decode_opc (CPUState *env, DisasContext
*ctx, int *is_branch)
case OPC_LDC1:
case OPC_SWC1:
case OPC_SDC1:
-if (env->CP0_Config1 & (1 << CP0C1_FP)) {
-check_cp1_enabled(ctx);
-gen_flt_ldst(ctx, op, rt, rs, imm);
-} else {
-generate_exception_err(ctx, EXCP_CpU, 1);
-}
+gen_cop1_ldst(env, ctx, op, rt, rs, imm);
break;
case OPC_CP1:
--
1.6.3.2
[Qemu-devel] [PATCH 09/10] linux-user: honor low bit of entry PC for MIPS
Signed-off-by: Nathan Froyd
---
linux-user/main.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 18b52c0..76d443b 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3192,7 +3192,9 @@ int main(int argc, char **argv, char **envp)
for(i = 0; i < 32; i++) {
env->active_tc.gpr[i] = regs->regs[i];
}
-env->active_tc.PC = regs->cp0_epc;
+env->active_tc.PC = regs->cp0_epc & ~(target_ulong)1;
+if (regs->cp0_epc & 1)
+env->hflags |= MIPS_HFLAG_M16;
}
#elif defined(TARGET_SH4)
{
--
1.6.3.2
[Qemu-devel] [PATCH 04/10] target-mips: refactor {c, abs}.cond.fmt insns
Move all knowledge about coprocessor-checking and register numbering
into the gen_cmp* helper functions.
Signed-off-by: Nathan Froyd
---
target-mips/translate.c | 232 ++-
1 files changed, 149 insertions(+), 83 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 2568e16..8a7f3e9 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -354,6 +354,18 @@ enum {
/* Coprocessor 1 (rs field) */
#define MASK_CP1(op) MASK_OP_MAJOR(op) | (op & (0x1F << 21))
+/* Values for the fmt field in FP instructions */
+enum {
+/* 0 - 15 are reserved */
+FMT_S = 16,
+FMT_D = 17,
+/* 18 - 19 are reserved */
+FMT_W = 20,
+FMT_L = 21,
+FMT_PS = 22,
+/* 23 - 31 are reserved */
+};
+
enum {
OPC_MFC1 = (0x00 << 21) | OPC_CP1,
OPC_DMFC1= (0x01 << 21) | OPC_CP1,
@@ -663,39 +675,6 @@ static inline int get_fp_bit (int cc)
return 23;
}
-#define FOP_CONDS(type, fmt, bits)\
-static inline void gen_cmp ## type ## _ ## fmt(int n, TCGv_i##bits a, \
- TCGv_i##bits b, int cc)\
-{ \
-switch (n) { \
-case 0: gen_helper_2i(cmp ## type ## _ ## fmt ## _f, a, b, cc);break;\
-case 1: gen_helper_2i(cmp ## type ## _ ## fmt ## _un, a, b, cc); break;\
-case 2: gen_helper_2i(cmp ## type ## _ ## fmt ## _eq, a, b, cc); break;\
-case 3: gen_helper_2i(cmp ## type ## _ ## fmt ## _ueq, a, b, cc); break;\
-case 4: gen_helper_2i(cmp ## type ## _ ## fmt ## _olt, a, b, cc); break;\
-case 5: gen_helper_2i(cmp ## type ## _ ## fmt ## _ult, a, b, cc); break;\
-case 6: gen_helper_2i(cmp ## type ## _ ## fmt ## _ole, a, b, cc); break;\
-case 7: gen_helper_2i(cmp ## type ## _ ## fmt ## _ule, a, b, cc); break;\
-case 8: gen_helper_2i(cmp ## type ## _ ## fmt ## _sf, a, b, cc); break;\
-case 9: gen_helper_2i(cmp ## type ## _ ## fmt ## _ngle, a, b, cc); break;\
-case 10: gen_helper_2i(cmp ## type ## _ ## fmt ## _seq, a, b, cc); break;\
-case 11: gen_helper_2i(cmp ## type ## _ ## fmt ## _ngl, a, b, cc); break;\
-case 12: gen_helper_2i(cmp ## type ## _ ## fmt ## _lt, a, b, cc); break;\
-case 13: gen_helper_2i(cmp ## type ## _ ## fmt ## _nge, a, b, cc); break;\
-case 14: gen_helper_2i(cmp ## type ## _ ## fmt ## _le, a, b, cc); break;\
-case 15: gen_helper_2i(cmp ## type ## _ ## fmt ## _ngt, a, b, cc); break;\
-default: abort(); \
-} \
-}
-
-FOP_CONDS(, d, 64)
-FOP_CONDS(abs, d, 64)
-FOP_CONDS(, s, 32)
-FOP_CONDS(abs, s, 32)
-FOP_CONDS(, ps, 64)
-FOP_CONDS(abs, ps, 64)
-#undef FOP_CONDS
-
/* Tests */
static inline void gen_save_pc(target_ulong pc)
{
@@ -836,6 +815,125 @@ static inline void check_mips_64(DisasContext *ctx)
generate_exception(ctx, EXCP_RI);
}
+/* Define small wrappers for gen_load_fpr* so that we have a uniform
+ calling interface for 32 and 64-bit FPRs. No sense in changing
+ all callers for gen_load_fpr32 when we need the CTX parameter for
+ this one use. */
+#define gen_ldcmp_fpr32(ctx, x, y) gen_load_fpr32(x, y)
+#define gen_ldcmp_fpr64(ctx, x, y) gen_load_fpr64(ctx, x, y)
+#define FOP_CONDS(type, abs, fmt, ifmt, bits) \
+static inline void gen_cmp ## type ## _ ## fmt(DisasContext *ctx, int n, \
+ int ft, int fs, int cc)\
+{ \
+TCGv_i##bits fp0 = tcg_temp_new_i##bits (); \
+TCGv_i##bits fp1 = tcg_temp_new_i##bits (); \
+switch (ifmt) { \
+case FMT_PS: \
+check_cp1_64bitmode(ctx); \
+break;\
+case FMT_D: \
+if (abs) \
+check_cop1x(ctx); \
+check_cp1_registers(ctx, fs | ft);\
+break;\
+case FMT_S: \
+if (abs) \
+check_cop1x(ctx); \
+
[Qemu-devel] [PATCH 08/10] target-mips: add microMIPS exception handler support
Unlike MIPS16, microMIPS lets you choose the ISA mode for your exception
handlers.
Signed-off-by: Nathan Froyd
---
target-mips/helper.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/target-mips/helper.c b/target-mips/helper.c
index 8102f03..90c3b3a 100644
--- a/target-mips/helper.c
+++ b/target-mips/helper.c
@@ -385,6 +385,18 @@ static target_ulong exception_resume_pc (CPUState *env)
return bad_pc;
}
+static void set_hflags_for_handler (CPUState *env)
+{
+/* Exception handlers are entered in 32-bit mode. */
+env->hflags &= ~(MIPS_HFLAG_M16);
+/* ...except that microMIPS lets you choose. */
+if (env->insn_flags & ASE_MICROMIPS) {
+env->hflags |= (!!(env->CP0_Config3
+ & (1 << CP0C3_ISA_ON_EXC))
+<< MIPS_HFLAG_M16_SHIFT);
+}
+}
+
#endif
void do_interrupt (CPUState *env)
@@ -440,8 +452,7 @@ void do_interrupt (CPUState *env)
if (!(env->CP0_Status & (1 << CP0St_EXL)))
env->CP0_Cause &= ~(1 << CP0Ca_BD);
env->active_tc.PC = (int32_t)0xBFC00480;
-/* Exception handlers are entered in 32-bit mode. */
-env->hflags &= ~(MIPS_HFLAG_M16);
+set_hflags_for_handler(env);
break;
case EXCP_RESET:
cpu_reset(env);
@@ -461,8 +472,7 @@ void do_interrupt (CPUState *env)
if (!(env->CP0_Status & (1 << CP0St_EXL)))
env->CP0_Cause &= ~(1 << CP0Ca_BD);
env->active_tc.PC = (int32_t)0xBFC0;
-/* Exception handlers are entered in 32-bit mode. */
-env->hflags &= ~(MIPS_HFLAG_M16);
+set_hflags_for_handler(env);
break;
case EXCP_EXT_INTERRUPT:
cause = 0;
@@ -581,8 +591,7 @@ void do_interrupt (CPUState *env)
env->active_tc.PC = (int32_t)(env->CP0_EBase & ~0x3ff);
}
env->active_tc.PC += offset;
-/* Exception handlers are entered in 32-bit mode. */
-env->hflags &= ~(MIPS_HFLAG_M16);
+set_hflags_for_handler(env);
env->CP0_Cause = (env->CP0_Cause & ~(0x1f << CP0Ca_EC)) | (cause <<
CP0Ca_EC);
break;
default:
--
1.6.3.2
[Qemu-devel] [PATCH 03/10] target-mips: add enum constants for various invocations of FOP
Tweak gen_farith and its caller to use them.
Signed-off-by: Nathan Froyd
---
target-mips/translate.c | 266 ---
1 files changed, 180 insertions(+), 86 deletions(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 2075d09..2568e16 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -5714,6 +5714,100 @@ static void gen_compute_branch1 (CPUState *env,
DisasContext *ctx, uint32_t op,
#define FOP(func, fmt) (((fmt) << 21) | (func))
+enum {
+OPC_ADD_S = FOP(0, FMT_S),
+OPC_SUB_S = FOP(1, FMT_S),
+OPC_MUL_S = FOP(2, FMT_S),
+OPC_DIV_S = FOP(3, FMT_S),
+OPC_SQRT_S = FOP(4, FMT_S),
+OPC_ABS_S = FOP(5, FMT_S),
+OPC_MOV_S = FOP(6, FMT_S),
+OPC_NEG_S = FOP(7, FMT_S),
+OPC_ROUND_L_S = FOP(8, FMT_S),
+OPC_TRUNC_L_S = FOP(9, FMT_S),
+OPC_CEIL_L_S = FOP(10, FMT_S),
+OPC_FLOOR_L_S = FOP(11, FMT_S),
+OPC_ROUND_W_S = FOP(12, FMT_S),
+OPC_TRUNC_W_S = FOP(13, FMT_S),
+OPC_CEIL_W_S = FOP(14, FMT_S),
+OPC_FLOOR_W_S = FOP(15, FMT_S),
+OPC_MOVCF_S = FOP(17, FMT_S),
+OPC_MOVZ_S = FOP(18, FMT_S),
+OPC_MOVN_S = FOP(19, FMT_S),
+OPC_RECIP_S = FOP(21, FMT_S),
+OPC_RSQRT_S = FOP(22, FMT_S),
+OPC_RECIP2_S = FOP(28, FMT_S),
+OPC_RECIP1_S = FOP(29, FMT_S),
+OPC_RSQRT1_S = FOP(30, FMT_S),
+OPC_RSQRT2_S = FOP(31, FMT_S),
+OPC_CVT_D_S = FOP(33, FMT_S),
+OPC_CVT_W_S = FOP(36, FMT_S),
+OPC_CVT_L_S = FOP(37, FMT_S),
+OPC_CVT_PS_S = FOP(38, FMT_S),
+/* FOP(48..63, FMT_S) used for comparisons */
+OPC_ADD_D = FOP(0, FMT_D),
+OPC_SUB_D = FOP(1, FMT_D),
+OPC_MUL_D = FOP(2, FMT_D),
+OPC_DIV_D = FOP(3, FMT_D),
+OPC_SQRT_D = FOP(4, FMT_D),
+OPC_ABS_D = FOP(5, FMT_D),
+OPC_MOV_D = FOP(6, FMT_D),
+OPC_NEG_D = FOP(7, FMT_D),
+OPC_ROUND_L_D = FOP(8, FMT_D),
+OPC_TRUNC_L_D = FOP(9, FMT_D),
+OPC_CEIL_L_D = FOP(10, FMT_D),
+OPC_FLOOR_L_D = FOP(11, FMT_D),
+OPC_ROUND_W_D = FOP(12, FMT_D),
+OPC_TRUNC_W_D = FOP(13, FMT_D),
+OPC_CEIL_W_D = FOP(14, FMT_D),
+OPC_FLOOR_W_D = FOP(15, FMT_D),
+OPC_MOVCF_D = FOP(17, FMT_D),
+OPC_MOVZ_D = FOP(18, FMT_D),
+OPC_MOVN_D = FOP(19, FMT_D),
+OPC_RECIP_D = FOP(21, FMT_D),
+OPC_RSQRT_D = FOP(22, FMT_D),
+OPC_RECIP2_D = FOP(28, FMT_D),
+OPC_RECIP1_D = FOP(29, FMT_D),
+OPC_RSQRT1_D = FOP(30, FMT_D),
+OPC_RSQRT2_D = FOP(31, FMT_D),
+OPC_CVT_S_D = FOP(32, FMT_D),
+OPC_CVT_W_D = FOP(36, FMT_D),
+OPC_CVT_L_D = FOP(37, FMT_D),
+/* FOP(48..63, FMT_D) used for comparisons */
+
+OPC_CVT_S_W = FOP(32, FMT_W),
+OPC_CVT_D_W = FOP(33, FMT_W),
+OPC_CVT_S_L = FOP(32, FMT_L),
+OPC_CVT_D_L = FOP(33, FMT_L),
+OPC_CVT_PS_PW = FOP(38, FMT_W),
+
+OPC_ADD_PS = FOP(0, FMT_PS),
+OPC_SUB_PS = FOP(1, FMT_PS),
+OPC_MUL_PS = FOP(2, FMT_PS),
+OPC_DIV_PS = FOP(3, FMT_PS),
+OPC_ABS_PS = FOP(5, FMT_PS),
+OPC_MOV_PS = FOP(6, FMT_PS),
+OPC_NEG_PS = FOP(7, FMT_PS),
+OPC_MOVCF_PS = FOP(17, FMT_PS),
+OPC_MOVZ_PS = FOP(18, FMT_PS),
+OPC_MOVN_PS = FOP(19, FMT_PS),
+OPC_ADDR_PS = FOP(24, FMT_PS),
+OPC_MULR_PS = FOP(26, FMT_PS),
+OPC_RECIP2_PS = FOP(28, FMT_PS),
+OPC_RECIP1_PS = FOP(29, FMT_PS),
+OPC_RSQRT1_PS = FOP(30, FMT_PS),
+OPC_RSQRT2_PS = FOP(31, FMT_PS),
+
+OPC_CVT_S_PU = FOP(32, FMT_PS),
+OPC_CVT_PW_PS = FOP(36, FMT_PS),
+OPC_CVT_S_PL = FOP(40, FMT_PS),
+OPC_PLL_PS = FOP(44, FMT_PS),
+OPC_PLU_PS = FOP(45, FMT_PS),
+OPC_PUL_PS = FOP(46, FMT_PS),
+OPC_PUU_PS = FOP(47, FMT_PS),
+/* FOP(48..63, FMT_PS) used for comparisons */
+};
+
static void gen_cp1 (DisasContext *ctx, uint32_t opc, int rt, int fs)
{
const char *opn = "cp1 move";
@@ -5937,8 +6031,8 @@ static void gen_farith (DisasContext *ctx, uint32_t op1,
enum { BINOP, CMPOP, OTHEROP } optype = OTHEROP;
uint32_t func = ctx->opcode & 0x3f;
-switch (ctx->opcode & FOP(0x3f, 0x1f)) {
-case FOP(0, 16):
+switch (opc) {
+case OPC_ADD_S:
{
TCGv_i32 fp0 = tcg_temp_new_i32();
TCGv_i32 fp1 = tcg_temp_new_i32();
@@ -5953,7 +6047,7 @@ static void gen_farith (DisasContext *ctx, uint32_t op1,
opn = "add.s";
optype = BINOP;
break;
-case FOP(1, 16):
+case OPC_SUB_S:
{
TCGv_i32 fp0 = tcg_temp_new_i32();
TCGv_i32 fp1 = tcg_temp_new_i32();
@@ -5968,7 +6062,7 @@ static void gen_farith (DisasContext *ctx, uint32_t op1,
opn = "sub.s";
optype = BINOP;
break;
-case FOP(2, 16):
+case OPC_MUL_S:
{
TCGv_i32 fp0 = tcg_temp_new_i32();
TCGv_i32 fp1 = tcg_temp_new_i32();
@@ -5983,7 +6077,7 @@ static void gen_farith (DisasContext *ctx, uint32_t op1,
opn = "mul.s";
optype = BINOP;
break;
-case FOP(3, 16):
+case OPC_DIV_S:
{
TCGv_i32 fp0 = tcg_temp
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On 05/20/2010 03:44 PM, Luiz Capitulino wrote:
I think there's another issue in the handling of strings.
The spec says that valid unescaped chars are in the following range:
unescaped = %x20-21 / %x23-5B / %x5D-10
But we do:
[IN_DQ_STRING] = {
[1 ... 0xFF] = IN_DQ_STRING,
['\\'] = IN_DQ_STRING_ESCAPE,
['"'] = IN_DONE_STRING,
},
Shouldn't we cover 0x20 .. 0xFF instead?
If it's the lexer, isn't just it being liberal in what it accepts?
paolo
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On 05/20/2010 05:25 PM, Luiz Capitulino wrote:
On Thu, 20 May 2010 17:16:01 +0200
Paolo Bonzini wrote:
On 05/20/2010 03:44 PM, Luiz Capitulino wrote:
I think there's another issue in the handling of strings.
The spec says that valid unescaped chars are in the following range:
unescaped = %x20-21 / %x23-5B / %x5D-10
But we do:
[IN_DQ_STRING] = {
[1 ... 0xFF] = IN_DQ_STRING,
['\\'] = IN_DQ_STRING_ESCAPE,
['"'] = IN_DONE_STRING,
},
Shouldn't we cover 0x20 .. 0xFF instead?
If it's the lexer, isn't just it being liberal in what it accepts?
Yes, it's the lexer, but you meant that the fix should be in
somewhere else?
I meant that we're just accepting some invalid JSON and that's not a big
deal.
Paolo
[Qemu-devel] Re: [PATCH] QEMU: Change default disk caching to nocache
On 05/20/2010 11:32 AM, jes.soren...@redhat.com wrote:
+if (bdrv_flags & BDRV_O_NOCACHE) {
+fprintf(stderr, "qemu: failed to open disk image %s as "
+"nocache (O_DIRECT) retrying as write-back\n", file);
+bdrv_flags &= BDRV_O_NOCACHE;
Missing ~ here.
+bdrv_flags |= BDRV_O_CACHE_WB;
+if (bdrv_open(dinfo->bdrv, file, bdrv_flags, drv)< 0)
+goto error_open;
+} else {
I think the retry should be done silently if no cache= option is given.
That is cache=none will be the default but:
- if it is not specified and not supported by the image, fall back to
writeback with no warning. However, this is just a QoI issue and can be
fixed later.
- if it is specified and not supported by the image, either fall back to
writeback with a warning, or fail altogether. The former would be a
change in behavior, so it has to be documented somewhere if it changes.
Or maybe add BDRV_O_CACHE_WT and let the backend decide the default?
Paolo
[Qemu-devel] Re: [PATCH 0/6]: QMP: Fix issues in parser/lexer
On 05/19/2010 11:43 PM, Anthony Liguori wrote: 4. Lexer expects a 'terminal' char to process a token Which means clients must send a sort of end of line char, so that we process their input. Maybe I'm missing something here, but I thought that the whole point of writing our own parser was to avoid this. If the lexer gets: "abc" It has no way of knowing if that's a token or if we're going to get: "abcd" Only } and ] are valid characters at the end of a JSON object, and neither requires lookahead. Paolo
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On Thu, 20 May 2010 17:16:01 +0200
Paolo Bonzini wrote:
> On 05/20/2010 03:44 PM, Luiz Capitulino wrote:
> > I think there's another issue in the handling of strings.
> >
> > The spec says that valid unescaped chars are in the following range:
> >
> > unescaped = %x20-21 / %x23-5B / %x5D-10
> >
> > But we do:
> >
> > [IN_DQ_STRING] = {
> > [1 ... 0xFF] = IN_DQ_STRING,
> > ['\\'] = IN_DQ_STRING_ESCAPE,
> > ['"'] = IN_DONE_STRING,
> > },
> >
> > Shouldn't we cover 0x20 .. 0xFF instead?
>
> If it's the lexer, isn't just it being liberal in what it accepts?
Yes, it's the lexer, but you meant that the fix should be in
somewhere else?
[Qemu-devel] Re: [PATCH 0/6]: QMP: Fix issues in parser/lexer
On Thu, 20 May 2010 17:18:23 +0200 Paolo Bonzini wrote: > On 05/19/2010 11:43 PM, Anthony Liguori wrote: > > > >> 4. Lexer expects a 'terminal' char to process a token > >> > >> Which means clients must send a sort of end of line char, so that we > >> process their input. > >> > >> Maybe I'm missing something here, but I thought that the whole > >> point of writing our own parser was to avoid this. > > > > If the lexer gets: > > > > "abc" > > > > It has no way of knowing if that's a token or if we're going to get: > > > > "abcd" > > Only } and ] are valid characters at the end of a JSON object, and > neither requires lookahead. Good point.
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On Thu, 20 May 2010 17:26:03 +0200
Paolo Bonzini wrote:
> On 05/20/2010 05:25 PM, Luiz Capitulino wrote:
> > On Thu, 20 May 2010 17:16:01 +0200
> > Paolo Bonzini wrote:
> >
> >> On 05/20/2010 03:44 PM, Luiz Capitulino wrote:
> >>>I think there's another issue in the handling of strings.
> >>>
> >>>The spec says that valid unescaped chars are in the following range:
> >>>
> >>> unescaped = %x20-21 / %x23-5B / %x5D-10
> >>>
> >>>But we do:
> >>>
> >>> [IN_DQ_STRING] = {
> >>> [1 ... 0xFF] = IN_DQ_STRING,
> >>> ['\\'] = IN_DQ_STRING_ESCAPE,
> >>> ['"'] = IN_DONE_STRING,
> >>> },
> >>>
> >>>Shouldn't we cover 0x20 .. 0xFF instead?
> >>
> >> If it's the lexer, isn't just it being liberal in what it accepts?
> >
> > Yes, it's the lexer, but you meant that the fix should be in
> > somewhere else?
>
> I meant that we're just accepting some invalid JSON and that's not a big
> deal.
It can become a big deal if clients rely on it and for some reason we
decide we should drop it. Ie. after QMP is declared stable such changes
won't be allowed.
Yes, I know, the chances of someone relying on this kind of thing is
probably almost zero. At the same time I think we should be very
conservative if there's no good reason to do otherwise.
Re: [Qemu-devel] [PATCH 04/10] target-mips: refactor {c, abs}.cond.fmt insns
On 05/20/2010 07:52 AM, Nathan Froyd wrote:
> +/* Tests */
> +#define OP_COND(name, cond) \
> +static inline void glue(gen_op_, name) (TCGv ret, TCGv t0, TCGv t1) \
> +{ \
> +int l1 = gen_new_label(); \
> +int l2 = gen_new_label(); \
> +\
> +tcg_gen_brcond_tl(cond, t0, t1, l1);\
> +tcg_gen_movi_tl(ret, 0);\
> +tcg_gen_br(l2); \
> +gen_set_label(l1); \
> +tcg_gen_movi_tl(ret, 1);\
> +gen_set_label(l2); \
> +}
> +OP_COND(eq, TCG_COND_EQ);
> +OP_COND(ne, TCG_COND_NE);
> +OP_COND(ge, TCG_COND_GE);
> +OP_COND(geu, TCG_COND_GEU);
> +OP_COND(lt, TCG_COND_LT);
> +OP_COND(ltu, TCG_COND_LTU);
> +#undef OP_COND
> +
> +#define OP_CONDI(name, cond)
> \
...
> +#define OP_CONDZ(name, cond) \
What are these doing in this patch?
r~
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On 05/20/2010 05:34 PM, Rusty Russell wrote: Have just one ring, no indexes. The producer places descriptors into the ring and updates the head, The consumer copies out descriptors to be processed and copies back in completed descriptors. Chaining is always linear. The descriptors contain a tag that allow the producer to identify the completion. This could definitely work. The original reason for the page boundaries was for untrusted inter-guest communication: with appropriate page protections they could see each other's rings and a simply inter-guest copy hypercall could verify that the other guest really exposed that data via virtio ring. But, cute as that is, we never did that. And it's not clear that it wins much over simply having the hypervisor read both rings directly. AFAICS having separate avail_ring/used_ring/desc_pool is orthogonal to this cuteness. Can we do better? The obvious idea is to try to get rid of last_used and used, and use the ring itself. We would use an invalid entry to mark the head of the ring. Interesting! So a peer will read until it hits a wall. But how to update the wall atomically? Maybe we can have a flag in the descriptor indicate headness or tailness. Update looks ugly though: write descriptor with head flag, write next descriptor with head flag, remove flag from previous descriptor. I was thinking a separate magic "invalid" entry. To publish an 3 descriptor chain, you would write descriptors 2 and 3, write an invalid entry at 4, barrier, write entry 1. It is a bit ugly, yes, but not terrible. Worth exploring. This amortizes the indexes into the ring, a good thing. Another thing we can do is place the tail a half ring away from the head (and limit ring utilization to 50%), reducing bounces on short kicks. Or equivalently have an avail ring and used ring, but both containing tagged descriptors instead of pointers to descriptors. I think that a simple simulator for this is worth writing, which tracks cacheline moves under various fullness scenarios... Yup. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On 05/20/2010 10:16 AM, Paolo Bonzini wrote:
On 05/20/2010 03:44 PM, Luiz Capitulino wrote:
I think there's another issue in the handling of strings.
The spec says that valid unescaped chars are in the following range:
unescaped = %x20-21 / %x23-5B / %x5D-10
That's a spec bug IMHO. Tab is %x09. Surely you can include tabs in
strings. Any parser that didn't accept that would be broken.
But we do:
[IN_DQ_STRING] = {
[1 ... 0xFF] = IN_DQ_STRING,
['\\'] = IN_DQ_STRING_ESCAPE,
['"'] = IN_DONE_STRING,
},
Shouldn't we cover 0x20 .. 0xFF instead?
If it's the lexer, isn't just it being liberal in what it accepts?
I believe the parser correctly rejects invalid UTF-8 sequences.
Regards,
Anthony Liguori
paolo
[Qemu-devel] Re: [PATCH 0/6]: QMP: Fix issues in parser/lexer
On 05/20/2010 10:18 AM, Paolo Bonzini wrote: On 05/19/2010 11:43 PM, Anthony Liguori wrote: 4. Lexer expects a 'terminal' char to process a token Which means clients must send a sort of end of line char, so that we process their input. Maybe I'm missing something here, but I thought that the whole point of writing our own parser was to avoid this. If the lexer gets: "abc" It has no way of knowing if that's a token or if we're going to get: "abcd" Only } and ] are valid characters at the end of a JSON object, and neither requires lookahead. Having look ahead operate differently for different states really complicates the lexer. I don't see this as a big problem in practice. Regards, Anthony Liguori Paolo
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On 05/20/2010 10:35 AM, Luiz Capitulino wrote: I meant that we're just accepting some invalid JSON and that's not a big deal. It can become a big deal if clients rely on it and for some reason we decide we should drop it. Ie. after QMP is declared stable such changes won't be allowed. Clients should only rely on standard JSON. Anything else is a bug in the client. Regards, Anthony Liguori Yes, I know, the chances of someone relying on this kind of thing is probably almost zero. At the same time I think we should be very conservative if there's no good reason to do otherwise.
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On Thu, 20 May 2010 10:50:41 -0500
Anthony Liguori wrote:
> On 05/20/2010 10:16 AM, Paolo Bonzini wrote:
> > On 05/20/2010 03:44 PM, Luiz Capitulino wrote:
> >> I think there's another issue in the handling of strings.
> >>
> >> The spec says that valid unescaped chars are in the following range:
> >>
> >> unescaped = %x20-21 / %x23-5B / %x5D-10
>
> That's a spec bug IMHO. Tab is %x09. Surely you can include tabs in
> strings. Any parser that didn't accept that would be broken.
Honestly, I had the impression this should be encoded as: %x5C %x74, but
if you're right, wouldn't this be true for other sequences as well?
> >>
> >> But we do:
> >>
> >> [IN_DQ_STRING] = {
> >> [1 ... 0xFF] = IN_DQ_STRING,
> >> ['\\'] = IN_DQ_STRING_ESCAPE,
> >> ['"'] = IN_DONE_STRING,
> >> },
> >>
> >> Shouldn't we cover 0x20 .. 0xFF instead?
> >
> > If it's the lexer, isn't just it being liberal in what it accepts?
>
> I believe the parser correctly rejects invalid UTF-8 sequences.
Will check.
Re: [Qemu-devel] [PATCH 04/10] target-mips: refactor {c, abs}.cond.fmt insns
On Thu, May 20, 2010 at 08:34:16AM -0700, Richard Henderson wrote: > On 05/20/2010 07:52 AM, Nathan Froyd wrote: > > +/* Tests */ > > +#define OP_COND(name, cond) \ > > +#define OP_CONDI(name, cond) > > \ > > +#define OP_CONDZ(name, cond) \ > > What are these doing in this patch? They are zombies, come back from the grave of source control. v2 of the patch will be forthcoming once people have had time to comment on other parts of the patch. -Nathan
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On Thu, 20 May 2010 10:54:42 -0500 Anthony Liguori wrote: > On 05/20/2010 10:35 AM, Luiz Capitulino wrote: > >> I meant that we're just accepting some invalid JSON and that's not a big > >> deal. > >> > > It can become a big deal if clients rely on it and for some reason we > > decide we should drop it. Ie. after QMP is declared stable such changes > > won't be allowed. > > > > Clients should only rely on standard JSON. Anything else is a bug in > the client. I feel this is like a trap, why exposing it if don't want clients to use them?
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On 05/20/2010 11:27 AM, Luiz Capitulino wrote:
On Thu, 20 May 2010 10:50:41 -0500
Anthony Liguori wrote:
On 05/20/2010 10:16 AM, Paolo Bonzini wrote:
On 05/20/2010 03:44 PM, Luiz Capitulino wrote:
I think there's another issue in the handling of strings.
The spec says that valid unescaped chars are in the following range:
unescaped = %x20-21 / %x23-5B / %x5D-10
That's a spec bug IMHO. Tab is %x09. Surely you can include tabs in
strings. Any parser that didn't accept that would be broken.
Honestly, I had the impression this should be encoded as: %x5C %x74, but
if you're right, wouldn't this be true for other sequences as well?
I don't think most reasonable clients are going to quote tabs as '\t'.
Regards,
Anthony Liguori
But we do:
[IN_DQ_STRING] = {
[1 ... 0xFF] = IN_DQ_STRING,
['\\'] = IN_DQ_STRING_ESCAPE,
['"'] = IN_DONE_STRING,
},
Shouldn't we cover 0x20 .. 0xFF instead?
If it's the lexer, isn't just it being liberal in what it accepts?
I believe the parser correctly rejects invalid UTF-8 sequences.
Will check.
[Qemu-devel] [Bug 391879] Re: migrate exec ignores exit status
This is a bug and has been reported upstream, it is unlikely to be fixed at the distribution level and therefore anyone interested in working on this bug should contribute a patch to the upstream project. This will then filter down to Ubuntu when it is merged mainline. Marking "Won't Fix" against the Ubuntu package. Thanks for reporting this bug. ** Changed in: qemu-kvm (Ubuntu) Status: Confirmed => Won't Fix -- migrate exec ignores exit status https://bugs.launchpad.net/bugs/391879 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Won't Fix Bug description: Binary package hint: kvm Using migrate "exec:cat > foo; false" in the monitor results in the state of the VM being written to foo, as expected, and the VM then being stopped. This is surprising, as I think it stands to reason that in case of a failed migrate-exec process, which is what a non-zero exit status implies to me, the VM should continue. == Version information $ lsb_release -rd Description:Ubuntu 9.04 Release:9.04 $ apt-cache policy kvm kvm: Installed: 1:84+dfsg-0ubuntu11 Candidate: 1:84+dfsg-0ubuntu11 Version table: *** 1:84+dfsg-0ubuntu11 0 500 http://gb.archive.ubuntu.com jaunty/main Packages 100 /var/lib/dpkg/status
Re: [Qemu-devel] [Bug 391879] Re: migrate exec ignores exit status
On Thu, May 20, 2010 at 04:50:59PM -, Dave Walker wrote: > This is a bug and has been reported upstream, it is unlikely to be fixed > at the distribution level and therefore anyone interested in working on > this bug should contribute a patch to the upstream project. This will > then filter down to Ubuntu when it is merged mainline. Marking "Won't > Fix" against the Ubuntu package. > > Thanks for reporting this bug. > > ** Changed in: qemu-kvm (Ubuntu) >Status: Confirmed => Won't Fix > > -- > migrate exec ignores exit status > https://bugs.launchpad.net/bugs/391879 > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. This bug appears to be filed against the Ubuntu qemu component, rather than the upstream qemu component. Are we supposed to be getting notifications for all Ubuntu distro qemu bugs too, rather than just usptream bug reports ? Daniel. -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [Bug 391879] Re: migrate exec ignores exit status
On Thu, May 20, 2010 at 12:11 PM, Daniel P. Berrange wrote: > This bug appears to be filed against the Ubuntu qemu component, > rather than the upstream qemu component. Are we supposed to be > getting notifications for all Ubuntu distro qemu bugs too, rather > than just usptream bug reports ? This bug is filed as affecting both the qemu-kvm package in Ubuntu, as well as the QEMU project (upstream). Activity in the bug is sent to subscribed parties of both the affected package, and the affected project. :-Dustin
[Qemu-devel] Re: [PATCH 1/2] arm_timer: reload timer when enabled
On Sun, May 02, 2010 at 03:20:51PM +0530, Rabin Vincent wrote: > Reload the timer when TimerControl is written, if the timer is to be > enabled. Otherwise, if an earlier write to TimerLoad was done while > periodic mode was not set, s->delta may incorrectly still have the value > of the maximum limit instead of the value written to TimerLoad. > > This problem is evident on versatileap on current linux-next, which > enables TIMER_CTRL_32BIT before writing to TimerLoad and then enabling > periodic mode and starting the timer. This causes the first periodic > tick to be scheduled to occur after 0x periods, leading to a > perceived hang while the kernel waits for the first timer tick. > > Signed-off-by: Rabin Vincent Could these patches please be applied? What was then linux-next is now current Linux mainline, and it doesn't boot without this patch. Rabin
[Qemu-devel] Re: [PATCH 0/6]: QMP: Fix issues in parser/lexer
On Thu, 20 May 2010 10:52:58 -0500 Anthony Liguori wrote: > On 05/20/2010 10:18 AM, Paolo Bonzini wrote: > > On 05/19/2010 11:43 PM, Anthony Liguori wrote: > >> > >>> 4. Lexer expects a 'terminal' char to process a token > >>> > >>> Which means clients must send a sort of end of line char, so > >>> that we > >>> process their input. > >>> > >>> Maybe I'm missing something here, but I thought that the whole > >>> point of writing our own parser was to avoid this. > >> > >> If the lexer gets: > >> > >> "abc" > >> > >> It has no way of knowing if that's a token or if we're going to get: > >> > >> "abcd" > > > > Only } and ] are valid characters at the end of a JSON object, and > > neither requires lookahead. > > Having look ahead operate differently for different states really > complicates the lexer. I don't see this as a big problem in practice. Would be a nice feature, but it's fine for me too and we'll have to note that in the QMP's spec.
[Qemu-devel] [Bug 241119] Re: usb_add of a Creative ZEN unrecognized in guest
** Also affects: qemu Importance: Undecided Status: New -- usb_add of a Creative ZEN unrecognized in guest https://bugs.launchpad.net/bugs/241119 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Confirmed Bug description: Binary package hint: kvm This happens when I add my Creative ZEN to a virtual machine running XP. The device is recognised well at first and drivers are installed correctly. But when trying to connect windows crashes with the classic blue screen It complains about something like usbohci.sys, I can't read well because it crashes too fast. I have also tried with another virtual machine running Vista, same results. Any help would be really appreciated! I'm using the module kvm-amd with Ubuntu 8.04 The USB device has the following ID: 041e:4157 Creative Technology, Ltd kvm: Installed: 1:62+dfsg-0ubuntu7 Candidate: 1:62+dfsg-0ubuntu7 Version table: *** 1:62+dfsg-0ubuntu7 0 500 http://archive.ubuntu.com hardy/main Packages 100 /var/lib/dpkg/status
[Qemu-devel] [Bug 583462] [NEW] qemu disables screensaver
Public bug reported: lucid, with compiz and fglrx: Screensaver on host will not kick in when qemu is running (kvm or no kvm). It seems to be related to the fact that the idle time reported by libXss.so on the host is being reset every four seconds or so when qemu is running, eventhough there is no activity on either guest or host. ** Affects: qemu Importance: Undecided Status: New -- qemu disables screensaver https://bugs.launchpad.net/bugs/583462 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: lucid, with compiz and fglrx: Screensaver on host will not kick in when qemu is running (kvm or no kvm). It seems to be related to the fact that the idle time reported by libXss.so on the host is being reset every four seconds or so when qemu is running, eventhough there is no activity on either guest or host.
[Qemu-devel] [Bug 583462] Re: qemu disables screensaver
** Attachment added: "Code used to check idle time." http://launchpadlibrarian.net/48825708/idletime -- qemu disables screensaver https://bugs.launchpad.net/bugs/583462 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: lucid, with compiz and fglrx: Screensaver on host will not kick in when qemu is running (kvm or no kvm). It seems to be related to the fact that the idle time reported by libXss.so on the host is being reset every four seconds or so when qemu is running, eventhough there is no activity on either guest or host.
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On Thu, 20 May 2010 11:55:00 -0500
Anthony Liguori wrote:
> On 05/20/2010 11:27 AM, Luiz Capitulino wrote:
> > On Thu, 20 May 2010 10:50:41 -0500
> > Anthony Liguori wrote:
> >
> >
> >> On 05/20/2010 10:16 AM, Paolo Bonzini wrote:
> >>
> >>> On 05/20/2010 03:44 PM, Luiz Capitulino wrote:
> >>>
> I think there's another issue in the handling of strings.
>
> The spec says that valid unescaped chars are in the following range:
>
> unescaped = %x20-21 / %x23-5B / %x5D-10
>
> >> That's a spec bug IMHO. Tab is %x09. Surely you can include tabs in
> >> strings. Any parser that didn't accept that would be broken.
> >>
> > Honestly, I had the impression this should be encoded as: %x5C %x74, but
> > if you're right, wouldn't this be true for other sequences as well?
> >
>
> I don't think most reasonable clients are going to quote tabs as '\t'.
That would be a bug, wouldn't it?
Python example:
>>> json.dumps('\t')
'"\\t"'
>>>
YAJL example (inlined below):
/tmp/ ./teste
0x22 0x5c 0x74 0x22
/tmp/
I think we should strictly conform to the spec, quirks should only be
added when really needed.
#include
#include
int main(void)
{
yajl_gen g;
unsigned int i, len = 0;
const unsigned char *str = NULL;
yajl_gen_config conf = { 0, " " };
g = yajl_gen_alloc(&conf, NULL);
if (yajl_gen_string(g, (unsigned char *) "\t", 1) != yajl_gen_status_ok)
return 1;
if (yajl_gen_get_buf(g, &str, &len) != yajl_gen_status_ok)
return 1;
for (i = 0; i < len; i++)
printf("0x%x ", str[i]);
printf("\n");
return 0;
}
Re: [Qemu-devel] [PATCH 03/22] tcg-i386: Tidy ext8u and ext16u operations.
On Thu, May 20, 2010 at 07:40:59AM -0700, Richard Henderson wrote: > On 05/20/2010 07:04 AM, Aurelien Jarno wrote: > >> Do you have tried to compare the generated code before and after your > >> patch? I expect a few cases where your patch has some drawbacks, so I > >> don't know if there is a net gain on the size of the translated code. > >> > > > > I have done a quick test on /bin/ls. > >| instr | size | > >+++ > > before | 101305 | 344770 | > > after | 101258 | 344829 | > > > > In short a small gain in the number of instructions, and a small loss in > > the size of the translated code. > > That was pretty much the test I would have done. > > So where are we? Is the patch acceptable as-is, or should I be > re-writing it without the constraints change? > Given the tests do not show a real improvement and given that it complexify the code generation, I don't think we should have such a patch. Could you please rewrite it without the constraints change? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 04/22] tcg-i386: Tidy ext8s and ext16s operations.
On Tue, Apr 13, 2010 at 04:13:49PM -0700, Richard Henderson wrote: > Define OPC_MOVSBL and OPC_MOVSWL. Factor opcode emission to > separate functions. Don't restrict the input register to the > low 4 "q" registers; emit shifts instead if needed. > Given this patch is of the same type as the previous one, I have also benchmarked it, here are the results: | instr | size | +++ before | 101258 | 344829 | after | 101258 | 344833 | This time the patch clearly doesn't bring an improvement, so I think it should also be rewritten without the constraints change. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On 05/20/2010 01:47 PM, Luiz Capitulino wrote: On Thu, 20 May 2010 11:55:00 -0500 Anthony Liguori wrote: On 05/20/2010 11:27 AM, Luiz Capitulino wrote: On Thu, 20 May 2010 10:50:41 -0500 Anthony Liguori wrote: On 05/20/2010 10:16 AM, Paolo Bonzini wrote: On 05/20/2010 03:44 PM, Luiz Capitulino wrote: I think there's another issue in the handling of strings. The spec says that valid unescaped chars are in the following range: unescaped = %x20-21 / %x23-5B / %x5D-10 That's a spec bug IMHO. Tab is %x09. Surely you can include tabs in strings. Any parser that didn't accept that would be broken. Honestly, I had the impression this should be encoded as: %x5C %x74, but if you're right, wouldn't this be true for other sequences as well? I don't think most reasonable clients are going to quote tabs as '\t'. That would be a bug, wouldn't it? Tabs are valid in JavaScript strings and I don't think it's reasonable to expect that a valid JavaScript string is not a valid JSON string. Regards, Anthony Liguori
Re: [Qemu-devel] [Bug 391879] Re: migrate exec ignores exit status
On 05/20/2010 12:11 PM, Daniel P. Berrange wrote: On Thu, May 20, 2010 at 04:50:59PM -, Dave Walker wrote: This is a bug and has been reported upstream, it is unlikely to be fixed at the distribution level and therefore anyone interested in working on this bug should contribute a patch to the upstream project. This will then filter down to Ubuntu when it is merged mainline. Marking "Won't Fix" against the Ubuntu package. Thanks for reporting this bug. ** Changed in: qemu-kvm (Ubuntu) Status: Confirmed => Won't Fix -- migrate exec ignores exit status https://bugs.launchpad.net/bugs/391879 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. This bug appears to be filed against the Ubuntu qemu component, rather than the upstream qemu component. Are we supposed to be getting notifications for all Ubuntu distro qemu bugs too, rather than just usptream bug reports ? It's an upstream bug that references an Ubuntu bug. Whenever a referenced bug has it's status changed, the upstream bug will be notified. You can also reference bugs in just about any Bugzilla including the Fedora bugzilla which is pretty nice because then when a bug gets fixed in Fedora, you get an update in the Launchpad bug tracker. Regards, Anthony Liguori Daniel.
Re: [Qemu-devel] Re: [PATCH] QEMU: Change default disk caching to nocache
On 05/20/2010 10:24 AM, Paolo Bonzini wrote:
On 05/20/2010 11:32 AM, jes.soren...@redhat.com wrote:
+if (bdrv_flags & BDRV_O_NOCACHE) {
+fprintf(stderr, "qemu: failed to open disk image %s as "
+"nocache (O_DIRECT) retrying as write-back\n",
file);
+bdrv_flags &= BDRV_O_NOCACHE;
Missing ~ here.
+bdrv_flags |= BDRV_O_CACHE_WB;
+if (bdrv_open(dinfo->bdrv, file, bdrv_flags, drv)< 0)
+goto error_open;
+} else {
I think the retry should be done silently if no cache= option is
given. That is cache=none will be the default but:
- if it is not specified and not supported by the image, fall back to
writeback with no warning. However, this is just a QoI issue and can
be fixed later.
- if it is specified and not supported by the image, either fall back
to writeback with a warning, or fail altogether. The former would be
a change in behavior, so it has to be documented somewhere if it changes.
Or maybe add BDRV_O_CACHE_WT and let the backend decide the default?
It used to be that we had a CACHE_DEFAULT which allowed qcow2 to do
CACHE_WB by default whereas everything else did CACHE_WT. The same
technique could be used to let physical devices do NOCACHE by default.
Regards,
Anthony Liguori
Paolo
Re: [Qemu-devel] [PATCH] QEMU: change default disk cache behavior
On 05/20/2010 08:49 AM, Jes Sorensen wrote: On 05/20/10 15:40, Anthony Liguori wrote: On 05/20/2010 08:36 AM, Jes Sorensen wrote: And I strongly suspect that such a blanket change would be wrong but that a more targeted change like making cache=none default for physical devices would satisfy mostly everyone. Is there any other thing than physical devices attached to the -drive parameter? Image files which are the overwhelming more common use-case. For image files we certainly want it too, at least for proper ones (ie. raw). What makes you say that? It could be that it causes problems for qcow2. It's definitely the wrong thing for qcow2 with backing files. Regards, Anthony Liguori I'll try and look at it when I am back. Cheers, Jes
[Qemu-devel] Re: [PATCH 2/6] json-lexer: Handle missing escapes
On Thu, 20 May 2010 13:52:08 -0500 Anthony Liguori wrote: > On 05/20/2010 01:47 PM, Luiz Capitulino wrote: > > On Thu, 20 May 2010 11:55:00 -0500 > > Anthony Liguori wrote: > > > > > >> On 05/20/2010 11:27 AM, Luiz Capitulino wrote: > >> > >>> On Thu, 20 May 2010 10:50:41 -0500 > >>> Anthony Liguori wrote: > >>> > >>> > >>> > On 05/20/2010 10:16 AM, Paolo Bonzini wrote: > > > > On 05/20/2010 03:44 PM, Luiz Capitulino wrote: > > > > > >> I think there's another issue in the handling of strings. > >> > >> The spec says that valid unescaped chars are in the following > >> range: > >> > >>unescaped = %x20-21 / %x23-5B / %x5D-10 > >> > >> > That's a spec bug IMHO. Tab is %x09. Surely you can include tabs in > strings. Any parser that didn't accept that would be broken. > > > >>>Honestly, I had the impression this should be encoded as: %x5C %x74, > >>> but > >>> if you're right, wouldn't this be true for other sequences as well? > >>> > >>> > >> I don't think most reasonable clients are going to quote tabs as '\t'. > >> > > That would be a bug, wouldn't it? > > > > Tabs are valid in JavaScript strings and I don't think it's reasonable > to expect that a valid JavaScript string is not a valid JSON string. IMO, we should do what the spec says and what bug free clients expect, what we consider reasonable or unreasonable is a different matter. I would be with you if the spec was proved wrong, specially if reference implementations out there didn't follow it either, but everything I found so far shows this is not the case. Another example: http://www.json.org/json2.js Search for 'character substitutions'.
Re: [Qemu-devel] [PATCH 0/6]: QMP: Fix issues in parser/lexer
On 05/20/2010 12:43 AM, Anthony Liguori wrote: The JSON specification explicitly says: "A JSON parser transforms a JSON text into another representation. A JSON parser MUST accept all texts that conform to the JSON grammar. A JSON parser MAY accept non-JSON forms or extensions." IOW, we're under no obligation to reject extensions and I can't think of a reason why we should. At the very least, we should document them. If the extension doesn't add any value but is merely a side effect of the implementation, we should remove it. Examples where this could hurt us: - we move to a json parsing library, the extension disappears, client breaks - someone writes a qemu simulator to test managment tool scalability (run zillions of fake guests on one machine), client breaks - someone writes a debug tool that interposes between client and qemu, client breaks - the json specification adds a new form that conflicts with one of our extensions [1], we can't use the new form Being strict in what we accept will reduce our support burden later on. [1] allowing infinite extensibility like this is irresponsible -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] Re: [PATCH 3/3] target-sparc: Inline some generation of carry for ADDX/SUBX.
Thanks, applied.
On Wed, May 12, 2010 at 6:04 PM, Richard Henderson wrote:
> Computing carry is trivial for some inputs. By avoiding an
> external function call, we generate near-optimal code for
> the common cases of add+addx (double-word arithmetic) and
> cmp+addx (a setcc pattern).
>
> Signed-off-by: Richard Henderson
> ---
> target-sparc/helper.h | 2 +-
> target-sparc/op_helper.c | 2 +-
> target-sparc/translate.c | 272
> +-
> 3 files changed, 200 insertions(+), 76 deletions(-)
>
> diff --git a/target-sparc/helper.h b/target-sparc/helper.h
> index 04c1306..6f103e7 100644
> --- a/target-sparc/helper.h
> +++ b/target-sparc/helper.h
> @@ -158,6 +158,6 @@ VIS_CMPHELPER(cmpne);
> #undef VIS_HELPER
> #undef VIS_CMPHELPER
> DEF_HELPER_0(compute_psr, void);
> -DEF_HELPER_0(compute_C_icc, tl);
> +DEF_HELPER_0(compute_C_icc, i32);
>
> #include "def-helper.h"
> diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c
> index 3783b02..125cd67 100644
> --- a/target-sparc/op_helper.c
> +++ b/target-sparc/op_helper.c
> @@ -1342,7 +1342,7 @@ void helper_compute_psr(void)
> CC_OP = CC_OP_FLAGS;
> }
>
> -target_ulong helper_compute_C_icc(void)
> +uint32_t helper_compute_C_icc(void)
> {
> uint32_t ret;
>
> diff --git a/target-sparc/translate.c b/target-sparc/translate.c
> index ea7c71b..713d3e1 100644
> --- a/target-sparc/translate.c
> +++ b/target-sparc/translate.c
> @@ -332,24 +332,132 @@ static inline void gen_op_add_cc(TCGv dst, TCGv src1,
> TCGv src2)
> tcg_gen_mov_tl(dst, cpu_cc_dst);
> }
>
> -static inline void gen_op_addxi_cc(TCGv dst, TCGv src1, target_long src2)
> +static TCGv_i32 gen_add32_carry32(void)
> {
> - gen_helper_compute_C_icc(cpu_tmp0);
> - tcg_gen_mov_tl(cpu_cc_src, src1);
> - tcg_gen_movi_tl(cpu_cc_src2, src2);
> - tcg_gen_add_tl(cpu_cc_dst, cpu_cc_src, cpu_tmp0);
> - tcg_gen_addi_tl(cpu_cc_dst, cpu_cc_dst, src2);
> - tcg_gen_mov_tl(dst, cpu_cc_dst);
> + TCGv_i32 carry_32, cc_src1_32, cc_src2_32;
> +
> + /* Carry is computed from a previous add: (dst < src) */
> +#if TARGET_LONG_BITS == 64
> + cc_src1_32 = tcg_temp_new_i32();
> + cc_src2_32 = tcg_temp_new_i32();
> + tcg_gen_trunc_i64_i32(cc_src1_32, cpu_cc_dst);
> + tcg_gen_trunc_i64_i32(cc_src2_32, cpu_cc_src);
> +#else
> + cc_src1_32 = cpu_cc_dst;
> + cc_src2_32 = cpu_cc_src;
> +#endif
> +
> + carry_32 = tcg_temp_new_i32();
> + tcg_gen_setcond_i32(TCG_COND_LTU, carry_32, cc_src1_32, cc_src2_32);
> +
> +#if TARGET_LONG_BITS == 64
> + tcg_temp_free_i32(cc_src1_32);
> + tcg_temp_free_i32(cc_src2_32);
> +#endif
> +
> + return carry_32;
> }
>
> -static inline void gen_op_addx_cc(TCGv dst, TCGv src1, TCGv src2)
> +static TCGv_i32 gen_sub32_carry32(void)
> {
> - gen_helper_compute_C_icc(cpu_tmp0);
> - tcg_gen_mov_tl(cpu_cc_src, src1);
> - tcg_gen_mov_tl(cpu_cc_src2, src2);
> - tcg_gen_add_tl(cpu_cc_dst, cpu_cc_src, cpu_tmp0);
> - tcg_gen_add_tl(cpu_cc_dst, cpu_cc_dst, cpu_cc_src2);
> - tcg_gen_mov_tl(dst, cpu_cc_dst);
> + TCGv_i32 carry_32, cc_src1_32, cc_src2_32;
> +
> + /* Carry is computed from a previous borrow: (src1 < src2) */
> +#if TARGET_LONG_BITS == 64
> + cc_src1_32 = tcg_temp_new_i32();
> + cc_src2_32 = tcg_temp_new_i32();
> + tcg_gen_trunc_i64_i32(cc_src1_32, cpu_cc_src);
> + tcg_gen_trunc_i64_i32(cc_src2_32, cpu_cc_src2);
> +#else
> + cc_src1_32 = cpu_cc_src;
> + cc_src2_32 = cpu_cc_src2;
> +#endif
> +
> + carry_32 = tcg_temp_new_i32();
> + tcg_gen_setcond_i32(TCG_COND_LTU, carry_32, cc_src1_32, cc_src2_32);
> +
> +#if TARGET_LONG_BITS == 64
> + tcg_temp_free_i32(cc_src1_32);
> + tcg_temp_free_i32(cc_src2_32);
> +#endif
> +
> + return carry_32;
> +}
> +
> +static void gen_op_addx_int(DisasContext *dc, TCGv dst, TCGv src1,
> + TCGv src2, int update_cc)
> +{
> + TCGv_i32 carry_32;
> + TCGv carry;
> +
> + switch (dc->cc_op) {
> + case CC_OP_DIV:
> + case CC_OP_LOGIC:
> + /* Carry is known to be zero. Fall back to plain ADD. */
> + if (update_cc) {
> + gen_op_add_cc(dst, src1, src2);
> + } else {
> + tcg_gen_add_tl(dst, src1, src2);
> + }
> + return;
> +
> + case CC_OP_ADD:
> + case CC_OP_TADD:
> + case CC_OP_TADDTV:
> +#if TCG_TARGET_REG_BITS == 32 && TARGET_LONG_BITS == 32
> + {
> + /* For 32-bit hosts, we can re-use the host's hardware carry
> + generation by using an ADD2 opcode. We discard the low
> + part of the output. Ideally we'd combine this operation
> + with the add that generated the carry in the first place. */
> + TCGv dst_low = tcg_temp_new();
> + tcg_gen_op6_i32(INDEX_op_add2_i32, dst_low, dst,
> + cpu_cc_src, src1, cpu_cc_src2, src2);
> + tcg_temp_free(dst_low);
> + goto add_done;
[Qemu-devel] Re: phys_page_find bug?
2010/5/7 Artyom Tarasenko : > phys_page_find (exec.c) returns sometimes a page for addresses where > nothing is connected. > > One example, done with qemu-system-sparc -M SS-20 > > ok f130 2f spacec@ . > > // The address translates correctly, in cpu_physical_memory_rw > // addr== 0xff130 (where nothing is connected) > // but then phys_page_find returns a nonzero and produces > > Unassigned mem read access of 1 byte to 000ff150 from x > > (note the "5" in the line above where "3" is expected) > > I wonder if this is only true for non-wired addresses, or whether > phys_page_find can also > find wrong pages for the addresses where something is connected? > > Or is my assumption is wrong and phys_page_find can return a page for > not-connected > addresses and the bug is actually in cpu_physical_memory_rw ? > > Is the qemu algorithm of working with the physical address space > described somewhere? I'm surprised that no one is interested in discussing this issue. It may affect other targets too. After some debugging I see that page 0xff15ff000 is allocated twice when emulating SS-20. Can this be a problem? >From the phys_page_find logic it looks like the pages are expected to be allocated in the natural order: the loop descends till the page hits a search mask. sun4m_hw_init initializes devices in a more or less random order. Can this be a problem? Also the function cpu_register_physical_memory_offset the following comment: ...Both start_addr and region_offset are rounded down to a page boundary before calculating this offset. This should not be a problem unless the low bits of start_addr and region_offset differ. */ What is meant here by "low bits"? I put a check if((region_offset & TARGET_PAGE_MASK)!=(start_addr & TARGET_PAGE_MASK)) printf... and it gets hit a lot within the address range 0xd0512-ff180 . Does it indicate a problem? -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
[Qemu-devel] [[RfC PATCH]] linux fbdev display driver prototype.
Display works with 32 bpp (both host + guest) only.
Which surprisingly didn't cause much problems so far in my testing.
Host runs with kms and inteldrmfb.
Mouse support isn't available yet.
I've cheated by passed through the hosts usb mouse for testing.
Keyboard works. Guest screen has whatever keymap you load inside
the guest. Text windows (monitor, serial, ...) have a simple en-us
keymap. Good enougth to type monitor commands. Not goot enougth to
work seriously on a serial terminal. But the qemu terminal emulation
isn't good enougth for that anyway ;)
Hot keys:
Ctrl-Alt-F -> host console switching.
Ctrl-Alt- -> qemu console switching.
Ctrl-Alt-ESC-> exit qemu.
Special feature: Sane console switching. Switching away stops screen
updates. Switching back redraws the screen. When started from the
linux console qemu uses the vt you've started it from (requires just
read/write access to /dev/fb0). When starting from somewhere else qemu
tries to open a unused virtual terminal and switch to it (usually
requires root privileges to open /dev/tty).
For some strange reason console switching from X11 to qemu doesn't work.
Anything else (including X11 -> text console -> qemu) works fine. To be
investigated ...
Cc: Julian Pidancet
Cc: Stefano Stabellini
Signed-off-by: Gerd Hoffmann
---
Makefile.objs|1 +
console.h|3 +
fbdev.c | 770 ++
linux-keynames.h | 386 +++
qemu-options.hx | 10 +
sysemu.h |1 +
vl.c | 10 +
7 files changed, 1181 insertions(+), 0 deletions(-)
create mode 100644 fbdev.c
create mode 100644 linux-keynames.h
diff --git a/Makefile.objs b/Makefile.objs
index ecdd53e..cff1a23 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -102,6 +102,7 @@ common-obj-y += $(addprefix audio/, $(audio-obj-y))
common-obj-y += keymaps.o
common-obj-$(CONFIG_SDL) += sdl.o sdl_zoom.o x_keymap.o
common-obj-$(CONFIG_CURSES) += curses.o
+common-obj-$(CONFIG_LINUX) += fbdev.o
common-obj-y += vnc.o acl.o d3des.o
common-obj-y += vnc-encoding-zlib.o vnc-encoding-hextile.o
common-obj-y += iov.o
diff --git a/console.h b/console.h
index 6def115..bba1da8 100644
--- a/console.h
+++ b/console.h
@@ -338,6 +338,9 @@ void qemu_console_copy(DisplayState *ds, int src_x, int
src_y,
/* sdl.c */
void sdl_display_init(DisplayState *ds, int full_screen, int no_frame);
+/* fbdev.c */
+void fbdev_display_init(DisplayState *ds, const char *device);
+
/* cocoa.m */
void cocoa_display_init(DisplayState *ds, int full_screen);
diff --git a/fbdev.c b/fbdev.c
new file mode 100644
index 000..9ad7db6
--- /dev/null
+++ b/fbdev.c
@@ -0,0 +1,770 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "qemu-common.h"
+#include "console.h"
+#include "keymaps.h"
+
+/* */
+
+/* file handles */
+static inttty, fb;
+
+/* saved state, for restore on exit */
+static intorig_vtno = 0;
+static intkd_omode;
+static struct vt_mode vt_omode;
+static struct fb_var_screeninfo fb_ovar;
+
+/* framebuffer */
+static struct fb_fix_screeninfo fb_fix;
+static struct fb_var_screeninfo fb_var;
+static uint8_t *fb_mem;
+static int fb_mem_offset = 0;
+
+/* linux console */
+static intvtno;
+static struct vt_mode vt_mode;
+static struct termios tty_attributes;
+static unsigned long tty_mode;
+static unsigned int tty_flags;
+static bool tty_mediumraw;
+static bool key_down[KEY_CNT];
+
+/* console switching */
+#define SIG_ACQ (SIGRTMIN+6)
+#define SIG_REL (SIGRTMIN+7)
+#define FB_ACTIVE0
+#define FB_REL_REQ 1
+#define FB_INACTIVE 2
+#define FB_ACQ_REQ 3
+static int fb_switch_state = FB_ACTIVE;
+
+/* qdev windup */
+static DisplayChangeListener *dcl;
+static intresize_screen;
+static intredraw_screen;
+static intcx, cy;
+static intdebug = 0;
+
+/* fwd decls */
+static int fbdev_activate_vt(int tty, int vtno, bool wait);
+
+/* */
+/* keyboard */
+
+static const char *keynames[] = {
+#include "linux-keynames.h"
+};
+
+static int scancode_map[KEY_CNT] = {
+[ KEY_ESC ] = 0x01,
+[ KEY_1] = 0x02,
+[ KEY_2] = 0x03,
+[ KEY_3] = 0x04,
+[ KEY_4] = 0x05,
+[ KEY_5] = 0x06,
+[ KEY_6] = 0x07,
+[ KEY_7] = 0x08,
+[ KE
[Qemu-devel] Problems changing dvdrom iso during execution
I cannot change DVD roms during execution using the monitor. I can only mount a cdrom/dvdrom if I specify the iso file in the command line x86_64-softmmu/qemu-system-x86_64 -hda ../../OSImages/sles11.qcow2 -cdrom ../../ISOz/mydvd.iso -m 2048 In the guest I can mount the iso image as you could normally expect mount /dev/cdrom /mnt mount: block device /dev/sr0 is write-protected, mounting read-only Info block in the monitor yields (qemu) info block ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 drv=dcow2 encrypted=0 ide1-cd0: type=cdrom removable=1 locked=1 file=../../ISOz/mydvd.iso ro=0 drv=raw encrypted=0 floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] When I try to do a eject ide0-cd0, I get a device busy message so I have to do a eject -f ide0-cd0 After which, an info block yields: (qemu) info block ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 drv=dcow2 encrypted=0 ide1-cd0: type=cdrom removable=1 locked=1 [not inserted] floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] I change the iso image with (or so it seems) (qemu) change ide1-cd0 ../../ISOz/mydvd2_rom.iso (qemu) info block ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 drv=dcow2 encrypted=0 ide1-cd0: type=cdrom removable=1 locked=1 file=../../ISOz/mydvd2.iso ro=0 drv=raw encrypted=0 floppy0: type=floppy removable=1 locked=0 [not inserted] sd0: type=floppy removable=1 locked=0 [not inserted] I go back to the guest and when I try to mount: mount /dev/cdrom /mnt mount: /dev/sr0 unknown device I'm running sles11 as guest and I think it may have something to do with sles11 as it works fine with ubuntu9. Any ideas what might be happening? Thanks AK
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On Wed, May 19, 2010 at 7:22 PM, Christian Brunner wrote:
> The attached patch is a block driver for the distributed file system
> Ceph (http://ceph.newdream.net/). This driver uses librados (which
> is part of the Ceph server) for direct access to the Ceph object
> store and is running entirely in userspace. Therefore it is
> called "rbd" - rados block device.
>
> To compile the driver a recent version of ceph (>= 0.20.1) is needed
> and you have to "--enable-rbd" when running configure.
>
> Additional information is available on the Ceph-Wiki:
>
> http://ceph.newdream.net/wiki/Kvm-rbd
I have no idea whether it makes sense to add Ceph (no objection
either). I have some minor comments below.
>
> ---
> Makefile | 3 +
> Makefile.objs | 1 +
> block/rados.h | 376 ++
> block/rbd.c | 585
> +
> block/rbd_types.h | 48 +
> configure | 27 +++
> 6 files changed, 1040 insertions(+), 0 deletions(-)
> create mode 100644 block/rados.h
> create mode 100644 block/rbd.c
> create mode 100644 block/rbd_types.h
>
> diff --git a/Makefile b/Makefile
> index eb9e02b..b1ab3e9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -27,6 +27,9 @@ configure: ;
> $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
>
> LIBS+=-lz $(LIBS_TOOLS)
> +ifdef CONFIG_RBD
> +LIBS+=-lrados
> +endif
>
> ifdef BUILD_DOCS
> DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8
> diff --git a/Makefile.objs b/Makefile.objs
> index acbaf22..85791ac 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -18,6 +18,7 @@ block-nested-y += parallels.o nbd.o blkdebug.o
> block-nested-$(CONFIG_WIN32) += raw-win32.o
> block-nested-$(CONFIG_POSIX) += raw-posix.o
> block-nested-$(CONFIG_CURL) += curl.o
> +block-nested-$(CONFIG_RBD) += rbd.o
>
> block-obj-y += $(addprefix block/, $(block-nested-y))
>
> diff --git a/block/rados.h b/block/rados.h
> new file mode 100644
> index 000..6cde9a1
> --- /dev/null
> +++ b/block/rados.h
> @@ -0,0 +1,376 @@
> +#ifndef __RADOS_H
> +#define __RADOS_H
IIRC underscores here may conflict with system header use. Please use
something like QEMU_BLOCK_RADOS_H.
> +
> +/*
> + * Data types for the Ceph distributed object storage layer RADOS
> + * (Reliable Autonomic Distributed Object Store).
> + */
> +
> +
> +
> +/*
> + * osdmap encoding versions
> + */
> +#define CEPH_OSDMAP_INC_VERSION 5
> +#define CEPH_OSDMAP_INC_VERSION_EXT 5
> +#define CEPH_OSDMAP_VERSION 5
> +#define CEPH_OSDMAP_VERSION_EXT 5
> +
> +/*
> + * fs id
> + */
> +struct ceph_fsid {
> + unsigned char fsid[16];
Too large indent, please check also elsewhere.
> +};
> +
> +static inline int ceph_fsid_compare(const struct ceph_fsid *a,
> + const struct ceph_fsid *b)
> +{
> + return memcmp(a, b, sizeof(*a));
> +}
> +
> +/*
> + * ino, object, etc.
> + */
> +typedef __le64 ceph_snapid_t;
Please use uint64_t and le_to_cpu()/cpu_to_le().
> +#define CEPH_SNAPDIR ((__u64)(-1)) /* reserved for hidden .snap dir */
Likewise, uint64_t is the standard type. Also other places.
> +#define CEPH_NOSNAP ((__u64)(-2)) /* "head", "live" revision */
> +#define CEPH_MAXSNAP ((__u64)(-3)) /* largest valid snapid */
> +
> +struct ceph_timespec {
> + __le32 tv_sec;
> + __le32 tv_nsec;
> +} __attribute__ ((packed));
> +
> +
> +/*
> + * object layout - how objects are mapped into PGs
> + */
> +#define CEPH_OBJECT_LAYOUT_HASH 1
> +#define CEPH_OBJECT_LAYOUT_LINEAR 2
> +#define CEPH_OBJECT_LAYOUT_HASHINO 3
> +
> +/*
> + * pg layout -- how PGs are mapped onto (sets of) OSDs
> + */
> +#define CEPH_PG_LAYOUT_CRUSH 0
> +#define CEPH_PG_LAYOUT_HASH 1
> +#define CEPH_PG_LAYOUT_LINEAR 2
> +#define CEPH_PG_LAYOUT_HYBRID 3
> +
> +
> +/*
> + * placement group.
> + * we encode this into one __le64.
> + */
> +struct ceph_pg {
> + __le16 preferred; /* preferred primary osd */
> + __le16 ps; /* placement seed */
> + __le32 pool; /* object pool */
> +} __attribute__ ((packed));
> +
> +/*
> + * pg_pool is a set of pgs storing a pool of objects
> + *
> + * pg_num -- base number of pseudorandomly placed pgs
> + *
> + * pgp_num -- effective number when calculating pg placement. this
> + * is used for pg_num increases. new pgs result in data being "split"
> + * into new pgs. for this to proceed smoothly, new pgs are intiially
> + * colocated with their parents; that is, pgp_num doesn't increase
> + * until the new pgs have successfully split. only _then_ are the new
> + * pgs placed independently.
> + *
> + * lpg_num -- localized pg count (per device). replicas are randomly
> + * selected.
> + *
> + * lpgp_num -- as above.
> + */
> +#define CEPH_PG_TYPE_REP 1
> +#define CEPH_PG_TYPE_RAID4 2
> +#define CEPH_PG_POOL_VERSION 2
> +struct ceph_pg_pool {
> + __u8 type; /* CEPH_PG_TYPE_* */
> + __u8 size;
[Qemu-devel] Re: [PATCH] pc: fix segfault introduced by 3d53f5c36ff6
Good catch. Thanks, applied.
On Thu, May 20, 2010 at 6:14 AM, Eduard - Gabriel Munteanu
wrote:
> Commit 3d53f5c36ff6 introduced a segfault by erroneously making fw_cfg a
> 'void **' and passing it around in different ways.
>
> Signed-off-by: Eduard - Gabriel Munteanu
> ---
> hw/pc.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/pc.c b/hw/pc.c
> index fee08c9..4a4a706 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -822,7 +822,7 @@ void pc_memory_init(ram_addr_t ram_size,
> ram_addr_t ram_addr, bios_offset, option_rom_offset;
> ram_addr_t below_4g_mem_size, above_4g_mem_size = 0;
> int bios_size, isa_bios_size;
> - void **fw_cfg;
> + void *fw_cfg;
>
> if (ram_size >= 0xe000 ) {
> above_4g_mem_size = ram_size - 0xe000;
> @@ -905,7 +905,7 @@ void pc_memory_init(ram_addr_t ram_size,
> rom_set_fw(fw_cfg);
>
> if (linux_boot) {
> - load_linux(*fw_cfg, kernel_filename, initrd_filename,
> kernel_cmdline, below_4g_mem_size);
> + load_linux(fw_cfg, kernel_filename, initrd_filename, kernel_cmdline,
> below_4g_mem_size);
> }
>
> for (i = 0; i < nb_option_roms; i++) {
> --
> 1.6.4.4
>
>
Re: [Qemu-devel] Problems changing dvdrom iso during execution
On 05/20/2010 02:29 PM, Adnan Khaleel wrote: > I cannot change DVD roms during execution using the monitor. I can only > mount a cdrom/dvdrom if I specify the iso file in the command line > x86_64-softmmu/qemu-system-x86_64 -hda ../../OSImages/sles11.qcow2 > -cdrom ../../ISOz/mydvd.iso -m 2048 > > In the guest I can mount the iso image as you could normally expect > mount /dev/cdrom /mnt > mount: block device /dev/sr0 is write-protected, mounting read-only > > Info block in the monitor yields > (qemu) info block > ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 > drv=dcow2 encrypted=0 > ide1-cd0: type=cdrom removable=1 locked=1 file=../../ISOz/mydvd.iso ro=0 > drv=raw encrypted=0 > floppy0: type=floppy removable=1 locked=0 [not inserted] > sd0: type=floppy removable=1 locked=0 [not inserted] > > When I try to do a eject ide0-cd0, I get a device busy message so I have > to do a eject -f ide0-cd0 > > After which, an info block yields: > (qemu) info block > ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 > drv=dcow2 encrypted=0 > ide1-cd0: type=cdrom removable=1 locked=1 [not inserted] > floppy0: type=floppy removable=1 locked=0 [not inserted] > sd0: type=floppy removable=1 locked=0 [not inserted] > > I change the iso image with (or so it seems) > > (qemu) change ide1-cd0 ../../ISOz/mydvd2_rom.iso > (qemu) info block > ide0-hd0: type=hd removable=0 file../../OSImages/sles11.qcow2 ro=0 > drv=dcow2 encrypted=0 > ide1-cd0: type=cdrom removable=1 locked=1 file=../../ISOz/mydvd2.iso > ro=0 drv=raw encrypted=0 > floppy0: type=floppy removable=1 locked=0 [not inserted] > sd0: type=floppy removable=1 locked=0 [not inserted] > > I go back to the guest and when I try to mount: > > mount /dev/cdrom /mnt > mount: /dev/sr0 unknown device > > I'm running sles11 as guest and I think it may have something to do with > sles11 as it works fine with ubuntu9. > > Any ideas what might be happening? Does it work if the guest uses ide based CD's: rmmod ide-scsi modprobe ide-cd David > > Thanks > > AK
[Qemu-devel] [PATCH] fix curses update - v2
On Mon, May 03, 2010 at 01:06:46PM -0500, Anthony Liguori wrote:
> On 04/22/2010 09:08 AM, Bernhard Kauer wrote:
> >Hi,
> >
> >>I believe this issue has come up before with a similar patch but
> >well i've submitted such a patch more than two years ago. Unfortunatelly
> >it got never applied, so that I have to patch my Qemu on every update...
> >
> >
> >>someone checked their ncurses and they didn't see the same issue.
> >>I just checked and here mvwaddchnstr() does not expect a null-terminated
> >>string either, but it skips the \0 characters.
> >This is not conforming to the Single UNIX Specification, which states
> >that the string is shown "until a null chtype is encountered". See for
> >example:
> > http://www.opengroup.org/onlinepubs/007908775/xcurses/addchstr.html
> >
> >
> >> So probably we should
> >>replace them with spaces or something else, I wouldn't like to
> >>replace a single library call with 80 calls, it's better to go through
> >>the string and replace them, maybe in console_write_ch or somewhere
> >>else.
> >That would be a one-liner. Should I send such a patch?
>
> Yes.
Replace the \0 character with a space to allow to use mvwaddchnstr for
full-screen updates in curses mode.
Signed-off-by: Bernhard Kauer
diff --git a/console.h b/console.h
index 6def115..42ff822 100644
--- a/console.h
+++ b/console.h
@@ -306,6 +306,7 @@ static inline int ds_get_bytes_per_pixel(DisplayState *ds)
typedef unsigned long console_ch_t;
static inline void console_write_ch(console_ch_t *dest, uint32_t ch)
{
+if (!(ch & 0xff)) ch = 0x20;
cpu_to_le32wu((uint32_t *) dest, ch);
}
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
2010/5/20 Blue Swirl : > On Wed, May 19, 2010 at 7:22 PM, Christian Brunner wrote: >> The attached patch is a block driver for the distributed file system >> Ceph (http://ceph.newdream.net/). This driver uses librados (which >> is part of the Ceph server) for direct access to the Ceph object >> store and is running entirely in userspace. Therefore it is >> called "rbd" - rados block device. >> >> To compile the driver a recent version of ceph (>= 0.20.1) is needed >> and you have to "--enable-rbd" when running configure. >> >> Additional information is available on the Ceph-Wiki: >> >> http://ceph.newdream.net/wiki/Kvm-rbd > > > I have no idea whether it makes sense to add Ceph (no objection > either). I have some minor comments below. Thanks for your comments. I'll send an updated patch in a few days. Having a central storage system is quite essential in larger hosting environments, it enables you to move your guest systems from one node to another easily (live-migration or dynamic restart). Traditionally this has been done using SAN, iSCSI or NFS. However most of these systems don't scale very well and and the costs for high-availability are quite high. With new approaches like Sheepdog or Ceph, things are getting a lot cheaper and you can scale your system without disrupting your service. The concepts are quite similar to what Amazon is doing in their EC2 environment, but they certainly won't publish it as OpenSource anytime soon. Both projects have advantages and disadvantages. Ceph is a bit more universal as it implements a whole filesystem. Sheepdog is more feature complete in regards of managing images (e.g. snapshots). Both projects require some additional work to become stable, but they are on a good way. I would really like to see both drivers in the qemu tree, as they are the key to a design shift in how storage in the datacenter is being built. Christian
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On 05/20/2010 04:18 PM, Christian Brunner wrote: Thanks for your comments. I'll send an updated patch in a few days. Having a central storage system is quite essential in larger hosting environments, it enables you to move your guest systems from one node to another easily (live-migration or dynamic restart). Traditionally this has been done using SAN, iSCSI or NFS. However most of these systems don't scale very well and and the costs for high-availability are quite high. With new approaches like Sheepdog or Ceph, things are getting a lot cheaper and you can scale your system without disrupting your service. The concepts are quite similar to what Amazon is doing in their EC2 environment, but they certainly won't publish it as OpenSource anytime soon. Both projects have advantages and disadvantages. Ceph is a bit more universal as it implements a whole filesystem. Sheepdog is more feature complete in regards of managing images (e.g. snapshots). Both projects require some additional work to become stable, but they are on a good way. I would really like to see both drivers in the qemu tree, as they are the key to a design shift in how storage in the datacenter is being built. I'd be more interested in enabling people to build these types of storage systems without touching qemu. Both sheepdog and ceph ultimately transmit I/O over a socket to a central daemon, right? So could we not standardize a protocol for this that both sheepdog and ceph could implement? Regards, Anthony Liguori Christian -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010
20.05.2010 11:15, Andre Przywara wrote: Michael Tokarev wrote: [] It'd be nice if we had more flexibility in defining custom machine types so you could just do qemu -M win98. This is wrong IMHO. win98 and winNT can run on various different machines, including all modern ones (yes I tried the same winNT on my Athlon X2-64, just had to switch SATA from AHCI to IDE; win95 works too)... just not in kvm :) Well, not really. You were lucky with your Athlon X2-64, actually it is the last machine not triggering the bug. I tried it on a AthlonII-X4 (which has maxleaf=5 as any newer AMD machines) and it showed the same bug. On Intel boxes this bug should trigger on every CPU starting with some Pentium4 models, including all Core chips. Have you tried versions with a newer service pack (SP6)? I replied in the original discussion -- after upgrading to SP6 there's no need in ,level=1 anymore, any -cpu variant works without crashes. The problem is to set it up, at least for me, since I don't have sp6 integrated into setup. Well, I don't use winNT to start with, actually, so for me it's not a problem at all ;) -- the reason why I asked is because I have a debian bugreport about this very issue, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575439 (and because I had winNT install handy) But this is really interesting information - that winNT fails on other CPUs too. Thank you for that, now I can close the debian bugreport ;) BTW: Does anyone knows what the problem with Windows95/98 on KVM is? I tried some tracing today, but couldn't find a hint. Um. The bugreport(s) come as a surprize for me: I tried to install win98 in kvm several times in the past but setup always failed - different messages in different versions of kvm, either "unable to emulate" or "real mode trap" or something else, or just lockup, usually on first reboot. So - the bugreports talks about mouse non-working, but this means win98 itself works somehow... I dunno :) I think these bug reports are about plain QEMU. I tried it yesterday, in fact the mouse is non-functional. In KVM Windows95 gives me a black screen after the welcome screen with the moving bottom row. There are just two lines at the top: (translated from the german version) While initializing device NTKERN: Windows protection fault. Restart the computer. Yeah, that's what i've seen too, it's exactly ow it fails here with modern kvm. KVM catched some #UDs due to ARPL from VM86 mode, but TCG got them too and it survived. So if anyone has some more hints, I'd be grateful. Thank you! /mjt
Re: [Qemu-devel] Problems changing dvdrom iso during execution
Thanks for your response. Does it work if the guest uses ide based CD's: rmmod ide-scsi modprobe ide-cd There isn't an ide-scsi but there is a scsi_mod and when I try to remove that it gives ERROR: Module scsi_mod is in use by sr_mod,sg,sd_mod,libata modprobe ide-cd seems to work. However it doesn't fix the problem. Interestingly, before doing modprobe ide-cd, linux> lsmod | grep ide ide_pci_generic 46520 ide_core 115068 2 ide_pci_generic, piix After the modprobe ide-cd, I get ide_cd_mod 339840 cdrom 362002 ide_cd_mod, sr_mod ide_pci_generic 46520 ide_core 115068 3 ide_cd_mod, ide_pci_generic, piix
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
2010/5/20 Anthony Liguori : >> With new approaches like Sheepdog or Ceph, things are getting a lot >> cheaper and you can scale your system without disrupting your service. >> The concepts are quite similar to what Amazon is doing in their EC2 >> environment, but they certainly won't publish it as OpenSource anytime >> soon. >> >> Both projects have advantages and disadvantages. Ceph is a bit more >> universal as it implements a whole filesystem. Sheepdog is more >> feature complete in regards of managing images (e.g. snapshots). Both >> projects require some additional work to become stable, but they are >> on a good way. >> >> I would really like to see both drivers in the qemu tree, as they are >> the key to a design shift in how storage in the datacenter is being >> built. >> > > I'd be more interested in enabling people to build these types of storage > systems without touching qemu. You could do this by using Yehuda's rbd kernel driver, but I think that it would be better to avoid this additional layer. > Both sheepdog and ceph ultimately transmit I/O over a socket to a central > daemon, right? So could we not standardize a protocol for this that both > sheepdog and ceph could implement? There is no central daemon. The concept is that they talk to many storage nodes at the same time. Data is distributed and replicated over many nodes in the network. The mechanism to do this is quite complex. I don't know about sheepdog, but in Ceph this is called RADOS (reliable autonomic distributed object store). Sheepdog and Ceph may look similar, but this is where they act different. I don't think that it would be possible to implement a common protocol. Regards, Christian
Re: [Qemu-devel] Problems changing dvdrom iso during execution
On 05/20/2010 03:48 PM, Adnan Khaleel wrote: > Thanks for your response. > > > Does it work if the guest uses ide based CD's: > rmmod ide-scsi > modprobe ide-cd > > There isn't an ide-scsi but there is a scsi_mod and when I try to remove > that it gives > ERROR: Module scsi_mod is in use by sr_mod,sg,sd_mod,libata > > modprobe ide-cd seems to work. Ok, I pulled those from a RHEL3 VM. Looks like SLES11 is using a newer 2.6 kernel. The idea I was poking at was to get the CD in the VM to go through the ide-cd layer and not the ata/scsi route. I had to do that for my RHEL3 guest to get some consistency with the DVD -- similar to the problem you are seeing. David > > However it doesn't fix the problem. > > Interestingly, before doing modprobe ide-cd, > linux> lsmod | grep ide > ide_pci_generic 46520 > ide_core 115068 2 ide_pci_generic, piix > > After the modprobe ide-cd, I get > ide_cd_mod 339840 > cdrom 362002 ide_cd_mod, sr_mod > ide_pci_generic 46520 > ide_core 115068 3 ide_cd_mod, ide_pci_generic, piix > > > >
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On Thu, May 20, 2010 at 1:31 PM, Blue Swirl wrote:
> On Wed, May 19, 2010 at 7:22 PM, Christian Brunner wrote:
>> The attached patch is a block driver for the distributed file system
>> Ceph (http://ceph.newdream.net/). This driver uses librados (which
>> is part of the Ceph server) for direct access to the Ceph object
>> store and is running entirely in userspace. Therefore it is
>> called "rbd" - rados block device.
...
>
> IIRC underscores here may conflict with system header use. Please use
> something like QEMU_BLOCK_RADOS_H.
This header is shared between the linux kernel client and the ceph
userspace servers and client. We can actually get rid of it, as we
only need it to define CEPH_OSD_TMAP_SET. We can move this definition
to librados.h.
>> diff --git a/block/rbd_types.h b/block/rbd_types.h
>> new file mode 100644
>> index 000..dfd5aa0
>> --- /dev/null
>> +++ b/block/rbd_types.h
>> @@ -0,0 +1,48 @@
>> +#ifndef _FS_CEPH_RBD
>> +#define _FS_CEPH_RBD
>
> QEMU_BLOCK_RBD?
This header is shared between the ceph kernel client, between the qemu
rbd module (and between other ceph utilities). It'd be much easier
maintaining it without having to have a different implementation for
each. The same goes to the use of __le32/64 and __u32/64 within these
headers.
>
>> +
>> +#include
>
> Can you use standard includes, like or ? Are
> Ceph libraries used in other systems than Linux?
Not at the moment. I guess that we can take this include out.
>
>> +
>> +/*
>> + * rbd image 'foo' consists of objects
>> + * foo.rbd - image metadata
>> + * foo.
>> + * foo.0001
>> + * ... - data
>> + */
>> +
>> +#define RBD_SUFFIX ".rbd"
>> +#define RBD_DIRECTORY "rbd_directory"
>> +
>> +#define RBD_DEFAULT_OBJ_ORDER 22 /* 4MB */
>> +
>> +#define RBD_MAX_OBJ_NAME_SIZE 96
>> +#define RBD_MAX_SEG_NAME_SIZE 128
>> +
>> +#define RBD_COMP_NONE 0
>> +#define RBD_CRYPT_NONE 0
>> +
>> +static const char rbd_text[] = "<<< Rados Block Device Image >>>\n";
>> +static const char rbd_signature[] = "RBD";
>> +static const char rbd_version[] = "001.001";
>> +
>> +struct rbd_obj_snap_ondisk {
>> + __le64 id;
>> + __le64 image_size;
>> +} __attribute__((packed));
>> +
>> +struct rbd_obj_header_ondisk {
>> + char text[64];
>> + char signature[4];
>> + char version[8];
>> + __le64 image_size;
>
> Unaligned? Is the disk format fixed?
This is a packed structure that represents the on disk format.
Operations on it are being done only to read from the disk header or
to write to the disk header.
Yehuda
[Qemu-devel] [Bug 540230] Re: Configuration option error for ARM in default-configs
This problem has been fixed in 23f2166d at Feb 23 ** Changed in: qemu Status: New => Fix Committed -- Configuration option error for ARM in default-configs https://bugs.launchpad.net/bugs/540230 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Fix Committed Bug description: The problem occurs when I try to launch qemu-system-arm for the machine: lm3s6965evb (Stellaris LM3S6965EVB) The error message was: qemu: hardware error: Unknown device 'ssd0323' for bus 'SSI' The error message means that the LED display driver (SSD0323) of the LM3S6965 evaluation board isn't recognised. Searching through the source code of QEMU 0.12.3, I've seen in default-configs/arm-softmmu.mak that there is reference made to: CONFIG_SD0303=y CONFIG_SD0323=y These parameters in turn are evaluated in the Makefile, as obj-$(CONFIG_SSD0303) += ssd0303.o obj-$(CONFIG_SSD0323) += ssd0323.o The problem is that the spelling of the tags doesn't match up: CONFIG_SD0303 in the .mak vs CONFIG_SSD0303 in the Makefile (double SS) Furthermore, in arm-softmmu.mak, reference is made to CONFIG_LAN9118=y and CONFIG_SMC91C111=y, which isn't referenced by the Makefile at all. Please correct these parameters in default-configs/arm-softmmu.mak in order to give full functionality to the ARM Cortex M3 evaluation boards.
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
On Thu, May 20, 2010 at 11:16 PM, Christian Brunner wrote: > 2010/5/20 Anthony Liguori : >> Both sheepdog and ceph ultimately transmit I/O over a socket to a central >> daemon, right? So could we not standardize a protocol for this that both >> sheepdog and ceph could implement? > > There is no central daemon. The concept is that they talk to many > storage nodes at the same time. Data is distributed and replicated > over many nodes in the network. The mechanism to do this is quite > complex. I don't know about sheepdog, but in Ceph this is called RADOS > (reliable autonomic distributed object store). Sheepdog and Ceph may > look similar, but this is where they act different. I don't think that > it would be possible to implement a common protocol. I believe Sheepdog has a local daemon on each node. The QEMU storage backend talks to the daemon on the same node, which then does the real network communication with the rest of the distributed storage system. So I think we're not talking about a network protocol here, we're talking about a common interface that can be used by QEMU and other programs to take advantage of Ceph, Sheepdog, etc services available on the local node. Haven't looked into your patch enough yet, but does librados talk directly over the network or does it connect to a local daemon/driver? Stefan
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
At Fri, 21 May 2010 00:16:46 +0200, Christian Brunner wrote: > > 2010/5/20 Anthony Liguori : > >> With new approaches like Sheepdog or Ceph, things are getting a lot > >> cheaper and you can scale your system without disrupting your service. > >> The concepts are quite similar to what Amazon is doing in their EC2 > >> environment, but they certainly won't publish it as OpenSource anytime > >> soon. > >> > >> Both projects have advantages and disadvantages. Ceph is a bit more > >> universal as it implements a whole filesystem. Sheepdog is more > >> feature complete in regards of managing images (e.g. snapshots). Both I think a major difference is that Sheepdog servers act fully autonomously. Any Sheepdog server has no fixed role such as a monitor server, and Sheepdog doesn't require any configuration about a list of nodes in the cluster. > >> projects require some additional work to become stable, but they are > >> on a good way. > >> > >> I would really like to see both drivers in the qemu tree, as they are > >> the key to a design shift in how storage in the datacenter is being > >> built. > >> > > > > I'd be more interested in enabling people to build these types of storage > > systems without touching qemu. > > You could do this by using Yehuda's rbd kernel driver, but I think > that it would be better to avoid this additional layer. > I agree. In addition, if a storage client is a qemu driver, the storage system can support some features specific to qemu such as live snapshot from qemu monitor. Regards, Kazutaka
[Qemu-devel] [PATCH] resent: fix CPUID vendor override
the meaning of vendor_override is actually the opposite of how it
is currently used :-(
Fix it to allow KVM to export the non-native CPUID vendor if
explicitly requested by the user.
The semantic is now as intended:
- With TCG, the guest always sees the configured vendor.
- With KVM, the default is to propagate the host's vendor
- when explicitly requested via -cpu ,vendor=xxx obey this
and use the specified vendor
Signed-off-by: Andre Przywara
---
target-i386/cpuid.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Hi,
this hasn't been picked up the last time I sent it out, are there any
objections?
Regards,
Andre.
diff --git a/target-i386/cpuid.c b/target-i386/cpuid.c
index 56938e2..99d1f44 100644
--- a/target-i386/cpuid.c
+++ b/target-i386/cpuid.c
@@ -962,7 +962,7 @@ static void get_cpuid_vendor(CPUX86State *env, uint32_t
*ebx,
* this if you want to use KVM's sysenter/syscall emulation
* in compatibility mode and when doing cross vendor migration
*/
-if (kvm_enabled() && env->cpuid_vendor_override) {
+if (kvm_enabled() && ! env->cpuid_vendor_override) {
host_cpuid(0, 0, NULL, ebx, ecx, edx);
}
}
--
1.6.4
Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm
At Fri, 21 May 2010 06:28:42 +0100, Stefan Hajnoczi wrote: > > On Thu, May 20, 2010 at 11:16 PM, Christian Brunner wrote: > > 2010/5/20 Anthony Liguori : > >> Both sheepdog and ceph ultimately transmit I/O over a socket to a central > >> daemon, right? So could we not standardize a protocol for this that both > >> sheepdog and ceph could implement? > > > > There is no central daemon. The concept is that they talk to many > > storage nodes at the same time. Data is distributed and replicated > > over many nodes in the network. The mechanism to do this is quite > > complex. I don't know about sheepdog, but in Ceph this is called RADOS > > (reliable autonomic distributed object store). Sheepdog and Ceph may > > look similar, but this is where they act different. I don't think that > > it would be possible to implement a common protocol. > > I believe Sheepdog has a local daemon on each node. The QEMU storage > backend talks to the daemon on the same node, which then does the real > network communication with the rest of the distributed storage system. Yes. It is because Sheepdog doesn't have a configuration about cluster membership as I mentioned in another mail, so the drvier doesn't know which node to access other than localhost. > So I think we're not talking about a network protocol here, we're > talking about a common interface that can be used by QEMU and other > programs to take advantage of Ceph, Sheepdog, etc services available > on the local node. > > Haven't looked into your patch enough yet, but does librados talk > directly over the network or does it connect to a local daemon/driver? > AFAIK, librados access directly over the network, so I think it is difficult to define a common interface. Thanks, Kazutaka
Re: [Qemu-devel] [PATCH v2] Release usb devices on shutdown and usb_del command
"David S. Ahern" writes:
> On 05/19/2010 12:10 PM, Shahar Havivi wrote:
>> When closig Vm or removing usb on guest via usb_del monitor command,
>> qemu does not return the control to the host, the user have to
>> unplug and plug the device in order to use it on the host.
>>
>> v2:
>> added empty methods to usb-bsd and usb-stub.
>> release usb devices when main is out.
>>
>> Signed-off-by: Shahar Havivi
>> ---
>> hw/usb-bus.c |4
>> hw/usb.h |2 ++
>> usb-bsd.c| 10 ++
>> usb-linux.c | 21 +
>> usb-stub.c | 10 ++
>> vl.c |1 +
>> 6 files changed, 48 insertions(+), 0 deletions(-)
>>
>> diff --git a/hw/usb-bus.c b/hw/usb-bus.c
>> index b692503..75dc819 100644
>> --- a/hw/usb-bus.c
>> +++ b/hw/usb-bus.c
>> @@ -207,6 +207,10 @@ int usb_device_delete_addr(int busnr, int addr)
>> return -1;
>> dev = port->dev;
>>
>> +if (!strcmp(dev->info->usbdevice_name, "host")) {
>> +usb_host_device_release(dev);
>> +}
>> +
>
> Shouldn't this be done through a callback -- say usbdevice_release
> similar to usbdevice_init -- instead of embedding host specifics here?
> You wouldn't need the bsd and stub stubs then.
>
> David
What about the existing callbacks? Could handle_destroy do?
Note: usbdevice_init() is not for general initialization, just for
dealing with the legacy -usbdevice command line.
>> qdev_free(&dev->qdev);
>> return 0;
>> }
[...]
>> diff --git a/usb-linux.c b/usb-linux.c
>> index 88273ff..cea5b84 100644
>> --- a/usb-linux.c
>> +++ b/usb-linux.c
>> @@ -286,6 +286,27 @@ static void async_cancel(USBPacket *unused, void
>> *opaque)
>> }
>> }
>>
>> +void usb_cleanup(void)
>> +{
>> +struct USBHostDevice *s;
>> +
>> +QTAILQ_FOREACH(s, &hostdevs, next) {
>> +if (s->fd != -1) {
>> +usb_host_device_release((USBDevice*)s);
>> +}
>> +}
>> +}
>> +
>> +int usb_host_device_release(USBDevice *dev)
>> +{
>> +int ret;
>> +
>> +USBHostDevice *s = DO_UPCAST(USBHostDevice, dev, dev);
>> +ret = ioctl(s->fd, USBDEVFS_RESET);
>> +
>> +return ret;
>> +}
>> +
>> static int usb_host_claim_interfaces(USBHostDevice *dev, int configuration)
>> {
>> int dev_descr_len, config_descr_len;
[...]
>> diff --git a/vl.c b/vl.c
>> index d77b47c..e3f4dc9 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -3914,6 +3914,7 @@ int main(int argc, char **argv, char **envp)
>> main_loop();
>> quit_timers();
>> net_cleanup();
>> +usb_cleanup();
>>
>> return 0;
>> }
Figure we'd have to clean up the qdev tree on exit. Gerd?
Re: [Qemu-devel] [PATCH 3/3] Monitor: Drop QMP documentation from code
Luiz Capitulino writes: > Previous commit added the QMP/qmp-commands.txt file, which is a > copy of this information. This is no longer true. > While it's good to keep it near code, maintaining two copies of > the same information is too hard and has little benefit as we > don't expect client writers to consult the code to find how to > use a QMP command. > > Signed-off-by: Luiz Capitulino [...]
Re: [Qemu-devel] [PATCH v2] Release usb devices on shutdown and usb_del command
Hi, What about the existing callbacks? Could handle_destroy do? For hot-unplug it should do. --- a/vl.c +++ b/vl.c @@ -3914,6 +3914,7 @@ int main(int argc, char **argv, char **envp) main_loop(); quit_timers(); net_cleanup(); +usb_cleanup(); return 0; } Figure we'd have to clean up the qdev tree on exit. Gerd? Hmm, yes. Question is how to do that best. There is qdev_free(). Today this is used for hot-unplug only. Using it on exit() too could have unwanted guest-visible side effects as it doesn't just release ressources, but also unplugs the device if possible. Maybe it is better to add a exit notifier ... cheers, Gerd
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On 05/20/2010 08:01 AM, Rusty Russell wrote: A device with out of order completion (like virtio-blk) will quickly randomize the unused descriptor indexes, so every descriptor fetch will require a bounce. In contrast, if the rings hold the descriptors themselves instead of pointers, we bounce (sizeof(descriptor)/cache_line_size) cache lines for every descriptor, amortized. We already have indirect, this would be a logical next step. So let's think about it. The avail ring would contain 64 bit values, the used ring would contain indexes into the avail ring. Have just one ring, no indexes. The producer places descriptors into the ring and updates the head, The consumer copies out descriptors to be processed and copies back in completed descriptors. Chaining is always linear. The descriptors contain a tag that allow the producer to identify the completion. Indirect only pays when there are enough descriptors in it to fill a couple of cache lines. Otherwise it's an extra bounce. We will always bounce here, that what happens when transferring data. The question is whether how many cache lines per descriptor. A pointer adds 1 bounce, linear descriptors cost 1/4 bounce, chained descriptors cost a bounce. So best is one ring of linearly chained descriptors. Indirect works when you have large requests (like block). So client writes descriptor page and adds to avail ring, then writes to index. Server reads index, avail ring, descriptor page (3). Writes used entry (1). Updates last_used (1). Client reads used (1), derefs avail (1), updates last_used (1), cleans descriptor page (1). That's 9 cacheline transfers, worst case. Best case of a half-full ring in steady state, assuming 128-byte cache lines, the avail ring costs are 1/16, the used entry is 1/64. This drops it to 6 and 9/64 transfers. Cache lines are 64 bytes these days. With a single ring, client writes descriptors (ceil(N/4)), updates head (1). Server reads head (1) copies out descriptors (ceil(N/4)), issues requests, copies back completions ((ceil(N/4)), updates tail (1). Client reads back tail and descriptors (1 + ceil(N/4)) Worst case: 4 + 4 * ceil(N/4). Best case I think this drops by half. (Note, the current scheme adds 2 more cacheline transfers, for the descriptor table, worst case. 2 bounces per descriptor due to random access. Assuming indirect, we get 2/8 xfer best case. Either way, it's not the main source of cacheline xfers). Indirect adds a double bounce to get to the descriptor table, but any descriptors there are accessed linearly. It's only good when you have large chains. Can we do better? The obvious idea is to try to get rid of last_used and used, and use the ring itself. We would use an invalid entry to mark the head of the ring. Interesting! So a peer will read until it hits a wall. But how to update the wall atomically? Maybe we can have a flag in the descriptor indicate headness or tailness. Update looks ugly though: write descriptor with head flag, write next descriptor with head flag, remove flag from previous descriptor. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver
On 05/19/10 18:30, Jamie Lokier wrote: Julian Pidancet wrote: So after all, why not implementing our own VT switching and using directly the fbdev interface. It's a good idea. VT switching isn't hard to track reliably. Indeed, only problem is that the fbdev libs usually want to do that too. Being able to tell qemu, through the monitor, to attach/detach from a particular VT might be a nice easy bonus too. Yes, should be doable without too much effort. I just checked the linux fbdev code to find out if it provides with a blitting method that could perform the pixel color conversion automatically for Qemu. Unfortunately, from what I have read from the drivers/video/cfbimgblt.c file in the linux tree, there's no such thing, and it also means that we cannot take advantage of any kind of hardware pixel format conversion. I'm not sure if DirectFB provides that particular operation, but I have the impression it's the sort of thing DirectFB is intended for: A framebuffer, plus a variety of 2d acceleration methods (and other things like multi-buffering, video and alpha channel overlay). As far I know acceleration depends on the directfb kernel drivers though, i.e. in 99% of the cases (standard distro installs) those are not available and software fallbacks are active anyway. So from a performance point of view directfb doesn't buy us much. And for the pixel conversion I'd prefer see some reorganization of the existing qemu code which is spread all over the place now ... cheers, Gerd
Re: [Qemu-devel] [PATCH] Fix %lld or %llx printf format use
I had a look at the first few, and they're all fine. Thanks!
Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010
On 05/19/10 02:58, Natalia Portillo wrote: > Hi, > >> - We'll try to migrate as many confirmable bugs from the Source Forge >> tracker to Launchpad. > I think that part of the bug day should also include retesting OSes that > appear in OS Support List as having bug and confirming if the bug is still > present and if it's in Launchpad or not. This would be a great task for people who would like to contribute, but maybe don't feel they have the experience or knowledge to hack on the code itself. Jes
Re: [Qemu-devel] [RFC] Bug Day - June 1st, 2010
On 05/19/10 15:34, Anthony Liguori wrote: > On 05/19/2010 12:04 AM, Aurelien Jarno wrote: >> The idea is nice, but would it be possible to hold this on a week-end, >> I personally won't be able to attend such thing on a day week. >> >> Or maybe holding that on two days: friday and saturday so that people >> can participate at least one of the two days, depending if they do that >> from work or from home. > > The work week in Israel is Sunday - Thursday. > > It would have to be Sunday and Monday but honestly, I think both days > tend to be bad for this sort of thing. > > I'd much rather do more frequent bug days and alternate between a > weekday and a Saturday. If we settle for the 2nd of June, maybe the people who are unavailable on week days, could run a pre-bug day on Sunday the 30th. Maybe some of us would be able to stop by the channel briefly on the Sunday even if we plan to do the big bug day on the 2nd? Cheers, Jes
Re: [Qemu-devel] [PATCH] pc: fix segfault introduced by 3d53f5c36ff6
Thank you for fixing it. Probably I was too in hurry when rebasing the patches.
Acked-by: Isaku Yamahata
On Thu, May 20, 2010 at 09:14:04AM +0300, Eduard - Gabriel Munteanu wrote:
> Commit 3d53f5c36ff6 introduced a segfault by erroneously making fw_cfg a
> 'void **' and passing it around in different ways.
>
> Signed-off-by: Eduard - Gabriel Munteanu
> ---
> hw/pc.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/pc.c b/hw/pc.c
> index fee08c9..4a4a706 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -822,7 +822,7 @@ void pc_memory_init(ram_addr_t ram_size,
> ram_addr_t ram_addr, bios_offset, option_rom_offset;
> ram_addr_t below_4g_mem_size, above_4g_mem_size = 0;
> int bios_size, isa_bios_size;
> -void **fw_cfg;
> +void *fw_cfg;
>
> if (ram_size >= 0xe000 ) {
> above_4g_mem_size = ram_size - 0xe000;
> @@ -905,7 +905,7 @@ void pc_memory_init(ram_addr_t ram_size,
> rom_set_fw(fw_cfg);
>
> if (linux_boot) {
> -load_linux(*fw_cfg, kernel_filename, initrd_filename,
> kernel_cmdline, below_4g_mem_size);
> +load_linux(fw_cfg, kernel_filename, initrd_filename, kernel_cmdline,
> below_4g_mem_size);
> }
>
> for (i = 0; i < nb_option_roms; i++) {
> --
> 1.6.4.4
>
>
--
yamahata
Re: [Qemu-devel] Re: [PATCH] block: fix sector comparism in multiwrite_req_compare
Am 20.05.2010 08:09, schrieb Avi Kivity: > On 05/20/2010 12:09 AM, Kevin Wolf wrote: >> >>> Actually it's not that obvious. If the actual problem >>> here (besides the mis-comparison) is due to missing >>> barriers or flushes. Avi asked a good question in that >>> thread. >>> >> It's obvious that it's a hack. It doesn't fix anything, it just disables a >> feature that didn't work. Good for debugging, but not something that you >> would like to commit. >> >> It's reasonable to include something like this when we know that something is >> broken but we haven't found it yet - but I believe Christoph's patch is the >> real fix. If anyone can still find a case that is "fixed" by Avi's patch, I >> could be convinced to apply it anyway, but I'd prefer if I didn't have to. >> >> Note that we actually don't have overlapping requests. It just looks like it >> because the qsort call doesn't work correctly with the broken comparison >> function, so lower sector numbers can come after higher ones. >> > > I agree my patch didn't fix the problem, only made it disappear, but > won't the current code break with overlapping requests? Maybe --verbose for your patch descriptions would help. I didn't see any obvious problem. If you know any, care to explain? Anyway, I started to implement a multiwrite command for qemu-io yesterday, so that I can actually test such scenarios. Kevin
Re: [Qemu-devel] Re: [PATCH] block: fix sector comparism in multiwrite_req_compare
On 05/20/2010 11:19 AM, Kevin Wolf wrote: Am 20.05.2010 08:09, schrieb Avi Kivity: On 05/20/2010 12:09 AM, Kevin Wolf wrote: Actually it's not that obvious. If the actual problem here (besides the mis-comparison) is due to missing barriers or flushes. Avi asked a good question in that thread. It's obvious that it's a hack. It doesn't fix anything, it just disables a feature that didn't work. Good for debugging, but not something that you would like to commit. It's reasonable to include something like this when we know that something is broken but we haven't found it yet - but I believe Christoph's patch is the real fix. If anyone can still find a case that is "fixed" by Avi's patch, I could be convinced to apply it anyway, but I'd prefer if I didn't have to. Note that we actually don't have overlapping requests. It just looks like it because the qsort call doesn't work correctly with the broken comparison function, so lower sector numbers can come after higher ones. I agree my patch didn't fix the problem, only made it disappear, but won't the current code break with overlapping requests? Maybe --verbose for your patch descriptions would help. I didn't see any obvious problem. If you know any, care to explain? Looking again, you are right. There is code to take care of the overlap, and even a comment. So my patch is indeed bogus. size_t size; QEMUIOVector *qiov = qemu_mallocz(sizeof(*qiov)); qemu_iovec_init(qiov, reqs[outidx].qiov->niov + reqs[i].qiov->niov + 1); // Add the first request to the merged one. If the requests are // overlapping, drop the last sectors of the first request. size = (reqs[i].sector - reqs[outidx].sector) << 9; qemu_iovec_concat(qiov, reqs[outidx].qiov, size); size can overflow on 32-bit. Unrelated issue: it seems we read the request directly from guest memory. Since we access it multiple times, the guest can play with the contents meanwhile, invalidating previous decisions. Shouldn't we copy all non-data elements to private storage? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Qemu-devel] Re: [PATCH 10/12] kvm: enable smp > 1
Avi Kivity schrieb: On 05/19/2010 11:02 PM, Udo Lembke wrote: Unrelated, what are your smp issues? If i use one cpu i got a good io-performance: e.g. over 500MB/s at the profile "install" of the io-benchmark h2benchw.exe. ( aio=threads | SAS-Raid-0 | ftp://ftp.heise.de/pub/ct/ctsi/h2benchw.zip | hwbenchw.exe -p -w iotest 0) The same test but with two cpus gives results between 27 and 298 MB/s! Also in real life it's noticeable not only with an benchmark. I use a win-vm with two cpu for postscript-ripping and have a performance drop due to the bad io. Hi, What's your block device model? virtio or ide? in the test described before i used virtio, but the same happens with ide (but of course slightly different values). What does cpu usage look like on guest or host? On the guest it's looks like the io-process flap between the cpus. Windows show both cpus together are around 65% (less or more) , but if one CPU-usage rise, the other drop. On the host: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 5386 root 20 0 1160m 1.0g 1552 R 109 13.5 1:23.58 kvm The guest is a win-xp, but the same happens in real life on a win2003. Udo smime.p7s Description: S/MIME Cryptographic Signature
[Qemu-devel] [PATCH] vvfat: More build fixes with DEBUG
Casting a pointer to an int doesn't work on 64 bit platforms. Use the %p printf
conversion specifier instead.
Signed-off-by: Kevin Wolf
---
block/vvfat.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index 13c31fa..6d61c2e 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -1244,7 +1244,7 @@ static void print_direntry(const direntry_t* direntry)
int j = 0;
char buffer[1024];
-fprintf(stderr, "direntry 0x%x: ", (int)direntry);
+fprintf(stderr, "direntry %p: ", direntry);
if(!direntry)
return;
if(is_long_name(direntry)) {
@@ -1273,7 +1273,11 @@ static void print_direntry(const direntry_t* direntry)
static void print_mapping(const mapping_t* mapping)
{
-fprintf(stderr, "mapping (0x%x): begin, end = %d, %d, dir_index = %d,
first_mapping_index = %d, name = %s, mode = 0x%x, " , (int)mapping,
mapping->begin, mapping->end, mapping->dir_index, mapping->first_mapping_index,
mapping->path, mapping->mode);
+fprintf(stderr, "mapping (%p): begin, end = %d, %d, dir_index = %d, "
+"first_mapping_index = %d, name = %s, mode = 0x%x, " ,
+mapping, mapping->begin, mapping->end, mapping->dir_index,
+mapping->first_mapping_index, mapping->path, mapping->mode);
+
if (mapping->mode & MODE_DIRECTORY)
fprintf(stderr, "parent_mapping_index = %d, first_dir_index = %d\n",
mapping->info.dir.parent_mapping_index, mapping->info.dir.first_dir_index);
else
--
1.6.6.1
[Qemu-devel] Re: [PATCH] block: Fix compilation with DEBUG defined
Am 19.05.2010 22:53, schrieb Riccardo Magliocchetti: > gcc does not like passing a NULL where an int value is expected: > > block/vvfat.c: In function ‘checkpoint’: > block/vvfat.c:2868: error: passing argument 2 of ‘remove_mapping’ makes > integer from pointer without a cast > > Signed-off-by: Riccardo Magliocchetti Thanks, applied to the block branch. You're probably using a 32 bit platform? I needed another fix to get it compiling on x86_64, which I just sent to the list. Kevin
[Qemu-devel] [PATCH 2/2] hxtool: Add syntax error detection
From: Jan Kiszka
Add basic imbalance detection for STEXT/ETEXI.
Signed-off-by: Jan Kiszka
---
hxtool | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/hxtool b/hxtool
index 0fdbc64..8f65532 100644
--- a/hxtool
+++ b/hxtool
@@ -19,11 +19,24 @@ hxtoh()
hxtotexi()
{
flag=0
+line=1
while read -r str; do
case "$str" in
HXCOMM*)
;;
-STEXI*|ETEXI*) flag=$(($flag^1))
+STEXI*)
+if test $flag -eq 1 ; then
+echo "line $line: syntax error: expected ETEXI, found $str" >&2
+exit 1
+fi
+flag=1
+;;
+ETEXI*)
+if test $flag -ne 1 ; then
+echo "line $line: syntax error: expected STEXI, found $str" >&2
+exit 1
+fi
+flag=0
;;
DEFHEADING*)
echo "$(expr "$str" : "DEFHEADING(\(.*\))")"
@@ -32,6 +45,7 @@ hxtotexi()
test $flag -eq 1 && echo "$str"
;;
esac
+line=$((line+1))
done
}
--
1.6.0.2
[Qemu-devel] Re: [PATCH] block: fix sector comparism in multiwrite_req_compare
Am 19.05.2010 20:53, schrieb Christoph Hellwig: > The difference between the start sectors of two requests can be larger > than the size of the "int" type, which can lead to a not correctly > sorted multiwrite array and thus spurious I/O errors and filesystem > corruption due to incorrect request merges. > > So instead of doing the cute sector arithmetics trick spell out the > exact comparisms. > > Spotted by Kevin Wolf based on a testcase from Michael Tokarev. > > Signed-off-by: Christoph Hellwig Thanks, applied to the block branch. Kevin
[Qemu-devel] Re: [PATCH] block: Fix compilation with DEBUG defined
Il 20/05/2010 10:43, Kevin Wolf ha scritto: Am 19.05.2010 22:53, schrieb Riccardo Magliocchetti: gcc does not like passing a NULL where an int value is expected: block/vvfat.c: In function ‘checkpoint’: block/vvfat.c:2868: error: passing argument 2 of ‘remove_mapping’ makes integer from pointer without a cast Signed-off-by: Riccardo Magliocchetti Thanks, applied to the block branch. You're probably using a 32 bit platform? I needed another fix to get it compiling on x86_64, which I just sent to the list. Thanks, yes i'm on 32bit. riccardo
[Qemu-devel] [PATCH] QEMU: change default disk cache behavior
From: Jes Sorensen We seem to get into the discussion of what is the correct default setting disk images in QEMU. The libvirt team is reluctant to change specified for newly created images without the default setting matching it, and everybody seems to agree that the current setting of WT is the worse possible option. 'nocache' seems to be the preferred option, but it doesn't work for all cases, like images on ramfs, NFS etc. Therefore, here is a patch that does two things: - default to "nocache" - in case of failure with nocache, retry with "write-back" Jes Sorensen (1): QEMU: Change default disk caching to nocache vl.c | 25 +++-- 1 files changed, 19 insertions(+), 6 deletions(-)
[Qemu-devel] [PATCH] QEMU: Change default disk caching to nocache
From: Jes Sorensen
Change default disk image caching to nocache (O_DIRECT). However in
case it fails (ramfs, NFS etc.). fall back and retry with write-back.
Signed-off-by: Jes Sorensen
---
vl.c | 25 +++--
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/vl.c b/vl.c
index d77b47c..f3a7d63 100644
--- a/vl.c
+++ b/vl.c
@@ -787,7 +787,7 @@ DriveInfo *drive_init(QemuOpts *opts, void *opaque,
int max_devs;
int index;
int ro = 0;
-int bdrv_flags = 0;
+int bdrv_flags = BDRV_O_NOCACHE;
int on_read_error, on_write_error;
const char *devaddr;
DriveInfo *dinfo;
@@ -910,11 +910,11 @@ DriveInfo *drive_init(QemuOpts *opts, void *opaque,
if ((buf = qemu_opt_get(opts, "cache")) != NULL) {
if (!strcmp(buf, "off") || !strcmp(buf, "none")) {
-bdrv_flags |= BDRV_O_NOCACHE;
+/* default */
} else if (!strcmp(buf, "writeback")) {
bdrv_flags |= BDRV_O_CACHE_WB;
} else if (!strcmp(buf, "writethrough")) {
-/* this is the default */
+bdrv_flags &= ~BDRV_O_CACHE_MASK;
} else {
fprintf(stderr, "qemu: invalid cache option\n");
return NULL;
@@ -1120,15 +1120,28 @@ DriveInfo *drive_init(QemuOpts *opts, void *opaque,
bdrv_flags |= ro ? 0 : BDRV_O_RDWR;
if (bdrv_open(dinfo->bdrv, file, bdrv_flags, drv) < 0) {
-fprintf(stderr, "qemu: could not open disk image %s: %s\n",
-file, strerror(errno));
-return NULL;
+if (bdrv_flags & BDRV_O_NOCACHE) {
+fprintf(stderr, "qemu: failed to open disk image %s as "
+"nocache (O_DIRECT) retrying as write-back\n", file);
+bdrv_flags &= BDRV_O_NOCACHE;
+bdrv_flags |= BDRV_O_CACHE_WB;
+if (bdrv_open(dinfo->bdrv, file, bdrv_flags, drv) < 0)
+goto error_open;
+} else {
+goto error_open;
+}
}
if (bdrv_key_required(dinfo->bdrv))
autostart = 0;
*fatal_error = 0;
return dinfo;
+
+error_open:
+fprintf(stderr, "qemu: could not open disk image %s: %s\n",
+file, strerror(errno));
+return NULL;
+
}
static int drive_init_func(QemuOpts *opts, void *opaque)
--
1.6.5.2
[Qemu-devel] [Bug 267542] Re: MINIX 3 won't boot in qemu 0.9.1
Is that still a problem? What was the exact error? I quickly tried the 3.1.2a on qemu 0.12.4 (with and without KVM) and I could easily login. ** Changed in: qemu Status: New => Incomplete -- MINIX 3 won't boot in qemu 0.9.1 https://bugs.launchpad.net/bugs/267542 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Bug description: CD Image 3.1.2a was downloaded from http://www.minix3.org/download/ It booted with previous version of qemu but hangs at startup with 0.9.1. Hardware acceleration is disabled. Please ask if there is other information I can give you.
[Qemu-devel] [PATCH] Name the default PCI bus "pci.0" on all architectures (v2)
The system emulators for each arch are using inconsistent naming for the default PCI bus "pci" vs "pci.0". Since it is conceivable we'll have multiple PCI buses in the future standardize on "pci.0" for all architectures. This ensures mgmt apps can rely on a name when assigning PCI devices an address on the bus using eg '-device e1000,bus=pci.0,addr=3' Signed-off-by: Daniel P. Berrange --- hw/apb_pci.c |2 +- hw/grackle_pci.c |2 +- hw/gt64xxx.c |2 +- hw/ppc4xx_pci.c|2 +- hw/ppce500_pci.c |2 +- hw/prep_pci.c |2 +- hw/sh_pci.c|2 +- hw/unin_pci.c |4 ++-- hw/versatile_pci.c |2 +- 9 files changed, 10 insertions(+), 10 deletions(-) diff --git a/hw/apb_pci.c b/hw/apb_pci.c index 65d8ba6..841d0bc 100644 --- a/hw/apb_pci.c +++ b/hw/apb_pci.c @@ -338,7 +338,7 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, /* mem_data */ sysbus_mmio_map(s, 3, mem_base); d = FROM_SYSBUS(APBState, s); -d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci", +d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci.0", pci_apb_set_irq, pci_pbm_map_irq, d, 0, 32); pci_bus_set_mem_base(d->host_state.bus, mem_base); diff --git a/hw/grackle_pci.c b/hw/grackle_pci.c index aa0c51b..8444a35 100644 --- a/hw/grackle_pci.c +++ b/hw/grackle_pci.c @@ -88,7 +88,7 @@ PCIBus *pci_grackle_init(uint32_t base, qemu_irq *pic) qdev_init_nofail(dev); s = sysbus_from_qdev(dev); d = FROM_SYSBUS(GrackleState, s); -d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci", +d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci.0", pci_grackle_set_irq, pci_grackle_map_irq, pic, 0, 4); diff --git a/hw/gt64xxx.c b/hw/gt64xxx.c index 55971b9..756e1bf 100644 --- a/hw/gt64xxx.c +++ b/hw/gt64xxx.c @@ -1113,7 +1113,7 @@ PCIBus *pci_gt64120_init(qemu_irq *pic) s = qemu_mallocz(sizeof(GT64120State)); s->pci = qemu_mallocz(sizeof(GT64120PCIState)); -s->pci->bus = pci_register_bus(NULL, "pci", +s->pci->bus = pci_register_bus(NULL, "pci.0", pci_gt64120_set_irq, pci_gt64120_map_irq, pic, 144, 4); s->ISD_handle = cpu_register_io_memory(gt64120_read, gt64120_write, s); diff --git a/hw/ppc4xx_pci.c b/hw/ppc4xx_pci.c index c9e3279..dc1d2f8 100644 --- a/hw/ppc4xx_pci.c +++ b/hw/ppc4xx_pci.c @@ -357,7 +357,7 @@ PCIBus *ppc4xx_pci_init(CPUState *env, qemu_irq pci_irqs[4], controller = qemu_mallocz(sizeof(PPC4xxPCIState)); -controller->pci_state.bus = pci_register_bus(NULL, "pci", +controller->pci_state.bus = pci_register_bus(NULL, "pci.0", ppc4xx_pci_set_irq, ppc4xx_pci_map_irq, pci_irqs, 0, 4); diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c index 336d284..fa4387a 100644 --- a/hw/ppce500_pci.c +++ b/hw/ppce500_pci.c @@ -276,7 +276,7 @@ PCIBus *ppce500_pci_init(qemu_irq pci_irqs[4], target_phys_addr_t registers) controller = qemu_mallocz(sizeof(PPCE500PCIState)); -controller->pci_state.bus = pci_register_bus(NULL, "pci", +controller->pci_state.bus = pci_register_bus(NULL, "pci.0", mpc85xx_pci_set_irq, mpc85xx_pci_map_irq, pci_irqs, 0x88, 4); diff --git a/hw/prep_pci.c b/hw/prep_pci.c index 144fde0..7ea7ca5 100644 --- a/hw/prep_pci.c +++ b/hw/prep_pci.c @@ -117,7 +117,7 @@ PCIBus *pci_prep_init(qemu_irq *pic) int PPC_io_memory; s = qemu_mallocz(sizeof(PREPPCIState)); -s->bus = pci_register_bus(NULL, "pci", +s->bus = pci_register_bus(NULL, "pci.0", prep_set_irq, prep_map_irq, pic, 0, 4); pci_host_conf_register_ioport(0xcf8, s); diff --git a/hw/sh_pci.c b/hw/sh_pci.c index cc2f190..0e138ed 100644 --- a/hw/sh_pci.c +++ b/hw/sh_pci.c @@ -98,7 +98,7 @@ PCIBus *sh_pci_register_bus(pci_set_irq_fn set_irq, pci_map_irq_fn map_irq, int reg; p = qemu_mallocz(sizeof(SHPCIC)); -p->bus = pci_register_bus(NULL, "pci", +p->bus = pci_register_bus(NULL, "pci.0", set_irq, map_irq, opaque, devfn_min, nirq); p->dev = pci_register_device(p->bus, "SH PCIC", sizeof(PCIDevice), diff --git a/hw/unin_pci.c b/hw/unin_pci.c index f0a773d..57c56e0 100644 --- a/hw/unin_pci.c +++ b/hw/unin_pci.c @@ -226,7 +226,7 @@ PCIBus *pci_pmac_init(qemu_irq *pic) qdev_init_nofail(dev); s = sysbus_from_qdev(dev); d = FROM_SYSBUS(UNINState, s); -d->host_state.bus = pci_register_bus(&d->busdev.qdev, "pci", +
Re: [Qemu-devel] [PATCH] Name the default PCI bus "pci.0" on all architectures
On Wed, May 19, 2010 at 10:19:06PM +0300, Blue Swirl wrote: > On 5/19/10, Daniel P. Berrange wrote: > > The system emulators for each arch are using inconsistent > > naming for the default PCI bus "pci" vs "pci.0". Since it > > is conceivable we'll have multiple PCI buses in the future > > standardize on "pci.0" for all architectures. This ensures > > mgmt apps can rely on a name when assigning PCI devices an > > address on the bus using eg '-device e1000,bus=pci.0,addr=3' > > > > Signed-off-by: Daniel P. Berrange > > --- > > hw/grackle_pci.c |2 +- > > hw/gt64xxx.c |2 +- > > hw/ppc4xx_pci.c|2 +- > > hw/ppce500_pci.c |2 +- > > hw/prep_pci.c |2 +- > > hw/sh_pci.c|2 +- > > hw/unin_pci.c |4 ++-- > > hw/versatile_pci.c |2 +- > > Missing hw/apb_pci.c. Ah yes, don't know how I missed that. Have posted another version of this patch with that included Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [PATCH RFC] virtio: put last seen used index into ring itself
On Thu, May 20, 2010 at 02:31:50PM +0930, Rusty Russell wrote: > Can we do better? The obvious idea is to try to get rid of last_used and > used, and use the ring itself. We would use an invalid entry to mark the > head of the ring. > > Any other thoughts? > Rusty. We also need a way to avoid interrupts at least while we are processing the ring. -- MST
[Qemu-devel] Do qemu support ARM1176JZ(F)-S chip？
Where can I find the last list about arm? Thanks a lot. wql
Re: [Qemu-devel] [Bug 267542] Re: MINIX 3 won't boot in qemu 0.9.1
On Thu, May 20, 2010 at 12:44 PM, Andre Przywara wrote: > Is that still a problem? What was the exact error? > I quickly tried the 3.1.2a on qemu 0.12.4 (with and without KVM) and I could > easily login. This happens with MINIX 3.1.6, during boot it briefly goes into an invalid state while switching to protected mode IIRC. > > > ** Changed in: qemu > Status: New => Incomplete > > -- > MINIX 3 won't boot in qemu 0.9.1 > https://bugs.launchpad.net/bugs/267542 > You received this bug notification because you are a member of qemu- > devel-ml, which is subscribed to QEMU. > > Status in QEMU: Incomplete > > Bug description: > CD Image 3.1.2a was downloaded from http://www.minix3.org/download/ > > It booted with previous version of qemu but hangs at startup with 0.9.1. > > Hardware acceleration is disabled. > > Please ask if there is other information I can give you. > > > >
[Qemu-devel] [PATCH] Add dependency of JSON unit tests on config-host.h
From: Jan Kiszka Signed-off-by: Jan Kiszka --- Makefile |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 110698e..aa81d9b 100644 --- a/Makefile +++ b/Makefile @@ -144,6 +144,8 @@ qemu-io$(EXESUF): qemu-io.o cmd.o qemu-tool.o qemu-error.o $(block-obj-y) $(qobj qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx $(call quiet-command,sh $(SRC_PATH)/hxtool -h < $< > $@," GEN $@") +check-qint.o check-qstring.o check-qdict.o check-qlist.o check-qfloat.o check-qjson.o: $(GENERATED_HEADERS) + check-qint: check-qint.o qint.o qemu-malloc.o check-qstring: check-qstring.o qstring.o qemu-malloc.o check-qdict: check-qdict.o qdict.o qfloat.o qint.o qstring.o qbool.o qemu-malloc.o qlist.o -- 1.6.0.2
[Qemu-devel] [Bug 583296] Re: I/O errors with qemu-nbd/qcow2
** Attachment added: "dmesg" http://launchpadlibrarian.net/48810728/kern.log -- I/O errors with qemu-nbd/qcow2 https://bugs.launchpad.net/bugs/583296 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to open a qcow2 file with qemu-nbd and backup the files in it. After some coping I get lot of I/O errors in dmesg and the system hangs. One time I got even a kernel panic (Of course on a productive Server ;-) ) How to reproduce: 1. Connect nbd to a qcow2 file, a virtual machine mustn't use this file: qemu-nbd --connect=/dev/nbd0 /mnt/qcow/andromeda.qcow2 2. Read some data from /dev/nbd0p1 dd if=/dev/nbd0p1 of=/dev/null bs=1M After a few Seconds till Minutes somethings crash's Attached some dmesg logs
[Qemu-devel] [Bug 583296] [NEW] I/O errors with qemu-nbd/qcow2
Public bug reported: I tried to open a qcow2 file with qemu-nbd and backup the files in it. After some coping I get lot of I/O errors in dmesg and the system hangs. One time I got even a kernel panic (Of course on a productive Server ;-) ) How to reproduce: 1. Connect nbd to a qcow2 file, a virtual machine mustn't use this file: qemu-nbd --connect=/dev/nbd0 /mnt/qcow/andromeda.qcow2 2. Read some data from /dev/nbd0p1 dd if=/dev/nbd0p1 of=/dev/null bs=1M After a few Seconds till Minutes somethings crash's Attached some dmesg logs ** Affects: qemu Importance: Undecided Status: New -- I/O errors with qemu-nbd/qcow2 https://bugs.launchpad.net/bugs/583296 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to open a qcow2 file with qemu-nbd and backup the files in it. After some coping I get lot of I/O errors in dmesg and the system hangs. One time I got even a kernel panic (Of course on a productive Server ;-) ) How to reproduce: 1. Connect nbd to a qcow2 file, a virtual machine mustn't use this file: qemu-nbd --connect=/dev/nbd0 /mnt/qcow/andromeda.qcow2 2. Read some data from /dev/nbd0p1 dd if=/dev/nbd0p1 of=/dev/null bs=1M After a few Seconds till Minutes somethings crash's Attached some dmesg logs
[Qemu-devel] [Bug 583296] Re: I/O errors with qemu-nbd/qcow2
I forgot: this is on Ubuntu 10.04, Qemu 0.12.3. -- I/O errors with qemu-nbd/qcow2 https://bugs.launchpad.net/bugs/583296 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: New Bug description: I tried to open a qcow2 file with qemu-nbd and backup the files in it. After some coping I get lot of I/O errors in dmesg and the system hangs. One time I got even a kernel panic (Of course on a productive Server ;-) ) How to reproduce: 1. Connect nbd to a qcow2 file, a virtual machine mustn't use this file: qemu-nbd --connect=/dev/nbd0 /mnt/qcow/andromeda.qcow2 2. Read some data from /dev/nbd0p1 dd if=/dev/nbd0p1 of=/dev/null bs=1M After a few Seconds till Minutes somethings crash's Attached some dmesg logs
Re: [Qemu-devel] [PATCH] QEMU: change default disk cache behavior
On 05/20/2010 04:32 AM, jes.soren...@redhat.com wrote: From: Jes Sorensen We seem to get into the discussion of what is the correct default setting disk images in QEMU. The libvirt team is reluctant to change specified for newly created images without the default setting matching it, and everybody seems to agree that the current setting of WT is the worse possible option. 'nocache' seems to be the preferred option, but it doesn't work for all cases, like images on ramfs, NFS etc. Therefore, here is a patch that does two things: - default to "nocache" - in case of failure with nocache, retry with "write-back" This sort of change requires performance data in a variety of circumstances to justify. And I strongly suspect that such a blanket change would be wrong but that a more targeted change like making cache=none default for physical devices would satisfy mostly everyone. Regards, Anthony Liguori Jes Sorensen (1): QEMU: Change default disk caching to nocache vl.c | 25 +++-- 1 files changed, 19 insertions(+), 6 deletions(-)
[Qemu-devel] [PATCH 1/2] Fix TEXI section mark imbalance in qemu-img-cmd.hx
From: Jan Kiszka
Signed-off-by: Jan Kiszka
---
qemu-img-cmds.hx |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index c079019..c4cf3e7 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -7,7 +7,7 @@ HXCOMM HXCOMM can be used for comments, discarded from
both texi and C
STEXI
@table @option
-STEXI
+ETEXI
DEF("check", img_check,
"check [-f fmt] filename")
--
1.6.0.2
