[Qemu-devel] [PATCH 1/2] target-openrisc: Separate of load/store instructions
This patch separates the load and store instruction to a
separate function.
The repetition of the source code can be reduced and further
optimizations can be implemented.
In this case it checks for a zero offset and optimizes it.
Signed-off-by: Sebastian Macke sebast...@macke.de
---
target-openrisc/translate.c | 119 +---
1 file changed, 78 insertions(+), 41 deletions(-)
diff --git a/target-openrisc/translate.c b/target-openrisc/translate.c
index b90181d..543aa67 100644
--- a/target-openrisc/translate.c
+++ b/target-openrisc/translate.c
@@ -254,6 +254,63 @@ static void gen_jump(DisasContext *dc, uint32_t imm,
uint32_t reg, uint32_t op0)
gen_sync_flags(dc);
}
+static void gen_loadstore(DisasContext *dc, uint32 op0,
+ uint32_t ra, uint32_t rb, uint32_t rd,
+ uint32_t offset)
+{
+TCGv t0 = cpu_R[ra];
+if (offset != 0) {
+t0 = tcg_temp_new();
+tcg_gen_addi_tl(t0, cpu_R[ra], sign_extend(offset, 16));
+}
+
+switch (op0) {
+case 0x21:/* l.lwz */
+tcg_gen_qemu_ld_tl(cpu_R[rd], t0, dc-mem_idx, MO_TEUL);
+break;
+
+case 0x22:/* l.lws */
+tcg_gen_qemu_ld_tl(cpu_R[rd], t0, dc-mem_idx, MO_TESL);
+break;
+
+case 0x23:/* l.lbz */
+tcg_gen_qemu_ld_tl(cpu_R[rd], t0, dc-mem_idx, MO_UB);
+break;
+
+case 0x24:/* l.lbs */
+tcg_gen_qemu_ld_tl(cpu_R[rd], t0, dc-mem_idx, MO_SB);
+break;
+
+case 0x25:/* l.lhz */
+tcg_gen_qemu_ld_tl(cpu_R[rd], t0, dc-mem_idx, MO_TEUW);
+break;
+
+case 0x26:/* l.lhs */
+tcg_gen_qemu_ld_tl(cpu_R[rd], t0, dc-mem_idx, MO_TESW);
+break;
+
+case 0x35:/* l.sw */
+tcg_gen_qemu_st_tl(cpu_R[rb], t0, dc-mem_idx, MO_TEUL);
+break;
+
+case 0x36:/* l.sb */
+tcg_gen_qemu_st_tl(cpu_R[rb], t0, dc-mem_idx, MO_UB);
+break;
+
+case 0x37:/* l.sh */
+tcg_gen_qemu_st_tl(cpu_R[rb], t0, dc-mem_idx, MO_TEUW);
+break;
+
+default:
+break;
+}
+
+if (offset != 0) {
+tcg_temp_free(t0);
+}
+
+}
+
static void dec_calc(DisasContext *dc, uint32_t insn)
{
@@ -702,6 +759,9 @@ static void dec_calc(DisasContext *dc, uint32_t insn)
}
}
+
+
+
static void dec_misc(DisasContext *dc, uint32_t insn)
{
uint32_t op0, op1;
@@ -710,7 +770,6 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
uint32_t L6, K5;
#endif
uint32_t I16, I5, I11, N26, tmp;
-TCGMemOp mop;
op0 = extract32(insn, 26, 6);
op1 = extract32(insn, 24, 2);
@@ -843,48 +902,37 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
/*#ifdef TARGET_OPENRISC64
case 0x20: l.ld
LOG_DIS(l.ld r%d, r%d, %d\n, rd, ra, I16);
-check_ob64s(dc);
-mop = MO_TEQ;
-goto do_load;
+gen_loadstore(dc, op0, ra, rb, rd, I16);
#endif*/
case 0x21:/* l.lwz */
LOG_DIS(l.lwz r%d, r%d, %d\n, rd, ra, I16);
-mop = MO_TEUL;
-goto do_load;
+gen_loadstore(dc, op0, ra, rb, rd, I16);
+break;
case 0x22:/* l.lws */
LOG_DIS(l.lws r%d, r%d, %d\n, rd, ra, I16);
-mop = MO_TESL;
-goto do_load;
+gen_loadstore(dc, op0, ra, rb, rd, I16);
+break;
case 0x23:/* l.lbz */
LOG_DIS(l.lbz r%d, r%d, %d\n, rd, ra, I16);
-mop = MO_UB;
-goto do_load;
+gen_loadstore(dc, op0, ra, rb, rd, I16);
+break;
case 0x24:/* l.lbs */
LOG_DIS(l.lbs r%d, r%d, %d\n, rd, ra, I16);
-mop = MO_SB;
-goto do_load;
+gen_loadstore(dc, op0, ra, rb, rd, I16);
+break;
case 0x25:/* l.lhz */
LOG_DIS(l.lhz r%d, r%d, %d\n, rd, ra, I16);
-mop = MO_TEUW;
-goto do_load;
+gen_loadstore(dc, op0, ra, rb, rd, I16);
+break;
case 0x26:/* l.lhs */
LOG_DIS(l.lhs r%d, r%d, %d\n, rd, ra, I16);
-mop = MO_TESW;
-goto do_load;
-
-do_load:
-{
-TCGv t0 = tcg_temp_new();
-tcg_gen_addi_tl(t0, cpu_R[ra], sign_extend(I16, 16));
-tcg_gen_qemu_ld_tl(cpu_R[rd], t0, dc-mem_idx, mop);
-tcg_temp_free(t0);
-}
+gen_loadstore(dc, op0, ra, rb, rd, I16);
break;
case 0x27:/* l.addi */
@@ -1021,33 +1069,22 @@ static void dec_misc(DisasContext *dc, uint32_t insn)
/*#ifdef TARGET_OPENRISC64
case 0x34: l.sd
LOG_DIS(l.sd %d, r%d, r%d, %d\n, I5, ra, rb, I11);
-check_ob64s(dc);
-mop = MO_TEQ;
-goto do_store;
+gen_loadstore(dc, op0, ra, rb, rd, tmp);
#endif*/
case 0x35:/* l.sw */
LOG_DIS(l.sw %d, r%d, r%d, %d\n, I5, ra, rb, I11);
-mop = MO_TEUL;
-goto do_store;
+gen_loadstore(dc, op0, ra, rb, rd, tmp);
+break;
case 0x36:/* l.sb */
[Qemu-devel] [PATCH 2/2] target-openrisc: Add l.lwa/l.swa support
From: Christian Svensson b...@cmd.nu
This patch adds support for atomic locks
and is an adaption from
https://github.com/bluecmd/or1k-qemu/commits/or32-optimize
Tested via the atomic lock implementation of musl
Signed-off-by: Christian Svensson b...@cmd.nu
Signed-off-by: Sebastian Macke sebast...@macke.de
---
target-openrisc/cpu.h | 3 ++
target-openrisc/interrupt.c | 3 ++
target-openrisc/translate.c | 77 ++---
3 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/target-openrisc/cpu.h b/target-openrisc/cpu.h
index 69b96c6..abdba75 100644
--- a/target-openrisc/cpu.h
+++ b/target-openrisc/cpu.h
@@ -302,6 +302,9 @@ typedef struct CPUOpenRISCState {
in solt so far. */
uint32_t btaken; /* the SR_F bit */
+target_ulong lock_addr; /* Atomicity lock address. */
+target_ulong lock_value; /* Atomicity lock value. */
+
CPU_COMMON
/* Fields from here on are preserved across CPU reset. */
diff --git a/target-openrisc/interrupt.c b/target-openrisc/interrupt.c
index e480cfd..68d554c 100644
--- a/target-openrisc/interrupt.c
+++ b/target-openrisc/interrupt.c
@@ -54,6 +54,9 @@ void openrisc_cpu_do_interrupt(CPUState *cs)
env-tlb-cpu_openrisc_map_address_data = cpu_openrisc_get_phys_nommu;
env-tlb-cpu_openrisc_map_address_code = cpu_openrisc_get_phys_nommu;
+/* invalidate lock */
+env-cpu_lock_addr = -1;
+
if (cs-exception_index 0 cs-exception_index EXCP_NR) {
env-pc = (cs-exception_index 8);
} else {
diff --git a/target-openrisc/translate.c b/target-openrisc/translate.c
index 543aa67..6401b4b 100644
--- a/target-openrisc/translate.c
+++ b/target-openrisc/translate.c
@@ -55,6 +55,8 @@ typedef struct DisasContext {
static TCGv_ptr cpu_env;
static TCGv cpu_sr;
static TCGv cpu_R[32];
+static TCGv cpu_lock_addr;
+static TCGv cpu_lock_value;
static TCGv cpu_pc;
static TCGv jmp_pc;/* l.jr/l.jalr temp pc */
static TCGv cpu_npc;
@@ -82,6 +84,12 @@ void openrisc_translate_init(void)
env_flags = tcg_global_mem_new_i32(TCG_AREG0,
offsetof(CPUOpenRISCState, flags),
flags);
+cpu_lock_addr = tcg_global_mem_new(TCG_AREG0,
+ offsetof(CPUOpenRISCState, lock_addr),
+ lock_addr);
+cpu_lock_value = tcg_global_mem_new(TCG_AREG0,
+offsetof(CPUOpenRISCState, lock_value),
+lock_value);
cpu_pc = tcg_global_mem_new(TCG_AREG0,
offsetof(CPUOpenRISCState, pc), pc);
cpu_npc = tcg_global_mem_new(TCG_AREG0,
@@ -254,17 +262,67 @@ static void gen_jump(DisasContext *dc, uint32_t imm,
uint32_t reg, uint32_t op0)
gen_sync_flags(dc);
}
+/* According to the OpenRISC specification we should poison our atomic lock
+ * if any other store is detected to the same address. For the sake of speed
+ * and because we're single-threaded we guarantee that atomic stores
+ * fail only if an atomic load or another atomic store
+ * is executed.
+ *
+ * To prevent the potential case of an ordinary store, we save
+ * the *value* of the address at the lock time. */
+
+static void gen_atomic_load(TCGv tD, TCGv t0, DisasContext *dc)
+{
+tcg_gen_qemu_ld_tl(tD, t0, dc-mem_idx, MO_TEUL);
+tcg_gen_mov_i32(cpu_lock_addr, t0);
+tcg_gen_mov_i32(cpu_lock_value, tD);
+}
+
+static void gen_atomic_store(TCGv tB, TCGv t0, DisasContext *dc)
+{
+int store_fail;
+int store_done;
+
+store_fail = gen_new_label();
+store_done = gen_new_label();
+
+/* check address */
+tcg_gen_brcond_i32(TCG_COND_NE, t0, cpu_lock_addr, store_fail);
+
+/* check value */
+TCGv val = tcg_temp_new();
+tcg_gen_qemu_ld_tl(val, t0, dc-mem_idx, MO_TEUL);
+tcg_gen_brcond_i32(TCG_COND_NE, val, cpu_lock_value, store_fail);
+tcg_temp_free(val);
+
+/* success of atomic access */
+tcg_gen_qemu_st_tl(tB, t0, dc-mem_idx, MO_TEUL);
+tcg_gen_ori_tl(cpu_sr, cpu_sr, SR_F);
+tcg_gen_br(store_done);
+
+gen_set_label(store_fail);
+tcg_gen_andi_tl(cpu_sr, cpu_sr, ~SR_F);
+
+gen_set_label(store_done);
+/* the atomic store invalidates the lock address. */
+tcg_gen_movi_i32(cpu_lock_addr, -1);
+}
+
static void gen_loadstore(DisasContext *dc, uint32 op0,
uint32_t ra, uint32_t rb, uint32_t rd,
uint32_t offset)
{
TCGv t0 = cpu_R[ra];
if (offset != 0) {
-t0 = tcg_temp_new();
+t0 = tcg_temp_local_new();
tcg_gen_addi_tl(t0, cpu_R[ra], sign_extend(offset, 16));
}
switch (op0) {
+case 0x1b:/* l.lwa */
+gen_atomic_load(cpu_R[rd], t0, dc);
+break;
+
case 0x21:/* l.lwz */
tcg_gen_qemu_ld_tl(cpu_R[rd], t0, dc-mem_idx, MO_TEUL);
[Qemu-devel] [PATCH 0/2] target-openrisc: Add atomic instructions
This patch adds the new atomic operations of the Load-link/store-conditional type which are called l.lwa and l.swa. For a cleaner implementation, all load and store instructions are separated to a function. Christian Svensson (1): target-openrisc: Add l.lwa/l.swa support Sebastian Macke (1): target-openrisc: Separate of load/store instructions target-openrisc/cpu.h | 3 + target-openrisc/interrupt.c | 3 + target-openrisc/translate.c | 188 ++-- 3 files changed, 153 insertions(+), 41 deletions(-) -- 2.2.2
[Qemu-devel] [PATCH] linux-user/main.c: Use TARGET_SIG* instead of SIG*
In main.c, all SIG* need be change to TARGET_SIG*, since the related
next call are all for TARGET_SIG*: queue_signal() and gdb_handlesig().
The related vi operation command is 1,$ s/\SIG/TARGET_SIG/g.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
linux-user/main.c | 64 +++
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 2d52c1f..bb214b6 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -313,7 +313,7 @@ void cpu_loop(CPUX86State *env)
#endif
case EXCP0B_NOSEG:
case EXCP0C_STACK:
-info.si_signo = SIGBUS;
+info.si_signo = TARGET_SIGBUS;
info.si_errno = 0;
info.si_code = TARGET_SI_KERNEL;
info._sifields._sigfault._addr = 0;
@@ -327,7 +327,7 @@ void cpu_loop(CPUX86State *env)
} else
#endif
{
-info.si_signo = SIGSEGV;
+info.si_signo = TARGET_SIGSEGV;
info.si_errno = 0;
info.si_code = TARGET_SI_KERNEL;
info._sifields._sigfault._addr = 0;
@@ -335,7 +335,7 @@ void cpu_loop(CPUX86State *env)
}
break;
case EXCP0E_PAGE:
-info.si_signo = SIGSEGV;
+info.si_signo = TARGET_SIGSEGV;
info.si_errno = 0;
if (!(env-error_code 1))
info.si_code = TARGET_SEGV_MAPERR;
@@ -352,7 +352,7 @@ void cpu_loop(CPUX86State *env)
#endif
{
/* division by zero */
-info.si_signo = SIGFPE;
+info.si_signo = TARGET_SIGFPE;
info.si_errno = 0;
info.si_code = TARGET_FPE_INTDIV;
info._sifields._sigfault._addr = env-eip;
@@ -367,7 +367,7 @@ void cpu_loop(CPUX86State *env)
} else
#endif
{
-info.si_signo = SIGTRAP;
+info.si_signo = TARGET_SIGTRAP;
info.si_errno = 0;
if (trapnr == EXCP01_DB) {
info.si_code = TARGET_TRAP_BRKPT;
@@ -387,7 +387,7 @@ void cpu_loop(CPUX86State *env)
} else
#endif
{
-info.si_signo = SIGSEGV;
+info.si_signo = TARGET_SIGSEGV;
info.si_errno = 0;
info.si_code = TARGET_SI_KERNEL;
info._sifields._sigfault._addr = 0;
@@ -395,7 +395,7 @@ void cpu_loop(CPUX86State *env)
}
break;
case EXCP06_ILLOP:
-info.si_signo = SIGILL;
+info.si_signo = TARGET_SIGILL;
info.si_errno = 0;
info.si_code = TARGET_ILL_ILLOPN;
info._sifields._sigfault._addr = env-eip;
@@ -517,7 +517,7 @@ segv:
end_exclusive();
/* We get the PC of the entry address - which is as good as anything,
on a real kernel what you get depends on which mode it uses. */
-info.si_signo = SIGSEGV;
+info.si_signo = TARGET_SIGSEGV;
info.si_errno = 0;
/* XXX: check env-error_code */
info.si_code = TARGET_SEGV_MAPERR;
@@ -692,7 +692,7 @@ void cpu_loop(CPUARMState *env)
rc = EmulateAll(opcode, ts-fpa, env);
if (rc == 0) { /* illegal instruction */
-info.si_signo = SIGILL;
+info.si_signo = TARGET_SIGILL;
info.si_errno = 0;
info.si_code = TARGET_ILL_ILLOPN;
info._sifields._sigfault._addr = env-regs[15];
@@ -716,7 +716,7 @@ void cpu_loop(CPUARMState *env)
//printf(fpsr 0x%x, arm_fpe 0x%x\n,fpsr,arm_fpe);
if (fpsr (arm_fpe 16)) { /* exception enabled? */
- info.si_signo = SIGFPE;
+ info.si_signo = TARGET_SIGFPE;
info.si_errno = 0;
/* ordered by priority, least first */
@@ -840,7 +840,7 @@ void cpu_loop(CPUARMState *env)
case EXCP_DATA_ABORT:
addr = env-exception.vaddress;
{
-info.si_signo = SIGSEGV;
+info.si_signo = TARGET_SIGSEGV;
info.si_errno = 0;
/* XXX: check env-error_code */
info.si_code = TARGET_SEGV_MAPERR;
@@ -1026,7 +1026,7 @@ void cpu_loop(CPUARMState *env)
/* just indicate that signals should be handled asap */
break;
case EXCP_UDEF:
-info.si_signo = SIGILL;
+info.si_signo = TARGET_SIGILL;
info.si_errno = 0;
info.si_code = TARGET_ILL_ILLOPN;
info._sifields._sigfault._addr = env-pc;
@@ -1039,7 +1039,7 @@ void cpu_loop(CPUARMState *env)
/* fall through for segv */
case EXCP_PREFETCH_ABORT:
case EXCP_DATA_ABORT:
-info.si_signo = SIGSEGV;
+info.si_signo =
[Qemu-devel] [PATCH v2] linux-user/main.c: Remove redundant end_exclusive() in arm_kernel_cmpxchg64_helper()
start/end_exclusive() need be pairs, except the start_exclusive() in stop_all_tasks() which is only used by force_sig(), which will be abort. So at present, start_exclusive() in stop_all_task() need not be paired. queue_signal() may call force_sig(), or return after kill pid (or queue signal). If could return from queue_signal(), stop_all_task() would not be called in time, the next end_exclusive() would be issue. So in arm_kernel_cmpxchg64_helper() for ARM, need remove end_exclusive() after queue_signal(). The related commit: 97cc756 linux-user: Implement new ARM 64 bit cmpxchg kernel helper. Signed-off-by: Chen Gang gang.chen.5...@gmail.com --- linux-user/main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/linux-user/main.c b/linux-user/main.c index 8c70be4..2d52c1f 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -523,8 +523,6 @@ segv: info.si_code = TARGET_SEGV_MAPERR; info._sifields._sigfault._addr = env-exception.vaddress; queue_signal(env, info.si_signo, info); - -end_exclusive(); } /* Handle a jump to the kernel code page. */ -- 1.9.3
Re: [Qemu-devel] [RFC PATCH 09/11] hw/acpi/acpi-build-utils: Add acpi_fixed_memory32() and acpi_extended_irq()
On Sat, Jan 24, 2015 at 05:21:18PM +0800, Shannon Zhao wrote:
Add acpi_fixed_memory32() for describing device mmio region in resource
template.
Add acpi_extended_irq() for describing device interrupt in resource template.
These can be used to generating DSDT table for ACPI on ARM.
Signed-off-by: Shannon Zhao zhaoshengl...@huawei.com
---
hw/acpi/acpi-build-utils.c | 42
include/hw/acpi/acpi-build-utils.h |2 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/hw/acpi/acpi-build-utils.c b/hw/acpi/acpi-build-utils.c
index 59873e3..211c4d3 100644
--- a/hw/acpi/acpi-build-utils.c
+++ b/hw/acpi/acpi-build-utils.c
@@ -493,6 +493,48 @@ AcpiAml acpi_call4(const char *method, AcpiAml arg1,
AcpiAml arg2,
}
/*
+ * ACPI 5.1: 19.5.80 Memory32Fixed (Memory Resource Descriptor Macro)
Pls document the first spec which includes a feature, not the last one.
+ * 6.4.2 Small Resource Data Type
So add API for small resource data type?
+ */
+AcpiAml acpi_fixed_memory32(uint64_t addr, uint64_t size, uint8_t rw_flag)
so name it memory32_fixed?
+{
+AcpiAml var = aml_allocate_internal(0, NON_BLOCK);
+build_append_byte(var.buf, 0x86); /* Extended irq descriptor */
+build_append_byte(var.buf, 9);
+build_append_byte(var.buf, 0);
+build_append_byte(var.buf, rw_flag);
+build_append_byte(var.buf, addr 0xff);
+build_append_byte(var.buf, (addr 8) 0xff);
+build_append_byte(var.buf, (addr 16) 0xff);
+build_append_byte(var.buf, (addr 24) 0xff);
+
+build_append_byte(var.buf, size 0xff);
+build_append_byte(var.buf, (size 8) 0xff);
+build_append_byte(var.buf, (size 16) 0xff);
+build_append_byte(var.buf, (size 24) 0xff);
+return var;
+}
+
+/*
+ * ACPI 5.1: 19.5.61 Interrupt (Interrupt Resource Descriptor Macro)
+ * 6.4.2 Small Resource Data Type
+ */
+AcpiAml acpi_extended_irq(uint8_t irq_flags, int irq)
So acpi_interrupt?
+{
+AcpiAml var = aml_allocate_internal(0, NON_BLOCK);
+build_append_byte(var.buf, 0x89); /* Extended irq descriptor */
+build_append_byte(var.buf, 6);
+build_append_byte(var.buf, 0);
+build_append_byte(var.buf, irq_flags);
+build_append_byte(var.buf, 0x01);
+build_append_byte(var.buf, irq 0xff);
+build_append_byte(var.buf, (irq 8) 0xff);
+build_append_byte(var.buf, (irq 16) 0xff);
+build_append_byte(var.buf, (irq 24) 0xff);
+return var;
Pls add comments to document opcode constants.
+}
+
+/*
* ACPI 5.0: 19.5.62 IO (IO Resource Descriptor Macro)
* 6.4.2 Small Resource Data Type
*/
diff --git a/include/hw/acpi/acpi-build-utils.h
b/include/hw/acpi/acpi-build-utils.h
index d39b5b1..bfed546 100644
--- a/include/hw/acpi/acpi-build-utils.h
+++ b/include/hw/acpi/acpi-build-utils.h
@@ -115,6 +115,8 @@ AcpiAml acpi_call3(const char *method, AcpiAml arg1,
AcpiAml arg2,
AcpiAml arg3);
AcpiAml acpi_call4(const char *method, AcpiAml arg1, AcpiAml arg2,
AcpiAml arg3, AcpiAml arg4);
+AcpiAml acpi_fixed_memory32(uint64_t addr, uint64_t size, uint8_t rw_flag);
+AcpiAml acpi_extended_irq(uint8_t irq_flags, int irq);
AcpiAml acpi_io(acpiIODecode dec, uint16_t min_base, uint16_t max_base,
uint8_t aln, uint8_t len);
AcpiAml acpi_iqr_no_flags(uint8_t irq);
--
1.7.1
Re: [Qemu-devel] [PATCH v2] alt-gr on Windows
Hello
attached is the v2 set of patchs.
Le 01/01/2015 20:10, Stefan Weil a écrit :
I suggest calling MapVirtualKey only for those keys which don't need special
handling, so it would be in the default case of the switch statement.
Done (patch 0001) . updated code yields to same result as previous patch. Added
a FIXME note regarding the previous alt gr fix, which do not look relevant
anymore to me.
It looks like Alt-Ctrl is a valid alternative for pressing AltGr on Windows,
so we have to take that into account, too.
Few tests I did on a XP vm give correct keyboard behaviour. looks like this is
transparent on Windows guest.
Wine also needs special handling because it sends a single (different) key
code instead of two key codes.
By this I understand that Wine should just be excluded from this fix (what I do
by patch 0002)
Regards,
Rémi
From 3ecdd74fd12f33b6c00b66fce2e082c7fe9b273e Mon Sep 17 00:00:00 2001
From: Remi Thebault remi.theba...@outlook.com
Date: Sun, 25 Jan 2015 16:57:45 +0100
Subject: [PATCH 1/4 v2] input: gtk win32 ui sends r-ctrl and r-alt key events
gtk ui on win32 only sent left ctrl and alt code, whatever the keystroke.
In case of a right keystroke and left scan code, this commit corrects
the qemu code to fit the actual keystroke.
Signed-off-by: Remi Thebault remi.theba...@outlook.com
---
ui/gtk.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index 0385757..da593f7 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -900,10 +900,26 @@ static int gd_map_keycode(GtkDisplayState *s, GdkDisplay
*dpy, int gdk_keycode)
#ifdef GDK_WINDOWING_WIN32
if (GDK_IS_WIN32_DISPLAY(dpy)) {
-qemu_keycode = MapVirtualKey(gdk_keycode, MAPVK_VK_TO_VSC);
-switch (qemu_keycode) {
-case 103: /* alt gr */
-qemu_keycode = 56 | SCANCODE_GREY;
+/*
+ testing for right ctrl and right alt and give corresponding code.
+ for all other keystrokes, scan code is given by MapVirtualKey.
+ (MapVirtualKey maps same code for left and right ctrl and alt keys)
+ */
+switch (gdk_keycode) {
+case 0xa3: // r-ctrl
+qemu_keycode = 0x9d;
+break;
+case 0xa5: // r-alt
+qemu_keycode = 0xb8;
+break;
+default:
+qemu_keycode = MapVirtualKey(gdk_keycode, MAPVK_VK_TO_VSC);
+/* FIXME: is following check still needed? */
+switch (qemu_keycode) {
+case 103: /* alt gr */
+qemu_keycode = 56 | SCANCODE_GREY;
+break;
+}
break;
}
return qemu_keycode;
--
1.8.5.2.msysgit.0
From b4866d32436e9b6bd9a9488eb5f998d196980e77 Mon Sep 17 00:00:00 2001
From: Remi Thebault remi.theba...@outlook.com
Date: Sun, 25 Jan 2015 17:04:01 +0100
Subject: [PATCH 2/4 v2] input: introduce INPUT_NEEDS_ALTGR_FIX macro
Common macro amoung all ui, to provide consistent alt gr fix.
defined such as to have the fix on win32 (excluding wine)
---
include/ui/input.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/ui/input.h b/include/ui/input.h
index 5d5ac00..64e531c 100644
--- a/include/ui/input.h
+++ b/include/ui/input.h
@@ -10,6 +10,13 @@
#define INPUT_EVENT_ABS_SIZE 0x8000
+#ifndef INPUT_NEEDS_ALTGR_FIX
+# if defined(_WIN32) !defined(__WINE__)
+# define INPUT_NEEDS_ALTGR_FIX 1
+# endif
+#endif
+
+
typedef struct QemuInputHandler QemuInputHandler;
typedef struct QemuInputHandlerState QemuInputHandlerState;
--
1.8.5.2.msysgit.0
From 23b3b8bfa8dfce05b72bde6a82adf6e122a5d74f Mon Sep 17 00:00:00 2001
From: Remi Thebault remi.theba...@outlook.com
Date: Sun, 25 Jan 2015 17:06:11 +0100
Subject: [PATCH 3/4 v2] input: gtk win32 ui handles altgr key correctly
Linux guest / Windows host had a dead altgr key problem due to
Windows mapping of altgr to ctrl-alt. This commit fixes it by sending
a fake ctrl-up event to the guest when appropriate.
In case of turbo mode, only one fake event is sent.
In a windows guest, altgr key still works as usual.
Signed-off-by: Remi Thebault remi.theba...@outlook.com
---
ui/gtk.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/ui/gtk.c b/ui/gtk.c
index da593f7..1287409 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -230,6 +230,12 @@ struct GtkDisplayState {
bool modifier_pressed[ARRAY_SIZE(modifier_keycode)];
bool has_evdev;
+
+#if defined(INPUT_NEEDS_ALTGR_FIX)
+/* win32 alt-gr handling */
+bool l_ctrl_down;
+bool r_alt_down;
+#endif
};
static void gd_grab_pointer(VirtualConsole *vc);
@@ -975,6 +981,30 @@ static gboolean gd_key_event(GtkWidget *widget,
GdkEventKey *key, void *opaque)
}
}
+#if defined(INPUT_NEEDS_ALTGR_FIX)
+/* Windows maps altgr key to l-ctrl + r-alt.
+ For proper handling in the guest, only r-alt is to be sent.
+ This is done by sending a fake ctrl up event
Re: [Qemu-devel] [PATCH v2] linux-user/main.c: Remove redundant end_exclusive() in arm_kernel_cmpxchg64_helper()
On 25 January 2015 at 11:03, Chen Gang S gang.c...@sunrus.com.cn wrote: start/end_exclusive() need be pairs, except the start_exclusive() in stop_all_tasks() which is only used by force_sig(), which will be abort. So at present, start_exclusive() in stop_all_task() need not be paired. queue_signal() may call force_sig(), or return after kill pid (or queue signal). If could return from queue_signal(), stop_all_task() would not be called in time, the next end_exclusive() would be issue. So in arm_kernel_cmpxchg64_helper() for ARM, need remove end_exclusive() after queue_signal(). The related commit: 97cc756 linux-user: Implement new ARM 64 bit cmpxchg kernel helper. Signed-off-by: Chen Gang gang.chen.5...@gmail.com --- linux-user/main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/linux-user/main.c b/linux-user/main.c index 8c70be4..2d52c1f 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -523,8 +523,6 @@ segv: info.si_code = TARGET_SEGV_MAPERR; info._sifields._sigfault._addr = env-exception.vaddress; queue_signal(env, info.si_signo, info); - -end_exclusive(); } /* Handle a jump to the kernel code page. */ Reviewed-by: Peter Maydell peter.mayd...@linaro.org thanks -- PMM
Re: [Qemu-devel] [PATCH] linux-user/syscall.c: Let all lock_user_struct() and unlock_user_struct() paired with each other
On 25 January 2015 at 12:06, Chen Gang S gang.c...@sunrus.com.cn wrote: lock_user_struct() and unlock_user_struct() need always be paired with each other, or will cause resource leak. Also remove redundant check for 'target_mb' in abi_long do_msgrcv(). Also match the coding styles found by ./scripts/checkpatch.pl. Signed-off-by: Chen Gang gang.chen.5...@gmail.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org Are you claiming that you've reviewed *all* the code in this file for mismatched lock/unlock calls? If so, it would be nice to say so explicitly in the commit message. If not, it would be nice if the commit message was clearer about what areas of the code it applied to. The code changes are correct, though. thanks -- PMM
Re: [Qemu-devel] [PATCH 01/15] rcu: add rcu library
On Thu, 01/22 15:47, Paolo Bonzini wrote:
This includes a (mangled) copy of the liburcu code. The main changes
are: 1) removing dependencies on many other header files in liburcu; 2)
removing for simplicity the tentative busy waiting in synchronize_rcu,
which has limited performance effects; 3) replacing futexes in
synchronize_rcu with QemuEvents for Win32 portability. The API is
the same as liburcu, so it should be possible in the future to require
liburcu on POSIX systems for example and use our copy only on Windows.
Among the various versions available I chose urcu-mb, which is the
least invasive implementation even though it does not have the
fastest rcu_read_{lock,unlock} implementation. The urcu flavor can
be changed later, after benchmarking.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Fam Zheng f...@redhat.com
---
docs/rcu.txt | 285
++
hw/9pfs/virtio-9p-synth.c | 1 +
include/qemu/atomic.h | 61 ++
include/qemu/queue.h | 13 +++
include/qemu/rcu.h| 112 ++
include/qemu/thread.h | 3 -
util/Makefile.objs| 1 +
util/rcu.c| 172
8 files changed, 645 insertions(+), 3 deletions(-)
create mode 100644 docs/rcu.txt
create mode 100644 include/qemu/rcu.h
create mode 100644 util/rcu.c
diff --git a/docs/rcu.txt b/docs/rcu.txt
new file mode 100644
index 000..9938ad3
--- /dev/null
+++ b/docs/rcu.txt
@@ -0,0 +1,285 @@
+Using RCU (Read-Copy-Update) for synchronization
+
+
+Read-copy update (RCU) is a synchronization mechanism that is used to
+protect read-mostly data structures. RCU is very efficient and scalable
+on the read side (it is wait-free), and thus can make the read paths
+extremely fast.
+
+RCU supports concurrency between a single writer and multiple readers,
+thus it is not used alone. Typically, the write-side will use a lock to
+serialize multiple updates, but other approaches are possible (e.g.,
+restricting updates to a single task). In QEMU, when a lock is used,
+this will often be the iothread mutex, also known as the big QEMU
+lock (BQL). Also, restricting updates to a single task is done in
+QEMU using the bottom half API.
+
+RCU is fundamentally a wait-to-finish mechanism. The read side marks
+sections of code with critical sections, and the update side will wait
+for the execution of all *currently running* critical sections before
+proceeding, or before asynchronously executing a callback.
+
+The key point here is that only the currently running critical sections
+are waited for; critical sections that are started _after_ the beginning
+of the wait do not extend the wait, despite running concurrently with
+the updater. This is the reason why RCU is more scalable than,
+for example, reader-writer locks. It is so much more scalable that
+the system will have a single instance of the RCU mechanism; a single
+mechanism can be used for an arbitrary number of things, without
+having to worry about things such as contention or deadlocks.
+
+How is this possible? The basic idea is to split updates in two phases,
+removal and reclamation. During removal, we ensure that subsequent
+readers will not be able to get a reference to the old data. After
+removal has completed, a critical section will not be able to access
+the old data. Therefore, critical sections that begin after removal
+do not matter; as soon as all previous critical sections have finished,
+there cannot be any readers who hold references to the data structure,
+and these can now be safely reclaimed (e.g., freed or unref'ed).
+
+Here is a picutre:
+
+thread 1 thread 2 thread 3
+------
+enter RCU crit.sec.
+ |finish removal phase
+ |begin wait
+ | |enter RCU crit.sec.
+exit RCU crit.sec | |
+complete wait |
+begin reclamation phase |
+ exit RCU crit.sec.
+
+
+Note how thread 3 is still executing its critical section when thread 2
+starts reclaiming data. This is possible, because the old version of the
+data structure was not accessible at the time thread 3 began executing
+that critical section.
+
+
+RCU API
+===
+
+The core RCU API is small:
+
+ void rcu_read_lock(void);
+
+Used by a reader to inform the reclaimer that the reader is
+entering an RCU read-side critical section.
+
+ void rcu_read_unlock(void);
+
+Used by a reader to inform the
Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
2)when numa is used, the hotplugged cpu is always on numa node 0
(cpu_add or device_add cpu)
About this, it seem to be a display bug in info numa,
cpu is correctly assigned to numa node1 in the guest.
- Mail original -
De: aderumier aderum...@odiso.com
À: Zhu Guihua zhugh.f...@cn.fujitsu.com
Cc: qemu-devel qemu-devel@nongnu.org, tangc...@cn.fujitsu.com, guz fnst
guz.f...@cn.fujitsu.com, isimatu yasuaki isimatu.yasu...@jp.fujitsu.com,
Anshul Makkar anshul.mak...@profitbricks.com, chen fan fnst
chen.fan.f...@cn.fujitsu.com, Igor Mammedov imamm...@redhat.com,
afaerber afaer...@suse.de
Envoyé: Lundi 26 Janvier 2015 04:19:52
Objet: Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
Thanks for your reply.
2 others things:
1)
on cpu unplug, I see that the cpu is correctly removed from my linux guest but
not from qemu
starting with a guest with 3cpus:
guest: #ls -lah /sys/devices/system/ |grep cpu
drwxr-xr-x 6 root root 0 Jan 25 22:16 cpu0
drwxr-xr-x 6 root root 0 Jan 25 22:16 cpu1
drwxr-xr-x 6 root root 0 Jan 25 22:16 cpu2
hmp: # info cpus
* CPU #0: pc=0x81057022 (halted) thread_id=24972
CPU #1: pc=0x81057022 (halted) thread_id=24973
CPU #2: pc=0x81048bc1 (halted) thread_id=25102
then unplug cpu2
hmp : device_del cpu2
guest:
dmesg:
[ 176.219754] Unregister pv shared memory for cpu 2
[ 176.278881] smpboot: CPU 2 is now offline
#ls -lah /sys/devices/system/ |grep cpu
drwxr-xr-x 6 root root 0 Jan 25 22:16 cpu0
drwxr-xr-x 6 root root 0 Jan 25 22:16 cpu1
hmp: # info cpus
* CPU #0: pc=0x81057022 (halted) thread_id=24972
CPU #1: pc=0x81057022 (halted) thread_id=24973
CPU #2: pc=0x81048bc1 (halted) thread_id=25102
2)when numa is used, the hotplugged cpu is always on numa node 0
(cpu_add or device_add cpu)
starting a guest, with 2 sockets,1 cores
-smp 2,sockets=2,cores=1,maxcpus=2
-object memory-backend-ram,size=256M,id=ram-node0 -numa
node,nodeid=0,cpus=0,memdev=ram-node0
-object memory-backend-ram,size=256M,id=ram-node1 -numa
node,nodeid=1,cpus=1,memdev=ram-node1
hmp:
# info numa
2 nodes
node 0 cpus: 0
node 0 size: 256 MB
node 1 cpus: 1
node 1 size: 256 MB
ok
now
starting with same topology, but with 1cpu at start
-smp 2,sockets=2,cores=1,maxcpus=2
-object memory-backend-ram,size=256M,id=ram-node0 -numa
node,nodeid=0,cpus=0,memdev=ram-node0
-object memory-backend-ram,size=256M,id=ram-node1 -numa
node,nodeid=1,cpus=1,memdev=ram-node1
# info numa
2 nodes
node 0 cpus: 0
node 0 size: 256 MB
node 1 cpus:
node 1 size: 256 MB
hotpluging a cpu
# device_add kvm64-x86_64-cpu,apic-id=1,id=cpu1
# info numa
2 nodes
node 0 cpus: 0 1
node 0 size: 256 MB
node 1 cpus:
node 1 size: 256 MB
cpu1 should be on node1, not node0.
Regards,
Alexandre
- Mail original -
De: Zhu Guihua zhugh.f...@cn.fujitsu.com
À: aderumier aderum...@odiso.com
Cc: qemu-devel qemu-devel@nongnu.org, tangc...@cn.fujitsu.com, guz fnst
guz.f...@cn.fujitsu.com, isimatu yasuaki isimatu.yasu...@jp.fujitsu.com,
Anshul Makkar anshul.mak...@profitbricks.com, chen fan fnst
chen.fan.f...@cn.fujitsu.com, Igor Mammedov imamm...@redhat.com,
afaerber afaer...@suse.de
Envoyé: Lundi 26 Janvier 2015 03:01:48
Objet: Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
On Fri, 2015-01-23 at 11:24 +0100, Alexandre DERUMIER wrote:
Hello,
I'm currently testing the new cpu unplug features,
Works fine here with debian guests and kernel 3.14.
Thanks for your test.
But I have notice some small potential bugs, but I'm not sure I'm doing it
right.
1)first, to unplug cpu, we need an id for cpu
Yes, if you want to unplug cpu, you must have an id for cpu.
The problem is that the current qemu command line
-smp 1,sockets=2,cores=1,maxcpus=2
for example, will create 1 cpu on apic-id 0 without any id, so we can't
unplug it.
So, I have tried with
-smp 1,sockets=2,cores=1,maxcpus=2 -device kvm64-x86_64-cpu,apic-id=0,id=cpu0
But this give me an error:
-device kvm64-x86_64-cpu,apic-id=0,id=cpu0: CPU with APIC ID 0 exists
APIC ID 0 was used by the cpu of '-smp 1'.
So you should use apic-id=1
(also try to set -smp 0, but it's not working).
2) second problem, if I start with
-smp 1,sockets=2,cores=1,maxcpus=2
then hmp:
device_add kvm64-x86_64-cpu,apic-id=1,id=cpu1
then hmp : device_del cpu1
Got an error:
This is the last cpu, should not be removed!
Oh, it's our problem, thanks for your pointing out.
I will fix it in next version.
Regards,
Zhu
This is coming from
[PATCH 06/12] pc: add cpu hot unplug request callback support
+ if (smp_cpus == 1) {
+ error_setg(local_err,
+ This is the last cpu, should not be removed!);
+ goto out;
+ }
So, the only way unplug is working for me, is to start with -smp 2 minimum
-smp 2,sockets=2,cores=1,maxcpus=4
Then I can hotplug|unplug
Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
On Mon, 2015-01-26 at 04:19 +0100, Alexandre DERUMIER wrote:
Thanks for your reply.
2 others things:
1)
on cpu unplug, I see that the cpu is correctly removed from my linux guest
but not from qemu
About this, I can do it successfully on my qemu.
So can you tell us more information about your operation?
And I found the patchset you applied is the last version in your last
email. I think you'd better apply the latest version.
Regards,
Zhu
starting with a guest with 3cpus:
guest: #ls -lah /sys/devices/system/ |grep cpu
drwxr-xr-x 6 root root0 Jan 25 22:16 cpu0
drwxr-xr-x 6 root root0 Jan 25 22:16 cpu1
drwxr-xr-x 6 root root0 Jan 25 22:16 cpu2
hmp: # info cpus
* CPU #0: pc=0x81057022 (halted) thread_id=24972
CPU #1: pc=0x81057022 (halted) thread_id=24973
CPU #2: pc=0x81048bc1 (halted) thread_id=25102
then unplug cpu2
hmp : device_del cpu2
guest:
dmesg:
[ 176.219754] Unregister pv shared memory for cpu 2
[ 176.278881] smpboot: CPU 2 is now offline
#ls -lah /sys/devices/system/ |grep cpu
drwxr-xr-x 6 root root0 Jan 25 22:16 cpu0
drwxr-xr-x 6 root root0 Jan 25 22:16 cpu1
hmp: # info cpus
* CPU #0: pc=0x81057022 (halted) thread_id=24972
CPU #1: pc=0x81057022 (halted) thread_id=24973
CPU #2: pc=0x81048bc1 (halted) thread_id=25102
2)when numa is used, the hotplugged cpu is always on numa node 0
(cpu_add or device_add cpu)
starting a guest, with 2 sockets,1 cores
-smp 2,sockets=2,cores=1,maxcpus=2
-object memory-backend-ram,size=256M,id=ram-node0 -numa
node,nodeid=0,cpus=0,memdev=ram-node0
-object memory-backend-ram,size=256M,id=ram-node1 -numa
node,nodeid=1,cpus=1,memdev=ram-node1
hmp:
# info numa
2 nodes
node 0 cpus: 0
node 0 size: 256 MB
node 1 cpus: 1
node 1 size: 256 MB
ok
now
starting with same topology, but with 1cpu at start
-smp 2,sockets=2,cores=1,maxcpus=2
-object memory-backend-ram,size=256M,id=ram-node0 -numa
node,nodeid=0,cpus=0,memdev=ram-node0
-object memory-backend-ram,size=256M,id=ram-node1 -numa
node,nodeid=1,cpus=1,memdev=ram-node1
# info numa
2 nodes
node 0 cpus: 0
node 0 size: 256 MB
node 1 cpus:
node 1 size: 256 MB
hotpluging a cpu
# device_add kvm64-x86_64-cpu,apic-id=1,id=cpu1
# info numa
2 nodes
node 0 cpus: 0 1
node 0 size: 256 MB
node 1 cpus:
node 1 size: 256 MB
cpu1 should be on node1, not node0.
Regards,
Alexandre
- Mail original -
De: Zhu Guihua zhugh.f...@cn.fujitsu.com
À: aderumier aderum...@odiso.com
Cc: qemu-devel qemu-devel@nongnu.org, tangc...@cn.fujitsu.com, guz fnst
guz.f...@cn.fujitsu.com, isimatu yasuaki
isimatu.yasu...@jp.fujitsu.com, Anshul Makkar
anshul.mak...@profitbricks.com, chen fan fnst
chen.fan.f...@cn.fujitsu.com, Igor Mammedov imamm...@redhat.com,
afaerber afaer...@suse.de
Envoyé: Lundi 26 Janvier 2015 03:01:48
Objet: Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
On Fri, 2015-01-23 at 11:24 +0100, Alexandre DERUMIER wrote:
Hello,
I'm currently testing the new cpu unplug features,
Works fine here with debian guests and kernel 3.14.
Thanks for your test.
But I have notice some small potential bugs, but I'm not sure I'm doing it
right.
1)first, to unplug cpu, we need an id for cpu
Yes, if you want to unplug cpu, you must have an id for cpu.
The problem is that the current qemu command line
-smp 1,sockets=2,cores=1,maxcpus=2
for example, will create 1 cpu on apic-id 0 without any id, so we can't
unplug it.
So, I have tried with
-smp 1,sockets=2,cores=1,maxcpus=2 -device
kvm64-x86_64-cpu,apic-id=0,id=cpu0
But this give me an error:
-device kvm64-x86_64-cpu,apic-id=0,id=cpu0: CPU with APIC ID 0 exists
APIC ID 0 was used by the cpu of '-smp 1'.
So you should use apic-id=1
(also try to set -smp 0, but it's not working).
2) second problem, if I start with
-smp 1,sockets=2,cores=1,maxcpus=2
then hmp:
device_add kvm64-x86_64-cpu,apic-id=1,id=cpu1
then hmp : device_del cpu1
Got an error:
This is the last cpu, should not be removed!
Oh, it's our problem, thanks for your pointing out.
I will fix it in next version.
Regards,
Zhu
This is coming from
[PATCH 06/12] pc: add cpu hot unplug request callback support
+ if (smp_cpus == 1) {
+ error_setg(local_err,
+ This is the last cpu, should not be removed!);
+ goto out;
+ }
So, the only way unplug is working for me, is to start with -smp 2 minimum
-smp 2,sockets=2,cores=1,maxcpus=4
Then I can hotplug|unplug cpuid = 2
Regards,
Alexandre Derumier
[...]
Re: [Qemu-devel] Help for beginner
Hi again, I am sorry for multiple reply, but i forget to mention one other thing. I also use lttng-ust method, and like my printf() attempt, I put my new defined trace points into all function within net/net.c, net/tap.c and hw/net/virtio-net.c. Using this approach, i also cannot capture my new trace points when doing 'ping'. I am sure that i added my new trace points correctly because i can list them using 'lttng list -u' what did i do wrong? ~Ady On 1/26/15, Ady Wahyudi Paundu awpau...@gmail.com wrote: Hi Stefan, thank you for the tips. I was trying the way you suggested to add printfs. For starter I try to put them into all function within net/net.c, net/tap.c and hw/net/virtio-net.c (I run qemu using virtio netcard). However, there were no printf message showed up (when i started a qemu process and when i tried ping from within the guest OS of that qemu process). As if those functions were not used. Do you think I put those trace points in a wrong functions? Thanks in advance ~Ady On 1/16/15, Stefan Hajnoczi stefa...@gmail.com wrote: Assuming you run qemu-system-x86_64 the default network card is an emulated Intel e1000 NIC. See hw/net/e1000.c:start_xmit() for the function that emulates packet transmission. It loops over the transmit descriptor ring and send off each packet that the guest has enqueued using qemu_send_packet(). qemu_send_packet() is a QEMU network subsystem API that passes the packet to a host network device (for example, -netdev tap). What happens next depends on which netdev the user launched QEMU with (the default is 'user'). The most popular netdev in production is tap. Look at net/tap.c:tap_receive() to see how QEMU writes the guest's packet to the tap device on the host. The tap driver in the host kernel will then receive the packet from the guest and process it further (often the user has configured a software bridge device so the packet will be forwarded onto the host's physical NIC). Just to recap the structure is: guest - emulated e1000 NIC - tap netdev - host kernel Use tcpdump in the guest or host, or add printfs to QEMU if you want to follow traffic further. Good luck, Stefan
Re: [Qemu-devel] [PATCH 05/15] memory: remove assertion on memory_region_destroy
On Thu, 01/22 15:47, Paolo Bonzini wrote: From: Jan Kiszka jan.kis...@siemens.com Now that memory_region_destroy can be called from an RCU callback, checking the BQL-protected global memory_region_transaction_depth does not make much sense. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- memory.c | 1 - 1 file changed, 1 deletion(-) diff --git a/memory.c b/memory.c index c343bf3..8c3d8c0 100644 --- a/memory.c +++ b/memory.c @@ -1263,7 +1263,6 @@ static void memory_region_finalize(Object *obj) MemoryRegion *mr = MEMORY_REGION(obj); assert(QTAILQ_EMPTY(mr-subregions)); -assert(memory_region_transaction_depth == 0); mr-destructor(mr); memory_region_clear_coalescing(mr); g_free((char *)mr-name); -- 1.8.3.1 Reviewed-by: Fam Zheng f...@redhat.com
Re: [Qemu-devel] [PATCH 04/15] rcu: add call_rcu
On Thu, 01/22 15:47, Paolo Bonzini wrote:
Asynchronous callbacks provided by call_rcu are particularly important
for QEMU, because the BQL makes it hard to use synchronize_rcu.
In addition, the current RCU implementation is not particularly friendly
to multiple concurrent synchronize_rcu callers, making call_rcu even
more important.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
docs/rcu.txt | 110 +++--
include/qemu/rcu.h | 22 ++
util/rcu.c | 119
+
3 files changed, 247 insertions(+), 4 deletions(-)
diff --git a/docs/rcu.txt b/docs/rcu.txt
index 9938ad3..61752b9 100644
--- a/docs/rcu.txt
+++ b/docs/rcu.txt
@@ -82,7 +82,50 @@ The core RCU API is small:
Note that it would be valid for another update to come while
synchronize_rcu is running. Because of this, it is better that
the updater releases any locks it may hold before calling
-synchronize_rcu.
+synchronize_rcu. If this is not possible (for example, because
+the updater is protected by the BQL), you can use call_rcu.
+
+ void call_rcu1(struct rcu_head * head,
+void (*func)(struct rcu_head *head));
+
+This function invokes func(head) after all pre-existing RCU
+read-side critical sections on all threads have completed. This
+marks the end of the removal phase, with func taking care
+asynchronously of the reclamation phase.
+
+The foo struct needs to have an rcu_head structure added,
+perhaps as follows:
+
+struct foo {
+struct rcu_head rcu;
+int a;
+char b;
+long c;
+};
+
+so that the reclaimer function can fetch the struct foo address
+and free it:
+
+call_rcu1(foo.rcu, foo_reclaim);
+
+void foo_reclaim(struct rcu_head *rp)
+{
+struct foo *fp = container_of(rp, struct foo, rcu);
+g_free(fp);
+}
+
+For the common case where the rcu_head member is the first of the
+struct, you can use the following macro.
+
+ void call_rcu(T *p,
+ void (*func)(T *p),
+ field-name);
+
+call_rcu1 is typically used through this macro, in the common case
+where the struct rcu_head is the first field in the struct. In
+the above case, one could have written simply:
+
+call_rcu(foo_reclaim, g_free, rcu);
typeof(*p) atomic_rcu_read(p);
@@ -153,6 +196,11 @@ DIFFERENCES WITH LINUX
- atomic_rcu_read and atomic_rcu_set replace rcu_dereference and
rcu_assign_pointer. They take a _pointer_ to the variable being accessed.
+- call_rcu is a macro that has an extra argument (the name of the first
+ field in the struct, which must be a struct rcu_head), and expects the
+ type of the callback's argument to be the type of the first argument.
+ call_rcu1 is the same as Linux's call_rcu.
+
RCU PATTERNS
@@ -206,7 +254,47 @@ The write side looks simply like this (with appropriate
locking):
synchronize_rcu();
free(old);
-Note that the same idiom would be possible with reader/writer
+If the processing cannot be done purely within the critical section, it
+is possible to combine this idiom with a real reference count:
+
+rcu_read_lock();
+p = atomic_rcu_read(foo);
+foo_ref(p);
+rcu_read_unlock();
+/* do something with p. */
+foo_unref(p);
+
+The write side can be like this:
+
+qemu_mutex_lock(foo_mutex);
+old = foo;
+atomic_rcu_set(foo, new);
+qemu_mutex_unlock(foo_mutex);
+synchronize_rcu();
+foo_unref(old);
+
+or with call_rcu:
+
+qemu_mutex_lock(foo_mutex);
+old = foo;
+atomic_rcu_set(foo, new);
+qemu_mutex_unlock(foo_mutex);
+call_rcu(foo_unref, old, rcu);
+
+In both cases, the write side only performs removal. Reclamation
+happens when the last reference to a foo object is dropped.
+Using synchronize_rcu() is undesirably expensive, because the
+last reference may be dropped on the read side. Hence you can
+use call_rcu() instead:
+
+ foo_unref(struct foo *p) {
+if (atomic_fetch_dec(p-refcount) == 1) {
+call_rcu(foo_destroy, p, rcu);
+}
+}
+
+
+Note that the same idioms would be possible with reader/writer
locks:
read_lock(foo_rwlock); write_mutex_lock(foo_rwlock);
@@ -216,13 +304,27 @@ locks:
write_mutex_unlock(foo_rwlock);
free(p);
+--
+
+read_lock(foo_rwlock); write_mutex_lock(foo_rwlock);
+p = foo;
[Qemu-devel] [Bug 1414466] [NEW] -net user, hostfwd=... is not working(qemu-system-aarch64)
Public bug reported: QEMU version: git a46b3aaf6bb038d4f6f192a84df204f10929e75c /opt/qemu.git/bin/qemu-system-aarch64 --version QEMU emulator version 2.2.50, Copyright (c) 2003-2008 Fabrice Bellard Hosts: ovs - host machine (Ubuntu 14.04.1, x86_64) debian8-arm64 - guest Guest start: user@ovs:~$ /opt/qemu.git/bin/qemu-system-aarch64 -machine virt -cpu cortex-a57 -nographic -smp 1 -m 512 -kernel vmlinuz-run -initrd initrd-run.img -append root=/dev/sda2 console=ttyAMA0 -global virtio-blk-device.scsi=off -device virtio-scsi-device,id=scsi -drive file=debian8-arm64.img,id=rootimg,cache=unsafe,if=none -device scsi-hd,drive=rootimg -netdev user,id=unet -device virtio-net-device,netdev=unet -net user,hostfwd=tcp:127.0.0.1:1122-:22 root@debian8-arm64:~# netstat -ntplu | grep ssh tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN 410/sshd tcp6 0 0 :::22 :::*LISTEN 410/sshd (no firewall in guest vm) user@ovs:~$ netstat -ntplu | grep 1122 tcp0 0 127.0.0.1:1122 0.0.0.0:* LISTEN 18722/qemu-system-a user@ovs:~$ time ssh user@127.0.0.1 -p 1122 ssh_exchange_identification: read: Connection reset by peer real1m29.341s user0m0.005s sys 0m0.000s Inside guest vm sshd works fine: root@debian8-arm64:~# ssh user@127.0.0.1 -p 22 user@127.0.0.1's password: user@debian8-arm64:~$ exit logout Connection to 127.0.0.1 closed. root@debian8-arm64:~# ssh user@10.0.2.15 -p 22 user@10.0.2.15's password: ... user@debian8-arm64:~$ exit logout Connection to 10.0.2.15 closed. ** Affects: qemu Importance: Undecided Status: New ** Tags: hostfwd -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1414466 Title: -net user,hostfwd=... is not working(qemu-system-aarch64) Status in QEMU: New Bug description: QEMU version: git a46b3aaf6bb038d4f6f192a84df204f10929e75c /opt/qemu.git/bin/qemu-system-aarch64 --version QEMU emulator version 2.2.50, Copyright (c) 2003-2008 Fabrice Bellard Hosts: ovs - host machine (Ubuntu 14.04.1, x86_64) debian8-arm64 - guest Guest start: user@ovs:~$ /opt/qemu.git/bin/qemu-system-aarch64 -machine virt -cpu cortex-a57 -nographic -smp 1 -m 512 -kernel vmlinuz-run -initrd initrd-run.img -append root=/dev/sda2 console=ttyAMA0 -global virtio-blk-device.scsi=off -device virtio-scsi-device,id=scsi -drive file=debian8-arm64.img,id=rootimg,cache=unsafe,if=none -device scsi-hd,drive=rootimg -netdev user,id=unet -device virtio-net-device,netdev=unet -net user,hostfwd=tcp:127.0.0.1:1122-:22 root@debian8-arm64:~# netstat -ntplu | grep ssh tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN 410/sshd tcp6 0 0 :::22 :::*LISTEN 410/sshd (no firewall in guest vm) user@ovs:~$ netstat -ntplu | grep 1122 tcp0 0 127.0.0.1:1122 0.0.0.0:* LISTEN 18722/qemu-system-a user@ovs:~$ time ssh user@127.0.0.1 -p 1122 ssh_exchange_identification: read: Connection reset by peer real 1m29.341s user 0m0.005s sys 0m0.000s Inside guest vm sshd works fine: root@debian8-arm64:~# ssh user@127.0.0.1 -p 22 user@127.0.0.1's password: user@debian8-arm64:~$ exit logout Connection to 127.0.0.1 closed. root@debian8-arm64:~# ssh user@10.0.2.15 -p 22 user@10.0.2.15's password: ... user@debian8-arm64:~$ exit logout Connection to 10.0.2.15 closed. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1414466/+subscriptions
Re: [Qemu-devel] [PATCH 03/15] rcu: allow nesting of rcu_read_lock/rcu_read_unlock
On Thu, 01/22 15:47, Paolo Bonzini wrote:
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
include/qemu/rcu.h | 15 ++-
tests/rcutorture.c | 2 ++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/qemu/rcu.h b/include/qemu/rcu.h
index cfef36e..da043f2 100644
--- a/include/qemu/rcu.h
+++ b/include/qemu/rcu.h
@@ -68,6 +68,9 @@ struct rcu_reader_data {
unsigned long ctr;
bool waiting;
+/* Data used by reader only */
+unsigned depth;
+
/* Data used for registry, protected by rcu_gp_lock */
QLIST_ENTRY(rcu_reader_data) node;
};
@@ -77,8 +80,13 @@ extern __thread struct rcu_reader_data rcu_reader;
static inline void rcu_read_lock(void)
{
struct rcu_reader_data *p_rcu_reader = rcu_reader;
+unsigned ctr;
+
+if (p_rcu_reader-depth++ 0) {
+return;
+}
-unsigned ctr = atomic_read(rcu_gp_ctr);
+ctr = atomic_read(rcu_gp_ctr);
atomic_xchg(p_rcu_reader-ctr, ctr);
if (atomic_read(p_rcu_reader-waiting)) {
atomic_set(p_rcu_reader-waiting, false);
@@ -90,6 +98,11 @@ static inline void rcu_read_unlock(void)
{
struct rcu_reader_data *p_rcu_reader = rcu_reader;
+assert(p_rcu_reader-depth != 0);
+if (--p_rcu_reader-depth 0) {
+return;
+}
+
atomic_xchg(p_rcu_reader-ctr, 0);
if (atomic_read(p_rcu_reader-waiting)) {
atomic_set(p_rcu_reader-waiting, false);
diff --git a/tests/rcutorture.c b/tests/rcutorture.c
index 214985f..31461c3 100644
--- a/tests/rcutorture.c
+++ b/tests/rcutorture.c
@@ -257,9 +257,11 @@ static void *rcu_read_stress_test(void *arg)
if (p-mbtest == 0) {
n_mberror++;
}
+rcu_read_lock();
for (i = 0; i 100; i++) {
garbage++;
}
+rcu_read_unlock();
pc = p-pipe_count;
rcu_read_unlock();
if ((pc RCU_STRESS_PIPE_LEN) || (pc 0)) {
--
1.8.3.1
Reviewed-by: Fam Zheng f...@redhat.com
Re: [Qemu-devel] [PATCH 02/15] rcu: add rcutorture
On Thu, 01/22 15:47, Paolo Bonzini wrote: + +long long n_reads = 0LL; +long n_updates = 0L; +int nthreadsrunning; + +char argsbuf[64]; This seems unused. Overall the gtest enabled part looks good to me. Reviewed-by: Fam Zheng f...@redhat.com
Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
On Mon, 2015-01-26 at 04:25 +0100, Alexandre DERUMIER wrote: 2)when numa is used, the hotplugged cpu is always on numa node 0 (cpu_add or device_add cpu) About this, it seem to be a display bug in info numa, cpu is correctly assigned to numa node1 in the guest. Now in the guest, VCPUs are assigned round-robin. But in qemu, vcpus' property 'numa_node' was assigned the default value 0. We have made a patchset to solve this successfully. But we plan to send the patchset to the community later. Regards, Zhu - Mail original - De: aderumier aderum...@odiso.com À: Zhu Guihua zhugh.f...@cn.fujitsu.com Cc: qemu-devel qemu-devel@nongnu.org, tangc...@cn.fujitsu.com, guz fnst guz.f...@cn.fujitsu.com, isimatu yasuaki isimatu.yasu...@jp.fujitsu.com, Anshul Makkar anshul.mak...@profitbricks.com, chen fan fnst chen.fan.f...@cn.fujitsu.com, Igor Mammedov imamm...@redhat.com, afaerber afaer...@suse.de Envoyé: Lundi 26 Janvier 2015 04:19:52 Objet: Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support Thanks for your reply. 2 others things: 1) on cpu unplug, I see that the cpu is correctly removed from my linux guest but not from qemu starting with a guest with 3cpus: guest: #ls -lah /sys/devices/system/ |grep cpu drwxr-xr-x 6 root root 0 Jan 25 22:16 cpu0 drwxr-xr-x 6 root root 0 Jan 25 22:16 cpu1 drwxr-xr-x 6 root root 0 Jan 25 22:16 cpu2 hmp: # info cpus * CPU #0: pc=0x81057022 (halted) thread_id=24972 CPU #1: pc=0x81057022 (halted) thread_id=24973 CPU #2: pc=0x81048bc1 (halted) thread_id=25102 then unplug cpu2 hmp : device_del cpu2 guest: dmesg: [ 176.219754] Unregister pv shared memory for cpu 2 [ 176.278881] smpboot: CPU 2 is now offline #ls -lah /sys/devices/system/ |grep cpu drwxr-xr-x 6 root root 0 Jan 25 22:16 cpu0 drwxr-xr-x 6 root root 0 Jan 25 22:16 cpu1 hmp: # info cpus * CPU #0: pc=0x81057022 (halted) thread_id=24972 CPU #1: pc=0x81057022 (halted) thread_id=24973 CPU #2: pc=0x81048bc1 (halted) thread_id=25102 2)when numa is used, the hotplugged cpu is always on numa node 0 (cpu_add or device_add cpu) starting a guest, with 2 sockets,1 cores -smp 2,sockets=2,cores=1,maxcpus=2 -object memory-backend-ram,size=256M,id=ram-node0 -numa node,nodeid=0,cpus=0,memdev=ram-node0 -object memory-backend-ram,size=256M,id=ram-node1 -numa node,nodeid=1,cpus=1,memdev=ram-node1 hmp: # info numa 2 nodes node 0 cpus: 0 node 0 size: 256 MB node 1 cpus: 1 node 1 size: 256 MB ok now starting with same topology, but with 1cpu at start -smp 2,sockets=2,cores=1,maxcpus=2 -object memory-backend-ram,size=256M,id=ram-node0 -numa node,nodeid=0,cpus=0,memdev=ram-node0 -object memory-backend-ram,size=256M,id=ram-node1 -numa node,nodeid=1,cpus=1,memdev=ram-node1 # info numa 2 nodes node 0 cpus: 0 node 0 size: 256 MB node 1 cpus: node 1 size: 256 MB hotpluging a cpu # device_add kvm64-x86_64-cpu,apic-id=1,id=cpu1 # info numa 2 nodes node 0 cpus: 0 1 node 0 size: 256 MB node 1 cpus: node 1 size: 256 MB cpu1 should be on node1, not node0. Regards, Alexandre - Mail original - De: Zhu Guihua zhugh.f...@cn.fujitsu.com À: aderumier aderum...@odiso.com Cc: qemu-devel qemu-devel@nongnu.org, tangc...@cn.fujitsu.com, guz fnst guz.f...@cn.fujitsu.com, isimatu yasuaki isimatu.yasu...@jp.fujitsu.com, Anshul Makkar anshul.mak...@profitbricks.com, chen fan fnst chen.fan.f...@cn.fujitsu.com, Igor Mammedov imamm...@redhat.com, afaerber afaer...@suse.de Envoyé: Lundi 26 Janvier 2015 03:01:48 Objet: Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support On Fri, 2015-01-23 at 11:24 +0100, Alexandre DERUMIER wrote: Hello, I'm currently testing the new cpu unplug features, Works fine here with debian guests and kernel 3.14. Thanks for your test. But I have notice some small potential bugs, but I'm not sure I'm doing it right. 1)first, to unplug cpu, we need an id for cpu Yes, if you want to unplug cpu, you must have an id for cpu. The problem is that the current qemu command line -smp 1,sockets=2,cores=1,maxcpus=2 for example, will create 1 cpu on apic-id 0 without any id, so we can't unplug it. So, I have tried with -smp 1,sockets=2,cores=1,maxcpus=2 -device kvm64-x86_64-cpu,apic-id=0,id=cpu0 But this give me an error: -device kvm64-x86_64-cpu,apic-id=0,id=cpu0: CPU with APIC ID 0 exists APIC ID 0 was used by the cpu of '-smp 1'. So you should use apic-id=1 (also try to set -smp 0, but it's not working). 2) second problem, if I start with -smp 1,sockets=2,cores=1,maxcpus=2 then hmp: device_add kvm64-x86_64-cpu,apic-id=1,id=cpu1 then hmp : device_del cpu1 Got an error: This is the last
Re: [Qemu-devel] [PATCH 07/15] memory: avoid ref/unref in memory_region_find
On Thu, 01/22 15:47, Paolo Bonzini wrote:
Do the entire lookup under RCU, which avoids atomic operations.
address_space_get_flatview() already is RCU protected, I don't see why this
patch is necessary. Could you explain?
And there is one question below:
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
memory.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/memory.c b/memory.c
index a844ced..577e87c 100644
--- a/memory.c
+++ b/memory.c
@@ -1828,7 +1828,8 @@ MemoryRegionSection memory_region_find(MemoryRegion *mr,
}
range = addrrange_make(int128_make64(addr), int128_make64(size));
-view = address_space_get_flatview(as);
+rcu_read_lock();
+view = atomic_rcu_read(as-current_map);
fr = flatview_lookup(view, range);
if (!fr) {
flatview_unref(view);
Following lines are:
return ret;
}
Which requires a rcu_read_unlock.
Fam
@@ -1850,7 +1851,7 @@ MemoryRegionSection memory_region_find(MemoryRegion *mr,
ret.readonly = fr-readonly;
memory_region_ref(ret.mr);
-flatview_unref(view);
+rcu_read_unlock();
return ret;
}
--
1.8.3.1
Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
Thanks for your reply.
2 others things:
1)
on cpu unplug, I see that the cpu is correctly removed from my linux guest but
not from qemu
starting with a guest with 3cpus:
guest: #ls -lah /sys/devices/system/ |grep cpu
drwxr-xr-x 6 root root0 Jan 25 22:16 cpu0
drwxr-xr-x 6 root root0 Jan 25 22:16 cpu1
drwxr-xr-x 6 root root0 Jan 25 22:16 cpu2
hmp: # info cpus
* CPU #0: pc=0x81057022 (halted) thread_id=24972
CPU #1: pc=0x81057022 (halted) thread_id=24973
CPU #2: pc=0x81048bc1 (halted) thread_id=25102
then unplug cpu2
hmp : device_del cpu2
guest:
dmesg:
[ 176.219754] Unregister pv shared memory for cpu 2
[ 176.278881] smpboot: CPU 2 is now offline
#ls -lah /sys/devices/system/ |grep cpu
drwxr-xr-x 6 root root0 Jan 25 22:16 cpu0
drwxr-xr-x 6 root root0 Jan 25 22:16 cpu1
hmp: # info cpus
* CPU #0: pc=0x81057022 (halted) thread_id=24972
CPU #1: pc=0x81057022 (halted) thread_id=24973
CPU #2: pc=0x81048bc1 (halted) thread_id=25102
2)when numa is used, the hotplugged cpu is always on numa node 0
(cpu_add or device_add cpu)
starting a guest, with 2 sockets,1 cores
-smp 2,sockets=2,cores=1,maxcpus=2
-object memory-backend-ram,size=256M,id=ram-node0 -numa
node,nodeid=0,cpus=0,memdev=ram-node0
-object memory-backend-ram,size=256M,id=ram-node1 -numa
node,nodeid=1,cpus=1,memdev=ram-node1
hmp:
# info numa
2 nodes
node 0 cpus: 0
node 0 size: 256 MB
node 1 cpus: 1
node 1 size: 256 MB
ok
now
starting with same topology, but with 1cpu at start
-smp 2,sockets=2,cores=1,maxcpus=2
-object memory-backend-ram,size=256M,id=ram-node0 -numa
node,nodeid=0,cpus=0,memdev=ram-node0
-object memory-backend-ram,size=256M,id=ram-node1 -numa
node,nodeid=1,cpus=1,memdev=ram-node1
# info numa
2 nodes
node 0 cpus: 0
node 0 size: 256 MB
node 1 cpus:
node 1 size: 256 MB
hotpluging a cpu
# device_add kvm64-x86_64-cpu,apic-id=1,id=cpu1
# info numa
2 nodes
node 0 cpus: 0 1
node 0 size: 256 MB
node 1 cpus:
node 1 size: 256 MB
cpu1 should be on node1, not node0.
Regards,
Alexandre
- Mail original -
De: Zhu Guihua zhugh.f...@cn.fujitsu.com
À: aderumier aderum...@odiso.com
Cc: qemu-devel qemu-devel@nongnu.org, tangc...@cn.fujitsu.com, guz fnst
guz.f...@cn.fujitsu.com, isimatu yasuaki isimatu.yasu...@jp.fujitsu.com,
Anshul Makkar anshul.mak...@profitbricks.com, chen fan fnst
chen.fan.f...@cn.fujitsu.com, Igor Mammedov imamm...@redhat.com,
afaerber afaer...@suse.de
Envoyé: Lundi 26 Janvier 2015 03:01:48
Objet: Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
On Fri, 2015-01-23 at 11:24 +0100, Alexandre DERUMIER wrote:
Hello,
I'm currently testing the new cpu unplug features,
Works fine here with debian guests and kernel 3.14.
Thanks for your test.
But I have notice some small potential bugs, but I'm not sure I'm doing it
right.
1)first, to unplug cpu, we need an id for cpu
Yes, if you want to unplug cpu, you must have an id for cpu.
The problem is that the current qemu command line
-smp 1,sockets=2,cores=1,maxcpus=2
for example, will create 1 cpu on apic-id 0 without any id, so we can't
unplug it.
So, I have tried with
-smp 1,sockets=2,cores=1,maxcpus=2 -device kvm64-x86_64-cpu,apic-id=0,id=cpu0
But this give me an error:
-device kvm64-x86_64-cpu,apic-id=0,id=cpu0: CPU with APIC ID 0 exists
APIC ID 0 was used by the cpu of '-smp 1'.
So you should use apic-id=1
(also try to set -smp 0, but it's not working).
2) second problem, if I start with
-smp 1,sockets=2,cores=1,maxcpus=2
then hmp:
device_add kvm64-x86_64-cpu,apic-id=1,id=cpu1
then hmp : device_del cpu1
Got an error:
This is the last cpu, should not be removed!
Oh, it's our problem, thanks for your pointing out.
I will fix it in next version.
Regards,
Zhu
This is coming from
[PATCH 06/12] pc: add cpu hot unplug request callback support
+ if (smp_cpus == 1) {
+ error_setg(local_err,
+ This is the last cpu, should not be removed!);
+ goto out;
+ }
So, the only way unplug is working for me, is to start with -smp 2 minimum
-smp 2,sockets=2,cores=1,maxcpus=4
Then I can hotplug|unplug cpuid = 2
Regards,
Alexandre Derumier
[...]
Re: [Qemu-devel] [PATCH 06/15] memory: protect current_map by RCU
On Thu, 01/22 15:47, Paolo Bonzini wrote:
Replace the flat_view_mutex by RCU, avoiding futex contention for
dataplane on large systems and many iothreads.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
include/exec/memory.h | 5 +
memory.c | 54
++-
2 files changed, 28 insertions(+), 31 deletions(-)
diff --git a/include/exec/memory.h b/include/exec/memory.h
index 0cd96b1..06ffa1d 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -33,6 +33,7 @@
#include qemu/notify.h
#include qapi/error.h
#include qom/object.h
+#include qemu/rcu.h
#define MAX_PHYS_ADDR_SPACE_BITS 62
#define MAX_PHYS_ADDR(((hwaddr)1 MAX_PHYS_ADDR_SPACE_BITS) -
1)
@@ -207,9 +208,13 @@ struct MemoryListener {
*/
struct AddressSpace {
/* All fields are private. */
+struct rcu_head rcu;
char *name;
MemoryRegion *root;
+
+/* Accessed via RCU. */
struct FlatView *current_map;
+
int ioeventfd_nb;
struct MemoryRegionIoeventfd *ioeventfds;
struct AddressSpaceDispatch *dispatch;
diff --git a/memory.c b/memory.c
index 8c3d8c0..a844ced 100644
--- a/memory.c
+++ b/memory.c
@@ -33,26 +33,12 @@ static bool memory_region_update_pending;
static bool ioeventfd_update_pending;
static bool global_dirty_log = false;
-/* flat_view_mutex is taken around reading as-current_map; the critical
- * section is extremely short, so I'm using a single mutex for every AS.
- * We could also RCU for the read-side.
- *
- * The BQL is taken around transaction commits, hence both locks are taken
- * while writing to as-current_map (with the BQL taken outside).
- */
-static QemuMutex flat_view_mutex;
-
static QTAILQ_HEAD(memory_listeners, MemoryListener) memory_listeners
= QTAILQ_HEAD_INITIALIZER(memory_listeners);
static QTAILQ_HEAD(, AddressSpace) address_spaces
= QTAILQ_HEAD_INITIALIZER(address_spaces);
-static void memory_init(void)
-{
-qemu_mutex_init(flat_view_mutex);
-}
-
typedef struct AddrRange AddrRange;
/*
@@ -242,6 +228,7 @@ struct FlatRange {
* order.
*/
struct FlatView {
+struct rcu_head rcu;
unsigned ref;
FlatRange *ranges;
unsigned nr;
@@ -654,10 +641,10 @@ static FlatView
*address_space_get_flatview(AddressSpace *as)
{
FlatView *view;
-qemu_mutex_lock(flat_view_mutex);
-view = as-current_map;
+rcu_read_lock();
+view = atomic_rcu_read(as-current_map);
flatview_ref(view);
-qemu_mutex_unlock(flat_view_mutex);
+rcu_read_unlock();
return view;
}
@@ -766,10 +753,9 @@ static void address_space_update_topology(AddressSpace
*as)
address_space_update_topology_pass(as, old_view, new_view, false);
address_space_update_topology_pass(as, old_view, new_view, true);
-qemu_mutex_lock(flat_view_mutex);
-flatview_unref(as-current_map);
-as-current_map = new_view;
-qemu_mutex_unlock(flat_view_mutex);
+/* Writes are protected by the BQL. */
+atomic_rcu_set(as-current_map, new_view);
+call_rcu(old_view, flatview_unref, rcu);
/* Note that all the old MemoryRegions are still alive up to this
* point. This relieves most MemoryListeners from the need to
@@ -1957,10 +1943,6 @@ void memory_listener_unregister(MemoryListener
*listener)
void address_space_init(AddressSpace *as, MemoryRegion *root, const char
*name)
{
-if (QTAILQ_EMPTY(address_spaces)) {
-memory_init();
-}
-
memory_region_transaction_begin();
as-root = root;
as-current_map = g_new(FlatView, 1);
@@ -1974,15 +1956,10 @@ void address_space_init(AddressSpace *as,
MemoryRegion *root, const char *name)
memory_region_transaction_commit();
}
-void address_space_destroy(AddressSpace *as)
+static void do_address_space_destroy(AddressSpace *as)
{
MemoryListener *listener;
-/* Flush out anything from MemoryListeners listening in on this */
-memory_region_transaction_begin();
-as-root = NULL;
-memory_region_transaction_commit();
-QTAILQ_REMOVE(address_spaces, as, address_spaces_link);
address_space_destroy_dispatch(as);
QTAILQ_FOREACH(listener, memory_listeners, link) {
@@ -1994,6 +1971,21 @@ void address_space_destroy(AddressSpace *as)
g_free(as-ioeventfds);
}
+void address_space_destroy(AddressSpace *as)
+{
+/* Flush out anything from MemoryListeners listening in on this */
+memory_region_transaction_begin();
+as-root = NULL;
+memory_region_transaction_commit();
+QTAILQ_REMOVE(address_spaces, as, address_spaces_link);
+
+/* At this point, as-dispatch and as-current_map are dummy
+ * entries that the guest should never use. Wait for the old
+ * values to expire before freeing the data.
+ */
+call_rcu(as, do_address_space_destroy, rcu);
+}
+
[Qemu-devel] [PATCH] linux-user/syscall.c: Let all lock_user_struct() and unlock_user_struct() paired with each other
lock_user_struct() and unlock_user_struct() need always be paired with
each other, or will cause resource leak.
Also remove redundant check for 'target_mb' in abi_long do_msgrcv().
Also match the coding styles found by ./scripts/checkpatch.pl.
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
linux-user/syscall.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index ec9e4fc..b2da432 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -2518,8 +2518,10 @@ static inline abi_long target_to_host_semid_ds(struct
semid_ds *host_sd,
if (!lock_user_struct(VERIFY_READ, target_sd, target_addr, 1))
return -TARGET_EFAULT;
-if (target_to_host_ipc_perm((host_sd-sem_perm),target_addr))
+if (target_to_host_ipc_perm((host_sd-sem_perm), target_addr)) {
+unlock_user_struct(target_sd, target_addr, 0);
return -TARGET_EFAULT;
+}
host_sd-sem_nsems = tswapal(target_sd-sem_nsems);
host_sd-sem_otime = tswapal(target_sd-sem_otime);
host_sd-sem_ctime = tswapal(target_sd-sem_ctime);
@@ -2534,8 +2536,10 @@ static inline abi_long host_to_target_semid_ds(abi_ulong
target_addr,
if (!lock_user_struct(VERIFY_WRITE, target_sd, target_addr, 0))
return -TARGET_EFAULT;
-if (host_to_target_ipc_perm(target_addr,(host_sd-sem_perm)))
+if (host_to_target_ipc_perm(target_addr, (host_sd-sem_perm))) {
+unlock_user_struct(target_sd, target_addr, 0);
return -TARGET_EFAULT;
+}
target_sd-sem_nsems = tswapal(host_sd-sem_nsems);
target_sd-sem_otime = tswapal(host_sd-sem_otime);
target_sd-sem_ctime = tswapal(host_sd-sem_ctime);
@@ -2796,8 +2800,10 @@ static inline abi_long target_to_host_msqid_ds(struct
msqid_ds *host_md,
if (!lock_user_struct(VERIFY_READ, target_md, target_addr, 1))
return -TARGET_EFAULT;
-if (target_to_host_ipc_perm((host_md-msg_perm),target_addr))
+if (target_to_host_ipc_perm((host_md-msg_perm), target_addr)) {
+unlock_user_struct(target_md, target_addr, 0);
return -TARGET_EFAULT;
+}
host_md-msg_stime = tswapal(target_md-msg_stime);
host_md-msg_rtime = tswapal(target_md-msg_rtime);
host_md-msg_ctime = tswapal(target_md-msg_ctime);
@@ -2817,8 +2823,10 @@ static inline abi_long host_to_target_msqid_ds(abi_ulong
target_addr,
if (!lock_user_struct(VERIFY_WRITE, target_md, target_addr, 0))
return -TARGET_EFAULT;
-if (host_to_target_ipc_perm(target_addr,(host_md-msg_perm)))
+if (host_to_target_ipc_perm(target_addr, (host_md-msg_perm))) {
+unlock_user_struct(target_md, target_addr, 0);
return -TARGET_EFAULT;
+}
target_md-msg_stime = tswapal(host_md-msg_stime);
target_md-msg_rtime = tswapal(host_md-msg_rtime);
target_md-msg_ctime = tswapal(host_md-msg_ctime);
@@ -2953,8 +2961,7 @@ static inline abi_long do_msgrcv(int msqid, abi_long msgp,
target_mb-mtype = tswapal(host_mb-mtype);
end:
-if (target_mb)
-unlock_user_struct(target_mb, msgp, 1);
+unlock_user_struct(target_mb, msgp, 1);
g_free(host_mb);
return ret;
}
@@ -2966,8 +2973,10 @@ static inline abi_long target_to_host_shmid_ds(struct
shmid_ds *host_sd,
if (!lock_user_struct(VERIFY_READ, target_sd, target_addr, 1))
return -TARGET_EFAULT;
-if (target_to_host_ipc_perm((host_sd-shm_perm), target_addr))
+if (target_to_host_ipc_perm((host_sd-shm_perm), target_addr)) {
+unlock_user_struct(target_sd, target_addr, 0);
return -TARGET_EFAULT;
+}
__get_user(host_sd-shm_segsz, target_sd-shm_segsz);
__get_user(host_sd-shm_atime, target_sd-shm_atime);
__get_user(host_sd-shm_dtime, target_sd-shm_dtime);
@@ -2986,8 +2995,10 @@ static inline abi_long host_to_target_shmid_ds(abi_ulong
target_addr,
if (!lock_user_struct(VERIFY_WRITE, target_sd, target_addr, 0))
return -TARGET_EFAULT;
-if (host_to_target_ipc_perm(target_addr, (host_sd-shm_perm)))
+if (host_to_target_ipc_perm(target_addr, (host_sd-shm_perm))) {
+unlock_user_struct(target_sd, target_addr, 0);
return -TARGET_EFAULT;
+}
__put_user(host_sd-shm_segsz, target_sd-shm_segsz);
__put_user(host_sd-shm_atime, target_sd-shm_atime);
__put_user(host_sd-shm_dtime, target_sd-shm_dtime);
--
1.9.3
Re: [Qemu-devel] [PATCH] linux-user/main.c: Use TARGET_SIG* instead of SIG*
On 25 January 2015 at 11:35, Chen Gang S gang.c...@sunrus.com.cn wrote: In main.c, all SIG* need be change to TARGET_SIG*, since the related next call are all for TARGET_SIG*: queue_signal() and gdb_handlesig(). The related vi operation command is 1,$ s/\SIG/TARGET_SIG/g. Signed-off-by: Chen Gang gang.chen.5...@gmail.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org thanks -- PMM
Re: [Qemu-devel] [PATCH v2] linux-user/syscall.c: Need call unlock_user() before go to failure return in default case
On 25 January 2015 at 00:00, Chen Gang S gang.c...@sunrus.com.cn wrote: In abi_long do_ioctl_dm(), after calls lock_user(), it does not call unlock_user() before go to failure return in default case. Signed-off-by: Chen Gang gang.chen.5...@gmail.com --- linux-user/syscall.c | 2 ++ 1 file changed, 2 insertions(+) -- Reviewed-by: Peter Maydell peter.mayd...@linaro.org thanks -- PMM
[Qemu-devel] Download Qemu guest IOS image for gns3
Gns3 Labs shared a post with you on Google+. Google+ makes sharing on the web more like sharing in real life.Learn more: http://www.google.com/+/learnmore/ You have received this message because Gns3 Labs shared it with qemu-devel@nongnu.org. Accept the invitation to view the full post: https://plus.google.com/_/notifications/emlink?emr=08970316646201314043emid=COjq4sGNr8MCFdQZQgod-kcAAQpath=%2F107764530989109519583%2Fposts%2F3eiqWZCnAFu%3Fgpinv%3DAMIXal-aYJ8UQPRNqXI1bBJAzmzmBmMdNgxHPzDrGG1v3aYy2fyUD5PGUIE_aHEAGxNlAKEIUarTqncFlRp3MjITy0izAvPc3kKLw-fzPwGTr-4siwAZqeEdt=1422187558391ub=STREAM_SHARE_OFFNETWORKuob=8 You have received this message because Gns3 Labs shared it with qemu-devel@nongnu.org. Click here to unsubscribe from these emails: https://plus.google.com/_/notifications/emlink?emr=08970316646201314043emid=COjq4sGNr8MCFdQZQgod-kcAAQpath=%2F_%2Fnonplus%2Femailsettings%3Fgpinv%3DAMIXal-aYJ8UQPRNqXI1bBJAzmzmBmMdNgxHPzDrGG1v3aYy2fyUD5PGUIE_aHEAGxNlAKEIUarTqncFlRp3MjITy0izAvPc3kKLw-fzPwGTr-4siwAZqeE%26est%3DADH5u8UjkpwraOg34LAXstEI_4oijXB23CezbWtN1V9nA3wJVC-H7vtphC3HmCTGvmSsM1hi5VT30-6RB4XVOtUkvCoOOm06msL0Pt6dsQsDBGevpvfmKTkAvoNlYI-HJ_F7SXUH5J7e66rHGODb9aShXKTPSfHeUQdt=1422187558391ub=STREAM_SHARE_OFFNETWORKuob=8
Re: [Qemu-devel] [PATCH] linux-user/syscall.c: Let all lock_user_struct() and unlock_user_struct() paired with each other
On 1/25/15 20:49, Peter Maydell wrote: On 25 January 2015 at 12:06, Chen Gang S gang.c...@sunrus.com.cn wrote: lock_user_struct() and unlock_user_struct() need always be paired with each other, or will cause resource leak. Also remove redundant check for 'target_mb' in abi_long do_msgrcv(). Also match the coding styles found by ./scripts/checkpatch.pl. Signed-off-by: Chen Gang gang.chen.5...@gmail.com Reviewed-by: Peter Maydell peter.mayd...@linaro.org Thank you for your work about the several patches. Are you claiming that you've reviewed *all* the code in this file for mismatched lock/unlock calls? If so, it would be nice to say so explicitly in the commit message. If not, it would be nice if the commit message was clearer about what areas of the code it applied to. The code changes are correct, though. At present, I finished all lock_user_struct() and unlock_user_struct() in linux-user/syscall.c. For me, after this patch, they are all OK. But for all lock/unlock in linux-user/syscall.c, for me, I am doubting several areas, but I did not send patch for them: - I need check them carefully again to be sure they are really issue: Read the related code again and again, if I really treat it as an issue, I shall make related patch (and pass compiling, at least). - I have no enough time resources on it: In week end, I have to spend some time resource on my son (check his homework, play with him). I also need spend time resources on Linux kernel and gcc/binutils. In week day, I may work overtime sometimes, also I need spend 4 hours on subway between my home and office per day (come and go). - So it is really necessary for me to make a schedule (the tasks/steps, the time point, and the risks), and also need consider about: How to use the time resources efficiently: e.g. fully use the time resources on the subway between home and office, in work day; fully use the time resources on holidays (e.g. Chinese Spring Festival). How to fully use the human resources: e.g. try my best to always keep well communication with all related open source members (which will give much valuable help for the related tasks). Welcome any members' ideas, suggestions, and completions, also welcome any members to help check linux-user/syscall.c (it will save my time resource: now for qemu, my highest priority task is for tile qemu). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
Re: [Qemu-devel] [PATCH] linux-user/syscall.c: Let all lock_user_struct() and unlock_user_struct() paired with each other
On 25 January 2015 at 21:59, Chen Gang S gang.c...@sunrus.com.cn wrote: On 1/25/15 20:49, Peter Maydell wrote: Are you claiming that you've reviewed *all* the code in this file for mismatched lock/unlock calls? If so, it would be nice to say so explicitly in the commit message. If not, it would be nice if the commit message was clearer about what areas of the code it applied to. The code changes are correct, though. At present, I finished all lock_user_struct() and unlock_user_struct() in linux-user/syscall.c. For me, after this patch, they are all OK. But for all lock/unlock in linux-user/syscall.c, for me, I am doubting several areas, but I did not send patch for them: - I need check them carefully again to be sure they are really issue: Read the related code again and again, if I really treat it as an issue, I shall make related patch (and pass compiling, at least). - I have no enough time resources on it: That's fine. I'm definitely not asking you to do this work. I would just like the commit message to be clear about the scope of the work the patch covers. If the patch is just Fix mismatched lock/unlock calls in IPC struct conversion functions then that's fine, but the commit message should say that. At the moment the commit message is very vague. thanks -- PMM
Re: [Qemu-devel] [RFC][PATCH 1/1] libxl: add one machine property to support IGD GFX passthrough
On 2015/1/23 8:43, Chen, Tiejun wrote: On 2015/1/22 8:51, Chen, Tiejun wrote: On 2015/1/21 21:48, Gerd Hoffmann wrote: On Mi, 2015-01-21 at 11:37 +, Ian Jackson wrote: Tiejun Chen writes ([RFC][PATCH 1/1] libxl: add one machine property to support IGD GFX passthrough): When we're working to support IGD GFX passthrough with qemu upstream, instead of -gfx_passthru we'd like to make that a machine option, -machine xxx,gfx_passthru=on. This need to bring several changes on tool side. Has the corresponding patch to qemu-upstream been accepted yet ? I'd like to see a confirmation from the qemu side that this is going into their tree and that the command-line option syntax has been agreed. Suggested at patch review, not merged (guess thats why it is tagged 'rfc', to get both qemu+xen on the same page). Yeah, this is exactly what I intended to do here :) While being at it: Should we name this 'igd-passthru' instead of 'gfx-passthru'? The hostbridge / isabridge quirks needed are actually specific to igd and are not needed for -- say -- nvidia gfx cards. At this point I just concern here if we still use 'gfx_passthrou', at least it may look like a backward compatibility with older versions of qemu in Xen side, qemu-xen-traditional. But I'd like to follow your final option. Any feedback to this option I should follow here? Ping... Thanks Tiejun
[Qemu-devel] Fwd: Fwd: [Qemu-discuss] wrong command on snapshot wiki
I am not 100% sure whether this is the right place to raise this issue. Maybe you can forward this to right person | I have the feeling this wikipage http://wiki.qemu.org/Documentation/CreateSnapshot is wrong. I think the decription and the posted command for creating snapshots [||qemu-img create -f qcow2 -b centos-cleaninstall.img snapshot.img|] |is actually describing copy-on-write (or overlay) images. And I think this is not the same thing |||As far as I know such a command would creat a copy-on-write image and not a snapshot|. On the german debianforum.de I got another suggestion to vreate snaptshots which I have not tested yet, but sounds more likely to be correct to me qemu-img snapshot -c [snapshot_name] [base_name] |
Re: [Qemu-devel] [PATCH] vfio: fix wrong initialize vfio_group_list
CC: qemu-triv...@nongnu.org On 01/22/2015 04:14 PM, Eric Auger wrote: Hi Chen, thanks for correcting this mistake I introduced when moving code from pci to common. so, can you check in this patch? Thanks, Chen Best Regards Eric On 01/22/2015 04:50 AM, Chen Fan wrote: Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com --- hw/vfio/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/vfio/common.c b/hw/vfio/common.c index cf483ff..e71385e 100644 --- a/hw/vfio/common.c +++ b/hw/vfio/common.c @@ -32,7 +32,7 @@ #include trace.h struct vfio_group_head vfio_group_list = -QLIST_HEAD_INITIALIZER(vfio_address_spaces); +QLIST_HEAD_INITIALIZER(vfio_group_list); struct vfio_as_head vfio_address_spaces = QLIST_HEAD_INITIALIZER(vfio_address_spaces);
Re: [Qemu-devel] [RFC PATCH 07/11] hw/arm/virt-acpi-build: Generate FADT table and update ACPI headers
On 2015/1/25 6:05, Laszlo Ersek wrote:
comments below
On 01/24/15 10:21, Shannon Zhao wrote:
FADT points to FACS and DSDT, in the case of mach virt, it is also used
to set the Hardware Reduced bit and enable PSCI SMP booting through HVC.
Update the header definitions for FADT taking into account the new
additions of ACPI v5.1 in `include/hw/acpi/acpi-defs.h`
Signed-off-by: Shannon Zhao zhaoshengl...@huawei.com
---
hw/arm/virt-acpi-build.c| 26 ++
include/hw/acpi/acpi-defs.h | 114
+--
2 files changed, 103 insertions(+), 37 deletions(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 2872dff..e3c708d 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -218,6 +218,32 @@ build_gtdt(GArray *table_data, GArray *linker,
VirtGuestInfo *guest_info)
static void
build_fadt(GArray *table_data, GArray *linker, uint64_t facs, uint64_t dsdt)
{
+AcpiFadtDescriptorRev5_1 *fadt = acpi_data_push(table_data,
sizeof(*fadt));
+
+/* Hardware Reduced = 1 and use PSCI 0.2+ and with HVC */
You set Hardware Reduced here.
+fadt-flags = cpu_to_le32(1 ACPI_FADT_F_HW_REDUCED_ACPI);
+fadt-arm_boot_flags = cpu_to_le16((1 ACPI_FADT_ARM_USE_PSCI_G_0_2) |
+ (1 ACPI_FADT_ARM_PSCI_USE_HVC));
+
+/* ACPI v5.1 (fadt-revision.fadt-minor_revision) */
+fadt-minor_revision = 0x1;
+
+fadt-Xfacs = cpu_to_le64(facs);
But you also set up a FACS table.
Hardware Reduced mode makes Linux ignore the FACS table. Please see
upstream kernel commit
commit 22e5b40ab21fcac21db0ff25fbb844ffecc73a4a
Author: Bob Moore robert.mo...@intel.com
Date: Wed Nov 16 10:57:28 2011 +0800
ACPI 5.0: Implement hardware-reduced option
You can probably drop the generation of the FACS, unless you intend to
disable HW reduced mode.
Ok, Thanks for pointing this out :-)
I think we should drop the FACS to make it simple.
Thanks,
Shannon
Re: [Qemu-devel] [RFC PATCH 04/11] hw/arm/virt-acpi-build: Generate XSDT table and add a build_header function
On 2015/1/25 6:04, Laszlo Ersek wrote:
comments below, fix attached
On 01/24/15 10:21, Shannon Zhao wrote:
XDST points to other tables except FACS DSDT.
Implement a common header helper functions for generating ACPI tables.
Signed-off-by: Shannon Zhao zhaoshengl...@huawei.com
---
hw/arm/virt-acpi-build.c| 34 ++
include/hw/acpi/acpi-defs.h |9 +
2 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 9c3971a..446947a 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -61,6 +61,22 @@
#define ACPI_BUILD_RSDP_FILE etc/acpi/rsdp
#define ACPI_BUILD_TPMLOG_FILE etc/tpm/log
+static void
+build_header(GArray *linker, GArray *table_data,
+ AcpiTableHeader *h, const char *sig, int len, uint8_t rev)
+{
+memcpy(h-signature, sig, sizeof(h-signature));
+h-length = cpu_to_le32(len);
+h-revision = rev;
+memcpy(h-oem_id, ACPI_VIRT_QEMU_STR_6, sizeof(h-oem_id));
+memcpy(h-oem_table_id, ACPI_VIRT_MACH_STR_8, sizeof(h-oem_table_id));
+h-oem_revision = cpu_to_le32(1);
+h-checksum = 0;
+/* Checksum to be filled in by Guest linker */
+bios_linker_loader_add_checksum(linker, ACPI_BUILD_TABLE_FILE,
+table_data-data, h, len, h-checksum);
+}
+
static inline void *acpi_data_push(GArray *table_data, uint64_t size)
{
unsigned off = table_data-len;
@@ -115,6 +131,24 @@ build_rsdp(GArray *rsdp_table, GArray *linker, uint64_t
xsdt)
static void
build_xsdt(GArray *table_data, GArray *linker, GArray *table_offsets)
{
+AcpiXsdtDescriptor *xsdt;
+size_t xsdt_len;
+int i;
+
+xsdt_len = sizeof(*xsdt) + sizeof(uint64_t) * table_offsets-len;
+xsdt = acpi_data_push(table_data, xsdt_len);
+memcpy(xsdt-table_offset_entry, table_offsets-data,
+ sizeof(uint64_t) * table_offsets-len);
This is a bug, but it's not introduced here. The bug is introduced in:
[RFC PATCH 02/11] hw/arm/virt-acpi-build: Basic framework for
building ACPI tables
I'm attaching the fix.
Greate, thanks. Will fix this at next version.
Please do not squash the fix into this patch; you have to split it up.
The code fixes go into 02/11, and the typo fix goes:
+for (i = 0; i table_offsets-len; ++i) {
+/* rsdt-table_offset_entry to be filled by Guest linker */
here.
Ok
Re: [Qemu-devel] [PATCH v2 00/11] cpu: add i386 cpu hot remove support
On Fri, 2015-01-23 at 11:24 +0100, Alexandre DERUMIER wrote:
Hello,
I'm currently testing the new cpu unplug features,
Works fine here with debian guests and kernel 3.14.
Thanks for your test.
But I have notice some small potential bugs, but I'm not sure I'm doing it
right.
1)first, to unplug cpu, we need an id for cpu
Yes, if you want to unplug cpu, you must have an id for cpu.
The problem is that the current qemu command line
-smp 1,sockets=2,cores=1,maxcpus=2
for example, will create 1 cpu on apic-id 0 without any id, so we can't
unplug it.
So, I have tried with
-smp 1,sockets=2,cores=1,maxcpus=2 -device kvm64-x86_64-cpu,apic-id=0,id=cpu0
But this give me an error:
-device kvm64-x86_64-cpu,apic-id=0,id=cpu0: CPU with APIC ID 0 exists
APIC ID 0 was used by the cpu of '-smp 1'.
So you should use apic-id=1
(also try to set -smp 0, but it's not working).
2) second problem, if I start with
-smp 1,sockets=2,cores=1,maxcpus=2
then hmp:
device_add kvm64-x86_64-cpu,apic-id=1,id=cpu1
then hmp : device_del cpu1
Got an error:
This is the last cpu, should not be removed!
Oh, it's our problem, thanks for your pointing out.
I will fix it in next version.
Regards,
Zhu
This is coming from
[PATCH 06/12] pc: add cpu hot unplug request callback support
+if (smp_cpus == 1) {
+error_setg(local_err,
+ This is the last cpu, should not be removed!);
+goto out;
+}
So, the only way unplug is working for me, is to start with -smp 2 minimum
-smp 2,sockets=2,cores=1,maxcpus=4
Then I can hotplug|unplug cpuid = 2
Regards,
Alexandre Derumier
[...]
Re: [Qemu-devel] [question] incremental backup a running vm
On 2015-01-23 07:30:19, Kashyap Chamarthy wrote:
On Wed, Jan 21, 2015 at 11:39:44AM +0100, Paolo Bonzini wrote:
On 21/01/2015 11:32, Zhang Haoyu wrote:
Hi,
Does drive_mirror support incremental backup a running vm?
Or other mechanism does?
incremental backup a running vm requirements:
First time backup, all of the allocated data will be mirrored to
destination,
then a copied bitmap will be saved to a file, then the bitmap file will
log dirty for
the changed data.
Next time backup, only the dirty data will be mirrored to destination.
Even the VM shutdown and start after several days,
the bitmap will be loaded while starting vm.
Any ideas?
Drive-mirror is for storage migration. For backup there is another job,
drive-backup. drive-backup copies a point-in-time snapshot of one or
more disks corresponding to when the backup was started.
Zhang, I've been testing the `drive-backup` command via QMP for a little
while, and it works reasonably well. If you'd like to test it you can
quickly try as below, once you have a QEMU instance runing with QMP
(I invoke my QEMU instances with '-qmp tcp:localhost:,server').
Hi, Kashyap
I've tried ‘drive_backup’ via QMP,
but the snapshots were missed to backup to destination,
I think the reason is that backup_run() only copy the
guest data regarding qcow2 image.
Thanks,
Zhang Haoyu
The below script invokes the 'drive-backup' QMP command (Ensure you're
using the correct disk, your disk ID might be 'drive-virtio-disk1' :-) )
-
#!/bin/bash
set -x
exec 3/dev/tcp/localhost/
echo -e { 'execute': 'qmp_capabilities' } 3
read response 3
echo $response
echo -e { 'execute': 'drive-backup', 'arguments':
{ 'device': 'drive-virtio-disk0', 'sync': 'full', 'target':
'/export/backup-of-vm1.qcow2', 'mode': 'absolute-paths', 'format':
'qcow2' } } 3
read response 3
echo $response
-
Once the above is invoked succesfully, you can see the success of the
command on the shell where your QMP server is running:
-
[. . .]
char device redirected to /dev/pts/8 (label charserial0)
QEMU waiting for connection on: disconnected:tcp:localhost:,server
Formatting '/export/backup-of-vm1.qcow2', fmt=qcow2 size=53687091200
encryption=off cluster_size=65536 lazy_refcounts=off
-
Incremental backup is being worked on. You can see patches on the list.
--
/kashyap
Re: [Qemu-devel] [RFC PATCH 09/11] hw/acpi/acpi-build-utils: Add acpi_fixed_memory32() and acpi_extended_irq()
Hi MST,
Thanks for your review :-) Reply below.
On 2015/1/25 16:39, Michael S. Tsirkin wrote:
On Sat, Jan 24, 2015 at 05:21:18PM +0800, Shannon Zhao wrote:
Add acpi_fixed_memory32() for describing device mmio region in resource
template.
Add acpi_extended_irq() for describing device interrupt in resource template.
These can be used to generating DSDT table for ACPI on ARM.
Signed-off-by: Shannon Zhao zhaoshengl...@huawei.com
---
hw/acpi/acpi-build-utils.c | 42
include/hw/acpi/acpi-build-utils.h |2 +
2 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/hw/acpi/acpi-build-utils.c b/hw/acpi/acpi-build-utils.c
index 59873e3..211c4d3 100644
--- a/hw/acpi/acpi-build-utils.c
+++ b/hw/acpi/acpi-build-utils.c
@@ -493,6 +493,48 @@ AcpiAml acpi_call4(const char *method, AcpiAml arg1,
AcpiAml arg2,
}
/*
+ * ACPI 5.1: 19.5.80 Memory32Fixed (Memory Resource Descriptor Macro)
Pls document the first spec which includes a feature, not the last one.
Ok, thanks, will fix :-)
+ * 6.4.2 Small Resource Data Type
So add API for small resource data type?
Will fix.
+ */
+AcpiAml acpi_fixed_memory32(uint64_t addr, uint64_t size, uint8_t rw_flag)
so name it memory32_fixed?
Good idea
+{
+AcpiAml var = aml_allocate_internal(0, NON_BLOCK);
+build_append_byte(var.buf, 0x86); /* Extended irq descriptor */
+build_append_byte(var.buf, 9);
+build_append_byte(var.buf, 0);
+build_append_byte(var.buf, rw_flag);
+build_append_byte(var.buf, addr 0xff);
+build_append_byte(var.buf, (addr 8) 0xff);
+build_append_byte(var.buf, (addr 16) 0xff);
+build_append_byte(var.buf, (addr 24) 0xff);
+
+build_append_byte(var.buf, size 0xff);
+build_append_byte(var.buf, (size 8) 0xff);
+build_append_byte(var.buf, (size 16) 0xff);
+build_append_byte(var.buf, (size 24) 0xff);
+return var;
+}
+
+/*
+ * ACPI 5.1: 19.5.61 Interrupt (Interrupt Resource Descriptor Macro)
+ * 6.4.2 Small Resource Data Type
+ */
+AcpiAml acpi_extended_irq(uint8_t irq_flags, int irq)
So acpi_interrupt?
Ok
+{
+AcpiAml var = aml_allocate_internal(0, NON_BLOCK);
+build_append_byte(var.buf, 0x89); /* Extended irq descriptor */
+build_append_byte(var.buf, 6);
+build_append_byte(var.buf, 0);
+build_append_byte(var.buf, irq_flags);
+build_append_byte(var.buf, 0x01);
+build_append_byte(var.buf, irq 0xff);
+build_append_byte(var.buf, (irq 8) 0xff);
+build_append_byte(var.buf, (irq 16) 0xff);
+build_append_byte(var.buf, (irq 24) 0xff);
+return var;
Pls add comments to document opcode constants.
Will add next version.
+}
+
+/*
* ACPI 5.0: 19.5.62 IO (IO Resource Descriptor Macro)
* 6.4.2 Small Resource Data Type
*/
diff --git a/include/hw/acpi/acpi-build-utils.h
b/include/hw/acpi/acpi-build-utils.h
index d39b5b1..bfed546 100644
--- a/include/hw/acpi/acpi-build-utils.h
+++ b/include/hw/acpi/acpi-build-utils.h
@@ -115,6 +115,8 @@ AcpiAml acpi_call3(const char *method, AcpiAml arg1,
AcpiAml arg2,
AcpiAml arg3);
AcpiAml acpi_call4(const char *method, AcpiAml arg1, AcpiAml arg2,
AcpiAml arg3, AcpiAml arg4);
+AcpiAml acpi_fixed_memory32(uint64_t addr, uint64_t size, uint8_t rw_flag);
+AcpiAml acpi_extended_irq(uint8_t irq_flags, int irq);
AcpiAml acpi_io(acpiIODecode dec, uint16_t min_base, uint16_t max_base,
uint8_t aln, uint8_t len);
AcpiAml acpi_iqr_no_flags(uint8_t irq);
--
1.7.1
.
Re: [Qemu-devel] [RFC PATCH 11/11] hw/arm/virt: Enable dynamic generation of ACPI v5.1 tables
On 2015/1/25 2:56, Laszlo Ersek wrote: On 01/24/15 10:21, Shannon Zhao wrote: Expose the needed device information to the table generation insfrastructure and register a machine_init_done notify to call virt_acpi_build(). Add CONFIG_ACPI to arm-softmmu.mak, but there is compile error. Don't include unnecessary file for ARM. Maybe this way is not right, fix me please. Signed-off-by: Shannon Zhao zhaoshengl...@huawei.com --- default-configs/arm-softmmu.mak |1 + default-configs/i386-softmmu.mak |3 ++ default-configs/mips-softmmu.mak |3 ++ default-configs/mips64-softmmu.mak |3 ++ default-configs/mips64el-softmmu.mak |3 ++ default-configs/mipsel-softmmu.mak |3 ++ default-configs/x86_64-softmmu.mak |3 ++ hw/acpi/Makefile.objs|5 ++- hw/arm/virt.c| 59 +++-- hw/i2c/Makefile.objs |2 +- 10 files changed, 78 insertions(+), 7 deletions(-) diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs index cad0355..4e3f15f 100644 --- a/hw/acpi/Makefile.objs +++ b/hw/acpi/Makefile.objs @@ -1,5 +1,6 @@ -common-obj-$(CONFIG_ACPI) += core.o piix4.o ich9.o pcihp.o cpu_hotplug.o -common-obj-$(CONFIG_ACPI) += memory_hotplug.o +common-obj-$(CONFIG_ACPI_CORE) += core.o piix4.o ich9.o pcihp.o +common-obj-$(CONFIG_ACPI_HOTPLUG) += cpu_hotplug.o This line has a typo and it breaks the linking of qemu-system-x86_64. You need to say CONFIG_ACPI_CPU_HOTPLUG here, not CONFIG_ACPI_HOTPLUG Laszlo, Thanks. Will fix this. Thanks, Shannon
Re: [Qemu-devel] [PATCH] vfio: fix wrong initialize vfio_group_list
- Original Message - CC: qemu-triv...@nongnu.org On 01/22/2015 04:14 PM, Eric Auger wrote: Hi Chen, thanks for correcting this mistake I introduced when moving code from pci to common. so, can you check in this patch? I've got it queued up and while it's clearly an error, I don't see that the fix actually changes the resulting code, the parameter is ignored in the macro. Am I missing something? If that's the case, I'll include it in my next pull request, but I don't see any pressing reason to rush that request. Thanks, Alex On 01/22/2015 04:50 AM, Chen Fan wrote: Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com --- hw/vfio/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/vfio/common.c b/hw/vfio/common.c index cf483ff..e71385e 100644 --- a/hw/vfio/common.c +++ b/hw/vfio/common.c @@ -32,7 +32,7 @@ #include trace.h struct vfio_group_head vfio_group_list = -QLIST_HEAD_INITIALIZER(vfio_address_spaces); +QLIST_HEAD_INITIALIZER(vfio_group_list); struct vfio_as_head vfio_address_spaces = QLIST_HEAD_INITIALIZER(vfio_address_spaces);
Re: [Qemu-devel] Help for beginner
Hi Stefan, thank you for the tips. I was trying the way you suggested to add printfs. For starter I try to put them into all function within net/net.c, net/tap.c and hw/net/virtio-net.c (I run qemu using virtio netcard). However, there were no printf message showed up (when i started a qemu process and when i tried ping from within the guest OS of that qemu process). As if those functions were not used. Do you think I put those trace points in a wrong functions? Thanks in advance ~Ady On 1/16/15, Stefan Hajnoczi stefa...@gmail.com wrote: Assuming you run qemu-system-x86_64 the default network card is an emulated Intel e1000 NIC. See hw/net/e1000.c:start_xmit() for the function that emulates packet transmission. It loops over the transmit descriptor ring and send off each packet that the guest has enqueued using qemu_send_packet(). qemu_send_packet() is a QEMU network subsystem API that passes the packet to a host network device (for example, -netdev tap). What happens next depends on which netdev the user launched QEMU with (the default is 'user'). The most popular netdev in production is tap. Look at net/tap.c:tap_receive() to see how QEMU writes the guest's packet to the tap device on the host. The tap driver in the host kernel will then receive the packet from the guest and process it further (often the user has configured a software bridge device so the packet will be forwarded onto the host's physical NIC). Just to recap the structure is: guest - emulated e1000 NIC - tap netdev - host kernel Use tcpdump in the guest or host, or add printfs to QEMU if you want to follow traffic further. Good luck, Stefan
[Qemu-devel] [PATCH] ui/vnc: make sure necessary shift-states are in effect when sending keys
If the keymap specifies the shift modifier for a keysym and that modifier
isn't in effect, send a fake press/release for shift around the key event.
Specifically, this resolves the issue of # producing a 3 when I press the
# on my UK keyboard with a VM with a US keyboard. (FYI the UK # key is
where the US @ key goes.)
I think this is a legit change because the RFB protocol specification says
that servers are expected to do this. It specifically highlights # as an
example of where you'd need to do this!
I wasn't sure whether to do this for all the modifiers - my use case
doesn't call for it - so I didn't.
Signed-off-by: Nathan Baum n...@p12a.org.uk
---
ui/vnc.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index a742c90..200cdd7 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1893,7 +1893,22 @@ static void do_key_event(VncState *vs, int down, int
keycode, int sym)
}
if (qemu_console_is_graphic(NULL)) {
-qemu_input_event_send_key_number(vs-vd-dcl.con, keycode, down);
+int scancode = keysym2scancode(vs-vd-kbd_layout, sym);
+if (scancode == (scancode SCANCODE_KEYMASK)) {
+qemu_input_event_send_key_number(vs-vd-dcl.con, keycode, down);
+} else {
+if (scancode SCANCODE_SHIFT !(vs-modifiers_state[0x2a] ||
+ vs-modifiers_state[0x36]) {
+qemu_input_event_send_key_number(vs-vd-dcl.con, 0x2a, true);
+qemu_input_event_send_key_delay(0);
+}
+qemu_input_event_send_key_number(vs-vd-dcl.con, keycode, down);
+if (scancode SCANCODE_SHIFT !(vs-modifiers_state[0x2a] ||
+ vs-modifiers_state[0x36]) {
+ qemu_input_event_send_key_delay(0);
+ qemu_input_event_send_key_number(vs-vd-dcl.con, 0x2a, false);
+}
+}
} else {
bool numlock = vs-modifiers_state[0x45];
bool control = (vs-modifiers_state[0x1d] ||
--
2.2.1
[Qemu-devel] [PATCH v4 1/2] zynq_gpio: GPIO model for Zynq SoC
Based on the pl061 model. This model implements all four banks with 32 I/Os
each.
The I/Os are placed in named groups:
* bankX_in for the 32 inputs of each bank
* bankX_out for the 32 outputs of each bank
Basic I/O and IRQ support tested with the Zynq GPIO driver in Linux 3.12.
Reviewed-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
Signed-off-by: Colin Leitner colin.leit...@gmail.com
---
hw/gpio/Makefile.objs |1 +
hw/gpio/zynq-gpio.c | 413 +++
include/hw/gpio/zynq-gpio.h | 79 +
3 files changed, 493 insertions(+)
create mode 100644 hw/gpio/zynq-gpio.c
create mode 100644 include/hw/gpio/zynq-gpio.h
diff --git a/hw/gpio/Makefile.objs b/hw/gpio/Makefile.objs
index 1abcf17..c927c66 100644
--- a/hw/gpio/Makefile.objs
+++ b/hw/gpio/Makefile.objs
@@ -5,3 +5,4 @@ common-obj-$(CONFIG_ZAURUS) += zaurus.o
common-obj-$(CONFIG_E500) += mpc8xxx.o
obj-$(CONFIG_OMAP) += omap_gpio.o
+obj-$(CONFIG_ZYNQ) += zynq-gpio.o
diff --git a/hw/gpio/zynq-gpio.c b/hw/gpio/zynq-gpio.c
new file mode 100644
index 000..c740f8f
--- /dev/null
+++ b/hw/gpio/zynq-gpio.c
@@ -0,0 +1,413 @@
+/*
+ * Zynq General Purpose IO
+ *
+ * Copyright (C) 2014 Colin Leitner colin.leit...@gmail.com
+ *
+ * Based on the PL061 model:
+ * Copyright (c) 2007 CodeSourcery.
+ * Written by Paul Brook
+ *
+ * This code is licensed under the GPL.
+ */
+
+/*
+ * We model all banks as if they were fully populated. MIO pins are usually
+ * limited to 54 pins, but this is probably device dependent and shouldn't
+ * cause too much trouble. One noticeable difference is the reset value of
+ * INT_TYPE_1, which is 0x003f according to the TRM and 0x here.
+ *
+ * The output enable pins are not modeled.
+ */
+
+#include hw/gpio/zynq-gpio.h
+#include qemu/bitops.h
+
+#ifndef ZYNQ_GPIO_ERR_DEBUG
+#define ZYNQ_GPIO_ERR_DEBUG 0
+#endif
+
+#define DB_PRINT_L(lvl, fmt, args...) do {\
+if (ZYNQ_GPIO_ERR_DEBUG = lvl) {\
+qemu_log(zynq-gpio: %s: fmt, __func__, ## args);\
+} \
+} while (0);
+
+#define DB_PRINT(fmt, args...) DB_PRINT_L(1, fmt, ## args)
+
+static void zynq_gpio_update_out(ZynqGPIOBank *bank)
+{
+uint32_t changed;
+uint32_t mask;
+uint32_t out;
+int i;
+
+DB_PRINT(dir = %d, data = %d\n, bank-dir, bank-out_data);
+
+/*
+ * We assume non-driven (DIRM = 0) outputs float high. On real hardware
+ * this could be different, but here we have to decide which value to set
+ * the output IRQ to if the direction register switches the I/O to an
+ * input.
+ */
+/* FIXME: This is board dependent. */
+out = (bank-out_data bank-dir) | ~bank-dir;
+
+changed = bank-old_out_data ^ out;
+bank-old_out_data = out;
+
+for (i = 0; i ZYNQ_GPIO_IOS_PER_BANK; i++) {
+mask = 1 i;
+if (changed mask) {
+DB_PRINT(Set output %d = %d\n, i, (out mask) != 0);
+qemu_set_irq(bank-out[i], (out mask) != 0);
+}
+}
+}
+
+static void zynq_gpio_update_in(ZynqGPIOBank *bank)
+{
+uint32_t changed;
+uint32_t mask;
+int i;
+
+changed = bank-old_in_data ^ bank-in_data;
+bank-old_in_data = bank-in_data;
+
+for (i = 0; i ZYNQ_GPIO_IOS_PER_BANK; i++) {
+mask = 1 i;
+if (changed mask) {
+DB_PRINT(Changed input %d = %d\n, i, (bank-in_data mask) !=
0);
+
+if (bank-itype mask) {
+/* Edge interrupt */
+if (bank-iany mask) {
+/* Any edge triggers the interrupt */
+bank-istat |= mask;
+} else {
+/* Edge is selected by INT_POLARITY */
+bank-istat |= ~(bank-in_data ^ bank-ipolarity) mask;
+}
+}
+}
+}
+
+/* Level interrupt */
+bank-istat |= ~(bank-in_data ^ bank-ipolarity) ~bank-itype;
+
+DB_PRINT(istat = %08X\n, bank-istat);
+}
+
+static void zynq_gpio_set_in_irq(ZynqGPIOState *s)
+{
+int b;
+uint32_t istat = 0;
+
+for (b = 0; b ZYNQ_GPIO_BANKS; b++) {
+ZynqGPIOBank *bank = s-banks[b];
+
+istat |= bank-istat ~bank-imask;
+}
+
+DB_PRINT(IRQ = %d\n, istat != 0);
+
+qemu_set_irq(s-irq, istat != 0);
+}
+
+static void zynq_gpio_update(ZynqGPIOState *s)
+{
+int b;
+
+for (b = 0; b ZYNQ_GPIO_BANKS; b++) {
+ZynqGPIOBank *bank = s-banks[b];
+
+zynq_gpio_update_out(bank);
+zynq_gpio_update_in(bank);
+}
+
+zynq_gpio_set_in_irq(s);
+}
+
+static uint64_t zynq_gpio_read(void *opaque, hwaddr offset,
+ unsigned int size)
+{
+ZynqGPIOState *s = opaque;
+int b;
+int shift;
+ZynqGPIOBank *bank;
+
+switch (offset) {
+case ZYNQ_GPIO_REG_MASK_DATA_0_LSW ... ZYNQ_GPIO_REG_MASK_DATA_3_MSW:
+b = extract32(offset - ZYNQ_GPIO_REG_MASK_DATA_0_LSW, 3, 2);
+shift = (offset 0x8) ? 16 : 0;
+return
[Qemu-devel] [PATCH v4 2/2] xilinx_zynq: Add zynq-gpio to the machine
Reviewed-by: Peter Crosthwaite peter.crosthwa...@xilinx.com Signed-off-by: Colin Leitner colin.leit...@gmail.com --- hw/arm/xilinx_zynq.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/arm/xilinx_zynq.c b/hw/arm/xilinx_zynq.c index 06e6e24..6d8c0d9 100644 --- a/hw/arm/xilinx_zynq.c +++ b/hw/arm/xilinx_zynq.c @@ -202,6 +202,8 @@ static void zynq_init(MachineState *machine) zynq_init_spi_flashes(0xE0007000, pic[81-IRQ_OFFSET], false); zynq_init_spi_flashes(0xE000D000, pic[51-IRQ_OFFSET], true); +sysbus_create_simple(zynq-gpio, 0xE000A000, pic[52-IRQ_OFFSET]); + sysbus_create_simple(xlnx,ps7-usb, 0xE0002000, pic[53-IRQ_OFFSET]); sysbus_create_simple(xlnx,ps7-usb, 0xE0003000, pic[76-IRQ_OFFSET]); -- 1.7.10.4
[Qemu-devel] [PATCH v4 0/2] Reworked Zynq GPIO model
Hello everyone, this is the fourth version of the Zynq GPIO model patch. It includes * removal of unneeded memset in zynq_gpio_realize * some minor code cleanup * fixes for all remaining checkpatch warnings (lines too long) Regards, Colin Colin Leitner (2): zynq_gpio: GPIO model for Zynq SoC xilinx_zynq: Add zynq-gpio to the machine hw/arm/xilinx_zynq.c|2 + hw/gpio/Makefile.objs |1 + hw/gpio/zynq-gpio.c | 413 +++ include/hw/gpio/zynq-gpio.h | 79 + 4 files changed, 495 insertions(+) create mode 100644 hw/gpio/zynq-gpio.c create mode 100644 include/hw/gpio/zynq-gpio.h -- 1.7.10.4
[Qemu-devel] [PATCH v2] ui/vnc: make sure necessary shift-states are in effect when sending keys
v2: Replaced some parentheses I lost when preparing the patch for submission.
If the keymap specifies the shift modifier for a keysym and that modifier
isn't in effect, send a fake press/release for shift around the key event.
Specifically, this resolves the issue of # producing a 3 when I press the
# on my UK keyboard with a VM with a US keyboard. (FYI the UK # key is
where the US @ key goes.)
I think this is a legit change because the RFB protocol specification says
that servers are expected to do this. It specifically highlights # as an
example of where you'd need to do this!
I wasn't sure whether to do this for all the modifiers - my use case
doesn't call for it - so I didn't.
Signed-off-by: Nathan Baum n...@p12a.org.uk
---
ui/vnc.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index a742c90..acfb24e 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1893,7 +1893,22 @@ static void do_key_event(VncState *vs, int down, int
keycode, int sym)
}
if (qemu_console_is_graphic(NULL)) {
-qemu_input_event_send_key_number(vs-vd-dcl.con, keycode, down);
+int scancode = keysym2scancode(vs-vd-kbd_layout, sym);
+if (scancode == (scancode SCANCODE_KEYMASK)) {
+qemu_input_event_send_key_number(vs-vd-dcl.con, keycode, down);
+} else {
+if (scancode SCANCODE_SHIFT !(vs-modifiers_state[0x2a] ||
+ vs-modifiers_state[0x36])) {
+qemu_input_event_send_key_number(vs-vd-dcl.con, 0x2a, true);
+qemu_input_event_send_key_delay(0);
+}
+qemu_input_event_send_key_number(vs-vd-dcl.con, keycode, down);
+if (scancode SCANCODE_SHIFT !(vs-modifiers_state[0x2a] ||
+ vs-modifiers_state[0x36])) {
+ qemu_input_event_send_key_delay(0);
+ qemu_input_event_send_key_number(vs-vd-dcl.con, 0x2a, false);
+}
+}
} else {
bool numlock = vs-modifiers_state[0x45];
bool control = (vs-modifiers_state[0x1d] ||
--
2.2.1
Re: [Qemu-devel] [PATCH] vfio: fix wrong initialize vfio_group_list
On 01/26/2015 10:06 AM, Alex Williamson wrote: - Original Message - CC: qemu-triv...@nongnu.org On 01/22/2015 04:14 PM, Eric Auger wrote: Hi Chen, thanks for correcting this mistake I introduced when moving code from pci to common. so, can you check in this patch? I've got it queued up and while it's clearly an error, I don't see that the fix actually changes the resulting code, the parameter is ignored in the macro. Am I missing something? If that's the case, I'll include it in my next pull request, but I don't see any pressing reason to rush that request. Thanks, Yes, this patch can not affect the result of the code execution for now, but I think it is also a typo mistake, if the macro QLIST_HEAD_INITIALIZER will be changed and using the parameter in the future, this error will be difficultly found. I think the earlier found the earlier fixed. Thanks, Chen Alex On 01/22/2015 04:50 AM, Chen Fan wrote: Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com --- hw/vfio/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/vfio/common.c b/hw/vfio/common.c index cf483ff..e71385e 100644 --- a/hw/vfio/common.c +++ b/hw/vfio/common.c @@ -32,7 +32,7 @@ #include trace.h struct vfio_group_head vfio_group_list = -QLIST_HEAD_INITIALIZER(vfio_address_spaces); +QLIST_HEAD_INITIALIZER(vfio_group_list); struct vfio_as_head vfio_address_spaces = QLIST_HEAD_INITIALIZER(vfio_address_spaces); .
Re: [Qemu-devel] [RFC PATCH 00/11] Generate ACPI v5.1 tables and expose it to guest over fw_cfg on ARM
On 2015/1/25 7:31, Laszlo Ersek wrote: On 01/24/15 10:21, Shannon Zhao wrote: This patch series generate seven ACPI v5.1 tables for machine virt on ARM. The set of generated tables are: - RSDP - XSDT - MADT - GTDT - FADT - FACS - DSDT These tables are created dynamically using the function of acpi-build-utils.c, taking into account the needed information passed from the virt machine model. When the generation is finalized, it use fw_cfg to expose the tables to guest. This patchset is based on Igor Mammedov's branch which can be found at below git tree: https://github.com/imammedo/qemu/commits/ASL_API_v2 Awesome! I didn't know you had been coordinating with Igor. This is the best (or, put differently, only :)) possible way forward. Great! Thanks, Laszlo. Igor Mammedov's work is awesome and make the ACPI generation simpler. And this patchset refers to Alexander Spyridakis's patches which are sent to qemu-devel mailing list before. http://lists.gnu.org/archive/html/qemu-devel/2014-10/msg03987.html As UEFI (ArmVirtualizationQemu) doesn't support downloading ACPI tables over fw_cfg, I just do compile test and start a guest with UEFI. But I contacted Laszlo Ersek before, he says that if qemu can expose the generated ACPI tables over fw_cfg, he can quickly add support in UEFI. So just send this out and make it go forward. I hope I was quick enough: - patches: http://thread.gmane.org/gmane.comp.bios.tianocore.devel/12158 - branch: https://github.com/lersek/edk2/commits/armvirt_acpi - binary: http://people.redhat.com/~lersek/armvirt_acpi/QEMU_EFI.fd Great work! Todo: 1) add GPIO controller in virt and expose it through ACPI 2) add cpu hotplug support Any comments are welcome. I answered with a couple of notes and fixes in the thread. I found those via testing. I won't offer a code review; I hope you don't mind. For testing on your end (and for further development) before the edk2 series is applied, you can fetch my patches from github, or even use the binary I built for you. Ok, thanks. Note: the binary includes a very small patch that is not upstream. (Well it includes some other patches too, but they are not relevant.) This is it: --- a/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc +++ b/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc @@ -87,7 +87,7 @@ gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|FALSE [PcdsFixedAtBuild.common] - gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x804F + gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x8040004F gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|QEMU It enables the EFI_D_VERBOSE loglevel. The ACPI code logs quite a bit of info on this loglevel, so if you build an image yourself, be sure to enable EFI_D_VERBOSE manually. Otherwise you'll only see a part of this log fragment: Ok, I see. Loading driver at 0x000BEE66000 EntryPoint=0x000BEE662B0 AcpiPlatformDxe.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BB7BBE98 ProcessCmdAllocate: File=etc/acpi/rsdp Alignment=0x10 Zone=2 Size=0x24 Address=0xB7048000 ProcessCmdAllocate: File=etc/acpi/tables Alignment=0x40 Zone=1 Size=0xBC0 Address=0xB7047000 ProcessCmdAddChecksum: File=etc/acpi/tables ResultOffset=0x49 Start=0x40 Length=0x8F4 ProcessCmdAddPointer: PointerFile=etc/acpi/tables PointeeFile=etc/acpi/tables PointerOffset=0x9B8 PointerSize=8 ProcessCmdAddPointer: PointerFile=etc/acpi/tables PointeeFile=etc/acpi/tables PointerOffset=0x9C0 PointerSize=8 ProcessCmdAddChecksum: File=etc/acpi/tables ResultOffset=0x93D Start=0x934 Length=0x10C ProcessCmdAddChecksum: File=etc/acpi/tables ResultOffset=0xA49 Start=0xA40 Length=0xDC ProcessCmdAddChecksum: File=etc/acpi/tables ResultOffset=0xB25 Start=0xB1C Length=0x60 ProcessCmdAddPointer: PointerFile=etc/acpi/tables PointeeFile=etc/acpi/tables PointerOffset=0xBA0 PointerSize=8 ProcessCmdAddPointer: PointerFile=etc/acpi/tables PointeeFile=etc/acpi/tables PointerOffset=0xBA8 PointerSize=8 ProcessCmdAddPointer: PointerFile=etc/acpi/tables PointeeFile=etc/acpi/tables PointerOffset=0xBB0 PointerSize=8 ProcessCmdAddChecksum: File=etc/acpi/tables ResultOffset=0xB85 Start=0xB7C Length=0x44 ProcessCmdAddPointer: PointerFile=etc/acpi/rsdp PointeeFile=etc/acpi/tables PointerOffset=0x18 PointerSize=8 ProcessCmdAddChecksum: File=etc/acpi/rsdp ResultOffset=0x8 Start=0x0 Length=0x24 Process2ndPassCmdAddPointer: checking for ACPI header in etc/acpi/tables at 0xB7047000 (remaining: 0xBC0): found FACS size 0x40 Process2ndPassCmdAddPointer: checking for ACPI header in etc/acpi/tables at 0xB7047040 (remaining: 0xB80): found DSDT size 0x8F4 Process2ndPassCmdAddPointer: checking for ACPI header in etc/acpi/tables at 0xB7047934 (remaining: 0x28C): found FACP size 0x10C Process2ndPassCmdAddPointer: checking for ACPI header in etc/acpi/tables at 0xB7047A40 (remaining: 0x180): found APIC size
Re: [Qemu-devel] [RFC PATCH 02/11] hw/arm/virt-acpi-build: Basic framework for building ACPI tables
On 2015/1/25 0:22, Michael S. Tsirkin wrote: On Sat, Jan 24, 2015 at 05:21:11PM +0800, Shannon Zhao wrote: Introduce a preliminary framework in virt-acpi-build.c with the main ACPI build functions. It exposes the generated ACPI contents to guest over fw_cfg. Some codes borrowed from hw/i386/acpi-build.c. The minimum required ACPI v5.1 tables for ARM are: - RSDP: Initial table that points to XSDT - XSDT: Points to all other tables (except FACS DSDT) - FADT: Generic information about the machine - DSDT: Holds all information about system devices/peripherals - FACS: Needs to be pointed from FADT Signed-off-by: Shannon Zhao zhaoshengl...@huawei.com --- hw/arm/Makefile.objs |1 + hw/arm/virt-acpi-build.c | 263 ++ include/hw/arm/virt-acpi-build.h | 71 ++ 3 files changed, 335 insertions(+), 0 deletions(-) create mode 100644 hw/arm/virt-acpi-build.c create mode 100644 include/hw/arm/virt-acpi-build.h diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs index 6088e53..8daf825 100644 --- a/hw/arm/Makefile.objs +++ b/hw/arm/Makefile.objs @@ -3,6 +3,7 @@ obj-$(CONFIG_DIGIC) += digic_boards.o obj-y += integratorcp.o kzm.o mainstone.o musicpal.o nseries.o obj-y += omap_sx1.o palm.o realview.o spitz.o stellaris.o obj-y += tosa.o versatilepb.o vexpress.o virt.o xilinx_zynq.o z2.o +obj-$(CONFIG_ACPI) += virt-acpi-build.o obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o pxa2xx_pic.o obj-$(CONFIG_DIGIC) += digic.o diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c new file mode 100644 index 000..4eed0a3 --- /dev/null +++ b/hw/arm/virt-acpi-build.c @@ -0,0 +1,263 @@ +/* Support for generating ACPI tables and passing them to Guests + * + * ARM virt ACPI generation + * + * Copyright (c) 2014 HUAWEI TECHNOLOGIES CO.,LTD. + * + * Author: Shannon Zhao zhaoshengl...@huawei.com Since you copied code over, you should append copyright and author information from the original file to the new one. Ok, will fix this :-) Thanks, Shannon
Re: [Qemu-devel] [PATCH] vfio: fix wrong initialize vfio_group_list
- Original Message - On 01/26/2015 10:06 AM, Alex Williamson wrote: - Original Message - CC: qemu-triv...@nongnu.org On 01/22/2015 04:14 PM, Eric Auger wrote: Hi Chen, thanks for correcting this mistake I introduced when moving code from pci to common. so, can you check in this patch? I've got it queued up and while it's clearly an error, I don't see that the fix actually changes the resulting code, the parameter is ignored in the macro. Am I missing something? If that's the case, I'll include it in my next pull request, but I don't see any pressing reason to rush that request. Thanks, Yes, this patch can not affect the result of the code execution for now, but I think it is also a typo mistake, if the macro QLIST_HEAD_INITIALIZER will be changed and using the parameter in the future, this error will be difficultly found. I think the earlier found the earlier fixed. Yes, it's obviously an error and I'll get it in before QEMU 2.3, likely within the next week or so. Thanks, Alex On 01/22/2015 04:50 AM, Chen Fan wrote: Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com --- hw/vfio/common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/vfio/common.c b/hw/vfio/common.c index cf483ff..e71385e 100644 --- a/hw/vfio/common.c +++ b/hw/vfio/common.c @@ -32,7 +32,7 @@ #include trace.h struct vfio_group_head vfio_group_list = -QLIST_HEAD_INITIALIZER(vfio_address_spaces); +QLIST_HEAD_INITIALIZER(vfio_group_list); struct vfio_as_head vfio_address_spaces = QLIST_HEAD_INITIALIZER(vfio_address_spaces); .
