Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
On 07/07/2014 09:20 PM, Al Viro wrote: and I'm reasonably sure that this is what they did internally. You are proposing to do 4 cases in all their messy glory in qemu itself... Yes. Primarily because we *have* to do so for the linux-user case. And that's not even going into generating the right si_code for that SIGFPE. What produces those TARGET_GEN_FLTINE and friends? linux-user/main.c, cpu_loop. r~
Re: [Qemu-devel] [RFC PATCH 00/11] Adding FreeBSD's Capsicum security framework (part 1)
On Mon, Jul 7, 2014 at 5:20 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 07/07/2014 12:29, David Drysdale ha scritto: I think that's more easily done by opening the file as O_RDONLY/O_WRONLY /O_RDWR. You could do it by running the file descriptor's seccomp-bpf program once per iocb with synthesized syscall numbers and argument vectors. Right, but generating the equivalent seccomp input environment for an equivalent single-fd syscall is going to be subtle and complex (which are worrying words to mention in a security context). And how many other syscalls are going to need similar special-case processing? (poll? select? send[m]msg? ...) Yeah, the difficult part is getting the right balance between: 1) limitations due to seccomp's impossibility to chase pointers (which is not something that can be lifted, as it's required for correctness) btw once seccomp moves to eBPF it will be able to 'chase pointers', since pointer walking will be possible via bpf_load_pointer() function call, which is a wrapper of: probe_kernel_read(ptr, unsafe_ptr, sizeof(void *)); return ptr; Not sure whether it helps this case or not. Just fyi. 2) subtlety and complexity of the resulting code. The problem stems when you have a single a single syscall operating on multiple file descriptors. So for example among the cases you mention poll and select are problematic; sendm?msg are not. They would be if Capsicum had a capability for SCM_RIGHTS file descriptor passing, but I cannot find it. But then you also have to strike the right balance between a complete solution and an overengineered one. For example, even though poll and select are problematic, I wonder what would really the point be in blocking them; poll/select are level-triggered, and calling them should be idempotent as far as the file descriptor is concerned. If you want to prevent a process/thread from issuing blocking system calls, but you'd do that with a per-process filter, not with per-file-descriptor filters or capabilities. Capsicum capabilities are associated with the file descriptor (a la F_GETFD), not the open file itself -- different FDs with different associated rights can map to the same underlying open file. Good to know, thanks. I suppose you have testcases that cover this. Paolo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Qemu-devel] [PATCH 14/15] target-tricore: Add instructions of SLR, SSRO and SRO opcode format
On 07/07/2014 11:13 AM, Bastian Koppelmann wrote: Add instructions of SLR, SSRO and SRO opcode format. All of my previous comments re memory accesses apply. r~
Re: [Qemu-devel] [PATCH] oslib-posix: Fix new compiler error with -Wclobbered
Il 07/07/2014 21:29, Stefan Weil ha scritto: Am 24.06.2014 23:03, schrieb Paolo Bonzini: Il 24/06/2014 22:52, Stefan Weil ha scritto: Newer versions of gcc report a warning (or an error with -Werror) when compiler option -Wclobbered (or -Wextra) is active: util/oslib-posix.c:372:12: error: variable ‘hpagesize’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered] The rewritten code fixes this warning: variable 'hpagesize' is now set and used in a block without any call of sigsetjmp or similar functions. Signed-off-by: Stefan Weil s...@weilnetz.de Reviewed-by: Paolo Bonzini pbonz...@redhat.com Ping? Maybe this patch can be committed directly as a build fix for people like me who use compiler flag -Wextra. Ok, I'll pick it up. Paolo
Re: [Qemu-devel] [PATCH 15/15] target-tricore: Add instructions of SR opcode format
On 07/07/2014 11:13 AM, Bastian Koppelmann wrote:
+static bool cdc_zero(TCState *tc)
+{
+int i;
+int cdc = tc-PSW MASK_PSW_CDC;
+/* Returns TRUE if PSW.CDC.COUNT == 0 or if PSW.CDC ==
+ 7'b111, otherwise returns FALSE. */
+if (cdc == 0x7f) {
+return true;
+}
+/* find CDC.COUNT */
+for (i = 7; i 0; i--) {
+if ((cdc (1 i)) == 0) {
+if ((cdc ~(0x7f i)) == 0) {
+return true;
+}
+}
+}
Consider using clo32 instead of a loop.
+static void gen_saturate(TCGv ret, TCGv arg, int32_t up, int32_t low)
+{
+TCGv sat_neg = tcg_const_i32(low);
+int l1 = gen_new_label();
+int l2 = gen_new_label();
+
+/* sat_neg = (arg low ) ? low : arg; */
+tcg_gen_brcondi_tl(TCG_COND_LT, arg, low, l1);
+tcg_gen_mov_tl(sat_neg, arg);
+gen_set_label(l1);
+
+/* ret = (sat_neg up ) ? up : sat_neg; */
+tcg_gen_movi_tl(ret, up);
+tcg_gen_brcondi_tl(TCG_COND_GT, sat_neg, up, l2);
+tcg_gen_mov_tl(ret, sat_neg);
+gen_set_label(l2);
+
+tcg_temp_free(sat_neg);
+}
Again with the movcond.
+static void gen_rsubi(TCGv ret, int32_t cons, TCGv r2)
+{
+TCGv temp = tcg_temp_new();
+tcg_gen_movi_tl(temp, cons);
+tcg_gen_sub_tl(ret, temp, r2);
+tcg_temp_free(temp);
This is tcg_gen_subfi_tl.
+/* SR-format jumps */
+case OPC1_16_SR_JI:
+tcg_gen_andi_tl(cpu_PC, cpu_gpr_a[r1], 0x);
Huh? This is a noop.
+static void decode_sr_system(CPUTRICOREState *env, DisasContext *ctx)
+{
+uint32_t op2;
+op2 = MASK_OP_SR_OP2(ctx-opcode);
+
+switch (op2) {
+case OPC2_16_SR_NOP:
+printf(NOP Instruction at %08x\n, ctx-pc);
+ctx-bstate = BS_STOP;
Why stop?
+case OPC2_16_SR_RFE:
+gen_helper_rfe(cpu_env);
+break;
But you do need one here.
+case OPC2_16_SR_DEBUG:
+printf(DEBUG Instruction at %08x\n, ctx-pc);
+ctx-bstate = BS_STOP;
Raise the EXP_DEBUG exception?
+case OPC1_16_SR_NOT:
+if (MASK_OP_SR_OP2(ctx-opcode) == 0x0) {
+printf(Wrong OP2 at at %08x\n, ctx-pc);
You're really going to have to clean up the printfs...
r~
Re: [Qemu-devel] [libvirt] Where to get precompiled qga-vss.dll from ?
Hi,
[Rephrasing my earlier post with more clarity.]
I need to work with guest-fsfreeze-* commands in Windows 2008 guest VM
(Host is CentOS 6.4) to quisce the applications.
*Windows 2008 Guest Machine*
1. Windows 2008 is running following services
- QEMU Guest Agent
- QEMU Guest Agent VSS Provider
2. C:\ vssadmin list providers
...
Provider name: 'QEMU Guest Agent VSS Provider
Version: 0.12.1
Provider name: 'Microsoft Software Shadow Copy provider 1.0'
Version: 1.0.0.7
*Host (CentOS 6.4)*
When guest-fsfreeze-* commands are invoked from host, response
received from guest is This is not supported. Since QEMU Guest Agent VSS
Provider was already running in Guest VM, I was expecting these commands
to succeed and quisce Windows applications, but they were reported as
unsupported.
[root@sdsr720-14 Downloads]# virsh qemu-agent-command vm_win_06 '{
execute: guest-fsfreeze-status}'
{error:{class:Unsupported,desc:this feature or command is not
currently supported,data:{}}}
[root@sdsr720-14 Downloads]# virsh qemu-agent-command vm_win_06 '{
execute: guest-fsfreeze-freeze}'
{error:{class:Unsupported,desc:this feature or command is not
currently supported,data:{}}}
*Is missing qga-vss.dll the reason?*
I searched my system for this dll and could not find it and suspected that
missing qga-vss.dll is the reason for this. I took suggestions from
following post which advised to cross-compile qemu code to get qga-vss.dll
http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg01963.html.
But I faced a lot of issues while building i686-w64-mingw32-* in CentOS 6.4
and had to eventually give up building i686-w64-mingw32-* and move to
getting pre-compiled QEMU guest agent (with VSS support), which I can
install on Windows to quisce the applications.
*What I need *
If I can get pre-compiled qga-vss.dll, I can copy it to Windows8 guest VM
and hopefully work with guest-fsfreeze-* commands to quisce the
applications.
Can somebody point me to pre-compiled QEMU guest agent with VSS support
(and qga-vss.dll) so that I can quisce the Windows guest VM applications?
Regards,
~Puneet
On Tue, Jul 8, 2014 at 3:27 AM, Eric Blake ebl...@redhat.com wrote:
On 07/07/2014 02:32 AM, Puneet Bakshi wrote:
Hi,
I want to work with guest-fsfreeze-* commands in Windows 2008 guest VM.
Host is CentOS 6.4.
Windows 2008 is running QEMU VSS provider. When guest-fsfreeze-*
commands
are invoked from host, response received is This is not supported.
I am following
http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg01963.html.
The libvirt list is the wrong place to be asking this question; qemu is
better.
The spice-devel list has done some pre-packaged virt stack builds for
Windows; maybe they might be a better resource to ask (for example, see
http://lists.freedesktop.org/archives/spice-devel/2014-February/016100.html
)
- but I don't follow that list closely enough to know if they have
pre-built qga.
You could always download the mingw cross-compiler and try to build qga
yourself, instead of relying on someone else to provide a pre-built binary.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] [RFC] COLO HA Project proposal
Hi Michael, Thank you for paying attention on this. On 07/08/2014 02:06 PM, Michael R. Hines wrote: On 07/03/2014 11:42 AM, Hongyang Yang wrote: I wonder if there is anyway to coordinate this between COLO, Michael Hines microcheckpointing and the two separate reverse-execution projects that also need to do some similar things. Are there any standard APIs for the heartbeet thing we can already tie into? Sadly we have checked MC, it does not have heartbeat support for now. Right, MC by itself does not need heartbeats out-of-the box. Probably the best thing we can coordinate from MC is the part of the data transmission protocol and memory management - because we need Yes, that's what we have planned. to make sure you guys are staying compatible with the QEMUFile abstraction the same way that the TCP and RDMA protocols are staying compatible with that abstraction. COLO should able to run over any protocol supported by QEMUFile. Indeed. I can help with some of that... - Michael . -- Thanks, Yang.
[Qemu-devel] [PATCH v2 8/9] target-mips: add BadInstr and BadInstrP support
BadInstr Register (CP0 Register 8, Select 1)
The BadInstr register is a read-only register that capture the most recent
instruction which caused an exception.
BadInstrP Register (CP0 Register 8, Select 2)
The BadInstrP register contains the prior branch instruction, when the
faulting instruction is in a branch delay slot.
Using error_code to indicate whether AdEL or TLBL was triggered during
instruction fetch, in this case BadInstr is not updated as valid instruction
word is not available.
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
target-mips/cpu.h |6 +++
target-mips/helper.c| 44 --
target-mips/op_helper.c | 17 +-
target-mips/translate.c | 80 +++---
4 files changed, 136 insertions(+), 11 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index bc5..656f5ca 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -177,6 +177,8 @@ struct TCState {
target_ulong CP0_TCScheFBack;
int32_t CP0_Debug_tcstatus;
target_ulong CP0_UserLocal;
+uint32_t CP0_BadInstr;
+uint32_t CP0_BadInstrP;
};
typedef struct CPUMIPSState CPUMIPSState;
@@ -383,6 +385,8 @@ struct CPUMIPSState {
#define CP0C2_SA 0
int32_t CP0_Config3;
#define CP0C3_M31
+#define CP0C3_BP 27
+#define CP0C3_BI 26
#define CP0C3_ISA_ON_EXC 16
#define CP0C3_ULRI 13
#define CP0C3_RXI 12
@@ -453,6 +457,8 @@ struct CPUMIPSState {
CPUMIPSFPUContext fpus[MIPS_FPU_MAX];
/* QEMU */
int error_code;
+#define EXCP_TLB_NOMATCH 0x1
+#define EXCP_INST_NOTAVAIL 0x2 /* No valid instruction word for BadInstr */
uint32_t hflags;/* CPU State */
/* TMASK defines different execution modes */
#define MIPS_HFLAG_TMASK 0xC07FF
diff --git a/target-mips/helper.c b/target-mips/helper.c
index 5d72438..67fc71d 100644
--- a/target-mips/helper.c
+++ b/target-mips/helper.c
@@ -25,6 +25,7 @@
#include cpu.h
#include sysemu/kvm.h
+#include exec/cpu_ldst.h
enum {
TLBRET_XI = -6,
@@ -241,6 +242,10 @@ static void raise_mmu_exception(CPUMIPSState *env,
target_ulong address,
CPUState *cs = CPU(mips_env_get_cpu(env));
int exception = 0, error_code = 0;
+if (rw == MMU_INST_FETCH) {
+error_code |= EXCP_INST_NOTAVAIL;
+}
+
switch (tlb_error) {
default:
case TLBRET_BADADDR:
@@ -259,7 +264,7 @@ static void raise_mmu_exception(CPUMIPSState *env,
target_ulong address,
} else {
exception = EXCP_TLBL;
}
-error_code = 1;
+error_code |= EXCP_TLB_NOMATCH;
break;
case TLBRET_INVALID:
/* TLB match with no valid bit */
@@ -451,6 +456,20 @@ static void set_hflags_for_handler (CPUMIPSState *env)
MIPS_HFLAG_M16_SHIFT);
}
}
+
+static inline void set_badinstr_registers(CPUMIPSState *env)
+{
+if (env-hflags MIPS_HFLAG_M16) {
+/* TODO: add BadInstr support for microMIPS */
+return;
+}
+if (env-CP0_Config3 (1 CP0C3_BI)) {
+env-active_tc.CP0_BadInstr = cpu_ldl_code(env, env-active_tc.PC);
+}
+if (env-CP0_Config3 (1 CP0C3_BP) env-hflags MIPS_HFLAG_BMASK) {
+env-active_tc.CP0_BadInstrP = cpu_ldl_code(env, env-active_tc.PC -
4);
+}
+}
#endif
void mips_cpu_do_interrupt(CPUState *cs)
@@ -458,6 +477,7 @@ void mips_cpu_do_interrupt(CPUState *cs)
#if !defined(CONFIG_USER_ONLY)
MIPSCPU *cpu = MIPS_CPU(cs);
CPUMIPSState *env = cpu-env;
+bool update_badinstr = 0;
target_ulong offset;
int cause = -1;
const char *name;
@@ -566,10 +586,13 @@ void mips_cpu_do_interrupt(CPUState *cs)
goto set_EPC;
case EXCP_LTLBL:
cause = 1;
+update_badinstr = !(env-error_code EXCP_INST_NOTAVAIL);
goto set_EPC;
case EXCP_TLBL:
cause = 2;
-if (env-error_code == 1 !(env-CP0_Status (1 CP0St_EXL))) {
+update_badinstr = !(env-error_code EXCP_INST_NOTAVAIL);
+if (env-error_code EXCP_TLB_NOMATCH
+!(env-CP0_Status (1 CP0St_EXL))) {
#if defined(TARGET_MIPS64)
int R = env-CP0_BadVAddr 62;
int UX = (env-CP0_Status (1 CP0St_UX)) != 0;
@@ -586,7 +609,9 @@ void mips_cpu_do_interrupt(CPUState *cs)
goto set_EPC;
case EXCP_TLBS:
cause = 3;
-if (env-error_code == 1 !(env-CP0_Status (1 CP0St_EXL))) {
+update_badinstr = 1;
+if (env-error_code EXCP_TLB_NOMATCH
+!(env-CP0_Status (1 CP0St_EXL))) {
#if defined(TARGET_MIPS64)
int R = env-CP0_BadVAddr 62;
int UX = (env-CP0_Status (1 CP0St_UX)) != 0;
@@ -603,9 +628,11 @@ void mips_cpu_do_interrupt(CPUState *cs)
goto set_EPC;
case EXCP_AdEL:
cause = 4;
+update_badinstr = !(env-error_code EXCP_INST_NOTAVAIL);
goto set_EPC;
case EXCP_AdES:
cause = 5;
+update_badinstr = 1;
goto set_EPC;
[Qemu-devel] [PATCH v2 2/9] softmmu: provide softmmu access type enum
New MIPS features depend on the access type and enum is more convenient than
using the numbers directly.
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
include/exec/cpu-common.h |6 ++
softmmu_template.h| 26 --
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index e3ec4c8..1c3171a 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -26,6 +26,12 @@ typedef struct CPUListState {
FILE *file;
} CPUListState;
+enum mmu_access_type {
+MMU_DATA_LOAD = 0,
+MMU_DATA_STORE = 1,
+MMU_INST_FETCH = 2
+};
+
#if !defined(CONFIG_USER_ONLY)
enum device_endian {
diff --git a/softmmu_template.h b/softmmu_template.h
index 5a07f99..858bf6b 100644
--- a/softmmu_template.h
+++ b/softmmu_template.h
@@ -67,10 +67,10 @@
#endif
#ifdef SOFTMMU_CODE_ACCESS
-#define READ_ACCESS_TYPE 2
+#define READ_ACCESS_TYPE MMU_INST_FETCH
#define ADDR_READ addr_code
#else
-#define READ_ACCESS_TYPE 0
+#define READ_ACCESS_TYPE MMU_DATA_LOAD
#define ADDR_READ addr_read
#endif
@@ -365,10 +365,11 @@ void helper_le_st_name(CPUArchState *env, target_ulong
addr, DATA_TYPE val,
!= (tlb_addr (TARGET_PAGE_MASK | TLB_INVALID_MASK))) {
#ifdef ALIGNED_ONLY
if ((addr (DATA_SIZE - 1)) != 0) {
-cpu_unaligned_access(ENV_GET_CPU(env), addr, 1, mmu_idx, retaddr);
+cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
+ mmu_idx, retaddr);
}
#endif
-tlb_fill(ENV_GET_CPU(env), addr, 1, mmu_idx, retaddr);
+tlb_fill(ENV_GET_CPU(env), addr, MMU_DATA_STORE, mmu_idx, retaddr);
tlb_addr = env-tlb_table[mmu_idx][index].addr_write;
}
@@ -394,7 +395,8 @@ void helper_le_st_name(CPUArchState *env, target_ulong
addr, DATA_TYPE val,
int i;
do_unaligned_access:
#ifdef ALIGNED_ONLY
-cpu_unaligned_access(ENV_GET_CPU(env), addr, 1, mmu_idx, retaddr);
+cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
+ mmu_idx, retaddr);
#endif
/* XXX: not efficient, but simple */
/* Note: relies on the fact that tlb_fill() does not remove the
@@ -413,7 +415,8 @@ void helper_le_st_name(CPUArchState *env, target_ulong
addr, DATA_TYPE val,
/* Handle aligned access or unaligned access in the same page. */
#ifdef ALIGNED_ONLY
if ((addr (DATA_SIZE - 1)) != 0) {
-cpu_unaligned_access(ENV_GET_CPU(env), addr, 1, mmu_idx, retaddr);
+cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
+ mmu_idx, retaddr);
}
#endif
@@ -441,10 +444,11 @@ void helper_be_st_name(CPUArchState *env, target_ulong
addr, DATA_TYPE val,
!= (tlb_addr (TARGET_PAGE_MASK | TLB_INVALID_MASK))) {
#ifdef ALIGNED_ONLY
if ((addr (DATA_SIZE - 1)) != 0) {
-cpu_unaligned_access(ENV_GET_CPU(env), addr, 1, mmu_idx, retaddr);
+cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
+ mmu_idx, retaddr);
}
#endif
-tlb_fill(ENV_GET_CPU(env), addr, 1, mmu_idx, retaddr);
+tlb_fill(ENV_GET_CPU(env), addr, MMU_DATA_STORE, mmu_idx, retaddr);
tlb_addr = env-tlb_table[mmu_idx][index].addr_write;
}
@@ -470,7 +474,8 @@ void helper_be_st_name(CPUArchState *env, target_ulong
addr, DATA_TYPE val,
int i;
do_unaligned_access:
#ifdef ALIGNED_ONLY
-cpu_unaligned_access(ENV_GET_CPU(env), addr, 1, mmu_idx, retaddr);
+cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
+ mmu_idx, retaddr);
#endif
/* XXX: not efficient, but simple */
/* Note: relies on the fact that tlb_fill() does not remove the
@@ -489,7 +494,8 @@ void helper_be_st_name(CPUArchState *env, target_ulong
addr, DATA_TYPE val,
/* Handle aligned access or unaligned access in the same page. */
#ifdef ALIGNED_ONLY
if ((addr (DATA_SIZE - 1)) != 0) {
-cpu_unaligned_access(ENV_GET_CPU(env), addr, 1, mmu_idx, retaddr);
+cpu_unaligned_access(ENV_GET_CPU(env), addr, MMU_DATA_STORE,
+ mmu_idx, retaddr);
}
#endif
--
1.7.5.4
[Qemu-devel] [Bug 1338957] [NEW] RFE: add an event to report block devices watermark
Public bug reported: Add an event to report if a block device usage exceeds a threshold. The threshold should be configurable with a monitor command. The event should report the affected block device. Additional useful information could be the offset of the highest sector , like in the query-blockstats output. Rationale for the RFE Managing applications, like oVirt (http://www.ovirt.org), make extensive use of thin-provisioned disk images. In order to let the guest run flawlessly and be not unnecessarily paused, oVirt sets a watermark and automatically resized the image once the watermark is reached or exceeded. In order to detect the mark crossing, the managing application has no choice than aggressively polling the QEMU monitor using the query-blockstats command. This lead to unnecessary system load, and is made even worse under scale: scenarios with hunderds of VM are becoming not unusual. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338957 Title: RFE: add an event to report block devices watermark Status in QEMU: New Bug description: Add an event to report if a block device usage exceeds a threshold. The threshold should be configurable with a monitor command. The event should report the affected block device. Additional useful information could be the offset of the highest sector , like in the query- blockstats output. Rationale for the RFE Managing applications, like oVirt (http://www.ovirt.org), make extensive use of thin-provisioned disk images. In order to let the guest run flawlessly and be not unnecessarily paused, oVirt sets a watermark and automatically resized the image once the watermark is reached or exceeded. In order to detect the mark crossing, the managing application has no choice than aggressively polling the QEMU monitor using the query-blockstats command. This lead to unnecessary system load, and is made even worse under scale: scenarios with hunderds of VM are becoming not unusual. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1338957/+subscriptions
[Qemu-devel] [PATCH v2 6/9] target-mips: add new Read-Inhibit and Execute-Inhibit exceptions
An Execute-Inhibit exception occurs when the virtual address of an instruction
fetch matches a TLB entry whose XI bit is set. This exception type can only
occur if the XI bit is implemented within the TLB and is enabled, this is
denoted by the PageGrain XIE bit.
An Read-Inhibit exception occurs when the virtual address of a memory load
reference matches a TLB entry whose RI bit is set. This exception type can
only occur if the RI bit is implemented within the TLB and is enabled, this is
denoted by the PageGrain RIE bit.
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
target-mips/cpu.h|5 -
target-mips/helper.c | 25 -
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 8ccb3bb..40ebca6 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -247,6 +247,7 @@ struct CPUMIPSState {
int32_t CP0_PageGrain;
#define CP0PG_RIE 31
#define CP0PG_XIE 30
+#define CP0PG_IEC 27
int32_t CP0_Wired;
int32_t CP0_SRSConf0_rw_bitmask;
int32_t CP0_SRSConf0;
@@ -645,8 +646,10 @@ enum {
EXCP_C2E,
EXCP_CACHE, /* 32 */
EXCP_DSPDIS,
+EXCP_TLBXI,
+EXCP_TLBRI,
-EXCP_LAST = EXCP_DSPDIS,
+EXCP_LAST = EXCP_TLBRI,
};
/* Dummy exception for conditional stores. */
#define EXCP_SC 0x100
diff --git a/target-mips/helper.c b/target-mips/helper.c
index 6aa8c8a..fed28b4 100644
--- a/target-mips/helper.c
+++ b/target-mips/helper.c
@@ -273,7 +273,22 @@ static void raise_mmu_exception(CPUMIPSState *env,
target_ulong address,
/* TLB match but 'D' bit is cleared */
exception = EXCP_LTLBL;
break;
-
+case TLBRET_XI:
+/* Execute-Inhibit Exception */
+if (env-CP0_PageGrain (1 CP0PG_IEC)) {
+exception = EXCP_TLBXI;
+} else {
+exception = EXCP_TLBL;
+}
+break;
+case TLBRET_RI:
+/* Read-Inhibit Exception */
+if (env-CP0_PageGrain (1 CP0PG_IEC)) {
+exception = EXCP_TLBRI;
+} else {
+exception = EXCP_TLBL;
+}
+break;
}
/* Raise exception */
env-CP0_BadVAddr = address;
@@ -404,6 +419,8 @@ static const char * const excp_names[EXCP_LAST + 1] = {
[EXCP_MDMX] = MDMX,
[EXCP_C2E] = precise coprocessor 2,
[EXCP_CACHE] = cache error,
+[EXCP_TLBXI] = TLB execute-inhibit,
+[EXCP_TLBRI] = TLB read-inhibit,
};
target_ulong exception_resume_pc (CPUMIPSState *env)
@@ -622,6 +639,12 @@ void mips_cpu_do_interrupt(CPUState *cs)
case EXCP_C2E:
cause = 18;
goto set_EPC;
+case EXCP_TLBRI:
+cause = 19;
+goto set_EPC;
+case EXCP_TLBXI:
+cause = 20;
+goto set_EPC;
case EXCP_MDMX:
cause = 22;
goto set_EPC;
--
1.7.5.4
[Qemu-devel] screen freezed for 2-3 minutes on spice connect on xen windows 7 domU's with qxl after save/restore
On xen 4.5 (tried with qemu 2.0.0/2.1-rc0, spice 0.12.5 and client with spice-gtk 0.23/0.25) windows 7 domUs with qxl vga works good as kvm except for one problem after xl save/restore, when after restore on spice client connect the domU's screen freezed for 2-3 minutes (and seems also windows), after this time seems that all return to works correctly. This problem happen also if spice client connect long time after restore. With stdvga not have this problem but stdvga has many missed resolutions and bad refresh performance. If you need more tests/informations tell me and I'll post them. Thanks for any reply and sorry for my bad english.
[Qemu-devel] [PATCH v2 7/9] target-mips: add TLBINV support
For Standard TLB configuration (Config.MT=1):
TLBINV invalidates a set of TLB entries based on ASID. The virtual address is
ignored in the entry match. TLB entries which have their G bit set to 1 are not
modified.
TLBINVF causes all entries to be invalidated.
Note that this commit introduces support for Config4.IE == 3 only (i.e. TLBINV*
instructions operate on entire MMU).
Single TLB entry can be marked as invalid on TLB entry write by having
EntryHi.EHINV set to 1.
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
disas/mips.c |2 +
target-mips/cpu.h|7
target-mips/helper.c |2 +-
target-mips/helper.h |2 +
target-mips/op_helper.c | 65 +
target-mips/translate.c | 22 ++
target-mips/translate_init.c |2 +
7 files changed, 94 insertions(+), 8 deletions(-)
diff --git a/disas/mips.c b/disas/mips.c
index e3e253f..ff2e4b3 100644
--- a/disas/mips.c
+++ b/disas/mips.c
@@ -2410,6 +2410,8 @@ const struct mips_opcode mips_builtin_opcodes[] =
{tlbp,, 0x4208, 0x, INSN_TLB, 0,
I1 },
{tlbr,, 0x4201, 0x, INSN_TLB, 0,
I1 },
{tlbwi, , 0x4202, 0x, INSN_TLB, 0,
I1 },
+{tlbinv, , 0x4203, 0x, INSN_TLB, 0, I32
},
+{tlbinvf, , 0x4204, 0x, INSN_TLB, 0, I32
},
{tlbwr, , 0x4206, 0x, INSN_TLB, 0,
I1 },
{tlti,s,j, 0x040a, 0xfc1f, RD_s|TRAP, 0,
I2 },
{tlt, s,t, 0x0032, 0xfc00, RD_s|RD_t|TRAP, 0,
I2 },
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 40ebca6..bc5 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -34,6 +34,7 @@ struct r4k_tlb_t {
uint_fast16_t XI1:1;
uint_fast16_t RI0:1;
uint_fast16_t RI1:1;
+uint_fast16_t EHINV:1;
target_ulong PFN[2];
};
@@ -47,6 +48,8 @@ struct CPUMIPSTLBContext {
void (*helper_tlbwr)(struct CPUMIPSState *env);
void (*helper_tlbp)(struct CPUMIPSState *env);
void (*helper_tlbr)(struct CPUMIPSState *env);
+void (*helper_tlbinv)(struct CPUMIPSState *env);
+void (*helper_tlbinvf)(struct CPUMIPSState *env);
union {
struct {
r4k_tlb_t tlb[MIPS_TLB_MAX];
@@ -282,6 +285,7 @@ struct CPUMIPSState {
target_ulong CP0_BadVAddr;
int32_t CP0_Count;
target_ulong CP0_EntryHi;
+#define CP0EnHi_EHINV 10
int32_t CP0_Compare;
int32_t CP0_Status;
#define CP0St_CU3 31
@@ -393,6 +397,7 @@ struct CPUMIPSState {
uint32_t CP0_Config4;
uint32_t CP0_Config4_rw_bitmask;
#define CP0C4_M31
+#define CP0C4_IE 29
#define CP0C4_KScrExist 16
uint32_t CP0_Config5;
uint32_t CP0_Config5_rw_bitmask;
@@ -528,6 +533,8 @@ void r4k_helper_tlbwi(CPUMIPSState *env);
void r4k_helper_tlbwr(CPUMIPSState *env);
void r4k_helper_tlbp(CPUMIPSState *env);
void r4k_helper_tlbr(CPUMIPSState *env);
+void r4k_helper_tlbinv(CPUMIPSState *env);
+void r4k_helper_tlbinvf(CPUMIPSState *env);
void mips_cpu_unassigned_access(CPUState *cpu, hwaddr addr,
bool is_write, bool is_exec, int unused,
diff --git a/target-mips/helper.c b/target-mips/helper.c
index fed28b4..5d72438 100644
--- a/target-mips/helper.c
+++ b/target-mips/helper.c
@@ -83,7 +83,7 @@ int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int
*prot,
#endif
/* Check ASID, virtual page number size */
-if ((tlb-G == 1 || tlb-ASID == ASID) VPN == tag) {
+if ((tlb-G == 1 || tlb-ASID == ASID) VPN == tag !tlb-EHINV) {
/* TLB match */
int n = !!(address mask ~(mask 1));
/* Check access rights */
diff --git a/target-mips/helper.h b/target-mips/helper.h
index e7e0c8c..aea12a9 100644
--- a/target-mips/helper.h
+++ b/target-mips/helper.h
@@ -342,6 +342,8 @@ DEF_HELPER_1(tlbwi, void, env)
DEF_HELPER_1(tlbwr, void, env)
DEF_HELPER_1(tlbp, void, env)
DEF_HELPER_1(tlbr, void, env)
+DEF_HELPER_1(tlbinv, void, env)
+DEF_HELPER_1(tlbinvf, void, env)
DEF_HELPER_1(di, tl, env)
DEF_HELPER_1(ei, tl, env)
DEF_HELPER_1(eret, void, env)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index 3579bde..fa96bb3 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -1361,10 +1361,14 @@ void helper_mtc0_count(CPUMIPSState *env, target_ulong
arg1)
void helper_mtc0_entryhi(CPUMIPSState *env, target_ulong arg1)
{
-target_ulong old, val;
+target_ulong old, val, mask;
+mask = (TARGET_PAGE_MASK 1) | 0xFF;
+if (env-CP0_Config4 (1 CP0C4_IE)) {
+mask |= 1 CP0EnHi_EHINV;
+}
/* 1k pages not implemented */
-val = arg1 ((TARGET_PAGE_MASK 1) | 0xFF);
+val = arg1 mask;
Re: [Qemu-devel] [PATCH v4] spapr: add uuid/host details to device tree
On 08.07.14 07:00, Nikunj A Dadhania wrote:
Useful for identifying the guest/host uniquely within the
guest. Adding following properties to the guest root node.
vm,uuid - uuid of the guest
host-model - Host model number
host-serial - Host machine serial number
hypervisor type - Tells its kvm
Signed-off-by: Nikunj A Dadhania nik...@linux.vnet.ibm.com
---
v4: make uuid as human readable
v3: rebase to ppcnext
v2: indentation fixes
---
hw/ppc/spapr.c | 25 +
target-ppc/kvm.c | 44 +++-
target-ppc/kvm_ppc.h | 12
3 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 077ad2d..485ea66 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -318,6 +318,7 @@ static void *spapr_create_fdt_skel(hwaddr initrd_base,
QemuOpts *opts = qemu_opts_find(qemu_find_opts(smp-opts), NULL);
unsigned sockets = opts ? qemu_opt_get_number(opts, sockets, 0) : 0;
uint32_t cpus_per_socket = sockets ? (smp_cpus / sockets) : 1;
+char char_buf[512];
Can't you just return callee allocated, caller free'd memory?
add_str(hypertas, hcall-pft);
add_str(hypertas, hcall-term);
@@ -347,6 +348,30 @@ static void *spapr_create_fdt_skel(hwaddr initrd_base,
_FDT((fdt_property_string(fdt, model, IBM pSeries (emulated by
qemu;
_FDT((fdt_property_string(fdt, compatible, qemu,pseries)));
+if (kvm_enabled()) {
+_FDT((fdt_property_string(fdt, hypervisor, kvm)));
+}
+
+/*
+ * Add info to guest to indentify which host is it being run on
+ * and what is the uuid of the guest
+ */
+memset(char_buf, 0, sizeof(char_buf));
+if (!kvmppc_get_host_model(char_buf, sizeof(char_buf))) {
+_FDT((fdt_property_string(fdt, host-model, char_buf)));
+memset(char_buf, 0, sizeof(char_buf));
+}
+if (!kvmppc_get_host_serial(char_buf, sizeof(char_buf))) {
+_FDT((fdt_property_string(fdt, host-serial, char_buf)));
+}
Please be aware that all of the above is bogus when you start thinking
about live migration.
+
+snprintf(char_buf, 37, UUID_FMT, qemu_uuid[0], qemu_uuid[1],
g_strdup_printf()
+ qemu_uuid[2], qemu_uuid[3], qemu_uuid[4], qemu_uuid[5],
+ qemu_uuid[6], qemu_uuid[7], qemu_uuid[8], qemu_uuid[9],
+ qemu_uuid[10], qemu_uuid[11], qemu_uuid[12], qemu_uuid[13],
+ qemu_uuid[14], qemu_uuid[15]);
+_FDT((fdt_property_string(fdt, vm,uuid, char_buf)));
+
_FDT((fdt_property_cell(fdt, #address-cells, 0x2)));
_FDT((fdt_property_cell(fdt, #size-cells, 0x2)));
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 2d87108..25091f8 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1369,7 +1369,7 @@ static int read_cpuinfo(const char *field, char *value,
int len)
}
do {
-if(!fgets(line, sizeof(line), f)) {
+if (!fgets(line, sizeof(line), f)) {
break;
}
if (!strncmp(line, field, field_len)) {
@@ -1404,6 +1404,48 @@ uint32_t kvmppc_get_tbfreq(void)
return retval;
}
+int32_t kvmppc_get_host_serial(char *value, int len)
+{
+FILE *f;
+int ret = -1;
+char line[512];
+
+memset(line, 0, sizeof(line));
+f = fopen(/proc/device-tree/system-id, r);
+if (!f) {
+return ret;
+}
+
+if (fgets(line, sizeof(line), f)) {
+snprintf(value, len, IBM,%s, line);
Why IBM,system-id?
+ret = 0;
+}
+fclose(f);
+
+return ret;
I think it makes sense to extract the read a full file into a buffer
logic into a separate function. For bonus points, find a glib function
that already does it and use that ;).
+}
+
+int32_t kvmppc_get_host_model(char *value, int len)
+{
+FILE *f;
+int ret = -1;
+char line[512];
+
+memset(line, 0, sizeof(line));
+f = fopen(/proc/device-tree/model, r);
+if (!f) {
+return ret;
+}
+
+if (fgets(line, sizeof(line), f)) {
+snprintf(value, len, IBM,%s, line);
Same here - wouldn't this be IBM,IBM,foo?
Alex
+ret = 0;
+}
+fclose(f);
+
+return ret;
+}
+
/* Try to find a device tree node for a CPU with clock-frequency property */
static int kvmppc_find_cpu_dt(char *buf, int buf_len)
{
diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
index 1118122..6fa3314 100644
--- a/target-ppc/kvm_ppc.h
+++ b/target-ppc/kvm_ppc.h
@@ -19,6 +19,8 @@ uint32_t kvmppc_get_tbfreq(void);
uint64_t kvmppc_get_clockfreq(void);
uint32_t kvmppc_get_vmx(void);
uint32_t kvmppc_get_dfp(void);
+int32_t kvmppc_get_host_model(char *buf, int buf_len);
+int32_t kvmppc_get_host_serial(char *buf, int buf_len);
int kvmppc_get_hasidle(CPUPPCState *env);
int kvmppc_get_hypercall(CPUPPCState *env, uint8_t *buf, int buf_len);
int kvmppc_set_interrupt(PowerPCCPU *cpu, int irq, int level);
@@ -60,6 +62,16 @@ static inline uint32_t
Re: [Qemu-devel] [RFC PATCH 1/5] bootindex: add *_boot_device_path function
On 2014/7/8 16:33, Amos Kong wrote:
On Mon, Jul 07, 2014 at 05:10:57PM +0800, arei.gong...@huawei.com wrote:
From: Chenliang chenlian...@huawei.com
Add del_boot_device_path and modify_boot_device_path. Device should
be removed from boot device list by del_boot_device_path when device
hotplug. modify_boot_device_path is used to modify deviceboot order.
s/hotplug/is unhotplugged/
same issue in commitlog of patch 3/5
Signed-off-by: Chenliang chenlian...@huawei.com
Signed-off-by: Gonglei arei.gong...@huawei.com
---
include/sysemu/sysemu.h | 4
vl.c| 55
+
2 files changed, 59 insertions(+)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 285c45b..38ef1cd 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -204,6 +204,10 @@ void usb_info(Monitor *mon, const QDict *qdict);
void add_boot_device_path(int32_t bootindex, DeviceState *dev,
const char *suffix);
+void del_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
+void modify_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
char *get_boot_devices_list(size_t *size, bool ignore_suffixes);
DeviceState *get_boot_device(uint32_t position);
diff --git a/vl.c b/vl.c
index a1686ef..6264e11 100644
--- a/vl.c
+++ b/vl.c
@@ -1247,6 +1247,61 @@ void add_boot_device_path(int32_t bootindex,
DeviceState *dev,
QTAILQ_INSERT_TAIL(fw_boot_order, node, link);
}
+static bool is_same_fw_dev_path(DeviceState *src, DeviceState *target)
+{
+bool ret = false;
+char *devpath_src = qdev_get_fw_dev_path(src);
+char *devpath_target = qdev_get_fw_dev_path(target);
+
+if (!strcmp(devpath_src, devpath_target)) {
+ret = true;
+}
+
+g_free(devpath_src);
+g_free(devpath_target);
+return ret;
+}
+
+void del_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+FWBootEntry *i;
+
+assert(dev != NULL);
+
assert(booindex = 0 || suffix != NULL);
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (is_same_fw_dev_path(i-dev, dev)) {
if (!suffix) {
break;
}
+if (suffix i-suffix strcmp(i-suffix, suffix)) {
+continue;
+}
If suffix is NULL, then all the entries will be removed?
yes, it will be if caller don't give suffix.
+QTAILQ_REMOVE(fw_boot_order, i, link);
+g_free(i-suffix);
+g_free(i);
+break;
+}
+}
+
+if (bootindex == -1) {
if (bootindex 0) {
acked
+return;
+}
+
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (i-bootindex == bootindex) {
+QTAILQ_REMOVE(fw_boot_order, i, link);
+g_free(i-suffix);
+g_free(i);
+break;
+}
+}
+}
+
+void modify_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+del_boot_device_path(bootindex, dev, suffix);
+add_boot_device_path(bootindex, dev, suffix);
Why do you directly modify existed entry?
Sometimes, in old boot device list:
device_id bootindex
net0 1
net1 2
net2 3
we want to make vm reboot from net2, we can do it like this:
modify_boot_device_path(bootindex=1, DeviceState=net2, suffix=NULL), the new
boot device list will like this:
device_id bootindex
net2 1
net1 2
Best regards
Chenliang
+}
+
DeviceState *get_boot_device(uint32_t position)
{
uint32_t counter = 0;
--
1.7.12.4
[Qemu-devel] [Bug 1338277] Re: Ubuntu 14.04 + QEmu 2.0 + KSM = 1, makes Windows 2008 R2 guests to crash (BSOD)
** Project changed: qemu = qemu (Ubuntu) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338277 Title: Ubuntu 14.04 + QEmu 2.0 + KSM = 1, makes Windows 2008 R2 guests to crash (BSOD) Status in “qemu” package in Ubuntu: New Bug description: Guys, I'm trying to run Windows 2008 as a QEmu guest on my Ubuntu 14.04 but, after lots of tests, I figured out that it doesn't work, QEmu makes Windows 2008 to crash, and it is not a Windows fault, I'm pretty sure that it is a QEmu bug. Lab environment (5 servers): 3 physical servers: Dell R610 2 physycal servers: IBM x3650 * Where Windows crash (5 servers tested) ? Ubuntu 14.04 + QEmu 2.0 + VirtIO 0.1-81 = Windows 2008 crash every hour - Installed with apt-get install ubuntu-virt-server. * Where Windows do not crash (5 servers tested) ? Ubuntu 14.04 + Xen 4.4 + gplpv_Vista2008x64_1.0.1092.9 = Windows working smoothly - Installed with apt-get install xen-system-amd64. So, after removing QEmu from my environment, and using Xen instead, all Windows guests are now running without any crash. What kind of information, can I provide for you guys, to deep debug this QEmu problem ? Plus, it is interesting to note that a lot of times, all Windows guests (on top of QEmu / KVM) crashes at the exactly the same time! So, it can not be a problem within each Windows guest, but at the Hypervisor itself! Something happen there, that affects almost all Windows guests simultaneously. Also, it worth to mention that this problem is probably affecting clouds based on OpenStack IceHouse, on top of Ubuntu + QEmu 2.0... Screenshots: http://i.imgur.com/vnJSTgg.png http://i.imgur.com/34nADWr.png NOTE: I'm using KSM (Kernel Samepage Merging) with QEmu, to save RAM. It seems that when with Xen (+QEmu / HVM), KSM is not used :'( , but it is enabled ( 1 /sys/kernel/mm/ksm/run at Dom0's kernel). I did not tried to disable KSM to see if Windows becomes more stable on QEmu 2.0... Also, I did not run tests on this environment with Ubuntu 12.04.4 (or 12.04.4 with Ubuntu Cloud Archives, to get newer versions of QEmu (but not 2.0) for old LTS). CURIOSITY: On older hardware, like Dell R1950, and at my old Intel Desktop Core i7, I'm running Windows 2008 and 7, on Ubuntu 14.04 with QEmu 2.0 without any crash... I really like to figure out why QEmu is crashing Windows guests on Dell R610 and on IBM x3650... Attaching the VM's configuration files on next posts... Best, Thiago To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1338277/+subscriptions
Re: [Qemu-devel] [PULL 2.1 0/8] ppc patch queue 2014-07-08
On 8 July 2014 11:20, Alexander Graf ag...@suse.de wrote: Hi Peter, This is my latest bugfix queue for ppc for the 2.1 release. Please pull. Alex The following changes since commit 128f0e66149afb2dfc325dfd183aac345f417763: Merge remote-tracking branch 'remotes/afaerber/tags/prep-for-2.1' into staging (2014-07-07 19:06:55 +0100) are available in the git repository at: git://github.com/agraf/qemu.git tags/signed-ppc-for-upstream for you to fetch changes up to 0c6ab8c988830d3fe01c4ee88100a95ea95c49fa: PPC: e500: Actually install u-boot.e500 (2014-07-08 12:10:37 +0200) Patch queue for ppc - 2014-07-08 A few bug fixes for 2.1: Applied, thanks. -- PMM
Re: [Qemu-devel] [PATCH] prepend the include path of libvixl header files
On 7 July 2014 16:25, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: Currently the Makefile of disas/libvixl appends -I$(SRC_PATH)/disas/libvixl to QEMU_CFLAGS. As a consequence C++ files that #include utils.h, such as disas/libvixl/a64/instructions-a64.cc, are going to look for utils.h on all the other include paths first. When building QEMU as part of the Xen make system, another unrelated utils.h file is going to be chosen for inclusion, causing a build failure: In file included from disas/libvixl/a64/instructions-a64.cc:27:0: /qemu/disas/libvixl/a64/instructions-a64.h:88:64: error: ‘rawbits_to_float’ was not declared in this scope const float kFP32PositiveInfinity = rawbits_to_float(0x7f80); Fix the problem by prepending (rather than appending) the libvixl include path to QEMU_CFLAGS. Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com --- diff --git a/disas/libvixl/Makefile.objs b/disas/libvixl/Makefile.objs index 0adb3ce..17e6565 100644 --- a/disas/libvixl/Makefile.objs +++ b/disas/libvixl/Makefile.objs @@ -3,6 +3,6 @@ libvixl_OBJS = utils.o \ a64/decoder-a64.o \ a64/disasm-a64.o -$(addprefix $(obj)/,$(libvixl_OBJS)): QEMU_CFLAGS += -I$(SRC_PATH)/disas/libvixl +$(addprefix $(obj)/,$(libvixl_OBJS)): QEMU_CFLAGS := -I$(SRC_PATH)/disas/libvixl $(QEMU_CFLAGS) common-obj-$(CONFIG_ARM_A64_DIS) += $(libvixl_OBJS) Reviewed-by: Peter Maydell peter.mayd...@linaro.org I spent a few moments wondering if the conversion of QEMU_CFLAGS from recursively-expanded to simply-expanded would be a problem, but because this is a target-specific variable it's pretty much going to be expanded at the same point that it would be anyhow. thanks -- PMM
Re: [Qemu-devel] [PATCH 02/12] target-mips: update cpu_save/cpu_load to support KScratch registers
On 19/06/2014 18:43, Richard Henderson wrote: You must update CPU_SAVE_VERSION when you change the contents of the save data. For extra credit, consider updating target-mips to VMStateDescription structure(s). r~ v2 contains updated CPU_SAVE_VERSION. VMStateDescription structures sound like nice to have in target-mips - at the moment I'm not able to look at this, but I'll keep that in mind. Thanks, Leon
Re: [Qemu-devel] [PATCH] prepend the include path of libvixl header files
On Tue, 8 Jul 2014, Peter Maydell wrote: On 8 July 2014 12:55, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: Are you going to pick it up or do you want me to send a pull request? I'm going to put it in the target-arm pullreq I'm currently testing. Great, thanks!
Re: [Qemu-devel] [PATCH] Makefile: Don't build generated headers before Makefile is reread
On 4 July 2014 15:33, Peter Maydell peter.mayd...@linaro.org wrote: On 30 June 2014 13:09, Paolo Bonzini pbonz...@redhat.com wrote: Il 28/06/2014 18:59, Peter Maydell ha scritto: Having a direct dependency Makefile: $(GENERATED_HEADERS) can result in not-from-clean builds failing sometimes, because it means that when Make does its is any makefile or include out of date and needing a rebuild? check, as well as possibly running configure (to update config-host.mak) it will also rebuild GENERATED_HEADERS under the old config-host.mak regime. If the makefile rules for rebuilding the generated headers have changed in a way that means they're not compatible with the old config-host.mak variable names, the build will fail. Even if it does work, it's wasted effort since we'll need to rebuild them with the right config-host.mak settings immediately. Instead, make the generated headers depend on config-host.mak and config-target.mak. This means we'll definitely rebuild them if the configuration changes, but it will be done after Make reloads its makefiles and includes so will happen with the correct set of config-host.mak settings. We rely on the various .o files having correct autogenerated dependency rules to cause the generated headers to be generated as and when they are needed. Reviewed-by: Paolo Bonzini pbonz...@redhat.com Any objections to this going into 2.1 for rc1 ? Unfortunately it doesn't seem to work correctly for a build from clean: e104462:trusty:qemu-for-merges$ make -C build/alldbg V=1 make: Entering directory `/home/petmay01/linaro/qemu-for-merges/build/alldbg' libtool --mode=compile --tag=CC ccache gcc -I/home/petmay01/linaro/qemu-for-merges/tcg -I/home/petmay01/linaro/qemu-for-merges/tcg/i386 -I/home/petmay01/linaro/qemu-for-merges/linux-headers -I/home/petmay01/linaro/qemu-for-merges/build/alldbg/linux-headers -I. -I/home/petmay01/linaro/qemu-for-merges -I/home/petmay01/linaro/qemu-for-merges/include -I/home/petmay01/linaro/qemu-for-merges/libcacard -Ilibcacard -Werror -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/p11-kit-1 -I/usr/include/libpng12 -I/usr/include/spice-server -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/spice-1 -I/usr/include/libusb-1.0 -I/usr/include/pixman-1 -I/home/petmay01/linaro/qemu-for-merges/tests -MMD -MP -MT libcacard/cac.lo -MF libcacard/cac.d -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -c -o libcacard/cac.lo /home/petmay01/linaro/qemu-for-merges/libcacard/cac.c libtool: compile: ccache gcc -I/home/petmay01/linaro/qemu-for-merges/tcg -I/home/petmay01/linaro/qemu-for-merges/tcg/i386 -I/home/petmay01/linaro/qemu-for-merges/linux-headers -I/home/petmay01/linaro/qemu-for-merges/build/alldbg/linux-headers -I. -I/home/petmay01/linaro/qemu-for-merges -I/home/petmay01/linaro/qemu-for-merges/include -I/home/petmay01/linaro/qemu-for-merges/libcacard -Ilibcacard -Werror -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1 -I/usr/include/p11-kit-1 -I/usr/include/libpng12 -I/usr/include/spice-server -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/spice-1 -I/usr/include/libusb-1.0 -I/usr/include/pixman-1 -I/home/petmay01/linaro/qemu-for-merges/tests -MMD -MP -MT libcacard/cac.lo -MF libcacard/cac.d -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -c /home/petmay01/linaro/qemu-for-merges/libcacard/cac.c -fPIC -DPIC -o libcacard/.libs/cac.o In file included from /home/petmay01/linaro/qemu-for-merges/include/qemu-common.h:15:0, from /home/petmay01/linaro/qemu-for-merges/libcacard/cac.c:8: /home/petmay01/linaro/qemu-for-merges/include/qemu/compiler.h:6:25: fatal error: config-host.h: No such file or directory #include config-host.h ^ compilation terminated. We're trying to do a build .o file and .d file in the same go gcc command, so the fact that we don't have the generated header yet causes us to blow up. This would work if we built the .d files separately using -MG to tell gcc to ignore missing headers... thanks -- PMM
Re: [Qemu-devel] [PATCH] prepend the include path of libvixl header files
On 8 July 2014 12:55, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: Are you going to pick it up or do you want me to send a pull request? I'm going to put it in the target-arm pullreq I'm currently testing. thanks -- PMM
[Qemu-devel] [Bug 1338277] Re: Ubuntu 14.04 + QEmu 2.0 + KSM = 1, makes Windows 2008 R2 guests to crash (BSOD)
** Description changed: Guys, I'm trying to run Windows 2008 as a QEmu guest on my Ubuntu 14.04 but, after lots of tests, I figured out that it doesn't work, QEmu makes Windows 2008 to crash, and it is not a Windows fault, I'm pretty sure that it is a QEmu bug. Lab environment (5 servers): 3 physical servers: Dell R610 2 physycal servers: IBM x3650 * Where Windows crash (5 servers tested) ? Ubuntu 14.04 + QEmu 2.0 + VirtIO 0.1-81 = Windows 2008 crash every hour - Installed with apt-get install ubuntu-virt-server. * Where Windows do not crash (5 servers tested) ? Ubuntu 14.04 + Xen 4.4 + gplpv_Vista2008x64_1.0.1092.9 = Windows working smoothly - Installed with apt-get install xen-system-amd64. So, after removing QEmu from my environment, and using Xen instead, all Windows guests are now running without any crash. What kind of information, can I provide for you guys, to deep debug this QEmu problem ? Plus, it is interesting to note that a lot of times, all Windows guests (on top of QEmu / KVM) crashes at the exactly the same time! So, it can not be a problem within each Windows guest, but at the Hypervisor itself! Something happen there, that affects almost all Windows guests simultaneously. Also, it worth to mention that this problem is probably affecting clouds based on OpenStack IceHouse, on top of Ubuntu + QEmu 2.0... Screenshots: http://i.imgur.com/vnJSTgg.png http://i.imgur.com/34nADWr.png NOTE: I'm using KSM (Kernel Samepage Merging) with QEmu, to save RAM. It seems that when with Xen (+QEmu / HVM), KSM is not used :'( , but it is enabled ( 1 /sys/kernel/mm/ksm/run at Dom0's kernel). I did not tried to disable KSM to see if Windows becomes more stable on QEmu 2.0... Also, I did not run tests on this environment with Ubuntu 12.04.4 (or 12.04.4 with Ubuntu Cloud Archives, to get newer versions of QEmu (but not 2.0) for old LTS). - CURIOSITY: On older hardware, like Dell R1950 / even R200, and at my old - Intel Desktop Core i7, I'm running Windows 2008 and 7, on Ubuntu 14.04 - with QEmu 2.0 without any crash... I really like to figure out why QEmu - is crashing Windows guests on Dell R610 and on IBM x3650... + CURIOSITY: On older hardware, like Dell R1950, and at my old Intel + Desktop Core i7, I'm running Windows 2008 and 7, on Ubuntu 14.04 with + QEmu 2.0 without any crash... I really like to figure out why QEmu is + crashing Windows guests on Dell R610 and on IBM x3650... Attaching the VM's configuration files on next posts... Best, Thiago -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1338277 Title: Ubuntu 14.04 + QEmu 2.0 + KSM = 1, makes Windows 2008 R2 guests to crash (BSOD) Status in QEMU: New Bug description: Guys, I'm trying to run Windows 2008 as a QEmu guest on my Ubuntu 14.04 but, after lots of tests, I figured out that it doesn't work, QEmu makes Windows 2008 to crash, and it is not a Windows fault, I'm pretty sure that it is a QEmu bug. Lab environment (5 servers): 3 physical servers: Dell R610 2 physycal servers: IBM x3650 * Where Windows crash (5 servers tested) ? Ubuntu 14.04 + QEmu 2.0 + VirtIO 0.1-81 = Windows 2008 crash every hour - Installed with apt-get install ubuntu-virt-server. * Where Windows do not crash (5 servers tested) ? Ubuntu 14.04 + Xen 4.4 + gplpv_Vista2008x64_1.0.1092.9 = Windows working smoothly - Installed with apt-get install xen-system-amd64. So, after removing QEmu from my environment, and using Xen instead, all Windows guests are now running without any crash. What kind of information, can I provide for you guys, to deep debug this QEmu problem ? Plus, it is interesting to note that a lot of times, all Windows guests (on top of QEmu / KVM) crashes at the exactly the same time! So, it can not be a problem within each Windows guest, but at the Hypervisor itself! Something happen there, that affects almost all Windows guests simultaneously. Also, it worth to mention that this problem is probably affecting clouds based on OpenStack IceHouse, on top of Ubuntu + QEmu 2.0... Screenshots: http://i.imgur.com/vnJSTgg.png http://i.imgur.com/34nADWr.png NOTE: I'm using KSM (Kernel Samepage Merging) with QEmu, to save RAM. It seems that when with Xen (+QEmu / HVM), KSM is not used :'( , but it is enabled ( 1 /sys/kernel/mm/ksm/run at Dom0's kernel). I did not tried to disable KSM to see if Windows becomes more stable on QEmu 2.0... Also, I did not run tests on this environment with Ubuntu 12.04.4 (or 12.04.4 with Ubuntu Cloud Archives, to get newer versions of QEmu (but not 2.0) for old LTS). CURIOSITY: On older hardware, like Dell R1950, and at my old Intel Desktop Core i7, I'm running Windows 2008 and 7, on Ubuntu 14.04
Re: [Qemu-devel] [PATCH v4] spapr: add uuid/host details to device tree
Alexander Graf ag...@suse.de writes:
On 08.07.14 13:04, Nikunj A Dadhania wrote:
Alexander Graf ag...@suse.de writes:
On 08.07.14 07:00, Nikunj A Dadhania wrote:
Useful for identifying the guest/host uniquely within the
guest. Adding following properties to the guest root node.
vm,uuid - uuid of the guest
host-model - Host model number
host-serial - Host machine serial number
hypervisor type - Tells its kvm
Signed-off-by: Nikunj A Dadhania nik...@linux.vnet.ibm.com
---
v4: make uuid as human readable
v3: rebase to ppcnext
v2: indentation fixes
---
hw/ppc/spapr.c | 25 +
target-ppc/kvm.c | 44 +++-
target-ppc/kvm_ppc.h | 12
3 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 077ad2d..485ea66 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -318,6 +318,7 @@ static void *spapr_create_fdt_skel(hwaddr initrd_base,
QemuOpts *opts = qemu_opts_find(qemu_find_opts(smp-opts), NULL);
unsigned sockets = opts ? qemu_opt_get_number(opts, sockets, 0) :
0;
uint32_t cpus_per_socket = sockets ? (smp_cpus / sockets) : 1;
+char char_buf[512];
Can't you just return callee allocated, caller free'd memory?
Tried doing it more in line of read_cpuinfo in target-ppc/kvm.c
I could do it either ways.
Yeah, feel free to convert that one too if you like ;).
add_str(hypertas, hcall-pft);
add_str(hypertas, hcall-term);
@@ -347,6 +348,30 @@ static void *spapr_create_fdt_skel(hwaddr initrd_base,
_FDT((fdt_property_string(fdt, model, IBM pSeries (emulated by
qemu;
_FDT((fdt_property_string(fdt, compatible, qemu,pseries)));
+if (kvm_enabled()) {
+_FDT((fdt_property_string(fdt, hypervisor, kvm)));
+}
+
+/*
+ * Add info to guest to indentify which host is it being run on
+ * and what is the uuid of the guest
+ */
+memset(char_buf, 0, sizeof(char_buf));
+if (!kvmppc_get_host_model(char_buf, sizeof(char_buf))) {
+_FDT((fdt_property_string(fdt, host-model, char_buf)));
+memset(char_buf, 0, sizeof(char_buf));
+}
+if (!kvmppc_get_host_serial(char_buf, sizeof(char_buf))) {
+_FDT((fdt_property_string(fdt, host-serial, char_buf)));
+}
Please be aware that all of the above is bogus when you start thinking
about live migration.
Yes, there are tools that look at these. Is there a way to update these
on migration?
As Ben already mentioned ;).
+
+snprintf(char_buf, 37, UUID_FMT, qemu_uuid[0], qemu_uuid[1],
g_strdup_printf()
Ok.
+ qemu_uuid[2], qemu_uuid[3], qemu_uuid[4], qemu_uuid[5],
+ qemu_uuid[6], qemu_uuid[7], qemu_uuid[8], qemu_uuid[9],
+ qemu_uuid[10], qemu_uuid[11], qemu_uuid[12], qemu_uuid[13],
+ qemu_uuid[14], qemu_uuid[15]);
+_FDT((fdt_property_string(fdt, vm,uuid, char_buf)));
+
_FDT((fdt_property_cell(fdt, #address-cells, 0x2)));
_FDT((fdt_property_cell(fdt, #size-cells, 0x2)));
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 2d87108..25091f8 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1369,7 +1369,7 @@ static int read_cpuinfo(const char *field, char
*value, int len)
}
do {
-if(!fgets(line, sizeof(line), f)) {
+if (!fgets(line, sizeof(line), f)) {
break;
}
if (!strncmp(line, field, field_len)) {
@@ -1404,6 +1404,48 @@ uint32_t kvmppc_get_tbfreq(void)
return retval;
}
+int32_t kvmppc_get_host_serial(char *value, int len)
+{
+FILE *f;
+int ret = -1;
+char line[512];
+
+memset(line, 0, sizeof(line));
+f = fopen(/proc/device-tree/system-id, r);
+if (!f) {
+return ret;
+}
+
+if (fgets(line, sizeof(line), f)) {
+snprintf(value, len, IBM,%s, line);
Why IBM,system-id?
There were userspace tools that looking at lparcfg, and were encoded
similarly.
I don't think we own the IBM namespace, so I find this slightly bogus.
Also why would a host machine have to be made by IBM?
You have a valid point, i will remove the IBM prefix :-)
+ret = 0;
+}
+fclose(f);
+
+return ret;
I think it makes sense to extract the read a full file into a buffer
logic into a separate function. For bonus points, find a glib function
that already does it and use that ;).
Let me search.
+}
+
+int32_t kvmppc_get_host_model(char *value, int len)
+{
+FILE *f;
+int ret = -1;
+char line[512];
+
+memset(line, 0, sizeof(line));
+f = fopen(/proc/device-tree/model, r);
+if (!f) {
+return ret;
+}
+
+if (fgets(line, sizeof(line), f)) {
+snprintf(value, len, IBM,%s, line);
Same here - wouldn't this be IBM,IBM,foo?
No, it will be IBM,model
Hrm, I just tried to
Re: [Qemu-devel] [PATCH v2 2/9] softmmu: provide softmmu access type enum
On 8 July 2014 08:57, Leon Alrae leon.al...@imgtec.com wrote:
New MIPS features depend on the access type and enum is more convenient than
using the numbers directly.
Mmm, I've thought for a while it would be better to have this
be an enum, but never got round to it.
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
include/exec/cpu-common.h |6 ++
softmmu_template.h| 26 --
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index e3ec4c8..1c3171a 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -26,6 +26,12 @@ typedef struct CPUListState {
FILE *file;
} CPUListState;
+enum mmu_access_type {
CODING_STYLE says enum names should be CamelCase.
I think you also want this to be a typedef.
+MMU_DATA_LOAD = 0,
+MMU_DATA_STORE = 1,
+MMU_INST_FETCH = 2
+};
+
We should probably also chase through and update the
prototypes of functions like tlb_fill() and cpu_unaligned_access()
and so on to take this enum type rather than int. (I
suspect there's a lot of those running into different
targets so it might need doing over multiple patches.)
thanks
-- PMM
Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
On 8 July 2014 08:13, Al Viro v...@zeniv.linux.org.uk wrote: Actually, that's badly worded; what codepath ends up setting si_code on e.g. fp addition overflows? In system mode it's done by completion code in the kernel, but AFAICS in user mode there are only two places where it might happen - one is gentrap handling and another - osf_setsysinfo(2) emulation for TARGET_SSI_IEEE_FP_CONTROL. What I don't understand is how do we get from float_raise(FP_STATUS, float_flag_overflow) in fpu/softfloat.c to either of those. IOW, suppose I do x = DBL_MAX; feenableexcept(FE_ALL_EXCEPT); x *= x; I understand how I'll get SIGFPE, but what will set correct si_code in siginfo I'll see in the hanler? The code we have currently may well be buggy, but the correct place to set si_code is (as Richard says) the Alpha cpu_loop() in linux-user/main.c, which has access to the trap type that just caused us to stop executing code, plus the CPUState, which should be enough information to set si_code correctly. In particular the GENTRAP case seems to be setting a variety of different si_code values for SIGFPE. thanks -- PMM
[Qemu-devel] [PULL for-2.1 3/3] s390x/css: reflect cpa in scsw
We neglected to update the the channel-program-address field of the scsw
after completion of the start or the halt function: Fortunately, Linux
didn't miss it so far. Let's update it for the cases where the cpa is
expected to be valid; in some cases, the cpa is 'unpredictable', so we
leave it untouched.
Reviewed-by: David Hildenbrand d...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
hw/s390x/css.c |9 +
1 file changed, 9 insertions(+)
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index e758890..49c2aaf 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -200,6 +200,7 @@ static void sch_handle_halt_func(SubchDev *sch)
PMCW *p = sch-curr_status.pmcw;
SCSW *s = sch-curr_status.scsw;
+hwaddr curr_ccw = sch-channel_prog;
int path;
/* Path management: In our simple css, we always choose the only path. */
@@ -216,6 +217,10 @@ static void sch_handle_halt_func(SubchDev *sch)
(s-ctrl SCSW_ACTL_SUSP))) {
s-dstat = SCSW_DSTAT_DEVICE_END;
}
+if ((s-ctrl (SCSW_ACTL_SUBCH_ACTIVE | SCSW_ACTL_DEVICE_ACTIVE)) ||
+(s-ctrl SCSW_ACTL_SUSP)) {
+s-cpa = curr_ccw + 8;
+}
s-cstat = 0;
p-lpum = path;
@@ -398,6 +403,7 @@ static void sch_handle_start_func(SubchDev *sch, ORB *orb)
s-ctrl |= SCSW_STCTL_PRIMARY | SCSW_STCTL_SECONDARY |
SCSW_STCTL_STATUS_PEND;
s-dstat = SCSW_DSTAT_CHANNEL_END | SCSW_DSTAT_DEVICE_END;
+s-cpa = sch-channel_prog + 8;
break;
case -ENOSYS:
/* unsupported command, generate unit check (command reject) */
@@ -408,6 +414,7 @@ static void sch_handle_start_func(SubchDev *sch, ORB *orb)
s-ctrl = ~SCSW_CTRL_MASK_STCTL;
s-ctrl |= SCSW_STCTL_PRIMARY | SCSW_STCTL_SECONDARY |
SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND;
+s-cpa = sch-channel_prog + 8;
break;
case -EFAULT:
/* memory problem, generate channel data check */
@@ -416,6 +423,7 @@ static void sch_handle_start_func(SubchDev *sch, ORB *orb)
s-ctrl = ~SCSW_CTRL_MASK_STCTL;
s-ctrl |= SCSW_STCTL_PRIMARY | SCSW_STCTL_SECONDARY |
SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND;
+s-cpa = sch-channel_prog + 8;
break;
case -EBUSY:
/* subchannel busy, generate deferred cc 1 */
@@ -436,6 +444,7 @@ static void sch_handle_start_func(SubchDev *sch, ORB *orb)
s-ctrl = ~SCSW_CTRL_MASK_STCTL;
s-ctrl |= SCSW_STCTL_PRIMARY | SCSW_STCTL_SECONDARY |
SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND;
+s-cpa = sch-channel_prog + 8;
break;
}
} while (ret == -EAGAIN);
--
1.7.9.5
[Qemu-devel] [PULL for-2.1 2/3] pc-bios/s390-ccw: update binary
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
---
pc-bios/s390-ccw.img | Bin 17624 - 17752 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/pc-bios/s390-ccw.img b/pc-bios/s390-ccw.img
index
603e19e003d574b24bb3b97bacda2bf38077e8fd..e3ea0d5664f01ff472d3531980941fb5f163ff02
100644
GIT binary patch
delta 5380
zcmZ`-4Rlo15x#HtCGYL#hutJ3oB!Pqk`Mw!e#}-mvI#j7G}x8KHmS6YtyrXjsm6*5
zU0PBL3QBUJqH=0f-~m!hg3!?ujwCFTjF2E7IoW#V*2vX^j%{`pvv0~w^*fA$g
z^Ud73Gjs2I$Z~+(Fc_ErGX}4kC06oHZcu}pwL7}qzQL-sM2-RR#qPE?kFyd+E6V?
zp;B$NP`f*Fm2mfugWkg=St*oJ+C5PDzl6E6MDYf;5L%0t{TGF3nB*A4d0`H%!uI=
zBJ2?dO^*z!xXg2Zo8Z6tm=(ILub5^_gfe`xZ^qcXxF$kYp{PskxC^rWnc@Kyx
zM)bmiKI?CS~yaTS(asViPdH=yuKRG79Nq_;u#RW-mTnZzsoY^|_9%MFAhU=6=W
zH9EyNjZH%F-Dd0)V(TqJ)ORGd7^^L7z{=Zg#p*s#-n0;@P^;+;6U+ot~#$@5d
zBH7(aVh3ni)}#2H5%VN=ithYe@KcNfLNR`C{oV8)UTQ!SeEqElvTa{gZwpX=Ad=
zu(-~UR)*Y9iqz9A`8rEh#6oA9uW6|#BVN3soBb#oK!yR1JMgVvkub`8%rv$dDD
z#2ywvzri?+te_W6%E}x_9*jqhB-)Wm#FzOjCA-x`C|F)E+Mg?mAlK(ido4`}zla|
zgT!iQkbbry^nO+Jv-!ge@@B%Jn@R@$1dM`EeO$QmSEiH1dVA%ImZ@nPz)32Z8fe
z#Gg%s?OKj0OuBrE0t-_oH7kn2*X+-bInj;{b$B_`7bOSQFa82KU5v$IwhS0c}O
z)-X$Vl8LLE(yAD=gX?y1jGJw=DU6pdK}$y8%jo5deqgr8U-zPSU;^wPH-bVKFJULO
ziO80Ckw`AVYpm|tp{TM0iV!g-fQ;DEoHogG#zx*l@1bfJ;M}U4|OthDTW#Dd
z6qQDhvuIiIgt1zP{W)S;{FgX8L_?rBooMq?5*CIVp-IK04~B#zP7k+j1__N9n!
zPL4OfADSF2DAF${iIOy^~~EjUr(+^s+)TI98K+g+)#AUxDn)Y$u}MvozMOYvD
z!TfRJGj3%|=b`#O4WZr_uaiUB#gXqMH#7u{zU0{d+vbuZVk;?Tk;AmTG*s*6ao
zc%3JCoe8wg`QM-^7qadJ)=B37#QZwOjU`;{IdXF-|EK^triM$*B=I-tPk=#PtMNv
z*hTEJyeMWBg1?{-L%#}lNEB5IQ0=G{N9MPL2Fj^E#x+8T)uNgz{5I0k+G^To#M3H
zAH38IULz;j;x;e^p|)C-$G?HvEF!q4jxK8$@nAOQFExz%@_UqeWJ*26=QJZli6mU
z%BZO==0JIif1rG9zfoY-YEK1RJodTdId#g%nsw)778x84#FVok3|kC%yBkx{UX
zX*!}U*dGvCMx*6NcG5Y(d~%U;hWTRV;~ear9Bc-H=ww|A)v6W15bI2ao-@^@Mply
zrDFiU3m~5-+#jS@7N7{2?}!v@CzYr0~!Q?gVqLX`re?T|7ltyEV7{l1{jD1;d
z$gQ05OpiOUvqvPJF*+R!GqPx3G91EeP3cbbw;;#KZrDPIvOcgaLoz`ZCgx=gK
zC+Ag;yNNNg?8AeNU%}`bSvnoO-aJo+OMQ{%5Q((Pi*FgB*n)DT=kSJ{#rAr_;65
z{IxfordTg7^n$yByr?6Lo6bBP2$8muZ3;FjCdz2{joZWe6ReM5=P=~=LfTms~d%x
zasll6ob|6Um`kYQUWMZp!k#+?Z0acXea0SSJztmV^UPnx*rNzS8^!*avD+dH;A=qb
zWghQPIPQ;`W`=#OXb)YyR$P17_I}hPci=^w!(6-qQk6T`vpDxK8oQfxFMLb`#!R
zcnzQ#P6$;SBs*8M`kZfBJ8T;Qj{*@xfnv8y{}O@4ml7Sg89yI3L@OVq2_#jn{m
zNW9zRg}#b+kZ}FsO=mCO_My)W*ooaTnCviVViAi6QWLY?SsvNi)D39C0s;x^Flvk
zBbANTvQb6M?7h{_QtH`DvXniC%?B{+@Q{n*y_7%m9|mzeseS|K4Z?ed4(-(_c~+I
zs+RTnzrefnYkh2ZTs9XJN046h^9vWVp|ixfi(T}vi*4*;GP^iTXU4Uu)zcx`Jb34I
ziCog^`x)8IR@e#w#%B$RzGV6w$0Nq+P3WjJcV4esa3oy?zOgN=0fu6e-t0zR0M
z2i5(K%qbif0s=2d=ydaYZmhSYPS70^C9T$zIu+R$_b4iw5(mjI($jluKJ^-N7{
z2YsdIGNy;AVEXSz*V=@OCVuG`q5Cf5+-XnDFP|^;mh!ii(nXD-Z=t|#^_WQ;rOVa
zGv$YclhU53pN|WMy7FmRQdF$O;dcZrvTLp?;+})gDgzSi)$}ki@ad$oFio4z^m
zIq0)NxPY~+wgsOc?9PA+;uSz#Oi*B@W#f%S2;2i+obS7Q(Q+!d6$x%bMF;n4S
zCg1Tt#9NAAk~!5XFPexz!z|%p1H)z1{jkZj}C?B%?VdkUEFJg=%=4sEviO36
zjINP5r~cfWBzs@?F+HKXq@vTVj+BItNcZsJe{e3mupLkr~L(Y{$BEz%9n=1872q
zi^6w?b1rrM+IJH+yQy4r1elVYiy+IAVzJ`y7+b{4(Z|HOm@$47l4+xrY-W`z4{j
zO5cCxN})HcqzjPFnjTPFKqOtyK!yjXXC0w!(M;!5Tq`a%S($hzK+X7r2d8S+SDw!
zm0o*U1tT*qL9#^fU9IPmR`6Y|tkD5WSPI#F{HAe|62dG1${Cd~G{PcaA@ywD%Ed
z)c#iZ^l#8PNcZ{Ya;LvE`vCcKJb7`o6y(BR?A=Y5QQzogl=8H62a1(PWL2P4StXkS
z6K_~TUd~U(dWCOl13LAmbq2FfC{rnT`y$Rd;x9AfxnFSR2*W`t(b{y@!*hfWC#V
zQhX|))AhTrl!pTi4(+^5FY~A0ts7T}O!{WM+bx4-UsB%Qv$pKC5_pNA)tiajYM$_
zpT@KI@3$9C7zulPuAF0WI5ASw;H}+}z5Hi{nPKPy3bNu+nLfTyc~Dl3-=oZx
z$Hs?(u~CD~mg9O=IV}Q6-cxWNeUc_#F64p)bPOZnGVWXP6^z@!1PSbO}?6v_bN
z#ccW6jg}{iE-v~T5g`P$5te@_pQ@NWiT~bPyW_ts4s0CrKP`64tjgJAJLt=M`Ivh
zYIESVm{(jZ7gs(!=L$rgb20MeQ!)35?h89vUX6K{SU);1!#vxb$KOjVvimp1DMM9l
z8Gof!Rvn?et$Iant6G@06@A@AeSP09nLA;g@*{ckgmKD^a`l9M$9-PeTpdtO$febJ
zQ%+J@wk*Wh@zI!^A8XcGaF4(rrh)*`s2R}A4^m3ylz^FL(09s%d4$~8fCIqt{
zmM_Y|K_Dte|o=erzU$K6QcFj^DOeN4vmGbH2{K?}3eZhJi;CDkZ;G?^xJ*
z*Bwjm^atER25S!PNu9LWnQkQjuoMU3_BxZ!x0$*S7KT3EWjbp0qq20bLK;Vp;DV
z1zl@d@1=w81#JaA26_xfCEc=O2SFPxjeI!cXV3T$!5@9mUSu$3f$(_U1vM3-Y(
ziOrxhE$hq%;|G#;FDS~Sm2YHpj$xUzCh#HqbXf33$@7231_cDkuU}i!AG3=q7bK
zXccHPXb|*f?eC3pa@jm0J;wp{{D?XRQMahMpEEQlqsCe0y5fcwoaszvc*54aaF
z5z}d^MTJieO)K-NX}Ra^Csz^k$3A5=aWn%?4t$sIr_W#?-4HPI)MGowioLCeut}
z$@f800@p_rqj?n9IEt%*{C!daH!N39ugFp;TudD+i6T2u3L~tk|1EDG?Pw?rnbuy
z({9kiWW`VL{iv%88(%!y~JzL%!CZjsH{eLx3TMgyKAcp9dO7WMLfjKJ=?dYwih
z8rXd7}95T%66RU5)lEJ0zns@?1CDvz%bh}|SUdFybLJT(^Y{s#RCR%iClqg0f
z9+Ll-CXgqHVwB(^`7xSk(OeHvj0!v?AEXK7L82H-@jiOr-GgZdShAMUwlOm6b
zO=AllGMGsd$PW_5NCxC=p$X)#5XHD4zl|o4b6}UqyOQ#gL`Al3fJL2~lZs(tSb%t
z)}Hwm5XD%Grv@l?r$v2-+8d8x0+5mEn3jGXM5dTT^?z4?RixBwGvPvM%2PN=eirj
zv%g9IJ4{Q`SZ`5nE$^Kl|Owr;6T{d+XPzH{aBGlf1H_T|U}Sp)8YT!{tg?e%cUp
zCCgfWSO#a;d6Tv#6DmYUIkQ@mSjC_|@_zMBjURydXN!4IaV`VyL0U9q%;{r
pR2iCGsC-ctH5Mu-Ww3Fa(h9!7(J)vYrM+cFfnQH9cecD{sRXFPAid
delta 5386
zcmZu#4RBP|6~1qGllOL$z$S#vh9qP+q$H3?R!ImI3L6qMATm)?B-U!$LTw!kDMmyM
zF2#(J7Kcr)bSkAbwn-mSswqK-XeiI17A;Cj#nNgu?ZT9HV|js8Kq9Z-IlDdOyA6V
z=jWckd(XM-rZ9_P)@Zf;avX~5qp9$uw*sEpqMWbMNqhevn^QQJQ^D;INH{j)Ar^K
zsbQkG2xT0~pyH9!mDK+`Qs6L^6FsT|3I*YhvHeXPdHVk{nd#hoa}qMvyvFeR8
zLTFd$n{q@Sfxa4DZw5rZF(AYw6%yXA_k_YyZy9c(Ej|RxrK1(C6=YPh@VB%gj*zg
[Qemu-devel] [Bug 1307473] Re: guest hang due to missing clock interrupt
Note that my list of affected nodes also include migrated VMs, so there are some false positives (VMs that came from an affected node). The affected VMs on node 1-8 all seem to be migrated from another node. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1307473 Title: guest hang due to missing clock interrupt Status in QEMU: New Status in “linux” package in Ubuntu: Confirmed Status in “qemu” package in Ubuntu: Confirmed Bug description: I noticed on 2 different systems that after upgrade from precise to latest trusty VMs are crashing: - in case of Windows VMs I'm getting BSOD with error message: A clock interrupt was not received on a secondary processor within the allocated time interval. - On linux VMs I'm noticing hrtimer: interrupt took 2992229 ns messages - On some proprietary virtual appliances I'm noticing crashes an due to missing timer interrupts QEMU version is: QEMU emulator version 1.7.91 (Debian 2.0.0~rc1+dfsg-0ubuntu3) Full command line: qemu-system-x86_64 -enable-kvm -name win7eval -S -machine pc- i440fx-1.7,accel=kvm,usb=off -cpu host -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 05e5089a- 4aa1-6bb2-ef06-ab4d020a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7eval.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb- uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/vm/win7eval.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio- disk0,id=virtio-disk0,bootindex=1 -drive file=/home/damarion/iso/7600.16385.090713-1255_x86fre_enterprise_en- us_EVAL_Eval_Enterprise-GRMCENEVAL_EN_DVD.iso,if=none,id=drive- ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive =drive-ide0-0-0,id=ide0-0-0 -drive file=/home/damarion/iso/virtio- win-0.1-74.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:38:31:0a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1307473/+subscriptions
[Qemu-devel] [Bug 1307473] Re: guest hang due to missing clock interrupt
Ondergetekende, can you provide further details to why you believe Bug #1326367 is causing this? Would you be willing to test a 3.11.0-24-generic kernel (reported stable) + the futex fix, or a chosen stable version of the 3.13 or 3.15 kernel with just the futex fix. To verify that the futex fix is the problem? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1307473 Title: guest hang due to missing clock interrupt Status in QEMU: New Status in “linux” package in Ubuntu: Confirmed Status in “qemu” package in Ubuntu: Confirmed Bug description: I noticed on 2 different systems that after upgrade from precise to latest trusty VMs are crashing: - in case of Windows VMs I'm getting BSOD with error message: A clock interrupt was not received on a secondary processor within the allocated time interval. - On linux VMs I'm noticing hrtimer: interrupt took 2992229 ns messages - On some proprietary virtual appliances I'm noticing crashes an due to missing timer interrupts QEMU version is: QEMU emulator version 1.7.91 (Debian 2.0.0~rc1+dfsg-0ubuntu3) Full command line: qemu-system-x86_64 -enable-kvm -name win7eval -S -machine pc- i440fx-1.7,accel=kvm,usb=off -cpu host -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 05e5089a- 4aa1-6bb2-ef06-ab4d020a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7eval.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb- uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/vm/win7eval.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio- disk0,id=virtio-disk0,bootindex=1 -drive file=/home/damarion/iso/7600.16385.090713-1255_x86fre_enterprise_en- us_EVAL_Eval_Enterprise-GRMCENEVAL_EN_DVD.iso,if=none,id=drive- ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive =drive-ide0-0-0,id=ide0-0-0 -drive file=/home/damarion/iso/virtio- win-0.1-74.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:38:31:0a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1307473/+subscriptions
Re: [Qemu-devel] [PATCH] Handle G_IO_HUP in tcp_chr_read for tcp chardev
On Mon, 7 Jul 2014, Nikolay Nikolaev wrote:
On Tue, Jul 1, 2014 at 2:52 PM, Kirill Batuzov batuz...@ispras.ru wrote:
Due to GLib limitations it is not possible to create several watches on one
channel on Windows hosts. See bug #338943 in GNOME bugzilla for details:
https://bugzilla.gnome.org/show_bug.cgi?id=338943
Handle G_IO_HUP in tcp_chr_read. It is already watched by corresponding
watch.
Also remove the second watch with its handler.
Shall this work when the connection is idle and the remote end closes it?
Yes, this should work. Why do you think it may not? The watch is
enabled, so tcp_chr_read will be called. During testing it handled
disconnects just fine.
This reverts commit cdaa86a54b232572bba594bf87a7416e527e460c.
(Add G_IO_HUP handler for socket chardev) but keeps its functionality.
Cc: Antonios Motakis a.mota...@virtualopensystems.com
Cc: Nikolay Nikolaev n.nikol...@virtualopensystems.com
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Kirill Batuzov batuz...@ispras.ru
Signed-off-by: Nikita Belov zod...@ispras.ru
---
GLib limitation resulted in a bug on Windows host. Steps to reproduce:
Start qemu: qemu-system-i386 -qmp tcp:127.0.0.1::server:nowait
Connect with telnet: telnet 127.0.0.1
Try sending some data from telnet.
Expected result: answers from QEMU.
Observed result: no answers (actually tcp_chr_read is not called at all).
---
include/sysemu/char.h |1 -
qemu-char.c | 27 ++-
2 files changed, 6 insertions(+), 22 deletions(-)
diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index c8b15f9..0bbd631 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -84,7 +84,6 @@ struct CharDriverState {
int avail_connections;
int is_mux;
guint fd_in_tag;
-guint fd_hup_tag;
QemuOpts *opts;
QTAILQ_ENTRY(CharDriverState) next;
};
diff --git a/qemu-char.c b/qemu-char.c
index 51917de..22a9777 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -2673,6 +2673,12 @@ static gboolean tcp_chr_read(GIOChannel *chan,
GIOCondition cond, void *opaque)
uint8_t buf[READ_BUF_LEN];
int len, size;
+if (cond G_IO_HUP) {
+/* connection closed */
+tcp_chr_disconnect(chr);
+return TRUE;
+}
+
if (!s-connected || s-max_size = 0) {
return TRUE;
}
@@ -2724,25 +2730,6 @@ CharDriverState *qemu_chr_open_eventfd(int eventfd)
}
#endif
-static gboolean tcp_chr_chan_close(GIOChannel *channel, GIOCondition cond,
- void *opaque)
-{
-CharDriverState *chr = opaque;
-
-if (cond != G_IO_HUP) {
-return FALSE;
-}
-
-/* connection closed */
-tcp_chr_disconnect(chr);
-if (chr-fd_hup_tag) {
-g_source_remove(chr-fd_hup_tag);
-chr-fd_hup_tag = 0;
-}
-
-return TRUE;
-}
-
static void tcp_chr_connect(void *opaque)
{
CharDriverState *chr = opaque;
@@ -2752,8 +2739,6 @@ static void tcp_chr_connect(void *opaque)
if (s-chan) {
chr-fd_in_tag = io_add_watch_poll(s-chan, tcp_chr_read_poll,
tcp_chr_read, chr);
-chr-fd_hup_tag = g_io_add_watch(s-chan, G_IO_HUP,
tcp_chr_chan_close,
- chr);
}
qemu_chr_be_generic_open(chr);
}
--
1.7.10.4
Re: [Qemu-devel] [PATCH 7/7] hw/misc/platform_devices: Add platform_bus_base to PlatformDevtreeData
On 07.07.14 09:08, Eric Auger wrote: The base address of the platform bus sometimes is used to build the reg property. --- Actually I did not succeed in doing it another way with Calxeda xgmac. If someone knows how to do without, please advise. Not sure I understand. The regs properties live inside the parent's ranges. So in device tree the only thing that should be aware of the bus offset is the platform bus node, no? Alex
Re: [Qemu-devel] [PATCH 4/7] hw/arm/virt: Support dynamically spawned sysbus devices
On 8 July 2014 14:51, Alexander Graf ag...@suse.de wrote: On 07.07.14 09:08, Eric Auger wrote: +#define MACHVIRT_PLATFORM_BASE 0xa004000 That's an odd address for a 128MB window. Can you make it 128MB aligned? Maybe move the virtio region behind this one? I'd rather not move things around if we can avoid it. I know in theory the guest should only ever be looking at the DTB to find things, but still... With a bit of smartness we don't need a virtio-mmio region with this patch set anymore btw. We could just generate the virtio-mmio devices on our platform bus on the fly. Hmmm thanks -- PMM
Re: [Qemu-devel] [RFC PATCH 1/5] bootindex: add *_boot_device_path function
On Mon, Jul 07, 2014 at 05:10:57PM +0800, arei.gong...@huawei.com wrote:
From: Chenliang chenlian...@huawei.com
Add del_boot_device_path and modify_boot_device_path. Device should
be removed from boot device list by del_boot_device_path when device
hotplug. modify_boot_device_path is used to modify deviceboot order.
s/hotplug/is unhotplugged/
same issue in commitlog of patch 3/5
Signed-off-by: Chenliang chenlian...@huawei.com
Signed-off-by: Gonglei arei.gong...@huawei.com
---
include/sysemu/sysemu.h | 4
vl.c| 55
+
2 files changed, 59 insertions(+)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 285c45b..38ef1cd 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -204,6 +204,10 @@ void usb_info(Monitor *mon, const QDict *qdict);
void add_boot_device_path(int32_t bootindex, DeviceState *dev,
const char *suffix);
+void del_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
+void modify_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
char *get_boot_devices_list(size_t *size, bool ignore_suffixes);
DeviceState *get_boot_device(uint32_t position);
diff --git a/vl.c b/vl.c
index a1686ef..6264e11 100644
--- a/vl.c
+++ b/vl.c
@@ -1247,6 +1247,61 @@ void add_boot_device_path(int32_t bootindex,
DeviceState *dev,
QTAILQ_INSERT_TAIL(fw_boot_order, node, link);
}
+static bool is_same_fw_dev_path(DeviceState *src, DeviceState *target)
+{
+bool ret = false;
+char *devpath_src = qdev_get_fw_dev_path(src);
+char *devpath_target = qdev_get_fw_dev_path(target);
+
+if (!strcmp(devpath_src, devpath_target)) {
+ret = true;
+}
+
+g_free(devpath_src);
+g_free(devpath_target);
+return ret;
+}
+
+void del_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+FWBootEntry *i;
+
+assert(dev != NULL);
+
assert(booindex = 0 || suffix != NULL);
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (is_same_fw_dev_path(i-dev, dev)) {
if (!suffix) {
break;
}
+if (suffix i-suffix strcmp(i-suffix, suffix)) {
+continue;
+}
If suffix is NULL, then all the entries will be removed?
+QTAILQ_REMOVE(fw_boot_order, i, link);
+g_free(i-suffix);
+g_free(i);
+break;
+}
+}
+
+if (bootindex == -1) {
if (bootindex 0) {
+return;
+}
+
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (i-bootindex == bootindex) {
+QTAILQ_REMOVE(fw_boot_order, i, link);
+g_free(i-suffix);
+g_free(i);
+break;
+}
+}
+}
+
+void modify_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+del_boot_device_path(bootindex, dev, suffix);
+add_boot_device_path(bootindex, dev, suffix);
Why do you directly modify existed entry?
+}
+
DeviceState *get_boot_device(uint32_t position)
{
uint32_t counter = 0;
--
1.7.12.4
--
Amos.
Re: [Qemu-devel] [RFC PATCH v1 1/5] QEMUSizedBuffer/QEMUFile
* Eric Blake (ebl...@redhat.com) wrote: On 07/07/2014 11:18 AM, Sanidhya Kashyap wrote: From: Dr. David Alan Gilbert dgilb...@redhat.com You are attributing the patch to David... Using the patch of Stefan Berger for memory buffer based QEMUFile. http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg05036.html In the words of David: Using the QEMUFile interface, this patch adds support functions for operating on in-memory sized buffers that can be written to or read from. Signed-off-by: Stefan Berger stef...@linux.vnet.ibm.com Signed-off-by: Joel Schopp jsch...@linux.vnet.ibm.com --- ...but lack his S-o-b. Is it something that Stefan and Joel wrote (in which case, one of them should be listed as author), or something that David adopted and further improvedd (in which case he needs a signature)? I adopted it and just updated it; nothing substantial. (I use it in both my BER world and my postcopy world; and both Stefan and Isaku wrote something similar, so it's about time this finds it's way into the code base one way or another before someone else writes a 3rd implementation). Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH] slirp: Give error message if hostfwd_add/remove for unrecognized vlan/stack
On 26 June 2014 13:35, Peter Maydell peter.mayd...@linaro.org wrote:
On 16 June 2014 16:47, Peter Maydell peter.mayd...@linaro.org wrote:
If the user specified a (vlan ID, slirp stack name) tuple in a monitor
hostfwd_add/remove command and we can't find it, give the user an
error message rather than silently doing nothing.
This brings this error case in slirp_lookup() into line with the
other two.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
net/slirp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/slirp.c b/net/slirp.c
index 8fddc03..647039e 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -282,6 +282,7 @@ static SlirpState *slirp_lookup(Monitor *mon, const char
*vlan,
NetClientState *nc;
nc = net_hub_find_client_by_name(strtol(vlan, NULL, 0), stack);
if (!nc) {
+monitor_printf(mon, unrecognized (vlan-id, stackname) pair\n);
return NULL;
}
if (strcmp(nc-model, user)) {
--
1.9.2
Ping! (and cc trivial).
Ping again...
thanks
-- PMM
Re: [Qemu-devel] [PATCH v5 30/30] spapr_hcall: Add address-translation-mode-on-interrupt resource in H_SET_MODE
On 4 June 2014 13:51, Alexey Kardashevskiy a...@ozlabs.ru wrote:
This adds handling of the RESOURCE_ADDR_TRANS_MODE resource from
the H_SET_MODE, for POWER8 (PowerISA 2.07) only.
This defines AIL flags for LPCR special register.
This changes @excp_prefix according to the mode, takes effect in TCG.
This turns support of a new capability PPC2_ISA207S flag for TCG.
I see this has hit master already, but:
+static target_ulong h_set_mode_resouce_addr_trans_mode(PowerPCCPU *cpu,
+ target_ulong mflags,
+ target_ulong value1,
+ target_ulong value2)
resource has two 'r's in it.
+{
+CPUState *cs;
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+target_ulong prefix;
+
+if (!(pcc-insns_flags2 PPC2_ISA207S)) {
+return H_P2;
+}
+if (value1) {
+return H_P3;
+}
+if (value2) {
+return H_P4;
+}
+
+switch (mflags) {
+case H_SET_MODE_ADDR_TRANS_NONE:
+prefix = 0;
+break;
+case H_SET_MODE_ADDR_TRANS_0001_8000:
+prefix = 0x18000;
+break;
+case H_SET_MODE_ADDR_TRANS_C000___4000:
+prefix = 0xC0004000;
Needs an ULL suffix to avoid warnings on 32 bit:
/home/petmay01/linaro/qemu-from-laptop/qemu/hw/ppc/spapr_hcall.c: In
function ‘h_set_mode_resouce_addr_trans_mode’:
/home/petmay01/linaro/qemu-from-laptop/qemu/hw/ppc/spapr_hcall.c:773:
warning: integer constant is too large for ‘long’ type
thanks
-- PMM
Re: [Qemu-devel] [PATCH 01/12] target-mips: add KScratch registers
On 20/06/2014 23:02, Aurelien Jarno wrote: @@ -5198,6 +5199,12 @@ static void gen_mfc0(DisasContext *ctx, TCGv arg, int reg, int sel) gen_mfc0_load32(arg, offsetof(CPUMIPSState, CP0_DESAVE)); rn = DESAVE; break; +case 2 ... 7: +tcg_gen_ld_tl(arg, cpu_env, + offsetof(CPUMIPSState, CP0_KScratch[sel-2])); +tcg_gen_ext32s_tl(arg, arg); +rn = KScratch; +break; This change the behaviour of existing CPU which don't implement scratch registers. Before it would generate an RI exception, and after the patch, it would simply leave the register unchanged. The architecture manuals says in that case the result is UNDEFINED, so that might be fine, that said it also says this instruction could generate an RI exception, and I wouldn't be surprised real silicon actually generate such an exception. On the real HW - reads from an unimplemented cp0 register return 0x (in R6 it will be 0) and writes are just ignored, there is no RI exception. In v2 I updated the behaviour for the new registers only. I think the same changes will be needed for the existing registers, but this is out of the current patch series scope - I plan to do this later. Thanks, Leon
Re: [Qemu-devel] [PATCH v2 0/4] virtio-blk: fix issues with unified virtio-blk request handling
On Tue, Jul 1, 2014 at 5:25 PM, Stefan Hajnoczi stefa...@redhat.com wrote: This series fixes issues recently introduced when unifying virtio-blk dataplane's request handling with non-dataplane virtio-blk. The problems include broken memory allocation for dataplane requests and a performance regression for non-dataplane. See the patches for details. Stefan Hajnoczi (4): virtio-blk: avoid dataplane VirtIOBlockReq early free dataplane: do not free VirtQueueElement in vring_push() virtio-blk: avoid g_slice_new0() for VirtIOBlockReq and VirtQueueElement virtio-blk: embed VirtQueueElement in VirtIOBlockReq hw/block/dataplane/virtio-blk.c | 30 +++--- hw/block/virtio-blk.c | 50 ++--- hw/virtio/dataplane/vring.c | 22 ++-- include/hw/virtio/dataplane/vring.h | 3 +-- include/hw/virtio/virtio-blk.h | 6 - 5 files changed, 53 insertions(+), 58 deletions(-) Hi Kevin, Please include this series in your block pull request. I missed it last week and it's needed to fix dataplane in QEMU 2.1. Thanks, Stefan
Re: [Qemu-devel] [PATCH v5 30/30] spapr_hcall: Add address-translation-mode-on-interrupt resource in H_SET_MODE
On 08.07.14 16:37, Peter Maydell wrote:
On 4 June 2014 13:51, Alexey Kardashevskiy a...@ozlabs.ru wrote:
This adds handling of the RESOURCE_ADDR_TRANS_MODE resource from
the H_SET_MODE, for POWER8 (PowerISA 2.07) only.
This defines AIL flags for LPCR special register.
This changes @excp_prefix according to the mode, takes effect in TCG.
This turns support of a new capability PPC2_ISA207S flag for TCG.
I see this has hit master already, but:
+static target_ulong h_set_mode_resouce_addr_trans_mode(PowerPCCPU *cpu,
+ target_ulong mflags,
+ target_ulong value1,
+ target_ulong value2)
resource has two 'r's in it.
+{
+CPUState *cs;
+PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
+target_ulong prefix;
+
+if (!(pcc-insns_flags2 PPC2_ISA207S)) {
+return H_P2;
+}
+if (value1) {
+return H_P3;
+}
+if (value2) {
+return H_P4;
+}
+
+switch (mflags) {
+case H_SET_MODE_ADDR_TRANS_NONE:
+prefix = 0;
+break;
+case H_SET_MODE_ADDR_TRANS_0001_8000:
+prefix = 0x18000;
+break;
+case H_SET_MODE_ADDR_TRANS_C000___4000:
+prefix = 0xC0004000;
Needs an ULL suffix to avoid warnings on 32 bit:
/home/petmay01/linaro/qemu-from-laptop/qemu/hw/ppc/spapr_hcall.c: In
function ‘h_set_mode_resouce_addr_trans_mode’:
/home/petmay01/linaro/qemu-from-laptop/qemu/hw/ppc/spapr_hcall.c:773:
warning: integer constant is too large for ‘long’ type
Wow, and there I thought I always catch those ;).
Can you please quickly fix those up and commit then straight to the
tree? I don't think we'll have to do the usual commit dance for changes
as trivial as this.
Alex
[Qemu-devel] [PATCH] add watermark reporting for block devices
Hello everyone I'm one of the oVirt developers (http://www.ovirt.org); oVirt is a virtualization management application built around qemu/kvm, so it is nice to get in touch :) We have begun a big scalability improvement effort, aiming to support without problems hundreds of VMs per host, with plans to support thousands in a not so distant future. In doing so, we are reviewing our usage flows. One of them is thin-provisioned storage, which is used quite extensively, with block devices (ISCSI for example) and COW images. When using thin provisioning, oVirt tries hard to hide this fact from the guest OS, and to do so watches closely the usage of the device, and resize it when its usage exceeds a configured threshold (the high water mark), in order to avoid the guest OS to get paused for space exhausted. To do the watching, we poll he devices using libvirt (virDomainGetBlockInfo), which in turn uses query-blockstats. This is suboptimal with just one VM, but with hundereds of them, let alone thousands, it doesn't scale and it is quite a resource hog. Would be great to have this watermark concept supported into qemu, with a new event to be raised when the limit is crossed. To track this RFE I filed https://bugs.launchpad.net/qemu/+bug/1338957 Moreover, I had the chance to take a look at the QEMU sources and come up with this tentative patch which I'd also like to submit. Comments and thoughts very welcome! Thanks and best regards, Francesco Romani (1): block: add watermark event block.c | 56 +++ blockdev.c| 21 ++ include/block/block.h | 2 ++ include/block/block_int.h | 3 +++ qapi/block-core.json | 33 qmp-commands.hx | 24 6 files changed, 139 insertions(+) -- 1.9.3
[Qemu-devel] [PATCH] block: add watermark event
Managing applications, like oVirt (http://www.ovirt.org), make extensive
use of thin-provisioned disk images.
In order to let the guest run flawlessly and be not unnecessarily
paused, oVirt sets a watermark based on the percentage occupation of the
device against the advertised size, and automatically resizes the image
once the watermark is reached or exceeded.
In order to detect the mark crossing, the managing application has no
choice than aggressively polling the QEMU monitor using the
query-blockstats command. This lead to unnecessary system
load, and is made even worse under scale: scenarios
with hundreds of VM are becoming not unusual.
To fix this, this patch adds:
* A new monitor command to set a mark for a given block device.
* A new event to report if a block device usage exceeds the threshold.
This will allow the managing application to drop the polling
alltogether and just wait for a watermark crossing event.
Signed-off-by: Francesco Romani from...@redhat.com
---
block.c | 56 +++
blockdev.c| 21 ++
include/block/block.h | 2 ++
include/block/block_int.h | 3 +++
qapi/block-core.json | 33
qmp-commands.hx | 24
6 files changed, 139 insertions(+)
diff --git a/block.c b/block.c
index 8800a6b..cf34b7f 100644
--- a/block.c
+++ b/block.c
@@ -1983,6 +1983,8 @@ static void bdrv_move_feature_fields(BlockDriverState
*bs_dest,
bs_dest-device_list = bs_src-device_list;
memcpy(bs_dest-op_blockers, bs_src-op_blockers,
sizeof(bs_dest-op_blockers));
+
+bs_dest-wr_watermark_perc = bs_src-wr_watermark_perc;
}
/*
@@ -5813,3 +5815,57 @@ void bdrv_flush_io_queue(BlockDriverState *bs)
bdrv_flush_io_queue(bs-file);
}
}
+
+static bool watermark_exceeded(BlockDriverState *bs,
+ int64_t sector_num,
+ int nb_sectors)
+{
+
+if (bs-wr_watermark_perc 0) {
+int64_t watermark = (bs-total_sectors) / 100 * bs-wr_watermark_perc;
+if (sector_num = watermark) {
+return true;
+}
+}
+return false;
+}
+
+static int coroutine_fn watermark_before_write_notify(NotifierWithReturn
*notifier,
+ void *opaque)
+{
+BdrvTrackedRequest *req = opaque;
+int64_t sector_num = req-offset BDRV_SECTOR_BITS;
+int nb_sectors = req-bytes BDRV_SECTOR_BITS;
+
+/* FIXME: needed? */
+assert((req-offset (BDRV_SECTOR_SIZE - 1)) == 0);
+assert((req-bytes (BDRV_SECTOR_SIZE - 1)) == 0);
+
+if (watermark_exceeded(req-bs, sector_num, nb_sectors)) {
+BlockDriverState *bs = req-bs;
+qapi_event_send_block_watermark(
+bdrv_get_device_name(bs),
+sector_num,
+bs-wr_highest_sector,
+error_abort);
+}
+
+return 0; /* should always let other notifiers run */
+}
+
+void bdrv_set_watermark_perc(BlockDriverState *bs,
+ int watermark_perc)
+{
+NotifierWithReturn before_write = {
+.notify = watermark_before_write_notify,
+};
+
+if (watermark_perc = 0) {
+return;
+}
+
+if (bs-wr_watermark_perc == 0) {
+bdrv_add_before_write_notifier(bs, before_write);
+}
+bs-wr_watermark_perc = watermark_perc;
+}
diff --git a/blockdev.c b/blockdev.c
index 48bd9a3..ede21d9 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -2546,6 +2546,27 @@ BlockJobInfoList *qmp_query_block_jobs(Error **errp)
return dummy.next;
}
+void qmp_block_set_watermark(const char *device, int64_t watermark,
+ Error **errp)
+{
+BlockDriverState *bs;
+AioContext *aio_context;
+
+bs = bdrv_find(device);
+if (!bs) {
+error_set(errp, QERR_DEVICE_NOT_FOUND, device);
+return;
+}
+
+aio_context = bdrv_get_aio_context(bs);
+aio_context_acquire(aio_context);
+
+bdrv_set_watermark_perc(bs, watermark);
+
+aio_context_release(aio_context);
+}
+
+
QemuOptsList qemu_common_drive_opts = {
.name = drive,
.head = QTAILQ_HEAD_INITIALIZER(qemu_common_drive_opts.head),
diff --git a/include/block/block.h b/include/block/block.h
index 32d3676..ff92ef9 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -588,4 +588,6 @@ void bdrv_io_plug(BlockDriverState *bs);
void bdrv_io_unplug(BlockDriverState *bs);
void bdrv_flush_io_queue(BlockDriverState *bs);
+void bdrv_set_watermark_perc(BlockDriverState *bs, int watermark_perc);
+
#endif
diff --git a/include/block/block_int.h b/include/block/block_int.h
index f6c3bef..666ea1d 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -393,6 +393,9 @@ struct BlockDriverState {
/* The error object in use for blocking operations on backing_hd */
Error *backing_blocker;
+
+/* watermark limit for writes, percentage of
Re: [Qemu-devel] [PATCH 08/12] target-mips: add BadInstr and BadInstrP support
On 19/06/2014 23:13, Aurelien Jarno wrote: I don't think this should implemented that way, as it would have a significant impact on the performances. Given we have the fault address (we fill EPC), we can fetch the corresponding opcode. There might be some code change to do for the branches, so that we can get the informations we need from re-translation (this might also simplify the current branches code). I changed the BadInstr implementation in v2. Now the instruction word is fetched when we have the exception (and the valid instruction word is available), so we don't have to generate code to save the last instruction. The same has been done for BadInstrP and the branch prior to the delay slot. Thanks, Leon
[Qemu-devel] [RFC] add watermark reporting for block devices
Sorry, this is actually an RFC; patch was posted separately. - Original Message - From: Francesco Romani from...@redhat.com To: qemu-devel@nongnu.org Cc: kw...@redhat.com, stefa...@redhat.com, lcapitul...@redhat.com, mdr...@linux.vnet.ibm.com, Francesco Romani from...@redhat.com Sent: Tuesday, July 8, 2014 4:49:23 PM Subject: [PATCH] add watermark reporting for block devices Hello everyone I'm one of the oVirt developers (http://www.ovirt.org); oVirt is a virtualization management application built around qemu/kvm, so it is nice to get in touch :) We have begun a big scalability improvement effort, aiming to support without problems hundreds of VMs per host, with plans to support thousands in a not so distant future. In doing so, we are reviewing our usage flows. One of them is thin-provisioned storage, which is used quite extensively, with block devices (ISCSI for example) and COW images. When using thin provisioning, oVirt tries hard to hide this fact from the guest OS, and to do so watches closely the usage of the device, and resize it when its usage exceeds a configured threshold (the high water mark), in order to avoid the guest OS to get paused for space exhausted. To do the watching, we poll he devices using libvirt (virDomainGetBlockInfo), which in turn uses query-blockstats. This is suboptimal with just one VM, but with hundereds of them, let alone thousands, it doesn't scale and it is quite a resource hog. Would be great to have this watermark concept supported into qemu, with a new event to be raised when the limit is crossed. To track this RFE I filed https://bugs.launchpad.net/qemu/+bug/1338957 Moreover, I had the chance to take a look at the QEMU sources and come up with this tentative patch which I'd also like to submit. Comments and thoughts very welcome! Thanks and best regards, Francesco Romani (1): block: add watermark event block.c | 56 +++ blockdev.c| 21 ++ include/block/block.h | 2 ++ include/block/block_int.h | 3 +++ qapi/block-core.json | 33 qmp-commands.hx | 24 6 files changed, 139 insertions(+) -- 1.9.3 -- Francesco Romani RedHat Engineering Virtualization R D Phone: 8261328 IRC: fromani
Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
On 07/08/2014 01:05 AM, Peter Maydell wrote: On 8 July 2014 08:13, Al Viro v...@zeniv.linux.org.uk wrote: Actually, that's badly worded; what codepath ends up setting si_code on e.g. fp addition overflows? In system mode it's done by completion code in the kernel, but AFAICS in user mode there are only two places where it might happen - one is gentrap handling and another - osf_setsysinfo(2) emulation for TARGET_SSI_IEEE_FP_CONTROL. What I don't understand is how do we get from float_raise(FP_STATUS, float_flag_overflow) in fpu/softfloat.c to either of those. IOW, suppose I do x = DBL_MAX; feenableexcept(FE_ALL_EXCEPT); x *= x; I understand how I'll get SIGFPE, but what will set correct si_code in siginfo I'll see in the hanler? The code we have currently may well be buggy, but the correct place to set si_code is (as Richard says) the Alpha cpu_loop() in linux-user/main.c, which has access to the trap type that just caused us to stop executing code, plus the CPUState, which should be enough information to set si_code correctly. In particular the GENTRAP case seems to be setting a variety of different si_code values for SIGFPE. The gentrap case is a red-herring. The case you're looking for is EXC_ARITH. The path is from arith_excp dynamic_excp cpu_loop_exit longjmp cpu_exec cpu_loop It's also true that we don't install the correct si_code there, but we could. Mostly the gcc/glibc test cases really only care that SIGFPE gets raised, not what the codes are, so I haven't bothered. r~
Re: [Qemu-devel] another locking issue in current dataplane code?
On 08/07/14 09:43, Ming Lei wrote: On Tue, Jul 8, 2014 at 3:19 PM, Christian Borntraeger borntrae...@de.ibm.com wrote: Ping. has anyone seen a similar hang on x86? The problem seems to be, that for managedsave, we do a VM stop before we call the migration_state_notifier. to be verified.
Re: [Qemu-devel] [RFC PATCH 1/5] bootindex: add *_boot_device_path function
On Tue, Jul 08, 2014 at 01:22:53PM +, Gonglei (Arei) wrote:
-Original Message-
From: chenliang (T)
Sent: Tuesday, July 08, 2014 7:03 PM
To: Amos Kong
Cc: Gonglei (Arei); qemu-devel@nongnu.org; afaer...@suse.de;
ag...@suse.de; stefa...@redhat.com; a...@ozlabs.ru;
alex.william...@redhat.com; arm...@redhat.com; ebl...@redhat.com;
kw...@redhat.com; peter.mayd...@linaro.org; lcapitul...@redhat.com;
m...@redhat.com; pbonz...@redhat.com; ler...@redhat.com;
kra...@redhat.com; imamm...@redhat.com; dmi...@daynix.com;
marce...@redhat.com; peter.crosthwa...@xilinx.com; r...@twiddle.net;
so...@cmu.edu; Huangweidong (C); Luonengjun; Huangpeng (Peter)
Subject: Re: [RFC PATCH 1/5] bootindex: add *_boot_device_path function
On 2014/7/8 16:33, Amos Kong wrote:
On Mon, Jul 07, 2014 at 05:10:57PM +0800, arei.gong...@huawei.com
wrote:
From: Chenliang chenlian...@huawei.com
Add del_boot_device_path and modify_boot_device_path. Device should
be removed from boot device list by del_boot_device_path when device
hotplug. modify_boot_device_path is used to modify deviceboot order.
s/hotplug/is unhotplugged/
same issue in commitlog of patch 3/5
Yep, thanks!
Signed-off-by: Chenliang chenlian...@huawei.com
Signed-off-by: Gonglei arei.gong...@huawei.com
---
include/sysemu/sysemu.h | 4
vl.c| 55
+
2 files changed, 59 insertions(+)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 285c45b..38ef1cd 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -204,6 +204,10 @@ void usb_info(Monitor *mon, const QDict *qdict);
void add_boot_device_path(int32_t bootindex, DeviceState *dev,
const char *suffix);
+void del_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
+void modify_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
char *get_boot_devices_list(size_t *size, bool ignore_suffixes);
DeviceState *get_boot_device(uint32_t position);
diff --git a/vl.c b/vl.c
index a1686ef..6264e11 100644
--- a/vl.c
+++ b/vl.c
@@ -1247,6 +1247,61 @@ void add_boot_device_path(int32_t bootindex,
DeviceState *dev,
QTAILQ_INSERT_TAIL(fw_boot_order, node, link);
}
+static bool is_same_fw_dev_path(DeviceState *src, DeviceState *target)
+{
+bool ret = false;
+char *devpath_src = qdev_get_fw_dev_path(src);
+char *devpath_target = qdev_get_fw_dev_path(target);
+
+if (!strcmp(devpath_src, devpath_target)) {
+ret = true;
+}
+
+g_free(devpath_src);
+g_free(devpath_target);
+return ret;
+}
+
+void del_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+FWBootEntry *i;
+
+assert(dev != NULL);
+
assert(booindex = 0 || suffix != NULL);
suffix call be NULL.
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (is_same_fw_dev_path(i-dev, dev)) {
if (!suffix) {
break;
}
If suffix is NULL, at least we should do nothing in the loop.
+if (suffix i-suffix strcmp(i-suffix, suffix)) {
+continue;
+}
How about this one?
if (!suffix) {
break;
} else (i-suffix strcmp(i-suffix, suffix)) {
continue;
}
If suffix is NULL, then all the entries will be removed?
If suffix is NULL, the entry will be checked by the bootindex as below
QTAILQ_FOREACH loop. If suffix and bootindex are all not match,
no entry will not be deleted from the global fw_boot_order list.
This is why I added assert(booindex = 0 || suffix != NULL); on
above.
yes, it will be if caller don't give suffix.
+QTAILQ_REMOVE(fw_boot_order, i, link);
+g_free(i-suffix);
+g_free(i);
+break;
+}
+}
+
+if (bootindex == -1) {
if (bootindex 0) {
acked
+return;
+}
+
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (i-bootindex == bootindex) {
+QTAILQ_REMOVE(fw_boot_order, i, link);
+g_free(i-suffix);
+g_free(i);
+break;
+}
+}
+}
+
+void modify_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+del_boot_device_path(bootindex, dev, suffix);
+add_boot_device_path(bootindex, dev, suffix);
Why do you directly modify existed
Re: [Qemu-devel] [RFC PATCH 00/11] Adding FreeBSD's Capsicum security framework (part 1)
On Mon, Jul 7, 2014 at 3:33 PM, Alexei Starovoitov alexei.starovoi...@gmail.com wrote: On Mon, Jul 7, 2014 at 5:20 AM, Paolo Bonzini pbonz...@redhat.com wrote: Il 07/07/2014 12:29, David Drysdale ha scritto: I think that's more easily done by opening the file as O_RDONLY/O_WRONLY /O_RDWR. You could do it by running the file descriptor's seccomp-bpf program once per iocb with synthesized syscall numbers and argument vectors. Right, but generating the equivalent seccomp input environment for an equivalent single-fd syscall is going to be subtle and complex (which are worrying words to mention in a security context). And how many other syscalls are going to need similar special-case processing? (poll? select? send[m]msg? ...) Yeah, the difficult part is getting the right balance between: 1) limitations due to seccomp's impossibility to chase pointers (which is not something that can be lifted, as it's required for correctness) btw once seccomp moves to eBPF it will be able to 'chase pointers', since pointer walking will be possible via bpf_load_pointer() function call, which is a wrapper of: probe_kernel_read(ptr, unsafe_ptr, sizeof(void *)); return ptr; Not sure whether it helps this case or not. Just fyi. It won't immediately help, since threads can race pointer target contents (i.e. seccomp sees one thing, and then the syscall see another thing). Having an immutable memory area could help with this (i.e. some kind of locked memory range that holds all the approved argument strings, at which point seccomp could then trust the chased pointers that land in this range.) Obviously eBPF is a prerequisite to this, but it isn't the full solution, as far as I understand it. -Kees -- Kees Cook Chrome OS Security
[Qemu-devel] [PATCH 3/3] qtest: Adapt vhost-user-test to latehs vhost-user changes
A new field mmap_offset was added in the vhost-user message, we need to reflect
this change in the test too.
Signed-off-by: Nikolay Nikolaev n.nikol...@virtualopensystems.com
---
tests/vhost-user-test.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tests/vhost-user-test.c b/tests/vhost-user-test.c
index 2af2381..b9dcec1 100644
--- a/tests/vhost-user-test.c
+++ b/tests/vhost-user-test.c
@@ -72,6 +72,7 @@ typedef struct VhostUserMemoryRegion {
uint64_t guest_phys_addr;
uint64_t memory_size;
uint64_t userspace_addr;
+uint64_t mmap_offset;
} VhostUserMemoryRegion;
typedef struct VhostUserMemory {
@@ -201,6 +202,7 @@ static void read_guest_mem(void)
uint32_t *guest_mem;
gint64 end_time;
int i, j;
+size_t size;
g_mutex_lock(data_mutex);
@@ -227,8 +229,13 @@ static void read_guest_mem(void)
g_assert_cmpint(memory.regions[i].memory_size, , 1024);
-guest_mem = mmap(0, memory.regions[i].memory_size,
-PROT_READ | PROT_WRITE, MAP_SHARED, fds[i], 0);
+size = memory.regions[i].memory_size + memory.regions[i].mmap_offset;
+
+guest_mem = mmap(0, size, PROT_READ | PROT_WRITE,
+ MAP_SHARED, fds[i], 0);
+
+g_assert(guest_mem != MAP_FAILED);
+guest_mem += (memory.regions[i].mmap_offset / sizeof(*guest_mem));
for (j = 0; j 256; j++) {
uint32_t a = readl(memory.regions[i].guest_phys_addr + j*4);
Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
On Tue, Jul 08, 2014 at 07:54:36AM +0100, Al Viro wrote: On Mon, Jul 07, 2014 at 11:03:08PM -0700, Richard Henderson wrote: On 07/07/2014 09:20 PM, Al Viro wrote: and I'm reasonably sure that this is what they did internally. You are proposing to do 4 cases in all their messy glory in qemu itself... Yes. Primarily because we *have* to do so for the linux-user case. And that's not even going into generating the right si_code for that SIGFPE. What produces those TARGET_GEN_FLTINE and friends? linux-user/main.c, cpu_loop. That's where we consume it; where is it produced? Sure, explicit gentrap in alpha code will lead there, with whatever we have in $16 deciding what'll go into si_code, but where does that happen on fp exception codepaths? IOW, what sets si_code on those? Actually, that's badly worded; what codepath ends up setting si_code on e.g. fp addition overflows? In system mode it's done by completion code in the kernel, but AFAICS in user mode there are only two places where it might happen - one is gentrap handling and another - osf_setsysinfo(2) emulation for TARGET_SSI_IEEE_FP_CONTROL. What I don't understand is how do we get from float_raise(FP_STATUS, float_flag_overflow) in fpu/softfloat.c to either of those. IOW, suppose I do x = DBL_MAX; feenableexcept(FE_ALL_EXCEPT); x *= x; I understand how I'll get SIGFPE, but what will set correct si_code in siginfo I'll see in the hanler?
Re: [Qemu-devel] [PATCH v2 8/9] target-mips: add BadInstr and BadInstrP support
Hi Leon,
On 08/07/14 08:57, Leon Alrae wrote:
BadInstr Register (CP0 Register 8, Select 1)
The BadInstr register is a read-only register that capture the most recent
instruction which caused an exception.
BadInstrP Register (CP0 Register 8, Select 2)
The BadInstrP register contains the prior branch instruction, when the
faulting instruction is in a branch delay slot.
Using error_code to indicate whether AdEL or TLBL was triggered during
instruction fetch, in this case BadInstr is not updated as valid instruction
word is not available.
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
target-mips/cpu.h |6 +++
target-mips/helper.c| 44 --
target-mips/op_helper.c | 17 +-
target-mips/translate.c | 80 +++---
4 files changed, 136 insertions(+), 11 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index bc5..656f5ca 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -177,6 +177,8 @@ struct TCState {
target_ulong CP0_TCScheFBack;
int32_t CP0_Debug_tcstatus;
target_ulong CP0_UserLocal;
+uint32_t CP0_BadInstr;
+uint32_t CP0_BadInstrP;
According to the PRA, BadInstr/BadInstrP are instantiated per VPE, so
shouldn't these be in struct CPUMIPSState?
Cheers
James
[Qemu-devel] [PATCH v2 9/9] target-mips: update cpu_save/cpu_load to support new registers
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
target-mips/cpu.h |2 +-
target-mips/machine.c | 14 ++
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 656f5ca..23bb22c 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -557,7 +557,7 @@ void mips_cpu_list (FILE *f, fprintf_function cpu_fprintf);
extern void cpu_wrdsp(uint32_t rs, uint32_t mask_num, CPUMIPSState *env);
extern uint32_t cpu_rddsp(uint32_t mask_num, CPUMIPSState *env);
-#define CPU_SAVE_VERSION 4
+#define CPU_SAVE_VERSION 5
/* MMU modes definitions. We carefully match the indices with our
hflags layout. */
diff --git a/target-mips/machine.c b/target-mips/machine.c
index 0496faa..576dc10 100644
--- a/target-mips/machine.c
+++ b/target-mips/machine.c
@@ -26,6 +26,8 @@ static void save_tc(QEMUFile *f, TCState *tc)
qemu_put_betls(f, tc-CP0_TCScheFBack);
qemu_put_sbe32s(f, tc-CP0_Debug_tcstatus);
qemu_put_betls(f, tc-CP0_UserLocal);
+qemu_put_be32s(f, tc-CP0_BadInstr);
+qemu_put_be32s(f, tc-CP0_BadInstrP);
}
static void save_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
@@ -144,6 +146,9 @@ void cpu_save(QEMUFile *f, void *opaque)
qemu_put_sbe32s(f, env-CP0_DataHi);
qemu_put_betls(f, env-CP0_ErrorEPC);
qemu_put_sbe32s(f, env-CP0_DESAVE);
+for (i = 0; i MIPS_KSCRATCH_NUM; i++) {
+qemu_put_betls(f, env-CP0_KScratch[i]);
+}
/* Save inactive TC state */
for (i = 0; i MIPS_SHADOW_SET_MAX; i++)
@@ -177,6 +182,10 @@ static void load_tc(QEMUFile *f, TCState *tc, int
version_id)
if (version_id = 4) {
qemu_get_betls(f, tc-CP0_UserLocal);
}
+if (version_id = 5) {
+qemu_get_be32s(f, tc-CP0_BadInstr);
+qemu_get_be32s(f, tc-CP0_BadInstrP);
+}
}
static void load_fpu(QEMUFile *f, CPUMIPSFPUContext *fpu)
@@ -301,6 +310,11 @@ int cpu_load(QEMUFile *f, void *opaque, int version_id)
qemu_get_sbe32s(f, env-CP0_DataHi);
qemu_get_betls(f, env-CP0_ErrorEPC);
qemu_get_sbe32s(f, env-CP0_DESAVE);
+if (version_id = 5) {
+for (i = 0; i MIPS_KSCRATCH_NUM; i++) {
+qemu_get_betls(f, env-CP0_KScratch[i]);
+}
+}
/* Load inactive TC state */
for (i = 0; i MIPS_SHADOW_SET_MAX; i++) {
--
1.7.5.4
[Qemu-devel] [for-2.1] hw/ppc/spapr_hcall.c: Add ULL suffix to 64 bit constant
Add ULL suffix to 64 bit constant to prevent compiler warnings on some 32 bit platforms. Signed-off-by: Peter Maydell peter.mayd...@linaro.org --- Planning to commit this to master as a buildfix for rc1. hw/ppc/spapr_hcall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c index 7952077..467858c 100644 --- a/hw/ppc/spapr_hcall.c +++ b/hw/ppc/spapr_hcall.c @@ -770,7 +770,7 @@ static target_ulong h_set_mode_resouce_addr_trans_mode(PowerPCCPU *cpu, prefix = 0x18000; break; case H_SET_MODE_ADDR_TRANS_C000___4000: -prefix = 0xC0004000; +prefix = 0xC0004000ULL; break; default: return H_UNSUPPORTED_FLAG; -- 1.9.1
[Qemu-devel] [PATCH] hw/ppc/spapr_hcall.c: Fix typo in function names
Fix a typo in the names of a couple of functions
(s/resouce/resource/).
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
---
Only a typo; I leave it up to you whether you want to put this
in 2.1 or not, Alex, but anyway it doesn't need to go in rc1.
hw/ppc/spapr_hcall.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 467858c..8651447 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -712,10 +712,10 @@ static target_ulong h_logical_dcbf(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
return H_SUCCESS;
}
-static target_ulong h_set_mode_resouce_le(PowerPCCPU *cpu,
- target_ulong mflags,
- target_ulong value1,
- target_ulong value2)
+static target_ulong h_set_mode_resource_le(PowerPCCPU *cpu,
+ target_ulong mflags,
+ target_ulong value1,
+ target_ulong value2)
{
CPUState *cs;
@@ -743,10 +743,10 @@ static target_ulong h_set_mode_resouce_le(PowerPCCPU *cpu,
return H_UNSUPPORTED_FLAG;
}
-static target_ulong h_set_mode_resouce_addr_trans_mode(PowerPCCPU *cpu,
- target_ulong mflags,
- target_ulong value1,
- target_ulong value2)
+static target_ulong h_set_mode_resource_addr_trans_mode(PowerPCCPU *cpu,
+target_ulong mflags,
+target_ulong value1,
+target_ulong value2)
{
CPUState *cs;
PowerPCCPUClass *pcc = POWERPC_CPU_GET_CLASS(cpu);
@@ -794,11 +794,11 @@ static target_ulong h_set_mode(PowerPCCPU *cpu,
sPAPREnvironment *spapr,
switch (resource) {
case H_SET_MODE_RESOURCE_LE:
-ret = h_set_mode_resouce_le(cpu, args[0], args[2], args[3]);
+ret = h_set_mode_resource_le(cpu, args[0], args[2], args[3]);
break;
case H_SET_MODE_RESOURCE_ADDR_TRANS_MODE:
-ret = h_set_mode_resouce_addr_trans_mode(cpu, args[0],
- args[2], args[3]);
+ret = h_set_mode_resource_addr_trans_mode(cpu, args[0],
+ args[2], args[3]);
break;
}
--
1.9.1
[Qemu-devel] [PATCH 0/3] vhost-user fixes
The latest vhost-user changes changed the VHOST_SET_MEM_TABLE handling. Now the memory regions are mapped from dev-mem. The BIOS is registered at address 0xfffc which is out of memory boundaries for guests with less than 4G RAM. Calling qemu_get_ram_fd with this address causes abort() in qemu_get_ram_block with Bad ram offset. To prevent this situation we introduce a new function to check if the address maps to any RAMBlock - qemu_is_ram_block. This is used in VHOST_SET_MEM_TABLE handling to revent the aborting call to qemu_get_ram_fd. The related vhost-user qtest is also updated to reflect the changes in vhost-user message structures. --- Nikolay Nikolaev (3): Add qemu_is_ram_block vhost-user: Fix VHOST_SET_MEM_TABLE processing qtest: Adapt vhost-user-test to latehs vhost-user changes exec.c | 15 +++ hw/virtio/vhost-user.c |4 include/exec/ram_addr.h |1 + tests/vhost-user-test.c | 11 +-- 4 files changed, 29 insertions(+), 2 deletions(-) -- Signature
Re: [Qemu-devel] [Xen-devel] [v5][PATCH 0/5] xen: add Intel IGD passthrough support
Hi, I've been working on IGD passthrough using native qemu and VFIO, (without any XEN components). This work hasn't progressed in recent, but I am able to continue it again. Late last year I was in discussions with Allen Kay, Vikas Shivappa from Intel and Alex Williamson from Redhat, which resulted in successfully loading the i915 driver with opregion support which provided Intel frame buffer, but I did not get 2D or 3D acceleration working. I did this using Q35. The code is not without similar hacks that have been scrutinised here, and most intellectual parts of the code come from XEN (like the opregion location and size) - the code in parts should look similar. but Alex helped me convert it from XEN to QEMU. with the disclaimer that this is code is immature, has been written to prove out the concept (not to be suggested as appropriate for upstream) and may not even patch correctly. but as some indication of the direction I was taking. please look here: https://github.com/UmbraMalison/qemu-igdvfio I realise that this takes this conversation on yet another tangent, however my justification for doing is that many of the root discussions and potential flaws of cross xen implementation and use of piix are at least addressed. Also, if there is potential for further help in completing this task that would be well received. I am still keen to complete this implementation and hope to find some missing pieces in Tiejun's work, currently I am re-basing on v2.0.0. Best, Andy On 25 June 2014 03:17, Tiejun Chen tiejun.c...@intel.com wrote: V5 is generated just based on Paolo's some comments. v5: * Don't set that ISA class property, instead, just fake this ISA bridge with 00:1f.0. * Don't pass vendor/device ids in igd_pci_read(). * Add to support offset 0x44/0x48. * Just rebase. v4: * Fix some typos in the patch head description. * Improve some comments. * Given that xen_pt_register_vga_regions()/xen_pt_unregister_vga_regions() are called unconditionally, so we just return 0 there. * Remove one spurious change. * Remove some unnecessary return in void foo(). * Given that pci_create_pch() is called unconditionally, so we just return 0 even if its failed to check xen_has_gfx_passthru. * Use (xen_enabled() xen_has_gfx_passthru) to make sure we only work in this scenario. v3: * In this case, as we discussed we will give priority to devices to reserve a specific devfn by passing device_model_args_hvm = ['-device', 'xen-platform,addr=0x3'] and vga=none, so withdraw patch #1, #2 and #4. * Fix some typos. * Add more comments to make that readable. * To unmap igd_opregion when call xen_pt_unregister_vga_regions(). * Improve some return paths. * Force to convert igd_guest/host_opoegion as an unsigned long type while calling xc_domain_memory_mapping(). * We need to map 3 pages for opregion as hvmloader set. v2: * rebase on current qemu tree. * retrieve VGA bios from sysfs properly. * redefine some function name. * introduce bitmap to manage registe/runregister pci dev, and provide a common way to reserve some specific devfn. * introduce is_igd_passthrough() to make sure we touch physical host bridge only in IGD case. * We should return zero as an invalid address value while calling igd_read_opregion(). Additionally, now its also not necessary to recompile seabios with some extra steps like v1. The following patches are ported partially from Xen Qemu-traditional branch which are adding Intel IGD passthrough supporting to Qemu upstream. To pass through IGD to guest, user need to add following lines in Xen config file: gfx_passthru=1 pci=['00:02.0@2'] Now successfully boot Ubuntu 14.04/Windows 7 guests with IGD assigned in Haswell desktop with Latest Xen + Qemu upstream. Tiejun Chen (5): xen, gfx passthrough: basic graphics passthrough support xen, gfx passthrough: create pseudo intel isa bridge xen, gfx passthrough: support Intel IGD passthrough with VT-D xen, gfx passthrough: create host bridge to passthrough xen, gfx passthrough: add opregion mapping hw/pci-host/piix.c | 56 +++- hw/xen/Makefile.objs | 2 +- hw/xen/xen-host-pci-device.c | 5 ++ hw/xen/xen-host-pci-device.h | 1 + hw/xen/xen_pt.c | 10 +++ hw/xen/xen_pt.h | 12 +++- hw/xen/xen_pt_config_init.c | 50 +- hw/xen/xen_pt_graphics.c | 513 + qemu-options.hx | 9 +++ vl.c | 10 +++ 10 files changed, 663 insertions(+), 5 deletion Thanks Tiejun ___ Xen-devel mailing list xen-de...@lists.xen.org http://lists.xen.org/xen-devel
Re: [Qemu-devel] [PATCH] block: add watermark event
On 07/08/2014 08:49 AM, Francesco Romani wrote:
Managing applications, like oVirt (http://www.ovirt.org), make extensive
use of thin-provisioned disk images.
In order to let the guest run flawlessly and be not unnecessarily
paused, oVirt sets a watermark based on the percentage occupation of the
device against the advertised size, and automatically resizes the image
once the watermark is reached or exceeded.
In order to detect the mark crossing, the managing application has no
choice than aggressively polling the QEMU monitor using the
query-blockstats command. This lead to unnecessary system
load, and is made even worse under scale: scenarios
with hundreds of VM are becoming not unusual.
To fix this, this patch adds:
* A new monitor command to set a mark for a given block device.
* A new event to report if a block device usage exceeds the threshold.
This will allow the managing application to drop the polling
alltogether and just wait for a watermark crossing event.
s/alltogether/altogether/
Signed-off-by: Francesco Romani from...@redhat.com
---
block.c | 56
+++
blockdev.c| 21 ++
include/block/block.h | 2 ++
include/block/block_int.h | 3 +++
qapi/block-core.json | 33
qmp-commands.hx | 24
6 files changed, 139 insertions(+)
+void bdrv_set_watermark_perc(BlockDriverState *bs,
+ int watermark_perc)
+{
+NotifierWithReturn before_write = {
+.notify = watermark_before_write_notify,
+};
+
+if (watermark_perc = 0) {
+return;
+}
Shouldn't you uninstall the write_notifier if someone is changing the
watermark_perc from non-zero back to zero?
+++ b/include/block/block_int.h
@@ -393,6 +393,9 @@ struct BlockDriverState {
/* The error object in use for blocking operations on backing_hd */
Error *backing_blocker;
+
+/* watermark limit for writes, percentage of sectors */
+int wr_watermark_perc;
I didn't see any code that ensures that this limit is between 0 and 100;
since it is under user control, your code probably misbehaves for values
such as 101.
+
+##
+# @BLOCK_WATERMARK
+#
+# Emitted when a block device reaches or exceeds the watermark limit.
+#
+# @device: device name
+#
+# @sector-num: number of the sector exceeding the threshold
+#
+# @sector-highest: number of the last highest written sector
+#
+# Since: 2.1
2.2. You've missed hard freeze for 2.1.
+##
+{ 'event': 'BLOCK_WATERMARK',
+ 'data': { 'device': 'str', 'sector-num': 'int', 'sector-highest': 'int' } }
+
+##
+# @block_set_watermark
s/_/-/2 - new commands should use - in their name.
+#
+# Change watermark percentage for a block drive.
+#
+# @device: The name of the device
+#
+# @watermark: high water mark, percentage
Is percentage the right unit? On a 10G disk, that means you only have a
granularity down to 100M. Should the watermark limit instead be
expressed as a byte value instead of a percentage?
+#
+# Returns: Nothing on success
+# If @device is not a valid block device, DeviceNotFound
+#
+# Since: 2.1
2.2.
+##
+{ 'command': 'block_set_watermark',
+ 'data': { 'device': 'str', 'watermark': 'int' } }
I hate write-only commands. Which query-* command are you modifying to
output the current watermark level?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for 2.1 0/4] AioContext cleanups and optimizations
Am 07.07.2014 um 15:18 hat Paolo Bonzini geschrieben: These patches do some cleanup and optimization in AioContext land. The first two drop AIO functions that operate on the main AioContext. These are not needed anymore now that each BlockDriverState explicitly operates on its own AioContext. They are independent, and can be skipped if the maintainers prefer doing so or have comments. Patch 3 is a testsuite change for the aio_notify optimization, and patch 4 is the aio_notify patch, now with a better comment about the smp_mb optimization. Thanks, applied to the block branch. Kevin
Re: [Qemu-devel] [PATCH v2 0/4] virtio-blk: fix issues with unified virtio-blk request handling
Am 08.07.2014 um 16:43 hat Stefan Hajnoczi geschrieben: On Tue, Jul 1, 2014 at 5:25 PM, Stefan Hajnoczi stefa...@redhat.com wrote: This series fixes issues recently introduced when unifying virtio-blk dataplane's request handling with non-dataplane virtio-blk. The problems include broken memory allocation for dataplane requests and a performance regression for non-dataplane. See the patches for details. Stefan Hajnoczi (4): virtio-blk: avoid dataplane VirtIOBlockReq early free dataplane: do not free VirtQueueElement in vring_push() virtio-blk: avoid g_slice_new0() for VirtIOBlockReq and VirtQueueElement virtio-blk: embed VirtQueueElement in VirtIOBlockReq hw/block/dataplane/virtio-blk.c | 30 +++--- hw/block/virtio-blk.c | 50 ++--- hw/virtio/dataplane/vring.c | 22 ++-- include/hw/virtio/dataplane/vring.h | 3 +-- include/hw/virtio/virtio-blk.h | 6 - 5 files changed, 53 insertions(+), 58 deletions(-) Hi Kevin, Please include this series in your block pull request. I missed it last week and it's needed to fix dataplane in QEMU 2.1. Patch 4 doesn't seem to apply any more. Can you rebase (and include the Tested-by tags of Christian)? Kevin
[Qemu-devel] virtio + virtq + iommu
Hi, Was tracing the buffer handling code flow after the kick has been initiated from the guest in case of virtio. Found this function cpu_physical_memory_map-address_space_map-address_space_translate which calls address_space_translate_internal and iommu-translate (get the translation from TLB) to get the corresponding host virtual address where I think the packet buffer is mapped to (from guest physical to host virtual). So, should I conclude that there is no hardware IOMMU involved in this translation. QEMU maintains its own TLB and translation mapping which is used. Or iommu-translate leads to hardware MMU call. We are developing a high speed packet transfer mechanism using infiniband cards. So, trying to analyse every possible bottleneck. Confused here, please suggest. Anshul Makkar www.justkernel.com
[Qemu-devel] [PULL 3/3] target-arm: Implement vCPU reset via KVM_ARM_VCPU_INIT for 32-bit CPUs
Implement kvm_arm_vcpu_init() as a simple call to arm_arm_vcpu_init()
(which uses the KVM_ARM_VCPU_INIT vcpu ioctl to tell the kernel
to re-initialize the vCPU), rather than via the complicated code
which saves a copy of the register state on first init and then
writes it back to the kernel. This is much simpler and brings the
32-bit KVM code into line with the 64-bit code.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Message-id: 1403802973-20841-1-git-send-email-peter.mayd...@linaro.org
---
target-arm/cpu-qom.h | 4
target-arm/kvm32.c | 19 +--
2 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h
index eaee944..ee4fbb1 100644
--- a/target-arm/cpu-qom.h
+++ b/target-arm/cpu-qom.h
@@ -72,10 +72,6 @@ typedef struct ARMCPU {
uint64_t *cpreg_indexes;
/* Values of the registers (cpreg_indexes[i]'s value is cpreg_values[i]) */
uint64_t *cpreg_values;
-/* When using KVM, keeps a copy of the initial state of the VCPU,
- * so that on reset we can feed the reset values back into the kernel.
- */
-uint64_t *cpreg_reset_values;
/* Length of the indexes, values, reset_values arrays */
int32_t cpreg_array_len;
/* These are used only for migration: incoming data arrives in
diff --git a/target-arm/kvm32.c b/target-arm/kvm32.c
index 068af7d..5ec4eb1 100644
--- a/target-arm/kvm32.c
+++ b/target-arm/kvm32.c
@@ -270,13 +270,6 @@ int kvm_arch_init_vcpu(CPUState *cs)
goto out;
}
-/* Save a copy of the initial register values so that we can
- * feed it back to the kernel on VCPU reset.
- */
-cpu-cpreg_reset_values = g_memdup(cpu-cpreg_values,
- cpu-cpreg_array_len *
- sizeof(cpu-cpreg_values[0]));
-
out:
g_free(rlp);
return ret;
@@ -518,11 +511,9 @@ int kvm_arch_get_registers(CPUState *cs)
void kvm_arm_reset_vcpu(ARMCPU *cpu)
{
-/* Feed the kernel back its initial register state */
-memmove(cpu-cpreg_values, cpu-cpreg_reset_values,
-cpu-cpreg_array_len * sizeof(cpu-cpreg_values[0]));
-
-if (!write_list_to_kvmstate(cpu)) {
-abort();
-}
+/* Re-init VCPU so that all registers are set to
+ * their respective reset values.
+ */
+kvm_arm_vcpu_init(CPU(cpu));
+write_kvmstate_to_list(cpu);
}
--
1.9.1
[Qemu-devel] [PATCH for-2.1] pc: fix qemu exiting with error when -m X 128 with old machines types
If machine doesn't support memory hotplug then staring QEMU with initial memory less than default will make QEMU exit with following error message: $QEMU -m 16 -M isapc qemu-system-i386: -memory 'slots|maxmem' is not supported by: isapc Set maxram_size to initial memory value before parsing 'maxmem' option allows to keep maxmem in sync with initial memory size if no maxmem option was specified. Signed-off-by: Igor Mammedov imamm...@redhat.com CC: Bruce Rogers brog...@suse.com --- vl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/vl.c b/vl.c index 6e084c2..6abedcf 100644 --- a/vl.c +++ b/vl.c @@ -3315,6 +3315,7 @@ int main(int argc, char **argv, char **envp) error_report(ram size too large); exit(EXIT_FAILURE); } +maxram_size = ram_size; maxmem_str = qemu_opt_get(opts, maxmem); slots_str = qemu_opt_get(opts, slots); -- 1.8.5.2 (Apple Git-48)
[Qemu-devel] live migration + licensing issue.
Hi, In our data center we are using qemu 1.0/ 1.2 and we need to do a live migration to qemu 2.0. One of the main hindrance that we are facing is that QEMU 1.0 uses old PC model so if a user using Windows on the VM running on QEMU 1.0 does a live migrate to QEMU 2.0 , he will see a licensing issue as after migration Windows will see a new hardware beneath it. Any suggestion as to how to overcome this problem. Thanks Anshul Makkar www.justkernel.com
Re: [Qemu-devel] [RFC PATCH 1/5] bootindex: add *_boot_device_path function
-Original Message-
From: chenliang (T)
Sent: Tuesday, July 08, 2014 7:03 PM
To: Amos Kong
Cc: Gonglei (Arei); qemu-devel@nongnu.org; afaer...@suse.de;
ag...@suse.de; stefa...@redhat.com; a...@ozlabs.ru;
alex.william...@redhat.com; arm...@redhat.com; ebl...@redhat.com;
kw...@redhat.com; peter.mayd...@linaro.org; lcapitul...@redhat.com;
m...@redhat.com; pbonz...@redhat.com; ler...@redhat.com;
kra...@redhat.com; imamm...@redhat.com; dmi...@daynix.com;
marce...@redhat.com; peter.crosthwa...@xilinx.com; r...@twiddle.net;
so...@cmu.edu; Huangweidong (C); Luonengjun; Huangpeng (Peter)
Subject: Re: [RFC PATCH 1/5] bootindex: add *_boot_device_path function
On 2014/7/8 16:33, Amos Kong wrote:
On Mon, Jul 07, 2014 at 05:10:57PM +0800, arei.gong...@huawei.com
wrote:
From: Chenliang chenlian...@huawei.com
Add del_boot_device_path and modify_boot_device_path. Device should
be removed from boot device list by del_boot_device_path when device
hotplug. modify_boot_device_path is used to modify deviceboot order.
s/hotplug/is unhotplugged/
same issue in commitlog of patch 3/5
Yep, thanks!
Signed-off-by: Chenliang chenlian...@huawei.com
Signed-off-by: Gonglei arei.gong...@huawei.com
---
include/sysemu/sysemu.h | 4
vl.c| 55
+
2 files changed, 59 insertions(+)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 285c45b..38ef1cd 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -204,6 +204,10 @@ void usb_info(Monitor *mon, const QDict *qdict);
void add_boot_device_path(int32_t bootindex, DeviceState *dev,
const char *suffix);
+void del_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
+void modify_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
char *get_boot_devices_list(size_t *size, bool ignore_suffixes);
DeviceState *get_boot_device(uint32_t position);
diff --git a/vl.c b/vl.c
index a1686ef..6264e11 100644
--- a/vl.c
+++ b/vl.c
@@ -1247,6 +1247,61 @@ void add_boot_device_path(int32_t bootindex,
DeviceState *dev,
QTAILQ_INSERT_TAIL(fw_boot_order, node, link);
}
+static bool is_same_fw_dev_path(DeviceState *src, DeviceState *target)
+{
+bool ret = false;
+char *devpath_src = qdev_get_fw_dev_path(src);
+char *devpath_target = qdev_get_fw_dev_path(target);
+
+if (!strcmp(devpath_src, devpath_target)) {
+ret = true;
+}
+
+g_free(devpath_src);
+g_free(devpath_target);
+return ret;
+}
+
+void del_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+FWBootEntry *i;
+
+assert(dev != NULL);
+
assert(booindex = 0 || suffix != NULL);
suffix call be NULL.
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (is_same_fw_dev_path(i-dev, dev)) {
if (!suffix) {
break;
}
+if (suffix i-suffix strcmp(i-suffix, suffix)) {
+continue;
+}
If suffix is NULL, then all the entries will be removed?
If suffix is NULL, the entry will be checked by the bootindex as below
QTAILQ_FOREACH loop. If suffix and bootindex are all not match,
no entry will not be deleted from the global fw_boot_order list.
yes, it will be if caller don't give suffix.
+QTAILQ_REMOVE(fw_boot_order, i, link);
+g_free(i-suffix);
+g_free(i);
+break;
+}
+}
+
+if (bootindex == -1) {
if (bootindex 0) {
acked
+return;
+}
+
+QTAILQ_FOREACH(i, fw_boot_order, link) {
+if (i-bootindex == bootindex) {
+QTAILQ_REMOVE(fw_boot_order, i, link);
+g_free(i-suffix);
+g_free(i);
+break;
+}
+}
+}
+
+void modify_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+del_boot_device_path(bootindex, dev, suffix);
+add_boot_device_path(bootindex, dev, suffix);
Why do you directly modify existed entry?
Sometimes, in old boot device list:
device_id bootindex
net0 1
net1 2
net2 3
we want to make vm reboot from net2, we can do it like this:
modify_boot_device_path(bootindex=1, DeviceState=net2, suffix=NULL), the
new boot device list will like this:
device_id bootindex
net2 1
net1 2
Yes.
the visual bootindex of net0 will be deleted, and then we can look
it as default value.
Best regards,
-Gonglei
[Qemu-devel] [PULL 7/8] target-ppc: Remove POWER7+ and POWER8E families
From: Alexey Kardashevskiy a...@ozlabs.ru
POWER8E is architecturally equal to POWER8 and POWER7+ is equal to
POWER7. Also no user space tool makes any difference for CPU node name
in the device tree (such as PowerPC,POWER7@0 vs. PowerPC,POWER7+@0).
So there is no point in emulating POWER7+ and POWER8E apart from POWER7
and POWER8. Also, the previos patch implemented multiple PVR mask support
per CPU class so POWER7 class now covers both POWER7 and POWER7+ CPUs,
same is valid for POWER8/8E.
This removes POWER7+ and POWER8E classes. This replaces references
to POWER7P/POWER8E families with POWER7/POWER8 families.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
Signed-off-by: Alexander Graf ag...@suse.de
---
target-ppc/cpu-models.c | 4 +--
target-ppc/translate_init.c | 73 ++---
2 files changed, 4 insertions(+), 73 deletions(-)
diff --git a/target-ppc/cpu-models.c b/target-ppc/cpu-models.c
index c9112e9..52ac6ec 100644
--- a/target-ppc/cpu-models.c
+++ b/target-ppc/cpu-models.c
@@ -1135,9 +1135,9 @@
#endif
POWERPC_DEF(POWER7_v2.3, CPU_POWERPC_POWER7_v23, POWER7,
POWER7 v2.3)
-POWERPC_DEF(POWER7+_v2.1, CPU_POWERPC_POWER7P_v21,POWER7P,
+POWERPC_DEF(POWER7+_v2.1, CPU_POWERPC_POWER7P_v21,POWER7,
POWER7+ v2.1)
-POWERPC_DEF(POWER8E_v1.0, CPU_POWERPC_POWER8E_v10,POWER8E,
+POWERPC_DEF(POWER8E_v1.0, CPU_POWERPC_POWER8E_v10,POWER8,
POWER8E v1.0)
POWERPC_DEF(POWER8_v1.0, CPU_POWERPC_POWER8_v10, POWER8,
POWER8 v1.0)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 2c9c277..5eacd46 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -8133,66 +8133,6 @@ POWERPC_FAMILY(POWER7)(ObjectClass *oc, void *data)
pcc-interrupts_big_endian = ppc_cpu_interrupts_big_endian_lpcr;
}
-POWERPC_FAMILY(POWER7P)(ObjectClass *oc, void *data)
-{
-DeviceClass *dc = DEVICE_CLASS(oc);
-PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc);
-
-dc-fw_name = PowerPC,POWER7+;
-dc-desc = POWER7+;
-dc-props = powerpc_servercpu_properties;
-pcc-pvr_match = ppc_pvr_match_power7;
-pcc-pcr_mask = PCR_COMPAT_2_05 | PCR_COMPAT_2_06;
-pcc-init_proc = init_proc_POWER7;
-pcc-check_pow = check_pow_nocheck;
-pcc-insns_flags = PPC_INSNS_BASE | PPC_ISEL | PPC_STRING | PPC_MFTB |
- PPC_FLOAT | PPC_FLOAT_FSEL | PPC_FLOAT_FRES |
- PPC_FLOAT_FSQRT | PPC_FLOAT_FRSQRTE |
- PPC_FLOAT_FRSQRTES |
- PPC_FLOAT_STFIWX |
- PPC_FLOAT_EXT |
- PPC_CACHE | PPC_CACHE_ICBI | PPC_CACHE_DCBZ |
- PPC_MEM_SYNC | PPC_MEM_EIEIO |
- PPC_MEM_TLBIE | PPC_MEM_TLBSYNC |
- PPC_64B | PPC_ALTIVEC |
- PPC_SEGMENT_64B | PPC_SLBI |
- PPC_POPCNTB | PPC_POPCNTWD;
-pcc-insns_flags2 = PPC2_VSX | PPC2_DFP | PPC2_DBRX | PPC2_ISA205 |
-PPC2_PERM_ISA206 | PPC2_DIVE_ISA206 |
-PPC2_ATOMIC_ISA206 | PPC2_FP_CVT_ISA206 |
-PPC2_FP_TST_ISA206;
-pcc-msr_mask = (1ull MSR_SF) |
-(1ull MSR_VR) |
-(1ull MSR_VSX) |
-(1ull MSR_EE) |
-(1ull MSR_PR) |
-(1ull MSR_FP) |
-(1ull MSR_ME) |
-(1ull MSR_FE0) |
-(1ull MSR_SE) |
-(1ull MSR_DE) |
-(1ull MSR_FE1) |
-(1ull MSR_IR) |
-(1ull MSR_DR) |
-(1ull MSR_PMM) |
-(1ull MSR_RI) |
-(1ull MSR_LE);
-pcc-mmu_model = POWERPC_MMU_2_06;
-#if defined(CONFIG_SOFTMMU)
-pcc-handle_mmu_fault = ppc_hash64_handle_mmu_fault;
-#endif
-pcc-excp_model = POWERPC_EXCP_POWER7;
-pcc-bus_model = PPC_FLAGS_INPUT_POWER7;
-pcc-bfd_mach = bfd_mach_ppc64;
-pcc-flags = POWERPC_FLAG_VRE | POWERPC_FLAG_SE |
- POWERPC_FLAG_BE | POWERPC_FLAG_PMM |
- POWERPC_FLAG_BUS_CLK | POWERPC_FLAG_CFAR |
- POWERPC_FLAG_VSX;
-pcc-l1_dcache_size = 0x8000;
-pcc-l1_icache_size = 0x8000;
-pcc-interrupts_big_endian = ppc_cpu_interrupts_big_endian_lpcr;
-}
-
static void init_proc_POWER8(CPUPPCState *env)
{
init_proc_book3s_64(env, BOOK3S_CPU_POWER8);
@@ -8209,13 +8149,13 @@ static bool ppc_pvr_match_power8(PowerPCCPUClass *pcc,
uint32_t pvr)
return false;
}
-POWERPC_FAMILY(POWER8E)(ObjectClass *oc, void *data)
+POWERPC_FAMILY(POWER8)(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc);
dc-fw_name = PowerPC,POWER8;
-
[Qemu-devel] [Bug 1307473] Re: guest hang due to missing clock interrupt
I'm not confident yet we're seeing the exact same problem, but it is pretty close. We're running a somewhat wide range of hyperisor kernels, these are our observations so far. node-1-1 3.13.0-24-generic is affected for 0% of vms node-1-3 3.13.0-24-generic is affected for 0% of vms node-1-5 3.13.0-24-generic is affected for 0% of vms node-1-6 3.13.0-27-generic is affected for 0% of vms node-1-7 3.13.0-29-generic is affected for 0% of vms node-2-3 3.13.0-30-generic is affected for 0% of vms node-2-4 3.13.0-27-generic is affected for 0% of vms node-2-5 3.13.0-24-generic is affected for 0% of vms node-1-8 3.13.0-27-generic is affected for 2% of vms node-1-10 3.13.0-30-generic is affected for 33% of vms node-1-2 3.13.0-29-generic is affected for 48% of vms node-1-9 3.13.0-30-generic is affected for 32% of vms node-2-1 3.13.0-30-generic is affected for 20% of vms node-2-2 3.13.0-30-generic is affected for 7% of vms node-1-4 3.13.0-29-generic is affected for 61% of vm -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1307473 Title: guest hang due to missing clock interrupt Status in QEMU: New Status in “linux” package in Ubuntu: Confirmed Status in “qemu” package in Ubuntu: Confirmed Bug description: I noticed on 2 different systems that after upgrade from precise to latest trusty VMs are crashing: - in case of Windows VMs I'm getting BSOD with error message: A clock interrupt was not received on a secondary processor within the allocated time interval. - On linux VMs I'm noticing hrtimer: interrupt took 2992229 ns messages - On some proprietary virtual appliances I'm noticing crashes an due to missing timer interrupts QEMU version is: QEMU emulator version 1.7.91 (Debian 2.0.0~rc1+dfsg-0ubuntu3) Full command line: qemu-system-x86_64 -enable-kvm -name win7eval -S -machine pc- i440fx-1.7,accel=kvm,usb=off -cpu host -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -uuid 05e5089a- 4aa1-6bb2-ef06-ab4d020a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7eval.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot strict=on -device piix3-usb- uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/vm/win7eval.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio- disk0,id=virtio-disk0,bootindex=1 -drive file=/home/damarion/iso/7600.16385.090713-1255_x86fre_enterprise_en- us_EVAL_Eval_Enterprise-GRMCENEVAL_EN_DVD.iso,if=none,id=drive- ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive =drive-ide0-0-0,id=ide0-0-0 -drive file=/home/damarion/iso/virtio- win-0.1-74.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:38:31:0a,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1307473/+subscriptions
[Qemu-devel] [PULL 4/8] PPC: Fix booke206 TLB with phys addrs 32bit
We were truncating physical addresses to 32bit when using qemu-system-ppc
with a booke206 TLB implementation. This patch fixes that and makes the full
address space available.
Signed-off-by: Alexander Graf ag...@suse.de
---
target-ppc/mmu_helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-ppc/mmu_helper.c b/target-ppc/mmu_helper.c
index 4d6b1e2..4a34a73 100644
--- a/target-ppc/mmu_helper.c
+++ b/target-ppc/mmu_helper.c
@@ -897,10 +897,10 @@ static hwaddr booke206_tlb_to_page_size(CPUPPCState *env,
/* TLB check function for MAS based SoftTLBs */
static int ppcmas_tlb_check(CPUPPCState *env, ppcmas_tlb_t *tlb,
-hwaddr *raddrp,
- target_ulong address, uint32_t pid)
+hwaddr *raddrp, target_ulong address,
+uint32_t pid)
{
-target_ulong mask;
+hwaddr mask;
uint32_t tlb_pid;
if (!msr_cm) {
--
1.8.1.4
Re: [Qemu-devel] [PATCH 12/15] target-tricore: Add instructions of SBR opcode format
On 07/07/2014 11:13 AM, Bastian Koppelmann wrote:
Add instructions of SBR opcode format.
Add gen_loop micro-op generator function.
Signed-off-by: Bastian Koppelmann kbast...@mail.uni-paderborn.de
---
target-tricore/translate.c | 69
++
1 file changed, 69 insertions(+)
diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 69d99d3..5b11396 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -281,6 +281,22 @@ static inline void gen_branch_condi(DisasContext *ctx,
int cond, TCGv r1,
tcg_temp_free(temp);
}
+static void gen_loop(DisasContext *ctx, int r1, int32_t offset)
+{
+int l1;
+l1 = gen_new_label();
+
+tcg_gen_brcondi_tl(TCG_COND_EQ, cpu_gpr_a[r1], 0, l1);
+gen_save_pc(ctx-pc+offset);
+tcg_gen_subi_tl(cpu_gpr_a[r1], cpu_gpr_a[r1], 1);
+tcg_gen_exit_tb(0);
+gen_set_label(l1);
+gen_save_pc(ctx-pc+insn_bytes);
+tcg_gen_subi_tl(cpu_gpr_a[r1], cpu_gpr_a[r1], 1);
+tcg_gen_exit_tb(0);
Given that TCG does not register allocate over blocks, you're probably better
off subtracting first and comparing against -1, that way you don't need to keep
re-loading a[r1] from memory.
Again, goto_tb.
+gen_loop(ctx, r1, 0xffe0+(offset1));
+break;
I'd be happier seeing offset * 2 - 32.
r~
Re: [Qemu-devel] [PATCH 5/7] hw/core/sysbus: add fdt_add_node method
On 07.07.14 09:08, Eric Auger wrote: This method is meant to be called on sysbus device dynamic instantiation (-device option). Devices that support this kind of instantiation must implement this method. Signed-off-by: Eric Auger eric.au...@linaro.org For the reason I stated earlier, I don't think it's a good idea to put device tree code into our device models. Alex
[Qemu-devel] [PATCH] linux-aio: fix submit aio as a batch
In the enqueue path, we can't complete request, otherwise
Co-routine re-entered recursively may be caused, so this
patch fixes the issue with below ideas:
- for -EAGAIN, retry the submission in an introduced event handler
- for part of completion, just update the io queue, since it is
moving on after all
- for other failure, return the failure if in enqueue path,
otherwise, abort all queued I/O
Signed-off-by: Ming Lei ming@canonical.com
---
block/linux-aio.c | 85 +++--
1 file changed, 63 insertions(+), 22 deletions(-)
diff --git a/block/linux-aio.c b/block/linux-aio.c
index 4867369..6f7dd51 100644
--- a/block/linux-aio.c
+++ b/block/linux-aio.c
@@ -51,6 +51,7 @@ struct qemu_laio_state {
/* io queue for submit at batch */
LaioQueue io_q;
+EventNotifier retry; /* handle -EAGAIN */
};
static inline ssize_t io_event_ret(struct io_event *ev)
@@ -154,45 +155,78 @@ static void ioq_init(LaioQueue *io_q)
io_q-plugged = 0;
}
-static int ioq_submit(struct qemu_laio_state *s)
+static void abort_queue(struct qemu_laio_state *s)
+{
+int i;
+for (i = 0; i s-io_q.idx; i++) {
+struct qemu_laiocb *laiocb = container_of(s-io_q.iocbs[i],
+ struct qemu_laiocb,
+ iocb);
+laiocb-ret = -EIO;
+qemu_laio_process_completion(s, laiocb);
+}
+}
+
+static int ioq_submit(struct qemu_laio_state *s, bool enqueue)
{
int ret, i = 0;
int len = s-io_q.idx;
+int j = 0;
-do {
-ret = io_submit(s-ctx, len, s-io_q.iocbs);
-} while (i++ 3 ret == -EAGAIN);
+if (!len) {
+return 0;
+}
-/* empty io queue */
-s-io_q.idx = 0;
+ret = io_submit(s-ctx, len, s-io_q.iocbs);
+if (ret == -EAGAIN) {
+event_notifier_set(s-retry);
+return 0;
+} else if (ret 0) {
+if (enqueue)
+return ret;
+
+/* in non-queue path, all IOs have to be completed */
+abort_queue(s);
+ret = len;
+} else if (ret == 0) {
+goto out;
+}
-if (ret 0) {
-i = 0;
-} else {
-i = ret;
+for (i = ret; i len; i++) {
+s-io_q.iocbs[j++] = s-io_q.iocbs[i];
}
-for (; i len; i++) {
-struct qemu_laiocb *laiocb =
-container_of(s-io_q.iocbs[i], struct qemu_laiocb, iocb);
+ out:
+/* update io queue */
+s-io_q.idx -= ret;
-laiocb-ret = (ret 0) ? ret : -EIO;
-qemu_laio_process_completion(s, laiocb);
-}
return ret;
}
-static void ioq_enqueue(struct qemu_laio_state *s, struct iocb *iocb)
+static void ioq_submit_retry(EventNotifier *e)
+{
+struct qemu_laio_state *s = container_of(e, struct qemu_laio_state, retry);
+
+event_notifier_test_and_clear(e);
+ioq_submit(s, false);
+}
+
+static int ioq_enqueue(struct qemu_laio_state *s, struct iocb *iocb)
{
unsigned int idx = s-io_q.idx;
+if (unlikely(idx == s-io_q.size))
+return -1;
+
s-io_q.iocbs[idx++] = iocb;
s-io_q.idx = idx;
-/* submit immediately if queue is full */
-if (idx == s-io_q.size) {
-ioq_submit(s);
+/* submit immediately if queue depth is above 2/3 */
+if (idx s-io_q.size * 2 / 3) {
+return ioq_submit(s, true);
}
+
+return 0;
}
void laio_io_plug(BlockDriverState *bs, void *aio_ctx)
@@ -214,7 +248,7 @@ int laio_io_unplug(BlockDriverState *bs, void *aio_ctx,
bool unplug)
}
if (s-io_q.idx 0) {
-ret = ioq_submit(s);
+ret = ioq_submit(s, false);
}
return ret;
@@ -258,7 +292,8 @@ BlockDriverAIOCB *laio_submit(BlockDriverState *bs, void
*aio_ctx, int fd,
goto out_free_aiocb;
}
} else {
-ioq_enqueue(s, iocbs);
+if (ioq_enqueue(s, iocbs) 0)
+goto out_free_aiocb;
}
return laiocb-common;
@@ -272,6 +307,7 @@ void laio_detach_aio_context(void *s_, AioContext
*old_context)
struct qemu_laio_state *s = s_;
aio_set_event_notifier(old_context, s-e, NULL);
+aio_set_event_notifier(old_context, s-retry, NULL);
}
void laio_attach_aio_context(void *s_, AioContext *new_context)
@@ -279,6 +315,7 @@ void laio_attach_aio_context(void *s_, AioContext
*new_context)
struct qemu_laio_state *s = s_;
aio_set_event_notifier(new_context, s-e, qemu_laio_completion_cb);
+aio_set_event_notifier(new_context, s-retry, ioq_submit_retry);
}
void *laio_init(void)
@@ -295,6 +332,9 @@ void *laio_init(void)
}
ioq_init(s-io_q);
+if (event_notifier_init(s-retry, false) 0) {
+goto out_close_efd;
+}
return s;
@@ -310,5 +350,6 @@ void laio_cleanup(void *s_)
struct qemu_laio_state *s = s_;
event_notifier_cleanup(s-e);
+event_notifier_cleanup(s-retry);
g_free(s);
}
--
1.7.9.5
[Qemu-devel] [PATCH v2 3/9] target-mips: distinguish between data load and instruction fetch
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
target-mips/helper.c | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/target-mips/helper.c b/target-mips/helper.c
index 8a997e4..9871273 100644
--- a/target-mips/helper.c
+++ b/target-mips/helper.c
@@ -87,7 +87,7 @@ int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int
*prot,
/* Check access rights */
if (!(n ? tlb-V1 : tlb-V0))
return TLBRET_INVALID;
-if (rw == 0 || (n ? tlb-D1 : tlb-D0)) {
+if (rw != MMU_DATA_STORE || (n ? tlb-D1 : tlb-D0)) {
*physical = tlb-PFN[n] | (address (mask 1));
*prot = PAGE_READ;
if (n ? tlb-D1 : tlb-D0)
@@ -237,25 +237,28 @@ static void raise_mmu_exception(CPUMIPSState *env,
target_ulong address,
case TLBRET_BADADDR:
/* Reference to kernel address from user mode or supervisor mode */
/* Reference to supervisor address from user mode */
-if (rw)
+if (rw == MMU_DATA_STORE) {
exception = EXCP_AdES;
-else
+} else {
exception = EXCP_AdEL;
+}
break;
case TLBRET_NOMATCH:
/* No TLB match for a mapped address */
-if (rw)
+if (rw == MMU_DATA_STORE) {
exception = EXCP_TLBS;
-else
+} else {
exception = EXCP_TLBL;
+}
error_code = 1;
break;
case TLBRET_INVALID:
/* TLB match with no valid bit */
-if (rw)
+if (rw == MMU_DATA_STORE) {
exception = EXCP_TLBS;
-else
+} else {
exception = EXCP_TLBL;
+}
break;
case TLBRET_DIRTY:
/* TLB match but 'D' bit is cleared */
@@ -312,8 +315,6 @@ int mips_cpu_handle_mmu_fault(CPUState *cs, vaddr address,
int rw,
qemu_log(%s pc TARGET_FMT_lx ad % VADDR_PRIx rw %d mmu_idx %d\n,
__func__, env-active_tc.PC, address, rw, mmu_idx);
-rw = 1;
-
/* data access */
#if !defined(CONFIG_USER_ONLY)
/* XXX: put correct access by using cpu_restore_state()
@@ -347,8 +348,6 @@ hwaddr cpu_mips_translate_address(CPUMIPSState *env,
target_ulong address, int r
int access_type;
int ret = 0;
-rw = 1;
-
/* data access */
access_type = ACCESS_INT;
ret = get_physical_address(env, physical, prot,
--
1.7.5.4
Re: [Qemu-devel] [PATCH 4/7] hw/arm/virt: Support dynamically spawned sysbus devices
On 07.07.14 09:08, Eric Auger wrote: Allows sysbus devices to be instantiated from command line by using -device option --- Inspired from what Alex Graf did in ppc e500 https://lists.gnu.org/archive/html/qemu-ppc/2014-07/msg00012.html Signed-off-by: Alexander Graf ag...@suse.de Signed-off-by: Eric Auger eric.au...@linaro.org --- hw/arm/virt.c | 58 +- 1 file changed, 57 insertions(+), 1 deletion(-) diff --git a/hw/arm/virt.c b/hw/arm/virt.c index eeecdbf..3a21db4 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -40,6 +40,8 @@ #include exec/address-spaces.h #include qemu/bitops.h #include qemu/error-report.h +#include hw/misc/platform_devices.h +#include hw/vfio/vfio-platform.h #define NUM_VIRTIO_TRANSPORTS 32 @@ -57,6 +59,14 @@ #define GIC_FDT_IRQ_PPI_CPU_START 8 #define GIC_FDT_IRQ_PPI_CPU_WIDTH 8 +#define MACHVIRT_PLATFORM_BASE 0xa004000 That's an odd address for a 128MB window. Can you make it 128MB aligned? Maybe move the virtio region behind this one? With a bit of smartness we don't need a virtio-mmio region with this patch set anymore btw. We could just generate the virtio-mmio devices on our platform bus on the fly. +#define MACHVIRT_PLATFORM_HOLE (128ULL * 1024 * 1024) /* 128 MB */ As Scott mentioned in the e500 review round, hole is an odd name ;). Alex
Re: [Qemu-devel] another locking issue in current dataplane code?
On Tue, Jul 8, 2014 at 3:19 PM, Christian Borntraeger borntrae...@de.ibm.com wrote: Ping. has anyone seen a similar hang on x86? On 07/07/14 13:58, Christian Borntraeger wrote: Folks, with current 2.1-rc0 ( + dataplane: do not free VirtQueueElement in vring_push() + virtio-blk: avoid dataplane VirtIOBlockReq early free + some not-ready yet s390 patches for migration ) I still having issues with dataplane during managedsave (without dataplane everything seems to work fine): With 1 CPU and 1 disk (and some workload, e.g. a simple dd on the disk) I get: Thread 3 (Thread 0x3fff90fd910 (LWP 27218)): #0 0x03fffcdb7ba0 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x03fffcdbac0c in __pthread_mutex_cond_lock () from /lib64/libpthread.so.0 #2 0x03fffcdb399a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #3 0x801fff06 in qemu_cond_wait (cond=optimized out, mutex=mutex@entry=0x8037f788 qemu_global_mutex) at /home/cborntra/REPOS/qemu/util/qemu-thread-posix.c:135 #4 0x800472f4 in qemu_kvm_wait_io_event (cpu=optimized out) at /home/cborntra/REPOS/qemu/cpus.c:843 #5 qemu_kvm_cpu_thread_fn (arg=0x809ad6b0) at /home/cborntra/REPOS/qemu/cpus.c:879 #6 0x03fffcdaf412 in start_thread () from /lib64/libpthread.so.0 #7 0x03fffba350ae in thread_start () from /lib64/libc.so.6 Thread 2 (Thread 0x3fff88fd910 (LWP 27219)): #0 0x03fffba2a8e0 in ppoll () from /lib64/libc.so.6 #1 0x801af250 in ppoll (__ss=0x0, __timeout=0x0, __nfds=optimized out, __fds=optimized out) at /usr/include/bits/poll2.h:77 #2 qemu_poll_ns (fds=fds@entry=0x3fff40010c0, nfds=nfds@entry=3, timeout=-1) at /home/cborntra/REPOS/qemu/qemu-timer.c:314 #3 0x801b0702 in aio_poll (ctx=0x807f2230, blocking=blocking@entry=true) at /home/cborntra/REPOS/qemu/aio-posix.c:221 #4 0x800be3c4 in iothread_run (opaque=0x807f20d8) at /home/cborntra/REPOS/qemu/iothread.c:41 #5 0x03fffcdaf412 in start_thread () from /lib64/libpthread.so.0 #6 0x03fffba350ae in thread_start () from /lib64/libc.so.6 Thread 1 (Thread 0x3fff9c529b0 (LWP 27215)): #0 0x03fffcdb38f0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x801fff06 in qemu_cond_wait (cond=cond@entry=0x807f22c0, mutex=mutex@entry=0x807f2290) at /home/cborntra/REPOS/qemu/util/qemu-thread-posix.c:135 #2 0x80212906 in rfifolock_lock (r=r@entry=0x807f2290) at /home/cborntra/REPOS/qemu/util/rfifolock.c:59 #3 0x8019e536 in aio_context_acquire (ctx=ctx@entry=0x807f2230) at /home/cborntra/REPOS/qemu/async.c:295 #4 0x801a34e6 in bdrv_drain_all () at /home/cborntra/REPOS/qemu/block.c:1907 #5 0x80048e24 in do_vm_stop (state=RUN_STATE_PAUSED) at /home/cborntra/REPOS/qemu/cpus.c:538 #6 vm_stop (state=state@entry=RUN_STATE_PAUSED) at /home/cborntra/REPOS/qemu/cpus.c:1221 #7 0x800e6338 in qmp_stop (errp=errp@entry=0x3a9dc00) at /home/cborntra/REPOS/qemu/qmp.c:98 #8 0x800e1314 in qmp_marshal_input_stop (mon=optimized out, qdict=optimized out, ret=optimized out) at qmp-marshal.c:2806 #9 0x8004b91a in qmp_call_cmd (cmd=optimized out, params=0x8096cf50, mon=0x8080b8a0) at /home/cborntra/REPOS/qemu/monitor.c:5038 #10 handle_qmp_command (parser=optimized out, tokens=optimized out) at /home/cborntra/REPOS/qemu/monitor.c:5104 #11 0x801faf16 in json_message_process_token (lexer=0x8080b7c0, token=0x808f2610, type=optimized out, x=optimized out, y=6) at /home/cborntra/REPOS/qemu/qobject/json-streamer.c:87 #12 0x80212bac in json_lexer_feed_char (lexer=lexer@entry=0x8080b7c0, ch=optimized out, flush=flush@entry=false) at /home/cborntra/REPOS/qemu/qobject/json-lexer.c:303 #13 0x80212cfe in json_lexer_feed (lexer=0x8080b7c0, buffer=optimized out, size=optimized out) at /home/cborntra/REPOS/qemu/qobject/json-lexer.c:356 #14 0x801fb10e in json_message_parser_feed (parser=optimized out, buffer=optimized out, size=optimized out) at /home/cborntra/REPOS/qemu/qobject/json-streamer.c:110 #15 0x80049f28 in monitor_control_read (opaque=optimized out, buf=optimized out, size=optimized out) at /home/cborntra/REPOS/qemu/monitor.c:5125 #16 0x800c8636 in qemu_chr_be_write (len=1, buf=0x3a9e010 }[B\377\373\251\372\b, s=0x807f5af0) at /home/cborntra/REPOS/qemu/qemu-char.c:213 #17 tcp_chr_read (chan=optimized out, cond=optimized out, opaque=0x807f5af0) at /home/cborntra/REPOS/qemu/qemu-char.c:2690 #18 0x03fffcc9f05a in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #19 0x801ae3e0 in glib_pollfds_poll () at /home/cborntra/REPOS/qemu/main-loop.c:190 #20 os_host_main_loop_wait (timeout=optimized out) at /home/cborntra/REPOS/qemu/main-loop.c:235 #21 main_loop_wait (nonblocking=optimized out) at /home/cborntra/REPOS/qemu/main-loop.c:484 #22
Re: [Qemu-devel] [PATCH 3/4] qed: Make qiov match request size until backing file EOF
Am 05.07.2014 um 22:06 hat Max Reitz geschrieben:
On 04.07.2014 17:55, Kevin Wolf wrote:
If a QED image has a shorter backing file and a read request to
unallocated clusters goes across EOF of the backing file, the backing
file sees a shortened request and the rest is filled with zeros.
However, the original too long qiov was used with the shortened request.
This patch makes the qiov size match the request size, avoiding a
potential buffer overflow in raw-posix.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/qed.c | 26 +++---
block/qed.h | 1 +
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/block/qed.c b/block/qed.c
index b69374b..1f63b8f 100644
--- a/block/qed.c
+++ b/block/qed.c
@@ -772,6 +772,7 @@ static BDRVQEDState *acb_to_s(QEDAIOCB *acb)
*/
static void qed_read_backing_file(BDRVQEDState *s, uint64_t pos,
QEMUIOVector *qiov,
+ QEMUIOVector **backing_qiov,
This could be documented in the comment above the function header.
BlockDriverCompletionFunc *cb, void
*opaque)
{
uint64_t backing_length = 0;
@@ -804,15 +805,20 @@ static void qed_read_backing_file(BDRVQEDState *s,
uint64_t pos,
/* If the read straddles the end of the backing file, shorten it */
size = MIN((uint64_t)backing_length - pos, qiov-size);
+*backing_qiov = g_new(QEMUIOVector, 1);
I guess at least because of the qemu_iovec_destroy() block in
qed_aio_next_io() *backing_qiov always has to be NULL before this
point. I guess I'd like an assert(!*backing_qiov) here (or
assert(!acb-backing_qiov) before the call to
qed_read_backing_file() in qed_aio_read_data()) anyway to express
clearly that there can be no leaks.
Okay, I'll add the suggested comment and assertion.
Speaking of leaks: Shouldn't the backing_qiov be freed in
qed_aio_complete()?
I can't see a code path where cb (i.e. qed_aio_next_io or
qed_copy_from_backing_file_write) wouldn't be called before
reaching qed_aio_complete(). Both of them free backing_qiov.
Kevin
Re: [Qemu-devel] [PATCH 13/15] target-tricore: Add instructions of SC opcode format
On 07/07/2014 11:13 AM, Bastian Koppelmann wrote: +env-active_tc.ICR |= (const9 0xff); /* ICR.CCPN = const9[7: 0];*/ There's no reason not to perform this AND at translation time. r~
Re: [Qemu-devel] [for-2.1] hw/ppc/spapr_hcall.c: Add ULL suffix to 64 bit constant
On 08.07.14 17:01, Peter Maydell wrote: Add ULL suffix to 64 bit constant to prevent compiler warnings on some 32 bit platforms. Signed-off-by: Peter Maydell peter.mayd...@linaro.org Reviewed-by: Alexander Graf ag...@suse.de Alex
[Qemu-devel] [PATCH v2 5/9] target-mips: update PageGrain and m{t, f}c0 EntryLo{0, 1}
PageGrain needs rw bitmask which differs between MIPS architectures.
In pre-R6 if RIXI is supported, PageGrain.XIE and PageGrain.RIE are writeable,
whereas in R6 they are read-only 1.
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
target-mips/cpu.h|4
target-mips/helper.h |5 +
target-mips/op_helper.c | 25 ++---
target-mips/translate.c | 26 --
target-mips/translate_init.c |2 ++
5 files changed, 57 insertions(+), 5 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 5afafd7..8ccb3bb 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -243,7 +243,10 @@ struct CPUMIPSState {
target_ulong CP0_Context;
target_ulong CP0_KScratch[MIPS_KSCRATCH_NUM];
int32_t CP0_PageMask;
+int32_t CP0_PageGrain_rw_bitmask;
int32_t CP0_PageGrain;
+#define CP0PG_RIE 31
+#define CP0PG_XIE 30
int32_t CP0_Wired;
int32_t CP0_SRSConf0_rw_bitmask;
int32_t CP0_SRSConf0;
@@ -377,6 +380,7 @@ struct CPUMIPSState {
#define CP0C3_M31
#define CP0C3_ISA_ON_EXC 16
#define CP0C3_ULRI 13
+#define CP0C3_RXI 12
#define CP0C3_DSPP 10
#define CP0C3_LPA 7
#define CP0C3_VEIC 6
diff --git a/target-mips/helper.h b/target-mips/helper.h
index a127db5..e7e0c8c 100644
--- a/target-mips/helper.h
+++ b/target-mips/helper.h
@@ -152,6 +152,11 @@ DEF_HELPER_2(mtc0_datalo, void, env, tl)
DEF_HELPER_2(mtc0_taghi, void, env, tl)
DEF_HELPER_2(mtc0_datahi, void, env, tl)
+#if defined(TARGET_MIPS64)
+DEF_HELPER_2(dmtc0_entrylo0, void, env, i64)
+DEF_HELPER_2(dmtc0_entrylo1, void, env, i64)
+#endif
+
/* MIPS MT functions */
DEF_HELPER_2(mftgpr, tl, env, i32)
DEF_HELPER_2(mftlo, tl, env, i32)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index 3f39305..3579bde 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -1099,9 +1099,18 @@ void helper_mtc0_entrylo0(CPUMIPSState *env,
target_ulong arg1)
{
/* Large physaddr (PABITS) not implemented */
/* 1k pages not implemented */
-env-CP0_EntryLo0 = arg1 0x3FFF;
+target_ulong rxi = arg1 (env-CP0_PageGrain (3u CP0PG_XIE));
+env-CP0_EntryLo0 = (arg1 0x3FFF) | (rxi (CP0EnLo_RI - 31));
}
+#if defined(TARGET_MIPS64)
+void helper_dmtc0_entrylo0(CPUMIPSState *env, uint64_t arg1)
+{
+uint64_t rxi = arg1 ((env-CP0_PageGrain (3ull CP0PG_XIE)) 32);
+env-CP0_EntryLo0 = (arg1 0x3FFF) | rxi;
+}
+#endif
+
void helper_mtc0_tcstatus(CPUMIPSState *env, target_ulong arg1)
{
uint32_t mask = env-CP0_TCStatus_rw_bitmask;
@@ -1266,9 +1275,18 @@ void helper_mtc0_entrylo1(CPUMIPSState *env,
target_ulong arg1)
{
/* Large physaddr (PABITS) not implemented */
/* 1k pages not implemented */
-env-CP0_EntryLo1 = arg1 0x3FFF;
+target_ulong rxi = arg1 (env-CP0_PageGrain (3u CP0PG_XIE));
+env-CP0_EntryLo1 = (arg1 0x3FFF) | (rxi (CP0EnLo_RI - 31));
}
+#if defined(TARGET_MIPS64)
+void helper_dmtc0_entrylo1(CPUMIPSState *env, uint64_t arg1)
+{
+uint64_t rxi = arg1 ((env-CP0_PageGrain (3ull CP0PG_XIE)) 32);
+env-CP0_EntryLo1 = (arg1 0x3FFF) | rxi;
+}
+#endif
+
void helper_mtc0_context(CPUMIPSState *env, target_ulong arg1)
{
env-CP0_Context = (env-CP0_Context 0x007F) | (arg1 ~0x007F);
@@ -1285,7 +1303,8 @@ void helper_mtc0_pagegrain(CPUMIPSState *env,
target_ulong arg1)
/* SmartMIPS not implemented */
/* Large physaddr (PABITS) not implemented */
/* 1k pages not implemented */
-env-CP0_PageGrain = 0;
+env-CP0_PageGrain = (arg1 env-CP0_PageGrain_rw_bitmask) |
+ (env-CP0_PageGrain ~env-CP0_PageGrain_rw_bitmask);
}
void helper_mtc0_wired(CPUMIPSState *env, target_ulong arg1)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index ee18bf3..a8c8318 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -1176,6 +1176,7 @@ typedef struct DisasContext {
target_ulong btarget;
bool ulri;
int kscrexist;
+bool rxi;
} DisasContext;
enum {
@@ -4703,6 +4704,15 @@ static void gen_mfc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
switch (sel) {
case 0:
tcg_gen_ld_tl(arg, cpu_env, offsetof(CPUMIPSState, CP0_EntryLo0));
+#if defined(TARGET_MIPS64)
+if (ctx-rxi) {
+TCGv tmp = tcg_temp_new();
+tcg_gen_andi_tl(tmp, arg, (3ull 62));
+tcg_gen_shri_tl(tmp, tmp, 32);
+tcg_gen_or_tl(arg, arg, tmp);
+tcg_temp_free(tmp);
+}
+#endif
tcg_gen_ext32s_tl(arg, arg);
rn = EntryLo0;
break;
@@ -4749,6 +4759,15 @@ static void gen_mfc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
switch (sel) {
case 0:
tcg_gen_ld_tl(arg, cpu_env, offsetof(CPUMIPSState, CP0_EntryLo1));
+#if defined(TARGET_MIPS64)
+if (ctx-rxi) {
+
Re: [Qemu-devel] [PATCH v2 2/9] softmmu: provide softmmu access type enum
Hi Peter,
On 08/07/2014 14:00, Peter Maydell wrote:
On 8 July 2014 08:57, Leon Alrae leon.al...@imgtec.com wrote:
New MIPS features depend on the access type and enum is more convenient than
using the numbers directly.
Mmm, I've thought for a while it would be better to have this
be an enum, but never got round to it.
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
include/exec/cpu-common.h |6 ++
softmmu_template.h| 26 --
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index e3ec4c8..1c3171a 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -26,6 +26,12 @@ typedef struct CPUListState {
FILE *file;
} CPUListState;
+enum mmu_access_type {
CODING_STYLE says enum names should be CamelCase.
I think you also want this to be a typedef.
The style was copied from enum device_endian { which is few lines
below, I assumed it was correct :) I'll fix this.
+MMU_DATA_LOAD = 0,
+MMU_DATA_STORE = 1,
+MMU_INST_FETCH = 2
+};
+
We should probably also chase through and update the
prototypes of functions like tlb_fill() and cpu_unaligned_access()
and so on to take this enum type rather than int. (I
suspect there's a lot of those running into different
targets so it might need doing over multiple patches.)
thanks
-- PMM
I intentionally skipped this here to focus this patchset on the new
features only. I also think that eventually we will have to update the
prototypes and go through all the targets.
Thanks,
Leon
Re: [Qemu-devel] [PATCH v2 2/9] softmmu: provide softmmu access type enum
On 8 July 2014 17:08, Leon Alrae leon.al...@imgtec.com wrote: I intentionally skipped this here to focus this patchset on the new features only. I also think that eventually we will have to update the prototypes and go through all the targets. Yeah, that's reasonable. If you make this a typedef then we can update the prototypes later. -- PMM
Re: [Qemu-devel] live migration + licensing issue.
Hi, Am 08.07.2014 17:24, schrieb Anshul Makkar: In our data center we are using qemu 1.0/ 1.2 and we need to do a live migration to qemu 2.0. One of the main hindrance that we are facing is that QEMU 1.0 uses old PC model so if a user using Windows on the VM running on QEMU 1.0 does a live migrate to QEMU 2.0 , he will see a licensing issue as after migration Windows will see a new hardware beneath it. Any suggestion as to how to overcome this problem. Please check the documentation. There's the -machine option with parameters such as pc-1.0 and pc-1.2 for that exact purpose. libvirt should supply the corresponding option automatically. More difficult is if you're trying to migrate from qemu-kvm to qemu - code changes to your copy of 2.0 will be necessary then. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
On 8 July 2014 17:13, Al Viro v...@zeniv.linux.org.uk wrote: On Tue, Jul 08, 2014 at 09:05:10AM +0100, Peter Maydell wrote: The code we have currently may well be buggy, but the correct It is ;-/ We set TARGET_FPE_FLTINV unconditionally there. BTW, what's the reason why all these cpu_loop() instances can't go into linux-user/arch/something? It's just ancient code nobody's cleaned up yet. I do have move all this stuff into arch directories on my would like to do list, but I just haven't got round to it yet, since it's not actually actively broken (unlike many other areas of our codebase :-/). BTW, are there any more or less uptodate docs on qemu profiling? I mean, things like perf/oprofile on the host obviously end up lumping all tcg output together. Is there any way to get information beyond ~40% of time is spent in generated code, ~15% - in tb_find_fast(), and the rest is very much colder? Alex, did you say you'd done something with profiling recently? Incidentally, combination of --enable-gprof and (default) --enable-pie won't build - it dies with ld(1) complaining about relocs in gcrt1.o. This sounds like a toolchain bug to me :-) -- PMM
Re: [Qemu-devel] another locking issue in current dataplane code?
On 08/07/14 11:09, Christian Borntraeger wrote: On 08/07/14 09:43, Ming Lei wrote: On Tue, Jul 8, 2014 at 3:19 PM, Christian Borntraeger borntrae...@de.ibm.com wrote: Ping. has anyone seen a similar hang on x86? The problem seems to be, that for managedsave, we do a VM stop before we call the migration_state_notifier. to be verified. Yes. virsh suspend also hangs. Any ideas?
[Qemu-devel] [PULL 2.1 0/8] ppc patch queue 2014-07-08
Hi Peter, This is my latest bugfix queue for ppc for the 2.1 release. Please pull. Alex The following changes since commit 128f0e66149afb2dfc325dfd183aac345f417763: Merge remote-tracking branch 'remotes/afaerber/tags/prep-for-2.1' into staging (2014-07-07 19:06:55 +0100) are available in the git repository at: git://github.com/agraf/qemu.git tags/signed-ppc-for-upstream for you to fetch changes up to 0c6ab8c988830d3fe01c4ee88100a95ea95c49fa: PPC: e500: Actually install u-boot.e500 (2014-07-08 12:10:37 +0200) Patch queue for ppc - 2014-07-08 A few bug fixes for 2.1: - Fix e500* TLB emulation with qemu-system-ppc - Update SLOF to current upstream (good number of bugfixes) - Make POWER7 / POWER8 PVR match more agnostic (needed in 2.1 for cmdline compat) - Fix u-boot.e500 install (how did that happen?) - Fix H_CAS on LE hosts - ppc64le-linux-user fixes Alexander Graf (1): PPC: Fix booke206 TLB with phys addrs 32bit Alexey Kardashevskiy (3): pseries: Update SLOF firmware image to qemu-slof-20140630 target-ppc: Add pvr_match() callback target-ppc: Remove POWER7+ and POWER8E families Cole Robinson (1): PPC: e500: Actually install u-boot.e500 Laurent Dufour (1): target-ppc: KVMPPC_H_CAS fix cpu-version endianess Richard Henderson (2): target-ppc: Change default cpu for ppc64le-linux-user target-ppc: Fix gdbstub for ppc64le-linux-user Makefile| 3 +- hw/ppc/spapr.c | 3 +- linux-user/main.c | 8 +-- pc-bios/README | 2 +- pc-bios/slof.bin| Bin 921720 - 923896 bytes roms/SLOF | 2 +- target-ppc/cpu-models.c | 5 +- target-ppc/cpu-models.h | 6 +-- target-ppc/cpu-qom.h| 2 +- target-ppc/gdbstub.c| 34 ++-- target-ppc/mmu_helper.c | 6 +-- target-ppc/translate_init.c | 122 ++-- 12 files changed, 70 insertions(+), 123 deletions(-)
[Qemu-devel] [PATCH v2 4/9] target-mips: add RI and XI fields to TLB entry
In Revision 3 of the architecture, the RI and XI bits were added to the TLB
to enable more secure access of memory pages. These bits (along with the Dirty
bit) allow the implementation of read-only, write-only, no-execute access
policies for mapped pages.
Signed-off-by: Leon Alrae leon.al...@imgtec.com
---
target-mips/cpu.h | 11 +++
target-mips/helper.c| 11 ++-
target-mips/op_helper.c |8
3 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/target-mips/cpu.h b/target-mips/cpu.h
index 4f6aa5b..5afafd7 100644
--- a/target-mips/cpu.h
+++ b/target-mips/cpu.h
@@ -30,6 +30,10 @@ struct r4k_tlb_t {
uint_fast16_t V1:1;
uint_fast16_t D0:1;
uint_fast16_t D1:1;
+uint_fast16_t XI0:1;
+uint_fast16_t XI1:1;
+uint_fast16_t RI0:1;
+uint_fast16_t RI1:1;
target_ulong PFN[2];
};
@@ -229,6 +233,13 @@ struct CPUMIPSState {
#define CP0VPEOpt_DWX0 0
target_ulong CP0_EntryLo0;
target_ulong CP0_EntryLo1;
+#if defined(TARGET_MIPS64)
+# define CP0EnLo_RI 63
+# define CP0EnLo_XI 62
+#else
+# define CP0EnLo_RI 31
+# define CP0EnLo_XI 30
+#endif
target_ulong CP0_Context;
target_ulong CP0_KScratch[MIPS_KSCRATCH_NUM];
int32_t CP0_PageMask;
diff --git a/target-mips/helper.c b/target-mips/helper.c
index 9871273..6aa8c8a 100644
--- a/target-mips/helper.c
+++ b/target-mips/helper.c
@@ -27,6 +27,8 @@
#include sysemu/kvm.h
enum {
+TLBRET_XI = -6,
+TLBRET_RI = -5,
TLBRET_DIRTY = -4,
TLBRET_INVALID = -3,
TLBRET_NOMATCH = -2,
@@ -85,8 +87,15 @@ int r4k_map_address (CPUMIPSState *env, hwaddr *physical,
int *prot,
/* TLB match */
int n = !!(address mask ~(mask 1));
/* Check access rights */
-if (!(n ? tlb-V1 : tlb-V0))
+if (!(n ? tlb-V1 : tlb-V0)) {
return TLBRET_INVALID;
+}
+if (rw == MMU_INST_FETCH (n ? tlb-XI1 : tlb-XI0)) {
+return TLBRET_XI;
+}
+if (rw == MMU_DATA_LOAD (n ? tlb-RI1 : tlb-RI0)) {
+return TLBRET_RI;
+}
if (rw != MMU_DATA_STORE || (n ? tlb-D1 : tlb-D0)) {
*physical = tlb-PFN[n] | (address (mask 1));
*prot = PAGE_READ;
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index b8d384a..3f39305 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -1849,10 +1849,14 @@ static void r4k_fill_tlb(CPUMIPSState *env, int idx)
tlb-V0 = (env-CP0_EntryLo0 2) != 0;
tlb-D0 = (env-CP0_EntryLo0 4) != 0;
tlb-C0 = (env-CP0_EntryLo0 3) 0x7;
+tlb-XI0 = (env-CP0_EntryLo0 CP0EnLo_XI) 1;
+tlb-RI0 = (env-CP0_EntryLo0 CP0EnLo_RI) 1;
tlb-PFN[0] = (env-CP0_EntryLo0 6) 12;
tlb-V1 = (env-CP0_EntryLo1 2) != 0;
tlb-D1 = (env-CP0_EntryLo1 4) != 0;
tlb-C1 = (env-CP0_EntryLo1 3) 0x7;
+tlb-XI1 = (env-CP0_EntryLo1 CP0EnLo_XI) 1;
+tlb-RI1 = (env-CP0_EntryLo1 CP0EnLo_RI) 1;
tlb-PFN[1] = (env-CP0_EntryLo1 6) 12;
}
@@ -1964,8 +1968,12 @@ void r4k_helper_tlbr(CPUMIPSState *env)
env-CP0_EntryHi = tlb-VPN | tlb-ASID;
env-CP0_PageMask = tlb-PageMask;
env-CP0_EntryLo0 = tlb-G | (tlb-V0 1) | (tlb-D0 2) |
+((target_ulong)tlb-RI0 CP0EnLo_RI) |
+((target_ulong)tlb-XI0 CP0EnLo_XI) |
(tlb-C0 3) | (tlb-PFN[0] 6);
env-CP0_EntryLo1 = tlb-G | (tlb-V1 1) | (tlb-D1 2) |
+((target_ulong)tlb-RI1 CP0EnLo_RI) |
+((target_ulong)tlb-XI1 CP0EnLo_XI) |
(tlb-C1 3) | (tlb-PFN[1] 6);
}
--
1.7.5.4
[Qemu-devel] [PULL 3/8] target-ppc: Fix gdbstub for ppc64le-linux-user
From: Richard Henderson r...@twiddle.net
The bswap that's needed for system mode isn't required for
user mode, and in fact breaks debugging.
Signed-off-by: Richard Henderson r...@twiddle.net
[agraf: fix apple gdbstub implementation]
Signed-off-by: Alexander Graf ag...@suse.de
---
target-ppc/gdbstub.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/target-ppc/gdbstub.c b/target-ppc/gdbstub.c
index 694d303..14675f4 100644
--- a/target-ppc/gdbstub.c
+++ b/target-ppc/gdbstub.c
@@ -83,16 +83,24 @@ static int ppc_gdb_register_len(int n)
}
}
-
-static void ppc_gdb_swap_register(uint8_t *mem_buf, int n, int len)
+/* We need to present the registers to gdb in the current memory ordering.
+ For user-only mode we get this for free; TARGET_WORDS_BIGENDIAN is set to
+ the proper ordering for the binary, and cannot be changed.
+ For system mode, TARGET_WORDS_BIGENDIAN is always set, and we must check
+ the current mode of the chip to see if we're running in little-endian. */
+static void maybe_bswap_register(CPUPPCState *env, uint8_t *mem_buf, int len)
{
-if (len == 4) {
+#ifndef CONFIG_USER_ONLY
+if (!msr_le) {
+/* do nothing */
+} else if (len == 4) {
bswap32s((uint32_t *)mem_buf);
} else if (len == 8) {
bswap64s((uint64_t *)mem_buf);
} else {
g_assert_not_reached();
}
+#endif
}
/* Old gdb always expects FP registers. Newer (xml-aware) gdb only
@@ -150,10 +158,7 @@ int ppc_cpu_gdb_read_register(CPUState *cs, uint8_t
*mem_buf, int n)
break;
}
}
-if (msr_le) {
-/* If cpu is in LE mode, convert memory contents to LE. */
-ppc_gdb_swap_register(mem_buf, n, r);
-}
+maybe_bswap_register(env, mem_buf, r);
return r;
}
@@ -209,10 +214,7 @@ int ppc_cpu_gdb_read_register_apple(CPUState *cs, uint8_t
*mem_buf, int n)
break;
}
}
-if (msr_le) {
-/* If cpu is in LE mode, convert memory contents to LE. */
-ppc_gdb_swap_register(mem_buf, n, r);
-}
+maybe_bswap_register(env, mem_buf, r);
return r;
}
@@ -225,10 +227,7 @@ int ppc_cpu_gdb_write_register(CPUState *cs, uint8_t
*mem_buf, int n)
if (!r) {
return r;
}
-if (msr_le) {
-/* If cpu is in LE mode, convert memory contents to LE. */
-ppc_gdb_swap_register(mem_buf, n, r);
-}
+maybe_bswap_register(env, mem_buf, r);
if (n 32) {
/* gprs */
env-gpr[n] = ldtul_p(mem_buf);
@@ -278,10 +277,7 @@ int ppc_cpu_gdb_write_register_apple(CPUState *cs, uint8_t
*mem_buf, int n)
if (!r) {
return r;
}
-if (msr_le) {
-/* If cpu is in LE mode, convert memory contents to LE. */
-ppc_gdb_swap_register(mem_buf, n, r);
-}
+maybe_bswap_register(env, mem_buf, r);
if (n 32) {
/* gprs */
env-gpr[n] = ldq_p(mem_buf);
--
1.8.1.4
[Qemu-devel] [PULL 8/8] PPC: e500: Actually install u-boot.e500
From: Cole Robinson crobi...@redhat.com Signed-off-by: Cole Robinson crobi...@redhat.com Signed-off-by: Alexander Graf ag...@suse.de --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 1eea0c4..d6b9dc1 100644 --- a/Makefile +++ b/Makefile @@ -344,7 +344,8 @@ multiboot.bin linuxboot.bin kvmvapic.bin \ s390-zipl.rom \ s390-ccw.img \ spapr-rtas.bin slof.bin \ -palcode-clipper +palcode-clipper \ +u-boot.e500 else BLOBS= endif -- 1.8.1.4
[Qemu-devel] [PATCH 037/156] virtio-net: out-of-bounds buffer write on load
From: Michael S. Tsirkin m...@redhat.com
CVE-2013-4149 QEMU 1.3.0 out-of-bounds buffer write in
virtio_net_load()@hw/net/virtio-net.c
} else if (n-mac_table.in_use) {
uint8_t *buf = g_malloc0(n-mac_table.in_use);
We are allocating buffer of size n-mac_table.in_use
qemu_get_buffer(f, buf, n-mac_table.in_use * ETH_ALEN);
and read to the n-mac_table.in_use size buffer n-mac_table.in_use *
ETH_ALEN bytes, corrupting memory.
If adversary controls state then memory written there is controlled
by adversary.
Reviewed-by: Michael Roth mdr...@linux.vnet.ibm.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Juan Quintela quint...@redhat.com
(cherry picked from commit 98f93ddd84800f207889491e0b5d851386b459cf)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/net/virtio-net.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index e00d1c0..29c5f35 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1342,10 +1342,17 @@ static int virtio_net_load(QEMUFile *f, void *opaque,
int version_id)
if (n-mac_table.in_use = MAC_TABLE_ENTRIES) {
qemu_get_buffer(f, n-mac_table.macs,
n-mac_table.in_use * ETH_ALEN);
-} else if (n-mac_table.in_use) {
-uint8_t *buf = g_malloc0(n-mac_table.in_use);
-qemu_get_buffer(f, buf, n-mac_table.in_use * ETH_ALEN);
-g_free(buf);
+} else {
+int64_t i;
+
+/* Overflow detected - can happen if source has a larger MAC table.
+ * We simply set overflow flag so there's no need to maintain the
+ * table of addresses, discard them all.
+ * Note: 64 bit math to avoid integer overflow.
+ */
+for (i = 0; i (int64_t)n-mac_table.in_use * ETH_ALEN; ++i) {
+qemu_get_byte(f);
+}
n-mac_table.multi_overflow = n-mac_table.uni_overflow = 1;
n-mac_table.in_use = 0;
}
--
1.9.1
[Qemu-devel] [PATCH 021/156] arm: translate.c: Fix smlald Instruction
From: Peter Crosthwaite peter.crosthwa...@xilinx.com
The smlald (and probably smlsld) instruction was doing incorrect sign
extensions of the operands amongst 64bit result calculation. The
instruction psuedo-code is:
operand2 = if m_swap then ROR(R[m],16) else R[m];
product1 = SInt(R[n]15:0) * SInt(operand215:0);
product2 = SInt(R[n]31:16) * SInt(operand231:16);
result = product1 + product2 + SInt(R[dHi]:R[dLo]);
R[dHi] = result63:32;
R[dLo] = result31:0;
The result calculation should be done in 64 bit arithmetic, and hence
product1 and product2 should be sign extended to 64b before calculation.
The current implementation was adding product1 and product2 together
then sign-extending the intermediate result leading to false negatives.
E.G. if product1 = product2 = 0x400, their sum = 0x8000, which
will be incorrectly interpreted as -ve on sign extension.
We fix by doing the 64b extensions on both product1 and product2 before
any addition/subtraction happens.
We also fix where we were possibly incorrectly setting the Q saturation
flag for SMLSLD, which the ARM ARM specifically says is not set.
Reported-by: Christina Smith christina.sm...@xilinx.com
Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
Message-id:
2cddb6f5a15be4ab8d2160f3499d128ae93d304d.1397704570.git.peter.crosthwa...@xilinx.com
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
(cherry picked from commit 33bbd75a7c3321432fe40a8cbacd64619c56138c)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
target-arm/translate.c | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 5f003e7..e0c3eaa 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -7732,27 +7732,39 @@ static void disas_arm_insn(CPUARMState * env,
DisasContext *s)
if (insn (1 5))
gen_swap_half(tmp2);
gen_smul_dual(tmp, tmp2);
-if (insn (1 6)) {
-/* This subtraction cannot overflow. */
-tcg_gen_sub_i32(tmp, tmp, tmp2);
-} else {
-/* This addition cannot overflow 32 bits;
- * however it may overflow considered as a signed
- * operation, in which case we must set the Q flag.
- */
-gen_helper_add_setq(tmp, cpu_env, tmp, tmp2);
-}
-tcg_temp_free_i32(tmp2);
if (insn (1 22)) {
/* smlald, smlsld */
+TCGv_i64 tmp64_2;
+
tmp64 = tcg_temp_new_i64();
+tmp64_2 = tcg_temp_new_i64();
tcg_gen_ext_i32_i64(tmp64, tmp);
+tcg_gen_ext_i32_i64(tmp64_2, tmp2);
tcg_temp_free_i32(tmp);
+tcg_temp_free_i32(tmp2);
+if (insn (1 6)) {
+tcg_gen_sub_i64(tmp64, tmp64, tmp64_2);
+} else {
+tcg_gen_add_i64(tmp64, tmp64, tmp64_2);
+}
+tcg_temp_free_i64(tmp64_2);
gen_addq(s, tmp64, rd, rn);
gen_storeq_reg(s, rd, rn, tmp64);
tcg_temp_free_i64(tmp64);
} else {
/* smuad, smusd, smlad, smlsd */
+if (insn (1 6)) {
+/* This subtraction cannot overflow. */
+tcg_gen_sub_i32(tmp, tmp, tmp2);
+} else {
+/* This addition cannot overflow 32 bits;
+ * however it may overflow considered as a
+ * signed operation, in which case we must set
+ * the Q flag.
+ */
+gen_helper_add_setq(tmp, cpu_env, tmp, tmp2);
+}
+tcg_temp_free_i32(tmp2);
if (rd != 15)
{
tmp2 = load_reg(s, rd);
--
1.9.1
[Qemu-devel] [PATCH 025/156] s390x: empty function stubs in preparation for __KVM_HAVE_GUEST_DEBUG
From: David Hildenbrand d...@linux.vnet.ibm.com
This patch creates empty function stubs (used by the gdbserver) in preparation
for the hw debugging support by kvm on s390, which will enable the
__KVM_HAVE_GUEST_DEBUG define in the linux headers and require these methods on
the qemu side.
Signed-off-by: David Hildenbrand d...@linux.vnet.ibm.com
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
Reviewed-by: Cornelia Huck cornelia.h...@de.ibm.com
Cc: qemu-sta...@nongnu.org
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
(cherry picked from commit 8c0124490bcd78c9c54139cd654c71c5fbd95e6b)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
target-s390x/kvm.c | 28
1 file changed, 28 insertions(+)
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index b00a661..ef4d5cc 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -362,6 +362,26 @@ int kvm_arch_remove_sw_breakpoint(CPUState *cs, struct
kvm_sw_breakpoint *bp)
return 0;
}
+int kvm_arch_insert_hw_breakpoint(target_ulong addr,
+ target_ulong len, int type)
+{
+return -ENOSYS;
+}
+
+int kvm_arch_remove_hw_breakpoint(target_ulong addr,
+ target_ulong len, int type)
+{
+return -ENOSYS;
+}
+
+void kvm_arch_remove_all_hw_breakpoints(void)
+{
+}
+
+void kvm_arch_update_guest_debug(CPUState *cpu, struct kvm_guest_debug *dbg)
+{
+}
+
void kvm_arch_pre_run(CPUState *cpu, struct kvm_run *run)
{
}
@@ -812,6 +832,11 @@ static int handle_tsch(S390CPU *cpu)
return ret;
}
+static int kvm_arch_handle_debug_exit(S390CPU *cpu)
+{
+return -ENOSYS;
+}
+
int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
{
S390CPU *cpu = S390_CPU(cs);
@@ -827,6 +852,9 @@ int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
case KVM_EXIT_S390_TSCH:
ret = handle_tsch(cpu);
break;
+case KVM_EXIT_DEBUG:
+ret = kvm_arch_handle_debug_exit(cpu);
+break;
default:
fprintf(stderr, Unknown KVM exit: %d\n, run-exit_reason);
break;
--
1.9.1
[Qemu-devel] [PATCH 013/156] mirror: fix early wake from sleep due to aio
From: Stefan Hajnoczi stefa...@redhat.com
The mirror blockjob coroutine rate-limits itself by sleeping. The
coroutine also performs I/O asynchronously so it's important that the
aio callback doesn't wake the coroutine early as that breaks
rate-limiting.
Reported-by: Joaquim Barrera jbarr...@ac.upc.edu
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
(cherry picked from commit 7b770c720b28b8ac5b82ae431f2f354b7f8add91)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
block/mirror.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/block/mirror.c b/block/mirror.c
index 9bfc22f..2d9104e 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -95,7 +95,14 @@ static void mirror_iteration_done(MirrorOp *op, int ret)
}
g_slice_free(MirrorOp, op);
-qemu_coroutine_enter(s-common.co, NULL);
+
+/* Enter coroutine when it is not sleeping. The coroutine sleeps to
+ * rate-limit itself. The coroutine will eventually resume since there is
+ * a sleep timeout so don't wake it early.
+ */
+if (s-common.busy) {
+qemu_coroutine_enter(s-common.co, NULL);
+}
}
static void mirror_write_complete(void *opaque, int ret)
--
1.9.1
[Qemu-devel] [PATCH 036/156] virtio-net: out-of-bounds buffer write on invalid state load
From: Michael S. Tsirkin m...@redhat.com
CVE-2013-4150 QEMU 1.5.0 out-of-bounds buffer write in
virtio_net_load()@hw/net/virtio-net.c
This code is in hw/net/virtio-net.c:
if (n-max_queues 1) {
if (n-max_queues != qemu_get_be16(f)) {
error_report(virtio-net: different max_queues );
return -1;
}
n-curr_queues = qemu_get_be16(f);
for (i = 1; i n-curr_queues; i++) {
n-vqs[i].tx_waiting = qemu_get_be32(f);
}
}
Number of vqs is max_queues, so if we get invalid input here,
for example if max_queues = 2, curr_queues = 3, we get
write beyond end of the buffer, with data that comes from
wire.
This might be used to corrupt qemu memory in hard to predict ways.
Since we have lots of function pointers around, RCE might be possible.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Acked-by: Jason Wang jasow...@redhat.com
Reviewed-by: Michael Roth mdr...@linux.vnet.ibm.com
Signed-off-by: Juan Quintela quint...@redhat.com
(cherry picked from commit eea750a5623ddac7a61982eec8f1c93481857578)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/net/virtio-net.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index ec96862..e00d1c0 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1387,6 +1387,11 @@ static int virtio_net_load(QEMUFile *f, void *opaque,
int version_id)
}
n-curr_queues = qemu_get_be16(f);
+if (n-curr_queues n-max_queues) {
+error_report(virtio-net: curr_queues %x max_queues %x,
+ n-curr_queues, n-max_queues);
+return -1;
+}
for (i = 1; i n-curr_queues; i++) {
n-vqs[i].tx_waiting = qemu_get_be32(f);
}
--
1.9.1
[Qemu-devel] [PATCH 024/156] s390x/helper: Added format control bit to MMU translation
From: Thomas Huth th...@linux.vnet.ibm.com
With the EDAT-1 facility, the MMU translation can stop at the
segment table already, pointing to a 1 MB block. And while we're
at it, move the page table entry handling to a separate function,
too, as suggested by Alexander Graf.
Acked-by: Alexander Graf ag...@suse.de
Signed-off-by: Thomas Huth th...@linux.vnet.ibm.com
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
(cherry picked from commit c4400206d43b6a235299c7047cca0af93269fc03)
Conflicts:
target-s390x/helper.c
*removed unecessary context
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
target-s390x/cpu.h| 4 +++
target-s390x/helper.c | 70 ++-
2 files changed, 56 insertions(+), 18 deletions(-)
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 68b5ab7..8c0d00a 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -274,6 +274,9 @@ typedef struct CPUS390XState {
#define FLAG_MASK_64(PSW_MASK_64 32)
#define FLAG_MASK_320x1000
+/* Control register 0 bits */
+#define CR0_EDAT0x0080ULL
+
static inline int cpu_mmu_index (CPUS390XState *env)
{
if (env-psw.mask PSW_MASK_PSTATE) {
@@ -932,6 +935,7 @@ struct sysib_322 {
#define _REGION_ENTRY_LENGTH0x03 /* region third length
*/
#define _SEGMENT_ENTRY_ORIGIN ~0x7ffULL /* segment table origin
*/
+#define _SEGMENT_ENTRY_FC 0x400 /* format control
*/
#define _SEGMENT_ENTRY_RO 0x200 /* page protection bit
*/
#define _SEGMENT_ENTRY_INV 0x20 /* invalid segment table entry
*/
diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index da33b38..e8e92ef 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -164,6 +164,50 @@ static void trigger_page_fault(CPUS390XState *env,
target_ulong vaddr,
trigger_pgm_exception(env, type, ilen);
}
+/* Decode page table entry (normal 4KB page) */
+static int mmu_translate_pte(CPUS390XState *env, target_ulong vaddr,
+ uint64_t asc, uint64_t asce,
+ target_ulong *raddr, int *flags, int rw)
+{
+if (asce _PAGE_INVALID) {
+DPRINTF(%s: PTE=0x% PRIx64 invalid\n, __func__, asce);
+trigger_page_fault(env, vaddr, PGM_PAGE_TRANS, asc, rw);
+return -1;
+}
+
+if (asce _PAGE_RO) {
+*flags = ~PAGE_WRITE;
+}
+
+*raddr = asce _ASCE_ORIGIN;
+
+PTE_DPRINTF(%s: PTE=0x% PRIx64 \n, __func__, asce);
+
+return 0;
+}
+
+/* Decode EDAT1 segment frame absolute address (1MB page) */
+static int mmu_translate_sfaa(CPUS390XState *env, target_ulong vaddr,
+ uint64_t asc, uint64_t asce, target_ulong *raddr,
+ int *flags, int rw)
+{
+if (asce _SEGMENT_ENTRY_INV) {
+DPRINTF(%s: SEG=0x% PRIx64 invalid\n, __func__, asce);
+trigger_page_fault(env, vaddr, PGM_SEGMENT_TRANS, asc, rw);
+return -1;
+}
+
+if (asce _SEGMENT_ENTRY_RO) {
+*flags = ~PAGE_WRITE;
+}
+
+*raddr = (asce 0xfff0ULL) | (vaddr 0xf);
+
+PTE_DPRINTF(%s: SEG=0x% PRIx64 \n, __func__, asce);
+
+return 0;
+}
+
static int mmu_translate_asce(CPUS390XState *env, target_ulong vaddr,
uint64_t asc, uint64_t asce, int level,
target_ulong *raddr, int *flags, int rw)
@@ -222,28 +266,18 @@ static int mmu_translate_asce(CPUS390XState *env,
target_ulong vaddr,
PTE_DPRINTF(%s: 0x% PRIx64 + 0x% PRIx64 = 0x%016 PRIx64 \n,
__func__, origin, offs, new_asce);
-if (level != _ASCE_TYPE_SEGMENT) {
+if (level == _ASCE_TYPE_SEGMENT) {
+/* 4KB page */
+return mmu_translate_pte(env, vaddr, asc, new_asce, raddr, flags, rw);
+} else if (level - 4 == _ASCE_TYPE_SEGMENT
+ (new_asce _SEGMENT_ENTRY_FC) (env-cregs[0] CR0_EDAT)) {
+/* 1MB page */
+return mmu_translate_sfaa(env, vaddr, asc, new_asce, raddr, flags, rw);
+} else {
/* yet another region */
return mmu_translate_asce(env, vaddr, asc, new_asce, level - 4, raddr,
flags, rw);
}
-
-/* PTE */
-if (new_asce _PAGE_INVALID) {
-DPRINTF(%s: PTE=0x% PRIx64 invalid\n, __func__, new_asce);
-trigger_page_fault(env, vaddr, PGM_PAGE_TRANS, asc, rw);
-return -1;
-}
-
-if (new_asce _PAGE_RO) {
-*flags = ~PAGE_WRITE;
-}
-
-*raddr = new_asce _ASCE_ORIGIN;
-
-PTE_DPRINTF(%s: PTE=0x% PRIx64 \n, __func__, new_asce);
-
-return 0;
}
static int mmu_translate_asc(CPUS390XState *env, target_ulong vaddr,
--
1.9.1
[Qemu-devel] [PATCH 060/156] target-arm: Make vbar_write 64bit friendly on 32bit hosts
From: Edgar E. Iglesias edgar.igles...@xilinx.com
Signed-off-by: Edgar E. Iglesias edgar.igles...@xilinx.com
Reviewed-by: Alex Bennée alex.ben...@linaro.org
Message-id: 1398926097-28097-2-git-send-email-edgar.igles...@gmail.com
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
(cherry picked from commit fed3ffb9f157f33bc9b2b1c3ef68e710ee6b7b4b)
Conflicts:
target-arm/helper.c
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
target-arm/helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 3445813..c3e4910 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -546,7 +546,7 @@ static int pmintenclr_write(CPUARMState *env, const
ARMCPRegInfo *ri,
static int vbar_write(CPUARMState *env, const ARMCPRegInfo *ri,
uint64_t value)
{
-env-cp15.c12_vbar = value ~0x1Ful;
+env-cp15.c12_vbar = value ~0x1FULL;
return 0;
}
--
1.9.1
[Qemu-devel] [PATCH 029/156] vmxnet3: validate queues configuration coming from guest
From: Dmitry Fleytman dmi...@daynix.com
CVE-2013-4544
Signed-off-by: Dmitry Fleytman dmi...@daynix.com
Reported-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Reviewed-by: Dr. David Alan Gilbert dgilb...@redhat.com
Message-id: 1396604722-11902-3-git-send-email-dmi...@daynix.com
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
(cherry picked from commit 9878d173f574df74bde0ff50b2f81009fbee81bb)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
hw/net/vmxnet3.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 7c709ca..0dd8c7a 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -1336,6 +1336,23 @@ static void vmxnet3_validate_interrupts(VMXNET3State *s)
}
}
+static void vmxnet3_validate_queues(VMXNET3State *s)
+{
+/*
+* txq_num and rxq_num are total number of queues
+* configured by guest. These numbers must not
+* exceed corresponding maximal values.
+*/
+
+if (s-txq_num VMXNET3_DEVICE_MAX_TX_QUEUES) {
+hw_error(Bad TX queues number: %d\n, s-txq_num);
+}
+
+if (s-rxq_num VMXNET3_DEVICE_MAX_RX_QUEUES) {
+hw_error(Bad RX queues number: %d\n, s-rxq_num);
+}
+}
+
static void vmxnet3_activate_device(VMXNET3State *s)
{
int i;
@@ -1382,7 +1399,7 @@ static void vmxnet3_activate_device(VMXNET3State *s)
VMXNET3_READ_DRV_SHARED8(s-drv_shmem, devRead.misc.numRxQueues);
VMW_CFPRN(Number of TX/RX queues %u/%u, s-txq_num, s-rxq_num);
-assert(s-txq_num = VMXNET3_DEVICE_MAX_TX_QUEUES);
+vmxnet3_validate_queues(s);
qdescr_table_pa =
VMXNET3_READ_DRV_SHARED64(s-drv_shmem, devRead.misc.queueDescPA);
--
1.9.1
[Qemu-devel] [PATCH 030/156] vmxnet3: validate interrupt indices read on migration
From: Dmitry Fleytman dmi...@daynix.com CVE-2013-4544 Signed-off-by: Dmitry Fleytman dmi...@daynix.com Reported-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Michael S. Tsirkin m...@redhat.com Reviewed-by: Dr. David Alan Gilbert dgilb...@redhat.com Message-id: 1396604722-11902-4-git-send-email-dmi...@daynix.com Signed-off-by: Peter Maydell peter.mayd...@linaro.org (cherry picked from commit 3c99afc779c2c78718a565ad8c5e98de7c2c7484) Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com --- hw/net/vmxnet3.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c index 0dd8c7a..b9ed47a 100644 --- a/hw/net/vmxnet3.c +++ b/hw/net/vmxnet3.c @@ -2393,6 +2393,8 @@ static int vmxnet3_post_load(void *opaque, int version_id) } } +vmxnet3_validate_interrupts(s); + return 0; } -- 1.9.1
[Qemu-devel] [PATCH 072/156] block/cloop: prevent offsets_size integer overflow (CVE-2014-0143)
From: Stefan Hajnoczi stefa...@redhat.com
The following integer overflow in offsets_size can lead to out-of-bounds
memory stores when n_blocks has a huge value:
uint32_t n_blocks, offsets_size;
[...]
ret = bdrv_pread(bs-file, 128 + 4, s-n_blocks, 4);
[...]
s-n_blocks = be32_to_cpu(s-n_blocks);
/* read offsets */
offsets_size = s-n_blocks * sizeof(uint64_t);
s-offsets = g_malloc(offsets_size);
[...]
for(i=0;is-n_blocks;i++) {
s-offsets[i] = be64_to_cpu(s-offsets[i]);
offsets_size can be smaller than n_blocks due to integer overflow.
Therefore s-offsets[] is too small when the for loop byteswaps offsets.
This patch refuses to open files if offsets_size would overflow.
Note that changing the type of offsets_size is not a fix since 32-bit
hosts still only have 32-bit size_t.
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
(cherry picked from commit 509a41bab5306181044b5fff02eadf96d9c8676a)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
block/cloop.c | 7 +++
tests/qemu-iotests/075 | 7 +++
tests/qemu-iotests/075.out | 4
3 files changed, 18 insertions(+)
diff --git a/block/cloop.c b/block/cloop.c
index f021663..563e916 100644
--- a/block/cloop.c
+++ b/block/cloop.c
@@ -99,6 +99,13 @@ static int cloop_open(BlockDriverState *bs, QDict *options,
int flags,
s-n_blocks = be32_to_cpu(s-n_blocks);
/* read offsets */
+if (s-n_blocks UINT32_MAX / sizeof(uint64_t)) {
+/* Prevent integer overflow */
+error_setg(errp, n_blocks %u must be %zu or less,
+ s-n_blocks,
+ UINT32_MAX / sizeof(uint64_t));
+return -EINVAL;
+}
offsets_size = s-n_blocks * sizeof(uint64_t);
s-offsets = g_malloc(offsets_size);
diff --git a/tests/qemu-iotests/075 b/tests/qemu-iotests/075
index 8f54a99..9ce6b1f 100755
--- a/tests/qemu-iotests/075
+++ b/tests/qemu-iotests/075
@@ -43,6 +43,7 @@ _supported_proto generic
_supported_os Linux
block_size_offset=128
+n_blocks_offset=132
echo
echo == check that the first sector can be read ==
@@ -67,6 +68,12 @@ _use_sample_img simple-pattern.cloop.bz2
poke_file $TEST_IMG $block_size_offset \xff\xff\xfe\x00
$QEMU_IO -c read 0 512 $TEST_IMG 21 | _filter_qemu_io | _filter_testdir
+echo
+echo == offsets_size overflow ===
+_use_sample_img simple-pattern.cloop.bz2
+poke_file $TEST_IMG $n_blocks_offset \xff\xff\xff\xff
+$QEMU_IO -c read 0 512 $TEST_IMG 21 | _filter_qemu_io | _filter_testdir
+
# success, all done
echo *** done
rm -f $seq.full
diff --git a/tests/qemu-iotests/075.out b/tests/qemu-iotests/075.out
index d362c95..a771789 100644
--- a/tests/qemu-iotests/075.out
+++ b/tests/qemu-iotests/075.out
@@ -15,4 +15,8 @@ no file open, try 'help open'
== huge block_size ===
qemu-io: can't open device TEST_DIR/simple-pattern.cloop: block_size
4294966784 must be 64 MB or less
no file open, try 'help open'
+
+== offsets_size overflow ===
+qemu-io: can't open device TEST_DIR/simple-pattern.cloop: n_blocks 4294967295
must be 536870911 or less
+no file open, try 'help open'
*** done
--
1.9.1
[Qemu-devel] [PATCH 153/156] vnc: Fix tight_detect_smooth_image() for lossless case
From: Markus Armbruster arm...@redhat.com
VncTight member uint8_t quality is either (uint8_t)-1 for lossless or
less than 10 for lossy.
tight_detect_smooth_image() first promotes it to int, then compares
with -1. Always unequal, so we always execute the lossy code. Reads
beyond tight_conf[] and returns crap when quality is actually
lossless.
Compare to (uint8_t)-1 instead, like we do elsewhere.
Spotted by Coverity.
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
(cherry picked from commit 2e7bcdb99adbd8fc10ad9ddcf93bd2bf3c0f1f2d)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
ui/vnc-enc-tight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c
index e6966ae..59b59c0 100644
--- a/ui/vnc-enc-tight.c
+++ b/ui/vnc-enc-tight.c
@@ -330,7 +330,7 @@ tight_detect_smooth_image(VncState *vs, int w, int h)
} else {
errors = tight_detect_smooth_image16(vs, w, h);
}
-if (quality != -1) {
+if (quality != (uint8_t)-1) {
return (errors tight_conf[quality].jpeg_threshold);
}
return (errors tight_conf[compression].gradient_threshold);
--
1.9.1
[Qemu-devel] [PATCH 144/156] coroutine-win32.c: Add noinline attribute to work around gcc bug
From: Peter Maydell peter.mayd...@linaro.org
A gcc codegen bug in x86_64-w64-mingw32-gcc (GCC) 4.6.3 means that
non-debug builds of QEMU for Windows tend to assert when using
coroutines. Work around this by marking qemu_coroutine_switch
as noinline.
If we allow gcc to inline qemu_coroutine_switch into
coroutine_trampoline, then it hoists the code to get the
address of the TLS variable current out of the while() loop.
This is an invalid transformation because the SwitchToFiber()
call may be called when running thread A but return in thread B,
and so we might be in a different thread context each time
round the loop. This can happen quite often. Typically.
a coroutine is started when a VCPU thread does bdrv_aio_readv:
VCPU thread
main VCPU thread coroutine I/O coroutine
bdrv_aio_readv -
start I/O operation
thread_pool_submit_co
yields
back to emulation
Then I/O finishes and the thread-pool.c event notifier triggers in
the I/O thread. event_notifier_ready calls thread_pool_co_cb, and
the I/O coroutine now restarts *in another thread*:
iothread
main iothread coroutine I/O coroutine (formerly in VCPU thread)
event_notifier_ready
thread_pool_co_cb - current = I/O coroutine;
call AIO callback
But on Win32, because of the bug, the current being set here the
current coroutine of the VCPU thread, not the iothread.
noinline is a good-enough workaround, and quite unlikely to break in
the future.
(Thanks to Paolo Bonzini for assistance in diagnosing the problem
and providing the detailed example/ascii art quoted above.)
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Message-id: 1403535303-14939-1-git-send-email-peter.mayd...@linaro.org
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Richard Henderson r...@twiddle.net
(cherry picked from commit ff4873cb8c81db89668d8b56e19e57b852edb5f5)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
coroutine-win32.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/coroutine-win32.c b/coroutine-win32.c
index edc1f72..17ace37 100644
--- a/coroutine-win32.c
+++ b/coroutine-win32.c
@@ -36,8 +36,17 @@ typedef struct
static __thread CoroutineWin32 leader;
static __thread Coroutine *current;
-CoroutineAction qemu_coroutine_switch(Coroutine *from_, Coroutine *to_,
- CoroutineAction action)
+/* This function is marked noinline to prevent GCC from inlining it
+ * into coroutine_trampoline(). If we allow it to do that then it
+ * hoists the code to get the address of the TLS variable current
+ * out of the while() loop. This is an invalid transformation because
+ * the SwitchToFiber() call may be called when running thread A but
+ * return in thread B, and so we might be in a different thread
+ * context each time round the loop.
+ */
+CoroutineAction __attribute__((noinline))
+qemu_coroutine_switch(Coroutine *from_, Coroutine *to_,
+ CoroutineAction action)
{
CoroutineWin32 *from = DO_UPCAST(CoroutineWin32, base, from_);
CoroutineWin32 *to = DO_UPCAST(CoroutineWin32, base, to_);
--
1.9.1
[Qemu-devel] [PATCH] ui/gtk: Restore keyboard focus after Page change
In the GTK UI, after changing focus to the qemu monitor Notebook Page,
when restoring focus to the virtual machine page, the keyboard focus is lost
to a hidden GTK widget. Focus can only be restored to the virtual machine by
pressing tab or any of the four directional arrow keys.
Clicking in the window or grabbing/ungrabbing input does not restore keyboard
focus to the child widget.
This patch adjusts the Notebook page switching callback to automatically
steal keyboard focus on the Page switch event, so that keyboard input
does not appear to break or disappear after tabbing to the QEMU monitor.
Signed-off-by: John Snow js...@redhat.com
---
ui/gtk.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/ui/gtk.c b/ui/gtk.c
index b02fcd6..2345d7e 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -992,13 +992,16 @@ static void gd_menu_switch_vc(GtkMenuItem *item, void
*opaque)
{
GtkDisplayState *s = opaque;
VirtualConsole *vc = gd_vc_find_by_menu(s);
+GtkNotebook *nb = GTK_NOTEBOOK(s-notebook);
+GtkWidget *child;
gint page;
gtk_release_modifiers(s);
if (vc) {
-page = gtk_notebook_page_num(GTK_NOTEBOOK(s-notebook),
- vc-tab_item);
-gtk_notebook_set_current_page(GTK_NOTEBOOK(s-notebook), page);
+page = gtk_notebook_page_num(nb, vc-tab_item);
+gtk_notebook_set_current_page(nb, page);
+child = gtk_notebook_get_nth_page(nb, page);
+gtk_widget_grab_focus(child);
}
}
--
1.9.3
[Qemu-devel] [PATCH 080/156] bochs: Check extent_size header field (CVE-2014-0142)
From: Kevin Wolf kw...@redhat.com
This fixes two possible division by zero crashes: In bochs_open() and in
seek_to_sector().
Signed-off-by: Kevin Wolf kw...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@redhat.com
(cherry picked from commit 8e53abbc20d08ae3ec30c2054e1161314ad9501d)
Signed-off-by: Michael Roth mdr...@linux.vnet.ibm.com
---
block/bochs.c | 8
tests/qemu-iotests/078 | 13 +
tests/qemu-iotests/078.out | 8
3 files changed, 29 insertions(+)
diff --git a/block/bochs.c b/block/bochs.c
index d1b1a2c..0ec980a 100644
--- a/block/bochs.c
+++ b/block/bochs.c
@@ -147,6 +147,14 @@ static int bochs_open(BlockDriverState *bs, QDict
*options, int flags,
s-extent_blocks = 1 + (le32_to_cpu(bochs.extent) - 1) / 512;
s-extent_size = le32_to_cpu(bochs.extent);
+if (s-extent_size == 0) {
+error_setg(errp, Extent size may not be zero);
+return -EINVAL;
+} else if (s-extent_size 0x80) {
+error_setg(errp, Extent size % PRIu32 is too large,
+ s-extent_size);
+return -EINVAL;
+}
if (s-catalog_size bs-total_sectors / s-extent_size) {
error_setg(errp, Catalog size is too small for this disk size);
diff --git a/tests/qemu-iotests/078 b/tests/qemu-iotests/078
index 902ef0f..872e734 100755
--- a/tests/qemu-iotests/078
+++ b/tests/qemu-iotests/078
@@ -43,6 +43,7 @@ _supported_proto generic
_supported_os Linux
catalog_size_offset=$((0x48))
+extent_size_offset=$((0x50))
disk_size_offset=$((0x58))
echo
@@ -68,6 +69,18 @@ _use_sample_img empty.bochs.bz2
poke_file $TEST_IMG $disk_size_offset \x00\xc0\x0f\x00\x00\x00\x00\x7f
{ $QEMU_IO -c read 2T 4k $TEST_IMG; } 21 | _filter_qemu_io |
_filter_testdir
+echo
+echo == Negative extent size ==
+_use_sample_img empty.bochs.bz2
+poke_file $TEST_IMG $extent_size_offset \xff\xff\xff\xff
+{ $QEMU_IO -c read 768k 512 $TEST_IMG; } 21 | _filter_qemu_io |
_filter_testdir
+
+echo
+echo == Zero extent size ==
+_use_sample_img empty.bochs.bz2
+poke_file $TEST_IMG $extent_size_offset \x00\x00\x00\x00
+{ $QEMU_IO -c read 0 512 $TEST_IMG; } 21 | _filter_qemu_io |
_filter_testdir
+
# success, all done
echo *** done
rm -f $seq.full
diff --git a/tests/qemu-iotests/078.out b/tests/qemu-iotests/078.out
index 7254693..ea95ffd 100644
--- a/tests/qemu-iotests/078.out
+++ b/tests/qemu-iotests/078.out
@@ -15,4 +15,12 @@ no file open, try 'help open'
== Too small catalog bitmap for image size ==
qemu-io: can't open device TEST_DIR/empty.bochs: Catalog size is too small for
this disk size
no file open, try 'help open'
+
+== Negative extent size ==
+qemu-io: can't open device TEST_DIR/empty.bochs: Extent size 4294967295 is too
large
+no file open, try 'help open'
+
+== Zero extent size ==
+qemu-io: can't open device TEST_DIR/empty.bochs: Extent size may not be zero
+no file open, try 'help open'
*** done
--
1.9.1
