[kvm-devel] [PATCH] qemu-kvm: Consolidate kvm_eat_signal v2
Here comes the second revision of the attempt to consolidate
kvm_eat_signal[s]. It follows the suggestions to remove looping over
kvm_eat_signal and folds everything into kvm_main_loop_wait.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/qemu-kvm.c | 43 ---
1 file changed, 8 insertions(+), 35 deletions(-)
Index: b/qemu/qemu-kvm.c
===
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -173,64 +173,37 @@ static int has_work(CPUState *env)
return kvm_arch_has_work(env);
}
-static int kvm_eat_signal(CPUState *env, int timeout)
+static void kvm_main_loop_wait(CPUState *env, int timeout)
{
struct timespec ts;
-int r, e, ret = 0;
+int r, e;
siginfo_t siginfo;
sigset_t waitset;
+pthread_mutex_unlock(qemu_mutex);
+
ts.tv_sec = timeout / 1000;
ts.tv_nsec = (timeout % 1000) * 100;
sigemptyset(waitset);
sigaddset(waitset, SIG_IPI);
r = sigtimedwait(waitset, siginfo, ts);
-if (r == -1 (errno == EAGAIN || errno == EINTR) !timeout)
- return 0;
e = errno;
pthread_mutex_lock(qemu_mutex);
-if (env vcpu)
-cpu_single_env = vcpu-env;
-if (r == -1 !(errno == EAGAIN || errno == EINTR)) {
+
+if (r == -1 !(e == EAGAIN || e == EINTR)) {
printf(sigtimedwait: %s\n, strerror(e));
exit(1);
}
-if (r != -1)
- ret = 1;
-if (env vcpu_info[env-cpu_index].stop) {
+if (vcpu_info[env-cpu_index].stop) {
vcpu_info[env-cpu_index].stop = 0;
vcpu_info[env-cpu_index].stopped = 1;
pthread_cond_signal(qemu_pause_cond);
}
-pthread_mutex_unlock(qemu_mutex);
-
-return ret;
-}
-
-
-static void kvm_eat_signals(CPUState *env, int timeout)
-{
-int r = 0;
-
-while (kvm_eat_signal(env, 0))
- r = 1;
-if (!r timeout) {
- r = kvm_eat_signal(env, timeout);
- if (r)
- while (kvm_eat_signal(env, 0))
- ;
-}
-}
-
-static void kvm_main_loop_wait(CPUState *env, int timeout)
-{
-pthread_mutex_unlock(qemu_mutex);
-kvm_eat_signals(env, timeout);
-pthread_mutex_lock(qemu_mutex);
cpu_single_env = env;
+
vcpu_info[env-cpu_index].signalled = 0;
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Reminder] kvm mailing lists moving
Avi Kivity wrote: [I forgot to do this last weekend, so it's postponed to Saturday] During the upcoming Saturday, the various kvm lists will move to vger.kenel.org. This will improve responsiveness, and reduce spam and advertising. Please subscribe to the lists you are interested in as soon as possible. You can subscribe by sending an email to [EMAIL PROTECTED], with the following lines in the body: subscribe kvm subscribe kvm-commits subscribe kvm-ia64 subscribe kvm-ppc Will someone take care of creating new gmane.org archives at the same time, too? I'm relying on their news services for high-traffic lists like kvm's. Thanks, Jan signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Reminder] kvm mailing lists moving
Jan Kiszka wrote: Avi Kivity wrote: [I forgot to do this last weekend, so it's postponed to Saturday] During the upcoming Saturday, the various kvm lists will move to vger.kenel.org. This will improve responsiveness, and reduce spam and advertising. Please subscribe to the lists you are interested in as soon as possible. You can subscribe by sending an email to [EMAIL PROTECTED], with the following lines in the body: subscribe kvm subscribe kvm-commits subscribe kvm-ia64 subscribe kvm-ppc Will someone take care of creating new gmane.org archives at the same time, too? I'm relying on their news services for high-traffic lists like kvm's. (Which means, if nobody does, I would do. Later, I'll just need the mbox archives in order to feed-in all postings up to the subscription time.) Jan signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC][PATCH 0/4] Guest debugging via soft breakpoints
This is yet only a proof of concept; more cleanups, generalizations, full arch support, and some care for ABI consistency are needed. However, this series allows to actually _use_ guest debugging with kvm on x86 (Intel only so far). There is no more limitation on how many breakpoints can be used in parallel, and this does not depend on existing (and correct) hardware breakpoint support. In fact, it breaks my patches for this, need to rebase them later and enable hw-breakpoint/ watchpoint support this way. The patch series depends on earlier fixes of mine, namely - qemu-kvm: Fix guest resetting v2 (http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/17442) - kvm-qemu: Fix monitor and gdbstub deadlocks v2 (http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/17444) Feedback is welcome. Jan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC][PATCH 1/4] qemu: refactor cpu_watch/breakpoint API
[ Should apply against vanilla QEMU, but not ATM due to ongoing
constructions in gdbstub. ]
This patch prepares the QEMU cpu_watchpoint/breakpoint API to allow us
hooking in with KVM and doing guest debugging differently (maybe
QEMUAccel should provide appropriate callbacks for this, too). But it
also allows to extend QEMU's debugging features one day, specifically
/wrt different watchpoint types.
---
qemu/cpu-all.h | 14 ++
qemu/exec.c| 30 --
qemu/gdbstub.c | 50 +-
3 files changed, 59 insertions(+), 35 deletions(-)
Index: b/qemu/cpu-all.h
===
--- a/qemu/cpu-all.h
+++ b/qemu/cpu-all.h
@@ -758,10 +758,16 @@ extern int code_copy_enabled;
void cpu_interrupt(CPUState *s, int mask);
void cpu_reset_interrupt(CPUState *env, int mask);
-int cpu_watchpoint_insert(CPUState *env, target_ulong addr);
-int cpu_watchpoint_remove(CPUState *env, target_ulong addr);
-int cpu_breakpoint_insert(CPUState *env, target_ulong pc);
-int cpu_breakpoint_remove(CPUState *env, target_ulong pc);
+#define GDB_BREAKPOINT_SW 0
+#define GDB_BREAKPOINT_HW 1
+#define GDB_WATCHPOINT_WRITE2
+#define GDB_WATCHPOINT_READ 3
+#define GDB_WATCHPOINT_ACCESS 4
+
+int cpu_watchpoint_insert(CPUState *env, target_ulong addr, target_ulong len,
int type);
+int cpu_watchpoint_remove(CPUState *env, target_ulong addr, target_ulong len,
int type);
+int cpu_breakpoint_insert(CPUState *env, target_ulong pc, target_ulong len,
int type);
+int cpu_breakpoint_remove(CPUState *env, target_ulong pc, target_ulong len,
int type);
void cpu_single_step(CPUState *env, int enabled);
void cpu_reset(CPUState *s);
Index: b/qemu/exec.c
===
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -1104,16 +1104,20 @@ static void breakpoint_invalidate(CPUSta
#endif
/* Add a watchpoint. */
-int cpu_watchpoint_insert(CPUState *env, target_ulong addr)
+int cpu_watchpoint_insert(CPUState *env, target_ulong addr, target_ulong len,
+ int type)
{
int i;
+if (type != GDB_WATCHPOINT_WRITE)
+return -ENOSYS;
+
for (i = 0; i env-nb_watchpoints; i++) {
if (addr == env-watchpoint[i].vaddr)
return 0;
}
if (env-nb_watchpoints = MAX_WATCHPOINTS)
-return -1;
+return -ENOBUFS;
i = env-nb_watchpoints++;
env-watchpoint[i].vaddr = addr;
@@ -1126,10 +1130,14 @@ int cpu_watchpoint_insert(CPUState *env
}
/* Remove a watchpoint. */
-int cpu_watchpoint_remove(CPUState *env, target_ulong addr)
+int cpu_watchpoint_remove(CPUState *env, target_ulong addr, target_ulong len,
+ int type)
{
int i;
+if (type != GDB_WATCHPOINT_WRITE)
+return -ENOSYS;
+
for (i = 0; i env-nb_watchpoints; i++) {
if (addr == env-watchpoint[i].vaddr) {
env-nb_watchpoints--;
@@ -1138,12 +1146,13 @@ int cpu_watchpoint_remove(CPUState *env,
return 0;
}
}
-return -1;
+return -ENOENT;
}
/* add a breakpoint. EXCP_DEBUG is returned by the CPU loop if a
breakpoint is reached */
-int cpu_breakpoint_insert(CPUState *env, target_ulong pc)
+int cpu_breakpoint_insert(CPUState *env, target_ulong pc, target_ulong len,
+ int type)
{
#if defined(TARGET_HAS_ICE)
int i;
@@ -1154,7 +1163,7 @@ int cpu_breakpoint_insert(CPUState *env,
}
if (env-nb_breakpoints = MAX_BREAKPOINTS)
-return -1;
+return -ENOBUFS;
env-breakpoints[env-nb_breakpoints++] = pc;
if (kvm_enabled())
@@ -1163,12 +1172,13 @@ int cpu_breakpoint_insert(CPUState *env,
breakpoint_invalidate(env, pc);
return 0;
#else
-return -1;
+return -ENOSYS;
#endif
}
/* remove a breakpoint */
-int cpu_breakpoint_remove(CPUState *env, target_ulong pc)
+int cpu_breakpoint_remove(CPUState *env, target_ulong pc, target_ulong len,
+ int type)
{
#if defined(TARGET_HAS_ICE)
int i;
@@ -1176,7 +1186,7 @@ int cpu_breakpoint_remove(CPUState *env,
if (env-breakpoints[i] == pc)
goto found;
}
-return -1;
+return -ENOENT;
found:
env-nb_breakpoints--;
if (i env-nb_breakpoints)
@@ -1188,7 +1198,7 @@ int cpu_breakpoint_remove(CPUState *env,
breakpoint_invalidate(env, pc);
return 0;
#else
-return -1;
+return -ENOSYS;
#endif
}
Index: b/qemu/gdbstub.c
===
--- a/qemu/gdbstub.c
+++ b/qemu/gdbstub.c
@@ -882,7 +882,7 @@ static void cpu_gdb_write_registers(CPUS
static int gdb_handle_packet(GDBState *s, CPUState *env, const char *line_buf)
{
const char *p;
-int ch, reg_size, type;
+int ch, reg_size, type, res;
char buf[4096];
uint8_t mem_buf[4096];
uint32_t
[kvm-devel] [RFC][PATCH 3/4] kvm-vmx: KVM_EXIT_DEBUG on #BP exceptions
In order to allow the gdbstub of QEMU to push (soft) breakpoint handling
completely into the gdb frontend, this patch enables guest exits also
for #BP exceptions - in case guest debugging was turned on.
Along this enhancement, this patch also fixes the flag manipulation for
the singlestep mode.
---
arch/x86/kvm/vmx.c | 38 +++---
1 file changed, 15 insertions(+), 23 deletions(-)
Index: b/arch/x86/kvm/vmx.c
===
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -461,7 +461,7 @@ static void update_exception_bitmap(stru
if (!vcpu-fpu_active)
eb |= 1u NM_VECTOR;
if (vcpu-guest_debug.enabled)
- eb |= 1u 1;
+ eb |= (1u 1) | (1u 3);
if (vcpu-arch.rmode.active)
eb = ~0;
if (vm_need_ept())
@@ -949,6 +949,7 @@ static int set_guest_debug(struct kvm_vc
{
unsigned long dr7 = 0x400;
int old_singlestep;
+ unsigned long flags;
old_singlestep = vcpu-guest_debug.singlestep;
@@ -969,13 +970,12 @@ static int set_guest_debug(struct kvm_vc
} else
vcpu-guest_debug.singlestep = 0;
- if (old_singlestep !vcpu-guest_debug.singlestep) {
- unsigned long flags;
-
- flags = vmcs_readl(GUEST_RFLAGS);
+ flags = vmcs_readl(GUEST_RFLAGS);
+ if (vcpu-guest_debug.singlestep)
+ flags |= X86_EFLAGS_TF | X86_EFLAGS_RF;
+ else if (old_singlestep !vcpu-guest_debug.singlestep)
flags = ~(X86_EFLAGS_TF | X86_EFLAGS_RF);
- vmcs_writel(GUEST_RFLAGS, flags);
- }
+ vmcs_writel(GUEST_RFLAGS, flags);
update_exception_bitmap(vcpu);
vmcs_writel(GUEST_DR7, dr7);
@@ -2192,14 +2192,6 @@ static void kvm_guest_debug_pre(struct k
set_debugreg(dbg-bp[1], 1);
set_debugreg(dbg-bp[2], 2);
set_debugreg(dbg-bp[3], 3);
-
- if (dbg-singlestep) {
- unsigned long flags;
-
- flags = vmcs_readl(GUEST_RFLAGS);
- flags |= X86_EFLAGS_TF | X86_EFLAGS_RF;
- vmcs_writel(GUEST_RFLAGS, flags);
- }
}
static int handle_rmode_exception(struct kvm_vcpu *vcpu,
@@ -2221,7 +2213,7 @@ static int handle_rmode_exception(struct
static int handle_exception(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
struct vcpu_vmx *vmx = to_vmx(vcpu);
- u32 intr_info, error_code;
+ u32 intr_info, ex_no, error_code;
unsigned long cr2, rip;
u32 vect_info;
enum emulation_result er;
@@ -2279,15 +2271,15 @@ static int handle_exception(struct kvm_v
return 1;
}
- if ((intr_info (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VECTOR_MASK)) ==
- (INTR_TYPE_EXCEPTION | 1)) {
+ ex_no = intr_info INTR_INFO_VECTOR_MASK;
+ if (ex_no == 1 || ex_no == 3) {
kvm_run-exit_reason = KVM_EXIT_DEBUG;
- kvm_run-debug.arch.exception = 1;
- return 0;
+ kvm_run-debug.arch.exception = ex_no;
+ } else {
+ kvm_run-exit_reason = KVM_EXIT_EXCEPTION;
+ kvm_run-ex.exception = ex_no;
+ kvm_run-ex.error_code = error_code;
}
- kvm_run-exit_reason = KVM_EXIT_EXCEPTION;
- kvm_run-ex.exception = intr_info INTR_INFO_VECTOR_MASK;
- kvm_run-ex.error_code = error_code;
return 0;
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC][PATCH 2/4] kvm: Arch-specifc KVM_EXIT_DEBUG payload
This adds an arch field to kvm_run.debug, the payload that is returned
to user space on KVM_EXIT_DEBUG guest exits. For x86, this field is now
supposed to report the precise debug exception (#DB or #BP) and the
current state of the debug registers (the latter is not yet
implemented).
---
arch/x86/kvm/vmx.c|1 +
include/asm-x86/kvm.h |5 +
include/linux/kvm.h |1 +
3 files changed, 7 insertions(+)
Index: b/arch/x86/kvm/vmx.c
===
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2282,6 +2282,7 @@ static int handle_exception(struct kvm_v
if ((intr_info (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VECTOR_MASK)) ==
(INTR_TYPE_EXCEPTION | 1)) {
kvm_run-exit_reason = KVM_EXIT_DEBUG;
+ kvm_run-debug.arch.exception = 1;
return 0;
}
kvm_run-exit_reason = KVM_EXIT_EXCEPTION;
Index: b/include/asm-x86/kvm.h
===
--- a/include/asm-x86/kvm.h
+++ b/include/asm-x86/kvm.h
@@ -230,4 +230,9 @@ struct kvm_pit_state {
#define KVM_TRC_APIC_ACCESS (KVM_TRC_HANDLER + 0x14)
#define KVM_TRC_TDP_FAULT(KVM_TRC_HANDLER + 0x15)
+struct kvm_debug_exit_arch {
+ __u32 exception;
+ __u64 dr[8];
+};
+
#endif
Index: b/include/linux/kvm.h
===
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -125,6 +125,7 @@ struct kvm_run {
__u64 data_offset; /* relative to kvm_run start */
} io;
struct {
+ struct kvm_debug_exit_arch arch;
} debug;
/* KVM_EXIT_MMIO */
struct {
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [RFC][PATCH 4/4] kvm-userspace: use soft-BPs for guest debugging
With this patch applied, kvm is able to ignore breakpoint requests of an
attached gdb frontend so that the latter is motivated to insert soft
breakpoints into the guest code. All we need to do for this is to catch
and forward #BP exceptions which are now provided by the kernel module.
Along this, the patch makes vm_stop-on-breakpoint start to work.
Limitations:
- only takes care of x86 so far
- gdbstub state tracking is broken (artificially incrementing
nb_breakpoints won't fly, as we'll have no chance to decrement it),
we need an enhanced interface to the stub
---
libkvm/kvm-common.h |2 ++
libkvm/libkvm-x86.c | 16
libkvm/libkvm.c |5 -
libkvm/libkvm.h |8 +++-
qemu/exec.c | 19 +--
qemu/qemu-kvm.c | 22 +-
6 files changed, 51 insertions(+), 21 deletions(-)
Index: b/libkvm/kvm-common.h
===
--- a/libkvm/kvm-common.h
+++ b/libkvm/kvm-common.h
@@ -85,4 +85,6 @@ int handle_io_window(kvm_context_t kvm);
int handle_debug(kvm_context_t kvm, int vcpu);
int try_push_interrupts(kvm_context_t kvm);
+int handle_debug(kvm_context_t kvm, int vcpu);
+
#endif
Index: b/libkvm/libkvm-x86.c
===
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -661,3 +661,19 @@ int kvm_disable_tpr_access_reporting(kvm
}
#endif
+
+int handle_debug(kvm_context_t kvm, int vcpu)
+{
+ struct kvm_run *run = kvm-run[vcpu];
+ unsigned long watchpoint = 0;
+ int break_type;
+
+ if (run-debug.arch.exception == 1) {
+ /* TODO: fully process run-debug.arch */
+ break_type = KVM_GDB_BREAKPOINT_HW;
+ } else
+ break_type = KVM_GDB_BREAKPOINT_SW;
+
+ return kvm-callbacks-debug(kvm-opaque, vcpu, break_type,
+watchpoint);
+}
Index: b/libkvm/libkvm.c
===
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -738,11 +738,6 @@ static int handle_io(kvm_context_t kvm,
return 0;
}
-int handle_debug(kvm_context_t kvm, int vcpu)
-{
- return kvm-callbacks-debug(kvm-opaque, vcpu);
-}
-
int kvm_get_regs(kvm_context_t kvm, int vcpu, struct kvm_regs *regs)
{
return ioctl(kvm-vcpu_fd[vcpu], KVM_GET_REGS, regs);
Index: b/qemu/exec.c
===
--- a/qemu/exec.c
+++ b/qemu/exec.c
@@ -1157,6 +1157,12 @@ int cpu_breakpoint_insert(CPUState *env,
#if defined(TARGET_HAS_ICE)
int i;
+if (kvm_enabled()) {
+env-nb_breakpoints++;
+kvm_update_debugger(env);
+return -ENOSYS;
+}
+
for(i = 0; i env-nb_breakpoints; i++) {
if (env-breakpoints[i] == pc)
return 0;
@@ -1166,9 +1172,6 @@ int cpu_breakpoint_insert(CPUState *env,
return -ENOBUFS;
env-breakpoints[env-nb_breakpoints++] = pc;
-if (kvm_enabled())
- kvm_update_debugger(env);
-
breakpoint_invalidate(env, pc);
return 0;
#else
@@ -1182,6 +1185,13 @@ int cpu_breakpoint_remove(CPUState *env,
{
#if defined(TARGET_HAS_ICE)
int i;
+
+if (kvm_enabled()) {
+env-nb_breakpoints--;
+kvm_update_debugger(env);
+return -ENOSYS;
+}
+
for(i = 0; i env-nb_breakpoints; i++) {
if (env-breakpoints[i] == pc)
goto found;
@@ -1192,9 +1202,6 @@ int cpu_breakpoint_remove(CPUState *env,
if (i env-nb_breakpoints)
env-breakpoints[i] = env-breakpoints[env-nb_breakpoints];
-if (kvm_enabled())
- kvm_update_debugger(env);
-
breakpoint_invalidate(env, pc);
return 0;
#else
Index: b/qemu/qemu-kvm.c
===
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -58,6 +58,8 @@ pthread_t io_thread;
static int io_thread_fd = -1;
static int io_thread_sigfd = -1;
+static int kvm_debug_stop_requested;
+
static inline unsigned long kvm_get_thread_id(void)
{
return syscall(SYS_gettid);
@@ -517,6 +519,10 @@ int kvm_main_loop(void)
qemu_system_powerdown();
else if (qemu_reset_requested())
qemu_kvm_system_reset();
+ else if (kvm_debug_stop_requested) {
+ kvm_debug_stop_requested = 0;
+ vm_stop(EXCP_DEBUG);
+ }
}
pause_all_threads();
@@ -525,11 +531,12 @@ int kvm_main_loop(void)
return 0;
}
-static int kvm_debug(void *opaque, int vcpu)
+static int kvm_debug(void *opaque, int vcpu, int break_type,
+ uint64_t watchpoint_addr)
{
-CPUState *env = cpu_single_env;
-
-env-exception_index = EXCP_DEBUG;
+/* TODO: process break_type */
+kvm_debug_stop_requested = 1;
+vcpu_info[vcpu].stopped = 1;
return 1;
}
@@ -748,15 +755,12 @@ int kvm_qemu_init_env(CPUState *cenv)
int
[kvm-devel] [PATCH] Remove unused get_bios_map
Dead code since it was introduced. Is it planned to use it in the near
future? Then I would suggest to put it under #if 0 for now. Otherwise,
please pick up this patch.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/kvm-tpr-opt.c | 13 -
1 file changed, 13 deletions(-)
Index: b/qemu/kvm-tpr-opt.c
===
--- a/qemu/kvm-tpr-opt.c
+++ b/qemu/kvm-tpr-opt.c
@@ -83,19 +83,6 @@ static void write_byte_virt(CPUState *en
stb_phys(map_addr(sregs, virt, NULL), b);
}
-static uint32_t get_bios_map(CPUState *env, unsigned *perms)
-{
-uint32_t v;
-struct kvm_sregs sregs;
-
-kvm_get_sregs(kvm_context, env-cpu_index, sregs);
-
-for (v = -4096u; v != 0; v -= 4096)
- if (map_addr(sregs, v, perms) == 0xe)
- return v;
-return -1u;
-}
-
struct vapic_bios {
char signature[8];
uint32_t virt_base;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Silence warnings in migration.c
These warnings continued to bug me (while scanning for my own mess).
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/migration.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: b/qemu/migration.c
===
--- a/qemu/migration.c
+++ b/qemu/migration.c
@@ -834,8 +834,8 @@ static int migrate_incoming_fd(int fd)
size = qemu_get_be32(f);
if (size != phys_ram_size) {
-fprintf(stderr, migration: memory size mismatch: recv %u mine %u\n,
-size, phys_ram_size);
+fprintf(stderr, migration: memory size mismatch: recv %u mine %llu\n,
+size, (unsigned long long)phys_ram_size);
return MIG_STAT_DST_MEM_SIZE_MISMATCH;
}
@@ -1090,7 +1090,8 @@ void do_info_migration(void)
term_printf(Transfer rate %3.1f mb/s\n,
(double)s-bps / (1024 * 1024));
term_printf(Iteration %d\n, s-iteration);
- term_printf(Transferred %d/%d pages\n, s-updated_pages,
phys_ram_size TARGET_PAGE_BITS);
+ term_printf(Transferred %d/%llu pages\n, s-updated_pages,
+ (unsigned long long)phys_ram_size TARGET_PAGE_BITS);
if (s-iteration)
term_printf(Last iteration found %d dirty pages\n,
s-last_updated_pages);
} else {
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST
Jerone Young wrote:
On Mon, 2008-05-12 at 13:34 +0200, Jan Kiszka wrote:
Hi,
before going wild with my idea, I would like to collect some comments on
this approach:
While doing first kernel debugging with my debug register patches for
kvm, I quickly ran into the 4-breakpoints-only limitation that comes
from the fact that we blindly map software to hardware breakpoints.
Unhandy, simply suboptimal. Also, having 4 breakpoint slots hard-coded
in the generic interface is not fair to arch that may support more.
Moreover, we do not support watchpoints although this would easily be
feasible. But if we supported watchpoints (via debug registers on x86),
we would need the break out of the 4 slots limitations even earlier. In
short, I came to the conclusion that a rewrite of the KVM_DEBUG_GUEST
interface is required.
So embedded power is also limited to 4 hardware registers for break
points. But there are 2 sepreate registers fro watch points. The reason
to use the registers is the hardware does the work for you and (at least
on Power) will throw an exception or trap. Then you deal with it.
But you still face the fact that you can only have a small number of
breakpoints watch points. Also you cannot use gdb in the guest at the
sametime while using the gdb stub on the guest itself (as there is only
one set of registers).
So gdb on power relies only on those few hw-breakpoints? With x86 you
can perfectly run gdb (with soft BPs) in parallel with the gdbstub
(currently based on hw-BPs, but the same would be true for soft-BPs
inserted by the gdbstub).
Why do we set breakpoints in the kernel? Why not simply catching all
debug traps, inserting software breakpoint ops into the guest code, and
handling all this stuff as normal debuggers do? And the hardware
breakpoints should just be pushed through the kernel interface like
ptrace does.
See above...But the cpu basically does the work for you. So you don't
have to try and go through and first insert a trap into the code in
memory. But then you have to remember the code that you replaced with
the trap and execute it after you handle the trap. This can get a little
hairy.
I cannot imaging that this is so hairy. It is basically daily (x86-)
debugger business. Maybe we need to handle it differently if other
arches prefer their own way. But for x86 I don't see a need to restrict
our self to use hw-BPs _only_.
Currently I'm actually implementing breakpoint support now in Power. But
you do have to create some mappings to handle traps and see if you put
the trap there, and execute the code you replaced. Also what if the
breakpoint is removed. Then you have to go back through and actually
replace the trap code. Doesn't sound hard, but I'm not sure of all the
pitfalls.
Again, this /should/ not be different from what gdb does to applications
or kgdb does to the kernel. (Looks like I need to get my feet wet soon. :) )
The new KVM_DEBUG_GUEST interface I currently have in mind would look
like this:
#define KVM_DBGGUEST_ENABLE 0x01
#define KVM_DBGGUEST_SINGLESTEP 0x02
struct kvm_debug_guest {
__u32 control;
struct kvm_debug_guest_arch arch;
}
Setting KVM_DBGGUEST_ENABLE would forward all debug-related traps to
userspace first, which can then decide to handle or re-inject them.
KVM_DBGGUEST_SINGLESTEP would work as before. And the extension for x86
would look like this:
struct kvm_debug_guest_arch {
__u32 use_hw_breakpoints;
__u64 debugreg[8];
}
If use_hw_breakpoints is non-zero, KVM would completely overwrite the
guest's debug registers with the content of debugreg, giving full
control of this feature to the host-side debugger (faking the content of
debug registers, effectively disabling them for the guest - as we now do
all the time).
Hmmm...so today at least the gdbstub in qemu does not inject traps and
track code that it trapped (I could be mistaken). This whould all need
to be implemented as well.
gdbstub inserts virtual traps today, ie. a call from the translated
guest code to a helper which signals the breakpoint to the stub. And I
don't want to change this. I want to add the BP injection/removal to
qemu-kvm as it already takes over breakpoint (and soon also watchpoint)
maintenance from qemu.
However, would the proposed interface for KVM_DEBUG_GUEST (with an
appropriate kvm_debug_guest_arch for power) restrict your plans in any way?
Jan
signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST
Hollis Blanchard wrote: On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote: So gdb on power relies only on those few hw-breakpoints? With x86 you can perfectly run gdb (with soft BPs) in parallel with the gdbstub (currently based on hw-BPs, but the same would be true for soft-BPs inserted by the gdbstub). GDB on Power inserts trap instructions, i.e. standard soft breakpoints. It does not rely on the hardware breakpoints. It gets a little more complicated when you involve a GDB stub. IIRC, GDB will ask the stub to set the breakpoint, and if the stub doesn't support it, GDB will fall back to overwriting the instructions in memory. Does the Qemu GDB stub advertise breakpoint support? Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something even gdbserver does not do! It just handles watchpoints (Z2..4). If not, the only support needed in KVM would be to send all debug interrupts to qemu, and allow qemu to send them back down for in-guest breakpoints. Simply returning unsupported on Z0 is not yet enough for x86, KVM's kernel side should not yet inform QEMU about soft-BP exceptions. But in theory, this should be easily fixable (or is already the case for other archs). And it would safe us from keeping track of N software breakpoints, where N could even become larger than 32, the current hardcoded limit for plain QEMU. :) Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is insufficient: We need a return channel for the debug register state (specifically to figure out details about hit watchpoints). I'm now favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us to write _and_ read-back the suggested data structure. Jan signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST
Hollis Blanchard wrote: On Wednesday 14 May 2008 14:10:06 Jan Kiszka wrote: Hollis Blanchard wrote: On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote: So gdb on power relies only on those few hw-breakpoints? With x86 you can perfectly run gdb (with soft BPs) in parallel with the gdbstub (currently based on hw-BPs, but the same would be true for soft-BPs inserted by the gdbstub). GDB on Power inserts trap instructions, i.e. standard soft breakpoints. It does not rely on the hardware breakpoints. It gets a little more complicated when you involve a GDB stub. IIRC, GDB will ask the stub to set the breakpoint, and if the stub doesn't support it, GDB will fall back to overwriting the instructions in memory. Does the Qemu GDB stub advertise breakpoint support? Yes, QEMU reacts on both Z0 (soft-BP) and Z1 (hard-BP). That's something even gdbserver does not do! It just handles watchpoints (Z2..4). If not, the only support needed in KVM would be to send all debug interrupts to qemu, and allow qemu to send them back down for in-guest breakpoints. Simply returning unsupported on Z0 is not yet enough for x86, KVM's kernel side should not yet inform QEMU about soft-BP exceptions. But in theory, this should be easily fixable (or is already the case for other archs). And it would safe us from keeping track of N software breakpoints, where N could even become larger than 32, the current hardcoded limit for plain QEMU. :) Meanwhile I realized that the proposed KVM_DEBUG_GUEST API is insufficient: We need a return channel for the debug register state (specifically to figure out details about hit watchpoints). I'm now favoring KVM_SET_DEBUG and KVM_GET_DEBUG as two new IOCTLs, enabling us to write _and_ read-back the suggested data structure. How about simply extending kvm_exit.debug to contain the virtual address of the breakpoint hit? Ah, there is an interface for such stuff already! And it can even take quite some payload... In Qemu, when exit_reason == KVM_EXIT_DEBUG, it would just need to see if that address is for a breakpoint Qemu set or not. If so, it's happy. If not, (commence handwaving) tell KVM to forward the debug interrupt to the guest. This way, the list of breakpoints is maintained in userspace (in the qemu gdb stub), which is nice because it could be arbitrarily large. Yes, but I would rather pass the debug registers (more general: some arch dependent state set) back in this slot. Those contain everything the gdbstub needs to know to catch relevant hardware-BP/watchpoint events (and report them to the gdb frontend). Also, this is not specific to hardware debug registers: soft and hard breakpoint interrupts would follow the same path. There's still a question of whether the GDB stub should set the breakpoint itself (Z0/Z1) or force GDB to modify memory, but either way the KVM code is simple. Only rejecting Z0 will enable us to avoid any soft-BP tracking in qemu-kvm, and that is definitely my plan. Z1 may become an option to add later on and would be answered as unsupported for now. Jan signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/2] qemu-kvm: Introduce qemu_cond_wait wrapper
As suggested by Anthony, this patch encapsulates the sequence save
cpu_single_env, temporarily drop qemu_mutex, restore cpu_single_env for
condition variables in a helper function. It also adds a safety check to
the open-coded kvm_mutex_lock that the caller is not a vcpu thread (as
kvm_mutex_unlock clears cpu_single_env).
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/qemu-kvm.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
Index: b/qemu/qemu-kvm.c
===
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -12,6 +12,7 @@ int kvm_allowed = 1;
int kvm_irqchip = 1;
int kvm_pit = 1;
+#include assert.h
#include string.h
#include hw/hw.h
#include sysemu.h
@@ -65,6 +66,14 @@ static inline unsigned long kvm_get_thre
return syscall(SYS_gettid);
}
+static void qemu_cond_wait(pthread_cond_t *cond)
+{
+CPUState *env = cpu_single_env;
+
+pthread_cond_wait(cond, qemu_mutex);
+cpu_single_env = env;
+}
+
CPUState *qemu_kvm_cpu_env(int index)
{
return vcpu_info[index].env;
@@ -246,11 +255,8 @@ static void pause_all_threads(void)
vcpu_info[i].stop = 1;
pthread_kill(vcpu_info[i].thread, SIG_IPI);
}
-while (!all_threads_paused()) {
- CPUState *env = cpu_single_env;
- pthread_cond_wait(qemu_pause_cond, qemu_mutex);
- cpu_single_env = env;
-}
+while (!all_threads_paused())
+ qemu_cond_wait(qemu_pause_cond);
}
static void resume_all_threads(void)
@@ -372,7 +378,7 @@ static void *ap_main_loop(void *_env)
/* and wait for machine initialization */
while (!qemu_system_ready)
- pthread_cond_wait(qemu_system_cond, qemu_mutex);
+ qemu_cond_wait(qemu_system_cond);
pthread_mutex_unlock(qemu_mutex);
kvm_main_loop_cpu(env);
@@ -384,7 +390,7 @@ void kvm_init_new_ap(int cpu, CPUState *
pthread_create(vcpu_info[cpu].thread, NULL, ap_main_loop, env);
while (vcpu_info[cpu].created == 0)
- pthread_cond_wait(qemu_vcpu_cond, qemu_mutex);
+ qemu_cond_wait(qemu_vcpu_cond);
}
int kvm_init_ap(void)
@@ -892,8 +898,6 @@ void qemu_kvm_aio_wait_start(void)
void qemu_kvm_aio_wait(void)
{
-CPUState *cpu_single = cpu_single_env;
-
if (!cpu_single_env) {
if (io_thread_sigfd != -1) {
fd_set rfds;
@@ -910,10 +914,8 @@ void qemu_kvm_aio_wait(void)
sigfd_handler((void *)(unsigned long)io_thread_sigfd);
}
qemu_aio_poll();
-} else {
-pthread_cond_wait(qemu_aio_cond, qemu_mutex);
-cpu_single_env = cpu_single;
-}
+} else
+qemu_cond_wait(qemu_aio_cond);
}
void qemu_kvm_aio_wait_end(void)
@@ -939,6 +941,7 @@ void kvm_cpu_destroy_phys_mem(target_phy
void kvm_mutex_unlock(void)
{
+assert(!cpu_single_env);
pthread_mutex_unlock(qemu_mutex);
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/2] qemu-kvm: Fix guest resetting v2
Resetting guests used to be racy, deadlock-prone, or simply broken (for
SMP). This patch fixes the issues, following Marcelo's suggestion to
consolidate the reset activity in the I/O thread. All vcpus are cleanly
stopped before the emulated hardware is reset, and kvm_arch_cpu_reset is
introduced and invoked to ensure that non-boot cpus are put into the
right state on x86. Note that other arch may need to look into this
service as well to get SMP reset right.
Moreover, a safety check is added to pause/resume_all_threads to ensure
that they are only invoked in I/O thread context.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/qemu-kvm-ia64.c|4
qemu/qemu-kvm-powerpc.c |4
qemu/qemu-kvm-x86.c | 16
qemu/qemu-kvm.c | 34 +-
qemu/qemu-kvm.h |1 +
qemu/vl.c |6 +-
6 files changed, 43 insertions(+), 22 deletions(-)
Index: b/qemu/qemu-kvm-ia64.c
===
--- a/qemu/qemu-kvm-ia64.c
+++ b/qemu/qemu-kvm-ia64.c
@@ -61,3 +61,7 @@ int kvm_arch_try_push_interrupts(void *o
void kvm_arch_update_regs_for_sipi(CPUState *env)
{
}
+
+void kvm_arch_cpu_reset(CPUState *env)
+{
+}
Index: b/qemu/qemu-kvm-powerpc.c
===
--- a/qemu/qemu-kvm-powerpc.c
+++ b/qemu/qemu-kvm-powerpc.c
@@ -213,3 +213,7 @@ int handle_powerpc_dcr_write(int vcpu, u
return 0; /* XXX ignore failed DCR ops */
}
+
+void kvm_arch_cpu_reset(CPUState *env)
+{
+}
Index: b/qemu/qemu-kvm-x86.c
===
--- a/qemu/qemu-kvm-x86.c
+++ b/qemu/qemu-kvm-x86.c
@@ -671,3 +671,19 @@ int handle_tpr_access(void *opaque, int
kvm_tpr_access_report(cpu_single_env, rip, is_write);
return 0;
}
+
+void kvm_arch_cpu_reset(CPUState *env)
+{
+struct kvm_mp_state mp_state = { .mp_state = KVM_MP_STATE_UNINITIALIZED };
+
+kvm_arch_load_regs(env);
+if (env-cpu_index != 0) {
+ if (kvm_irqchip_in_kernel(kvm_context))
+ kvm_set_mpstate(kvm_context, env-cpu_index, mp_state);
+ else {
+ env-interrupt_request = ~CPU_INTERRUPT_HARD;
+ env-hflags |= HF_HALTED_MASK;
+ env-exception_index = EXCP_HLT;
+ }
+}
+}
Index: b/qemu/qemu-kvm.c
===
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -32,8 +32,6 @@ kvm_context_t kvm_context;
extern int smp_cpus;
-static int qemu_kvm_reset_requested;
-
pthread_mutex_t qemu_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t qemu_aio_cond = PTHREAD_COND_INITIALIZER;
pthread_cond_t qemu_vcpu_cond = PTHREAD_COND_INITIALIZER;
@@ -53,7 +51,6 @@ struct vcpu_info {
int signalled;
int stop;
int stopped;
-int reload_regs;
int created;
} vcpu_info[256];
@@ -251,6 +248,8 @@ static void pause_all_threads(void)
{
int i;
+assert(!cpu_single_env);
+
for (i = 0; i smp_cpus; ++i) {
vcpu_info[i].stop = 1;
pthread_kill(vcpu_info[i].thread, SIG_IPI);
@@ -263,6 +262,8 @@ static void resume_all_threads(void)
{
int i;
+assert(!cpu_single_env);
+
for (i = 0; i smp_cpus; ++i) {
vcpu_info[i].stop = 0;
vcpu_info[i].stopped = 0;
@@ -307,15 +308,18 @@ static void setup_kernel_sigmask(CPUStat
kvm_set_signal_mask(kvm_context, env-cpu_index, set);
}
-void qemu_kvm_system_reset_request(void)
+void qemu_kvm_system_reset(void)
{
int i;
-for (i = 0; i smp_cpus; ++i) {
- vcpu_info[i].reload_regs = 1;
- pthread_kill(vcpu_info[i].thread, SIG_IPI);
-}
+pause_all_threads();
+
qemu_system_reset();
+
+for (i = 0; i smp_cpus; ++i)
+ kvm_arch_cpu_reset(vcpu_info[i].env);
+
+resume_all_threads();
}
static int kvm_main_loop_cpu(CPUState *env)
@@ -348,11 +352,6 @@ static int kvm_main_loop_cpu(CPUState *e
kvm_cpu_exec(env);
env-interrupt_request = ~CPU_INTERRUPT_EXIT;
kvm_main_loop_wait(env, 0);
-if (info-reload_regs) {
- info-reload_regs = 0;
- if (env-cpu_index == 0) /* ap needs to be placed in INIT */
- kvm_arch_load_regs(env);
- }
}
pthread_mutex_unlock(qemu_mutex);
return 0;
@@ -535,10 +534,8 @@ int kvm_main_loop(void)
break;
else if (qemu_powerdown_requested())
qemu_system_powerdown();
-else if (qemu_reset_requested()) {
-pthread_kill(vcpu_info[0].thread, SIG_IPI);
-qemu_kvm_reset_requested = 1;
-}
+else if (qemu_reset_requested())
+ qemu_kvm_system_reset();
}
pause_all_threads();
@@ -647,6 +644,9 @@ static int kvm_halt(void *opaque, int vc
static int kvm_shutdown(void *opaque, int vcpu)
{
+/* stop the current vcpu from going back to guest mode */
+vcpu_info[cpu_single_env
[kvm-devel] [PATCH] qemu-kvm: Consolidate kvm_eat_signals
Having both kvm_eat_signal and kvm_eat_signals makes the code harder to
read. Moreover, given the single caller of kvm_eat_signals, there is no
real reason to keep it in a separate function.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/qemu-kvm.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
Index: b/qemu/qemu-kvm.c
===
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -210,11 +210,12 @@ static int kvm_eat_signal(CPUState *env,
return ret;
}
-
-static void kvm_eat_signals(CPUState *env, int timeout)
+static void kvm_main_loop_wait(CPUState *env, int timeout)
{
int r = 0;
+pthread_mutex_unlock(qemu_mutex);
+
while (kvm_eat_signal(env, 0))
r = 1;
if (!r timeout) {
@@ -223,14 +224,10 @@ static void kvm_eat_signals(CPUState *en
while (kvm_eat_signal(env, 0))
;
}
-}
-static void kvm_main_loop_wait(CPUState *env, int timeout)
-{
-pthread_mutex_unlock(qemu_mutex);
-kvm_eat_signals(env, timeout);
pthread_mutex_lock(qemu_mutex);
cpu_single_env = env;
+
vcpu_info[env-cpu_index].signalled = 0;
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] kvm-qemu: Fix monitor and gdbstub deadlocks v2
Refreshed version of the earlier posted patch, now also adding a safety
check about the correct vm state to kvm_load_registers.
Some monitor commands as well as the vm_stop() issued by the gdbstub on
external interruption so far deadlock on vcpu locks in the kernel. Patch
below resolves the issue by temporarily or permanently stopping all vcpu
threads before issuing the related KVM IOCTLs. At this chance the patch
also removes redundant checks for kvm_enabled.
Among other things, the patch now allows to break into the BIOS or other
guest code spinning in the vcpu and to use things like info cpus in
the monitor.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/gdbstub.c | 12
qemu/monitor.c |3 +--
qemu/qemu-kvm.c | 41 +++--
qemu/vl.c |2 +-
4 files changed, 33 insertions(+), 25 deletions(-)
Index: b/qemu/monitor.c
===
--- a/qemu/monitor.c
+++ b/qemu/monitor.c
@@ -286,8 +286,7 @@ static CPUState *mon_get_cpu(void)
mon_set_cpu(0);
}
-if (kvm_enabled())
- kvm_save_registers(mon_cpu);
+kvm_save_registers(mon_cpu);
return mon_cpu;
}
Index: b/qemu/qemu-kvm.c
===
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -137,18 +137,6 @@ static int pre_kvm_run(void *opaque, int
return 0;
}
-void kvm_load_registers(CPUState *env)
-{
-if (kvm_enabled())
- kvm_arch_load_regs(env);
-}
-
-void kvm_save_registers(CPUState *env)
-{
-if (kvm_enabled())
- kvm_arch_save_regs(env);
-}
-
int kvm_cpu_exec(CPUState *env)
{
int r;
@@ -276,6 +264,26 @@ static void kvm_vm_state_change_handler(
pause_all_threads();
}
+void kvm_load_registers(CPUState *env)
+{
+assert(!vm_running);
+
+if (kvm_enabled())
+ kvm_arch_load_regs(env);
+}
+
+void kvm_save_registers(CPUState *env)
+{
+if (!kvm_enabled())
+return;
+
+if (vm_running)
+pause_all_threads();
+kvm_arch_save_regs(env);
+if (vm_running)
+resume_all_threads();
+}
+
static void update_regs_for_sipi(CPUState *env)
{
kvm_arch_update_regs_for_sipi(env);
@@ -764,7 +772,7 @@ int kvm_qemu_init_env(CPUState *cenv)
int kvm_update_debugger(CPUState *env)
{
struct kvm_debug_guest dbg;
-int i;
+int i, r;
dbg.enabled = 0;
if (env-nb_breakpoints || env-singlestep_enabled) {
@@ -775,7 +783,12 @@ int kvm_update_debugger(CPUState *env)
}
dbg.singlestep = env-singlestep_enabled;
}
-return kvm_guest_debug(kvm_context, env-cpu_index, dbg);
+if (vm_running)
+pause_all_threads();
+r = kvm_guest_debug(kvm_context, env-cpu_index, dbg);
+if (vm_running)
+resume_all_threads();
+return r;
}
Index: b/qemu/vl.c
===
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7225,12 +7225,12 @@ void vm_stop(int reason)
{
if (vm_running) {
cpu_disable_ticks();
-vm_running = 0;
if (reason != 0) {
if (vm_stop_cb) {
vm_stop_cb(vm_stop_opaque, reason);
}
}
+vm_running = 0;
vm_state_notify(0);
}
}
Index: b/qemu/gdbstub.c
===
--- a/qemu/gdbstub.c
+++ b/qemu/gdbstub.c
@@ -904,8 +904,7 @@ static int gdb_handle_packet(GDBState *s
addr = strtoull(p, (char **)p, 16);
#if defined(TARGET_I386)
env-eip = addr;
- if (kvm_enabled())
- kvm_load_registers(env);
+kvm_load_registers(env);
#elif defined (TARGET_PPC)
env-nip = addr;
#elif defined (TARGET_SPARC)
@@ -928,8 +927,7 @@ static int gdb_handle_packet(GDBState *s
addr = strtoull(p, (char **)p, 16);
#if defined(TARGET_I386)
env-eip = addr;
- if (kvm_enabled())
- kvm_load_registers(env);
+kvm_load_registers(env);
#elif defined (TARGET_PPC)
env-nip = addr;
#elif defined (TARGET_SPARC)
@@ -973,8 +971,7 @@ static int gdb_handle_packet(GDBState *s
}
break;
case 'g':
- if (kvm_enabled())
- kvm_save_registers(env);
+kvm_save_registers(env);
reg_size = cpu_gdb_read_registers(env, mem_buf);
memtohex(buf, mem_buf, reg_size);
put_packet(s, buf);
@@ -984,8 +981,7 @@ static int gdb_handle_packet(GDBState *s
len = strlen(p) / 2;
hextomem((uint8_t *)registers, p, len);
cpu_gdb_write_registers(env, mem_buf, len);
- if (kvm_enabled())
- kvm_load_registers(env);
+kvm_load_registers(env);
put_packet(s, OK);
break;
case 'm':
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
[kvm-devel] [RFC] Reworking KVM_DEBUG_GUEST
Hi,
before going wild with my idea, I would like to collect some comments on
this approach:
While doing first kernel debugging with my debug register patches for
kvm, I quickly ran into the 4-breakpoints-only limitation that comes
from the fact that we blindly map software to hardware breakpoints.
Unhandy, simply suboptimal. Also, having 4 breakpoint slots hard-coded
in the generic interface is not fair to arch that may support more.
Moreover, we do not support watchpoints although this would easily be
feasible. But if we supported watchpoints (via debug registers on x86),
we would need the break out of the 4 slots limitations even earlier. In
short, I came to the conclusion that a rewrite of the KVM_DEBUG_GUEST
interface is required.
Why do we set breakpoints in the kernel? Why not simply catching all
debug traps, inserting software breakpoint ops into the guest code, and
handling all this stuff as normal debuggers do? And the hardware
breakpoints should just be pushed through the kernel interface like
ptrace does.
The new KVM_DEBUG_GUEST interface I currently have in mind would look
like this:
#define KVM_DBGGUEST_ENABLE 0x01
#define KVM_DBGGUEST_SINGLESTEP 0x02
struct kvm_debug_guest {
__u32 control;
struct kvm_debug_guest_arch arch;
}
Setting KVM_DBGGUEST_ENABLE would forward all debug-related traps to
userspace first, which can then decide to handle or re-inject them.
KVM_DBGGUEST_SINGLESTEP would work as before. And the extension for x86
would look like this:
struct kvm_debug_guest_arch {
__u32 use_hw_breakpoints;
__u64 debugreg[8];
}
If use_hw_breakpoints is non-zero, KVM would completely overwrite the
guest's debug registers with the content of debugreg, giving full
control of this feature to the host-side debugger (faking the content of
debug registers, effectively disabling them for the guest - as we now do
all the time).
Questions:
- Does anyone see traps and pitfalls in this approach?
- May I replace the existing interface with this one, or am I overseeing
some use case that already worked with the current code so that ABI
compatibility is required (most debug stuff should have been simply
broken so far, also due to bugs in userland)?
Jan
signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 2/2] qemu-kvm: Fix guest resetting v2
Avi Kivity wrote: Jan Kiszka wrote: Resetting guests used to be racy, deadlock-prone, or simply broken (for SMP). This patch fixes the issues, following Marcelo's suggestion to consolidate the reset activity in the I/O thread. All vcpus are cleanly stopped before the emulated hardware is reset, and kvm_arch_cpu_reset is introduced and invoked to ensure that non-boot cpus are put into the right state on x86. Note that other arch may need to look into this service as well to get SMP reset right. hmm. This means that reset is executed asynchronously of the calling cpu. Nope, the calling cpu is put in stopped state after informing the I/O thread about the reset request. We just cannot control when the request is handled /wrt to other cpus, but that's not different from real life I guess. Jan signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu-kvm: Consolidate kvm_eat_signals
Avi Kivity wrote:
Jan Kiszka wrote:
Having both kvm_eat_signal and kvm_eat_signals makes the code harder to
read. Moreover, given the single caller of kvm_eat_signals, there is no
real reason to keep it in a separate function.
Given that with the iothread we spend very little time processing
signals in vcpu threads, maybe it's better to drop the loop completely.
The common case is zero or one pending signals. The uncommon case of
two or more pending signals will be handled by the KVM_RUN ioctl
returning immediately with -EINTR (i.e. in the outer loop).
You mean
static void kvm_main_loop_wait(CPUState *env, int timeout)
{
pthread_mutex_unlock(qemu_mutex);
kvm_eat_signal(env, timeout);
pthread_mutex_lock(qemu_mutex);
cpu_single_env = env;
vcpu_info[env-cpu_index].signalled = 0;
}
?
Jan
signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu-kvm: fix guest resetting
Anthony Liguori wrote:
Marcelo Tosatti wrote:
diff --git a/qemu/qemu-kvm-ia64.c b/qemu/qemu-kvm-ia64.c
index 4d0ddd7..d227d22 100644
--- a/qemu/qemu-kvm-ia64.c
+++ b/qemu/qemu-kvm-ia64.c
@@ -61,3 +61,7 @@ int kvm_arch_try_push_interrupts(void *opaque)
void kvm_arch_update_regs_for_sipi(CPUState *env)
{
}
+
+void kvm_arch_cpu_reset(CPUState *env)
+{
+}
diff --git a/qemu/qemu-kvm-powerpc.c b/qemu/qemu-kvm-powerpc.c
index 14ed945..024b18c 100644
--- a/qemu/qemu-kvm-powerpc.c
+++ b/qemu/qemu-kvm-powerpc.c
@@ -213,3 +213,7 @@ int handle_powerpc_dcr_write(int vcpu, uint32_t dcrn,
uint32_t data)
return 0; /* XXX ignore failed DCR ops */
}
+
+void kvm_arch_cpu_reset(CPUState *env)
+{
+}
diff --git a/qemu/qemu-kvm-x86.c b/qemu/qemu-kvm-x86.c
index 9a771ff..28eb5c2 100644
--- a/qemu/qemu-kvm-x86.c
+++ b/qemu/qemu-kvm-x86.c
@@ -689,3 +689,19 @@ int handle_tpr_access(void *opaque, int vcpu,
kvm_tpr_access_report(cpu_single_env, rip, is_write);
return 0;
}
+
+void kvm_arch_cpu_reset(CPUState *env)
+{
+struct kvm_mp_state mp_state = { .mp_state = KVM_MP_STATE_UNINITIALIZED
};
+
+kvm_arch_load_regs(env);
+if (env-cpu_index != 0) {
+if (kvm_irqchip_in_kernel(kvm_context))
+kvm_set_mpstate(kvm_context, env-cpu_index, mp_state);
+else {
+env-interrupt_request = ~CPU_INTERRUPT_HARD;
+env-hflags |= HF_HALTED_MASK;
+env-exception_index = EXCP_HLT;
+}
+}
+}
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 3cc6d8e..1e1f065 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -31,8 +31,6 @@ kvm_context_t kvm_context;
extern int smp_cpus;
-static int qemu_kvm_reset_requested;
-
pthread_mutex_t qemu_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t qemu_aio_cond = PTHREAD_COND_INITIALIZER;
pthread_cond_t qemu_vcpu_cond = PTHREAD_COND_INITIALIZER;
@@ -52,7 +50,6 @@ struct vcpu_info {
int signalled;
int stop;
int stopped;
-int reload_regs;
int created;
} vcpu_info[256];
@@ -242,21 +239,29 @@ static void pause_all_threads(void)
{
int i;
+if (cpu_single_env) {
+fprintf(stderr, qemu-kvm: pause_all_threads from vcpu context\n);
+exit(0);
+}
+
for (i = 0; i smp_cpus; ++i) {
vcpu_info[i].stop = 1;
pthread_kill(vcpu_info[i].thread, SIG_IPI);
}
-while (!all_threads_paused()) {
-CPUState *env = cpu_single_env;
+while (!all_threads_paused())
pthread_cond_wait(qemu_pause_cond, qemu_mutex);
-cpu_single_env = env;
-}
+cpu_single_env = NULL;
}
Personally, I prefer it the old way. All of the open-coded
cpu_single_env's are tough to understand and I believe error-prone. I
think a strategy of explicitly preserving cpu_single_env whenever we
drop qemu_mutex is more robust. Explicitly setting cpu_single_env =
NULL happens to work because this is only called from the io thread.
It's less clear to a casual reader why it's necessary.
In fact, I'd be much more inclined to see a wrapper around
pthread_cond_wait() so that we never explicitly had to set cpu_single_env.
You mean something like this?
(Hunks may have some offsets, the patch is from the middle of my queue.)
Marcelo, I'm fine with your approach. I even switched my
vm_stop-on-breakpoint patch to this pattern, and it seems to work
nicely. Will roll out an updated series later (but probably not today -
weather is too fine here 8)).
---
qemu/qemu-kvm.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
Index: b/qemu/qemu-kvm.c
===
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -12,6 +12,7 @@ int kvm_allowed = 1;
int kvm_irqchip = 1;
int kvm_pit = 1;
+#include assert.h
#include string.h
#include hw/hw.h
#include sysemu.h
@@ -65,6 +66,14 @@ static inline unsigned long kvm_get_thre
return syscall(SYS_gettid);
}
+static void qemu_cond_wait(pthread_cond_t *cond)
+{
+CPUState *env = cpu_single_env;
+
+pthread_cond_wait(cond, qemu_mutex);
+cpu_single_env = env;
+}
+
CPUState *qemu_kvm_cpu_env(int index)
{
return vcpu_info[index].env;
@@ -247,21 +256,22 @@ static void pause_all_threads(void)
{
int i;
+assert(!cpu_single_env);
+
for (i = 0; i smp_cpus; ++i) {
vcpu_info[i].stop = 1;
pthread_kill(vcpu_info[i].thread, SIG_IPI);
}
-while (!all_threads_paused()) {
- CPUState *env = cpu_single_env;
- pthread_cond_wait(qemu_pause_cond, qemu_mutex);
- cpu_single_env = env;
-}
+while (!all_threads_paused())
+ qemu_cond_wait(qemu_pause_cond);
}
static void resume_all_threads(void)
{
int i;
+assert(!cpu_single_env);
+
for (i = 0; i smp_cpus; ++i) {
vcpu_info[i].stop = 0;
vcpu_info[i].stopped = 0;
@@ -380,7 +390,7 @@ static void *ap_main_loop(void
Re: [kvm-devel] [PATCH] qemu-kvm: fix guest resetting
Marcelo Tosatti wrote:
Hi Jan,
On Thu, May 08, 2008 at 10:29:32AM +0200, Jan Kiszka wrote:
Resetting guests used to be racy, deadlock-prone, or simply broken (for
SMP). This patch fixes the issues - at least for me on x86 (tested on
Intel SMP host, UP and SMP guest, in-kernel und user space irqchip,
guest- and monitor-issued resets). Note that ia64 and powerpc may need
to look into the SMP thing as well (=kvm_arch_cpu_reset).
At this chance, the patch also cleans up some unneeded reset fragments.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
@@ -317,11 +317,18 @@ void qemu_kvm_system_reset_request(void)
{
int i;
+pause_all_threads();
+
+qemu_system_reset();
+
+for (i = 0; i smp_cpus; ++i)
+kvm_arch_cpu_reset(vcpu_info[i].env);
+
for (i = 0; i smp_cpus; ++i) {
-vcpu_info[i].reload_regs = 1;
+vcpu_info[i].stop = 0;
+vcpu_info[i].stopped = 0;
pthread_kill(vcpu_info[i].thread, SIG_IPI);
}
-qemu_system_reset();
Why don't you signal the IO thread to pause all vcpu's and place their
registers and run state in the proper condition if the reset request
comes from the guest? It should simplify things a lot (and avoid any
changes to vl.c).
After signalling the vcpu should stop instead of returning to guest
mode.
Hmm, need to think a bit more about it as I don't see the benefit yet
(code suggestions are welcome in the meantime :)!).
The changes to vl.c are actually cleanups, as pause_all_threads() is now
context-agnostic and we no longer need to go through the qemu way of
raising reset. This new property of pause_all_threads() is something we
should desire for simplicity and robustness reasons anyway (e.g. to
simplify guest debugging later on). And the way
qemu_kvm_system_reset_request() is implemented would not change, we need
this serialization to avoid races between IO and VCPU threads.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] qemu-kvm: fix monitor and gdbstub deadlocks
Some monitor commands as well as the vm_stop() issued by the gdbstub on
external interruption so far deadlock on some vcpu locks in the kernel.
Patch below resolve the issue by temporarily or permanently stopping all
vcpu threads before issuing the related KVM IOCTLs.
Among other things, this patch now allows to break into the BIOS or
other guest code spinning in the vcpu (*) and to use things like info
cpus in the monitor.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/gdbstub.c | 12
qemu/monitor.c |3 +--
qemu/qemu-kvm.c | 39 +--
qemu/vl.c |2 +-
4 files changed, 31 insertions(+), 25 deletions(-)
Index: b/qemu/monitor.c
===
--- a/qemu/monitor.c
+++ b/qemu/monitor.c
@@ -286,8 +286,7 @@ static CPUState *mon_get_cpu(void)
mon_set_cpu(0);
}
-if (kvm_enabled())
- kvm_save_registers(mon_cpu);
+kvm_save_registers(mon_cpu);
return mon_cpu;
}
Index: b/qemu/qemu-kvm.c
===
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -130,18 +130,6 @@ static int pre_kvm_run(void *opaque, int
return 0;
}
-void kvm_load_registers(CPUState *env)
-{
-if (kvm_enabled())
- kvm_arch_load_regs(env);
-}
-
-void kvm_save_registers(CPUState *env)
-{
-if (kvm_enabled())
- kvm_arch_save_regs(env);
-}
-
int kvm_cpu_exec(CPUState *env)
{
int r;
@@ -290,6 +278,24 @@ static void kvm_vm_state_change_handler(
pause_all_threads();
}
+void kvm_load_registers(CPUState *env)
+{
+if (kvm_enabled())
+ kvm_arch_load_regs(env);
+}
+
+void kvm_save_registers(CPUState *env)
+{
+if (!kvm_enabled())
+return;
+
+if (vm_running)
+pause_all_threads();
+kvm_arch_save_regs(env);
+if (vm_running)
+resume_all_threads();
+}
+
static void update_regs_for_sipi(CPUState *env)
{
kvm_arch_update_regs_for_sipi(env);
@@ -698,7 +704,7 @@ int kvm_qemu_init_env(CPUState *cenv)
int kvm_update_debugger(CPUState *env)
{
struct kvm_debug_guest dbg;
-int i;
+int i, r;
dbg.enabled = 0;
if (env-nb_breakpoints || env-singlestep_enabled) {
@@ -709,7 +715,12 @@ int kvm_update_debugger(CPUState *env)
}
dbg.singlestep = env-singlestep_enabled;
}
-return kvm_guest_debug(kvm_context, env-cpu_index, dbg);
+if (vm_running)
+pause_all_threads();
+r = kvm_guest_debug(kvm_context, env-cpu_index, dbg);
+if (vm_running)
+resume_all_threads();
+return r;
}
Index: b/qemu/vl.c
===
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7165,12 +7165,12 @@ void vm_stop(int reason)
{
if (vm_running) {
cpu_disable_ticks();
-vm_running = 0;
if (reason != 0) {
if (vm_stop_cb) {
vm_stop_cb(vm_stop_opaque, reason);
}
}
+vm_running = 0;
vm_state_notify(0);
}
}
Index: b/qemu/gdbstub.c
===
--- a/qemu/gdbstub.c
+++ b/qemu/gdbstub.c
@@ -904,8 +904,7 @@ static int gdb_handle_packet(GDBState *s
addr = strtoull(p, (char **)p, 16);
#if defined(TARGET_I386)
env-eip = addr;
- if (kvm_enabled())
- kvm_load_registers(env);
+kvm_load_registers(env);
#elif defined (TARGET_PPC)
env-nip = addr;
#elif defined (TARGET_SPARC)
@@ -928,8 +927,7 @@ static int gdb_handle_packet(GDBState *s
addr = strtoull(p, (char **)p, 16);
#if defined(TARGET_I386)
env-eip = addr;
- if (kvm_enabled())
- kvm_load_registers(env);
+kvm_load_registers(env);
#elif defined (TARGET_PPC)
env-nip = addr;
#elif defined (TARGET_SPARC)
@@ -973,8 +971,7 @@ static int gdb_handle_packet(GDBState *s
}
break;
case 'g':
- if (kvm_enabled())
- kvm_save_registers(env);
+kvm_save_registers(env);
reg_size = cpu_gdb_read_registers(env, mem_buf);
memtohex(buf, mem_buf, reg_size);
put_packet(s, buf);
@@ -984,8 +981,7 @@ static int gdb_handle_packet(GDBState *s
len = strlen(p) / 2;
hextomem((uint8_t *)registers, p, len);
cpu_gdb_write_registers(env, mem_buf, len);
- if (kvm_enabled())
- kvm_load_registers(env);
+kvm_load_registers(env);
put_packet(s, OK);
break;
case 'm':
(*) Fully functional guest debugging and guest debug register support is
also working here, patches just wait to be reformatted...
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code
Re: [kvm-devel] [RFC][PATCH 0/4] Enabled NMI support for KVM
Yang, Sheng wrote: Hi This patchset enabled NMI support for KVM. The first three patches enabled NMI for in-kernel irqchip and NMI supporting on VMX. The last patch enabled NMI watchdog in linux, can be used to test the NMI injection. In fact, this series should also included Jan Kiszka's patch to enable NMI for userspace irqchip, but now I got little trouble to get the merged version work on my machine... We would post it as soon as we solved it. Another thing is the vmx_intr_assist() and do_interrupt_requests() got some duplication. And the logic for normal interrupt and NMI is similiar, but vmx_intr_assist() seems a little implicit... Any comments welcome! To make rebasing my work easier (hope I find some time later today): Your patches show up line-wrapped here. Could you check and repost? Thanks, Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC][PATCH 0/4] Enabled NMI support for KVM
Jan Kiszka wrote: Yang, Sheng wrote: Hi This patchset enabled NMI support for KVM. The first three patches enabled NMI for in-kernel irqchip and NMI supporting on VMX. The last patch enabled NMI watchdog in linux, can be used to test the NMI injection. In fact, this series should also included Jan Kiszka's patch to enable NMI for userspace irqchip, but now I got little trouble to get the merged version work on my machine... We would post it as soon as we solved it. Another thing is the vmx_intr_assist() and do_interrupt_requests() got some duplication. And the logic for normal interrupt and NMI is similiar, but vmx_intr_assist() seems a little implicit... Any comments welcome! To make rebasing my work easier (hope I find some time later today): Your patches show up line-wrapped here. Could you check and repost? Missed the attachments on first glance, and they are fine. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] kvm_show_code for ROM code
Avi Kivity wrote:
Jan Kiszka wrote:
Userland-located ROM memory is not available via kvm-physical_memory +
guest_address. To let kvm_show_code also dump useful information when
some problem in ROM (BIOS...) occurs, this patch first tries to obtain
the memory content via the mmio_read callback - maybe not 100% clean,
but works at least for the QEMU use case. If the callback complains
about the given address, we then fall back to RAM access.
kvm-physical_memory is actually broken, since nothing guarantees a 1:1
(+offset) mapping.
Why not use -mmio_read() all the time? Sure it overloads the
definition of mmio_read(), but worse things have happened.
That was my first approach as well, but then I became unsure if such an
overloading is acceptable. As it is now:
--
Userland-located memory is not unconditionally available via
kvm-physical_memory + guest_address. To let kvm_show_code also dump
useful information when, e.g., some problem in ROM (BIOS...) occurs,
this patch tries to obtain the memory content via the mmio_read
callback. If the callback fails, the code byte is marked as invalid.
This patch also removes the check for protected mode and dumps the code
in any case - I didn't find the reason for this restriction.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
libkvm/libkvm-x86.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
Index: b/libkvm/libkvm-x86.c
===
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -393,14 +393,14 @@ int kvm_set_pit(kvm_context_t kvm, struc
void kvm_show_code(kvm_context_t kvm, int vcpu)
{
-#define CR0_PE_MASK(1ULL0)
+#define SHOW_CODE_LEN 50
int fd = kvm-vcpu_fd[vcpu];
struct kvm_regs regs;
struct kvm_sregs sregs;
- int r;
- unsigned char code[50];
+ int r, n;
int back_offset;
- char code_str[sizeof(code) * 3 + 1];
+ unsigned char code;
+ char code_str[SHOW_CODE_LEN * 3 + 1];
unsigned long rip;
r = ioctl(fd, KVM_GET_SREGS, sregs);
@@ -408,9 +408,6 @@ void kvm_show_code(kvm_context_t kvm, in
perror(KVM_GET_SREGS);
return;
}
- if (sregs.cr0 CR0_PE_MASK)
- return;
-
r = ioctl(fd, KVM_GET_REGS, regs);
if (r == -1) {
perror(KVM_GET_REGS);
@@ -420,12 +417,16 @@ void kvm_show_code(kvm_context_t kvm, in
back_offset = regs.rip;
if (back_offset 20)
back_offset = 20;
- memcpy(code, kvm-physical_memory + rip - back_offset, sizeof code);
*code_str = 0;
- for (r = 0; r sizeof code; ++r) {
- if (r == back_offset)
+ for (n = -back_offset; n SHOW_CODE_LEN-back_offset; ++n) {
+ if (n == 0)
strcat(code_str, --);
- sprintf(code_str + strlen(code_str), %02x, code[r]);
+ r = kvm-callbacks-mmio_read(kvm-opaque, rip + n, code, 1);
+ if (r 0) {
+ strcat(code_str, xx);
+ continue;
+ }
+ sprintf(code_str + strlen(code_str), %02x, code);
}
fprintf(stderr, code:%s\n, code_str);
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] State of debug register emulation
Avi Kivity wrote: Jan Kiszka wrote: This still leaves me with the question how to handle the case when the host sets and arms some debug registers to debug the guest and the latter does the same to debug itself. Guest access will be trapped, OK, but KVM will then have to decide which value should actually be transfered into the registers. Hmm, does SVM virtualizes all debug registers, leaving the real ones to the host? There's no way this can work. There are still only four debug registers, and the guest and host together can ask for eight different addresses. It is theoretically doable by hiding all mappings to pages that are debug targets, but it would probably double the kvm code size. A good short-term compomise is to abort if the guest starts using enabling a debug address register. A better solution might be to place host debug addresses into unused guest debug registers, so that as long as nr_guest_debug + nr_host_debug = 4, we can still proceed. I tried the latter, but we cannot cleanly share DR7 between both users. Thus I'm now going for a prioritized approach: debug register will stop to have any effect for the guest as soon as the host starts to use them. That's far simpler the implement and also easier to understand for the user. A bit work remains, though, to clean up and enhance the DRx support in KVM. And to test the changes (will contact you, Joerg, regarding SVM tests). Stay tuned. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] x86: handle double and triple faults for every exception
Avi Kivity wrote:
Jan Kiszka wrote:
Joerg Roedel wrote:
The current KVM x86 exception code handles double and triple faults
only for
page fault exceptions. This patch extends this detection for every
exception
that gets queued for the guest.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
Cc: Jan Kiszka [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c | 31 +--
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 578a0c1..c05aa32 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -144,9 +144,21 @@ void kvm_set_apic_base(struct kvm_vcpu *vcpu,
u64 data)
}
EXPORT_SYMBOL_GPL(kvm_set_apic_base);
+static void handle_multiple_faults(struct kvm_vcpu *vcpu)
+{
+if (vcpu-arch.exception.nr != DF_VECTOR) {
+vcpu-arch.exception.nr = DF_VECTOR;
+vcpu-arch.exception.error_code = 0;
+} else
+set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests);
+}
+
void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
{
-WARN_ON(vcpu-arch.exception.pending);
+if (vcpu-arch.exception.pending) {
+handle_multiple_faults(vcpu);
+return;
+}
vcpu-arch.exception.pending = true;
vcpu-arch.exception.has_error_code = false;
vcpu-arch.exception.nr = nr;
@@ -157,25 +169,16 @@ void kvm_inject_page_fault(struct kvm_vcpu
*vcpu, unsigned long addr,
u32 error_code)
{
++vcpu-stat.pf_guest;
-if (vcpu-arch.exception.pending) {
-if (vcpu-arch.exception.nr == PF_VECTOR) {
-printk(KERN_DEBUG kvm: inject_page_fault:
- double fault 0x%lx\n, addr);
-vcpu-arch.exception.nr = DF_VECTOR;
-vcpu-arch.exception.error_code = 0;
-} else if (vcpu-arch.exception.nr == DF_VECTOR) {
-/* triple fault - shutdown */
-set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests);
-}
-return;
-}
vcpu-arch.cr2 = addr;
kvm_queue_exception_e(vcpu, PF_VECTOR, error_code);
}
void kvm_queue_exception_e(struct kvm_vcpu *vcpu, unsigned nr, u32
error_code)
{
-WARN_ON(vcpu-arch.exception.pending);
+if (vcpu-arch.exception.pending) {
+handle_multiple_faults(vcpu);
+return;
+}
vcpu-arch.exception.pending = true;
vcpu-arch.exception.has_error_code = true;
vcpu-arch.exception.nr = nr;
And here is an add-on patch to fix reset-on-triple-fault:
Clear the pending original exception when raising a triple fault. This
allows to re-use the vcpu instance, e.g. after a reset which is
typically issued as reaction on the triple fault.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: b/arch/x86/kvm/x86.c
===
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -149,8 +149,10 @@ static void handle_multiple_faults(struc
if (vcpu-arch.exception.nr != DF_VECTOR) {
vcpu-arch.exception.nr = DF_VECTOR;
vcpu-arch.exception.error_code = 0;
-} else
+} else {
set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests);
+vcpu-arch.exception.pending = false;
+}
}
void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
There's a bigger problem here. The exception queue is hidden state that
qemu and load and save.
Could you elaborate a bit on what the problematic scenario precisely is
(that pending triple faults would not be saved/restored while pending
exceptions are?), and if I/we can do anything to resolve it?
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] x86: handle double and triple faults for every exception
Joerg Roedel wrote:
The current KVM x86 exception code handles double and triple faults only for
page fault exceptions. This patch extends this detection for every exception
that gets queued for the guest.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
Cc: Jan Kiszka [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c | 31 +--
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 578a0c1..c05aa32 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -144,9 +144,21 @@ void kvm_set_apic_base(struct kvm_vcpu *vcpu, u64 data)
}
EXPORT_SYMBOL_GPL(kvm_set_apic_base);
+static void handle_multiple_faults(struct kvm_vcpu *vcpu)
+{
+ if (vcpu-arch.exception.nr != DF_VECTOR) {
+ vcpu-arch.exception.nr = DF_VECTOR;
+ vcpu-arch.exception.error_code = 0;
+ } else
+ set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests);
+}
+
void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
{
- WARN_ON(vcpu-arch.exception.pending);
+ if (vcpu-arch.exception.pending) {
+ handle_multiple_faults(vcpu);
+ return;
+ }
vcpu-arch.exception.pending = true;
vcpu-arch.exception.has_error_code = false;
vcpu-arch.exception.nr = nr;
@@ -157,25 +169,16 @@ void kvm_inject_page_fault(struct kvm_vcpu *vcpu,
unsigned long addr,
u32 error_code)
{
++vcpu-stat.pf_guest;
- if (vcpu-arch.exception.pending) {
- if (vcpu-arch.exception.nr == PF_VECTOR) {
- printk(KERN_DEBUG kvm: inject_page_fault:
- double fault 0x%lx\n, addr);
- vcpu-arch.exception.nr = DF_VECTOR;
- vcpu-arch.exception.error_code = 0;
- } else if (vcpu-arch.exception.nr == DF_VECTOR) {
- /* triple fault - shutdown */
- set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests);
- }
- return;
- }
vcpu-arch.cr2 = addr;
kvm_queue_exception_e(vcpu, PF_VECTOR, error_code);
}
void kvm_queue_exception_e(struct kvm_vcpu *vcpu, unsigned nr, u32
error_code)
{
- WARN_ON(vcpu-arch.exception.pending);
+ if (vcpu-arch.exception.pending) {
+ handle_multiple_faults(vcpu);
+ return;
+ }
vcpu-arch.exception.pending = true;
vcpu-arch.exception.has_error_code = true;
vcpu-arch.exception.nr = nr;
And here is an add-on patch to fix reset-on-triple-fault:
Clear the pending original exception when raising a triple fault. This
allows to re-use the vcpu instance, e.g. after a reset which is
typically issued as reaction on the triple fault.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: b/arch/x86/kvm/x86.c
===
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -149,8 +149,10 @@ static void handle_multiple_faults(struc
if (vcpu-arch.exception.nr != DF_VECTOR) {
vcpu-arch.exception.nr = DF_VECTOR;
vcpu-arch.exception.error_code = 0;
- } else
+ } else {
set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests);
+ vcpu-arch.exception.pending = false;
+ }
}
void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] libkvm: dump all errors to stderr
Minor cleanup I came across while reverting printf instrumentations.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
libkvm/libkvm-x86.c |4 ++--
libkvm/libkvm.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
Index: b/libkvm/libkvm-x86.c
===
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -117,7 +117,7 @@ static int kvm_init_tss(kvm_context_t kv
*/
r = kvm_set_tss_addr(kvm, 0xfffbd000);
if (r 0) {
- printf(kvm_init_tss: unable to set tss addr\n);
+ fprintf(stderr, kvm_init_tss: unable to set tss
addr\n);
return r;
}
@@ -157,7 +157,7 @@ int kvm_create_pit(kvm_context_t kvm)
if (r = 0)
kvm-pit_in_kernel = 1;
else {
- printf(Create kernel PIC irqchip failed\n);
+ fprintf(stderr, Create kernel PIC irqchip
failed\n);
return r;
}
}
Index: b/libkvm/libkvm.c
===
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -368,7 +368,7 @@ void kvm_create_irqchip(kvm_context_t kv
if (r = 0)
kvm-irqchip_in_kernel = 1;
else
- printf(Create kernel PIC irqchip failed\n);
+ fprintf(stderr, Create kernel PIC irqchip
failed\n);
}
}
#endif
@@ -877,7 +877,7 @@ again:
if (r == -1 errno != EINTR errno != EAGAIN) {
r = -errno;
post_kvm_run(kvm, vcpu);
- printf(kvm_run: %s\n, strerror(-r));
+ fprintf(stderr, kvm_run: %s\n, strerror(-r));
return r;
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] libkvm: fix physical_memory calculation
This looks bogus, but it is so far without practical impact (phys_start is always 0 when we do the calculation). Signed-off-by: Jan Kiszka [EMAIL PROTECTED] --- libkvm/libkvm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/libkvm/libkvm.c === --- a/libkvm/libkvm.c +++ b/libkvm/libkvm.c @@ -550,7 +550,7 @@ int kvm_register_userspace_phys_mem(kvm_ int r; if (!kvm-physical_memory) - kvm-physical_memory = userspace_addr - phys_start; + kvm-physical_memory = userspace_addr + phys_start; memory.slot = get_free_slot(kvm); r = ioctl(kvm-vm_fd, KVM_SET_USER_MEMORY_REGION, memory); - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] x86: handle double and triple faults for every exception
Avi Kivity wrote:
Jan Kiszka wrote:
Clear the pending original exception when raising a triple fault. This
allows to re-use the vcpu instance, e.g. after a reset which is
typically issued as reaction on the triple fault.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: b/arch/x86/kvm/x86.c
===
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -149,8 +149,10 @@ static void handle_multiple_faults(struc
if (vcpu-arch.exception.nr != DF_VECTOR) {
vcpu-arch.exception.nr = DF_VECTOR;
vcpu-arch.exception.error_code = 0;
-} else
+} else {
set_bit(KVM_REQ_TRIPLE_FAULT, vcpu-requests);
+vcpu-arch.exception.pending = false;
+}
}
void kvm_queue_exception(struct kvm_vcpu *vcpu, unsigned nr)
There's a bigger problem here. The exception queue is hidden state that
qemu and load and save.
Could you elaborate a bit on what the problematic scenario precisely is
(that pending triple faults would not be saved/restored while pending
exceptions are?), and if I/we can do anything to resolve it?
Two scenarios:
savevm (no pending exception)
guest runs...
loadvm (with a pending exception in the current state)
spurious exception injected
savevm (pending exception, lost)
new qemu instance (or live migration)
loadvm (exception not delivered)
The second scenario is not too bad, I guess: for fault-like exceptions,
the first instruction would fault again and the exception would be
regenerated. The first scenario is bad, but I guess very unlikely.
One fix would be to expose the exception queue to userspace. I don't
like it since this is not x86 architectural state but a kvm artifact.
Maybe we should clear the exception queue on kvm_set_sregs() (that
should fix the reset case as well).
Yes, the following still works for me. But I'm not the right person to
ask if there are obscure cases where you may not want this clearing
while just editing some registers (I'm thinking of debugger scenarios
now).
-
Clear pending exceptions when setting new register values. This avoids
spurious exceptions after restoring a vcpu state or after
reset-on-triple-fault.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c |2 ++
1 file changed, 2 insertions(+)
Index: b/arch/x86/kvm/x86.c
===
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3025,6 +3025,8 @@ int kvm_arch_vcpu_ioctl_set_regs(struct
kvm_x86_ops-decache_regs(vcpu);
+ vcpu-arch.exception.pending = false;
+
vcpu_put(vcpu);
return 0;
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] kvm_show_code for ROM code
Userland-located ROM memory is not available via kvm-physical_memory +
guest_address. To let kvm_show_code also dump useful information when
some problem in ROM (BIOS...) occurs, this patch first tries to obtain
the memory content via the mmio_read callback - maybe not 100% clean,
but works at least for the QEMU use case. If the callback complains
about the given address, we then fall back to RAM access.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
libkvm/libkvm-x86.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
Index: b/libkvm/libkvm-x86.c
===
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -393,14 +393,15 @@ int kvm_set_pit(kvm_context_t kvm, struc
void kvm_show_code(kvm_context_t kvm, int vcpu)
{
+#define CODE_LEN 50
#define CR0_PE_MASK(1ULL0)
int fd = kvm-vcpu_fd[vcpu];
struct kvm_regs regs;
struct kvm_sregs sregs;
- int r;
- unsigned char code[50];
+ int r, n;
int back_offset;
- char code_str[sizeof(code) * 3 + 1];
+ unsigned char code;
+ char code_str[CODE_LEN * 3 + 1];
unsigned long rip;
r = ioctl(fd, KVM_GET_SREGS, sregs);
@@ -420,12 +421,14 @@ void kvm_show_code(kvm_context_t kvm, in
back_offset = regs.rip;
if (back_offset 20)
back_offset = 20;
- memcpy(code, kvm-physical_memory + rip - back_offset, sizeof code);
*code_str = 0;
- for (r = 0; r sizeof code; ++r) {
- if (r == back_offset)
+ for (n = -back_offset; n CODE_LEN-back_offset; ++n) {
+ if (n == 0)
strcat(code_str, --);
- sprintf(code_str + strlen(code_str), %02x, code[r]);
+ r = kvm-callbacks-mmio_read(kvm-opaque, rip + n, code, 1);
+ if (r 0)
+ code = *(unsigned char *)(kvm-physical_memory + rip +
n);
+ sprintf(code_str + strlen(code_str), %02x, code);
}
fprintf(stderr, code:%s\n, code_str);
}
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] WARN_ON in kvm_queue_exception_e triggers
Joerg Roedel wrote: On Tue, Apr 29, 2008 at 10:38:41AM +0200, Jan Kiszka wrote: Joerg Roedel wrote: Hmm, seems we have to check for DF and triple faults in the kvm_queue_exception functions too. Does the attached patch fix the problem (patch is against kvm-66). Thanks, it indeed fixes the warnings (*) and makes KVM issue a reset. But then is stumbles and falls probably over some inconsistent system state: exception 13 (43) rax rbx rcx rdx 0633 rsi rdi rsp rbp r8 r9 r10 r11 r12 r13 r14 r15 rip fff0 rflags 00033002 cs f000 (000f/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr 0178 (fffbd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 0/ idt 0/ cr0 6010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -- 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Looks like trying to execute the first instruction after reset is already unsuccessful. As the tr selector is non-zero here, I already tried a kvm_arch_reset_cpu-hack along the line that sets KVM_REQ_TRIPLE_FAULT, but without success. Any idea what to check? Its weird to me what triggers the taskswitch. What guest operating It is the guest, looking for a soft-restart (after it detected some other error - now our main problem). system are you running and what is the qemu/kvm command line to start the guest? Well, the guest is a proprietary OS of our customer, running in 16-bit protected mode with a lot of segment shuffling. Due to this and also some special hardware emulations, the current test case is not portable. So I'm looking for input on where to dig and what to try. Note that I ran the very same test with -no-kvm, and here we do not get those post-reset GPF (provided that some reset-on-triple-fault patch is applied to avoid the abort(), e.g. [1]). Note that this does not happen when I raise a reset via the monitor. BTW, kvm_show_code() does not seem to provide correct informations, even when I add it right before the first kvm_run(). When the guest state is messed up the information may be incorrect. I don't expect the guest state to be messed up right before the very first guest code execution (that's where kvm_show_code() also reported zeros)... :- (*) There is just a bit noise left behind in the syslog: kvm_handle_exit: unexpected, valid vectoring info and exit reason is 0x9 Reason 0x9 is the taskswitch intercept. kvm: inject_page_fault: double fault This is expected from the patch I sent you. For sure. I would just suggest to rethink if a final version should still issue such warnings. We basically had the same discussion on qemu-devel around the reset-on-triple-fault patch (which is unfortunately still not finalized :-/). Jan [1] http://permalink.gmane.org/gmane.comp.emulators.qemu/24475 -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] State of debug register emulation
Hi, looks like we are getting better and better here in hitting yet unsupported corner-case features of KVM :). This time our guest fiddles with hardware debugging registers, but quickly gets unhappy as they do not yet have the expected effect. Joerg, I found you SVM-related patch series in the archive which does not seem to have raised much responses. Is this general direction OK? Does it allow self-debugging of guests? But how are conflicts resolved if both guest and host need the physical registers (host debugging the guest which is debugging itself)? I would try to dig into the VMX side if the general architecture is -mostly- clear. [ Sorry, Joerg, someone put the latter type of HW on my desk :-. Hope I can once check our stuff against SVM as well! ] Thanks, Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] State of debug register emulation
Joerg Roedel wrote: On Tue, Apr 29, 2008 at 03:07:25PM +0200, Jan Kiszka wrote: Hi, looks like we are getting better and better here in hitting yet unsupported corner-case features of KVM :). This time our guest fiddles with hardware debugging registers, but quickly gets unhappy as they do not yet have the expected effect. KVM is mostly tested with guests that run with paging. So a 16 bit protected mode guest is not tested very well :) Yes, we know (we also had a bit fun with stock QEMU in corner cases). But that may change now... :) Joerg, I found you SVM-related patch series in the archive which does not seem to have raised much responses. Is this general direction OK? Does it allow self-debugging of guests? But how are conflicts resolved if both guest and host need the physical registers (host debugging the guest which is debugging itself)? I sent a patchset in the past to enable guest debugging for SVM which means debugging the guest from outside using gdb. But I was not able to test these patches because the userspace side of guest debugging is broken in the kvm-qemu. Debugging in the guest should work without problems. The debug registers are switched between guest and host if the guest uses them. So there should be no problems when the guest and the host using the debug registers. I'm currently digging my way through the current VMX code, but I cannot confirm this. Not sure what SVM does, but as far as I understood the VMX side, only DR7 is saved/restored in hardware. The rest is KVM's job. Unfortunately the access to the real debug registers only happens if (vcpu-guest_debug.enabled). And as all DR accesses of the guest are trapped, but the desired transfers to/from guest registers are nops, this cannot work yet, at least on VMX. This still leaves me with the question how to handle the case when the host sets and arms some debug registers to debug the guest and the latter does the same to debug itself. Guest access will be trapped, OK, but KVM will then have to decide which value should actually be transfered into the registers. Hmm, does SVM virtualizes all debug registers, leaving the real ones to the host? I would try to dig into the VMX side if the general architecture is -mostly- clear. [ Sorry, Joerg, someone put the latter type of HW on my desk :-. Hope I can once check our stuff against SVM as well! ] With some debug output from SVM I can better help to debug your problems ;-) I'm sure :). But I guess this topic has a few common aspects to be solved, too. So we may ideally end up with a single series of debug-enabling patches for KVM (maybe even fixing userland - we are not totally unfamiliar with the gdbstub here). Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] libkvm: initialize no_pit_creation
Avi Kivity wrote:
Marcelo Tosatti wrote:
Valgrind caught this:
==11754== Conditional jump or move depends on uninitialised value(s)
==11754==at 0x50C9BC: kvm_create_pit (libkvm-x86.c:153)
==11754==by 0x50CA7F: kvm_arch_create (libkvm-x86.c:178)
==11754==by 0x50AB31: kvm_create (libkvm.c:383)
==11754==by 0x4EE691: kvm_qemu_create_context (qemu-kvm.c:616)
==11754==by 0x412031: main (vl.c:9653)
Applied, thanks. Isn't valgrind great?
Yeah, it is. Reminds me of another warning I recently came across
(offsets may vary due to other patches:
==5801== 1 errors in context 1 of 2:
==5801== Conditional jump or move depends on uninitialised value(s)
==5801==at 0x53F4AE: kvm_register_userspace_phys_mem (libkvm.c:552)
==5801==by 0x521ACA: kvm_cpu_register_physical_memory (qemu-kvm.c:654)
==5801==by 0x45FC82: pc_init1 (pc.c:809)
==5801==by 0x461313: pc_init_pci (pc.c:1149)
==5801==by 0x43081B: main (vl.c:9845)
This silences valgrind and may even be correct (if I got the code path
right):
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -328,9 +328,10 @@ static int kvm_create_default_phys_mem(k
#ifdef KVM_CAP_USER_MEMORY
r = ioctl(kvm-fd, KVM_CHECK_EXTENSION, KVM_CAP_USER_MEMORY);
- if (r 0)
+ if (r 0) {
+ kvm-physical_memory = NULL;
return 0;
- else
+ } else
#endif
r = kvm_alloc_kernel_memory(kvm, memory, vm_mem);
if (r 0)
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] State of NMI support
Hi, I saw kvm-userspace recently merged qemu's new CPU_INTERRUPT_NMI support. But the required infrastructure to use this in kvm mode is not yet visible. Is anyone working on this? Sheng? IIRC, you once said to work on it. Currently I just need the basic mechanism for injecting NMIs into the guest (from special hardware emulation), no full support for in-kernel [A]PICs. But before starting some quickdirty hack, I would like to know if someone already has a patch pending and is able to share even just preliminary results. Thanks, Jan signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Oopses with Oprofile and qemu-kvm
Yang, Sheng wrote: ... BTW: I am working on NMI supporting now. That's good news! Some weeks ago I posted a NMI infrastructure patch [1] to qemu-devel already, for now only to support IOAPIC NMI watchdogs [1, 2]. Maybe you can make use of this. Please keep us posted about your approach! Jan [1] http://permalink.gmane.org/gmane.comp.emulators.qemu/22989 [2] http://permalink.gmane.org/gmane.comp.emulators.qemu/23448 [3] http://permalink.gmane.org/gmane.comp.emulators.qemu/23456 -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH RFC 0/4]Porting Xentrace to kvm
Avi Kivity wrote: Liu, Eric E wrote: Hi, The following patches port xentrace to kvm which is useful for performance tuning and debugging. It is designed to allow debugging traces of kvm to be generated on Up/Smp machines. Each trace entry is outputted in a trace ring buffer for per cpu which is mapped to userspace, and the userspace tools can analyze the data according to some formats definitions. Since we already have had debugfs_entries and some other kernel debug mechanism to use, does this kvmtrace make sense? Any comment is welcomed. This looks very useful. While kvm_stat provides good data, this is much more in depth. The kernel already contains a method of transferring percpu data to userspace; see Documentation/filesystems/relay.txt. It supports mmap() and read(). Please see if it is a good fit. I would also suggest to use the new kernel standard for instrumentation: trace_mark(). This would also allow to reuse the trace points with other tracer and maybe even obsolete a separate transportation channel, e.g. when LTTng is once :-/ merged. Jan signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH RFC 0/4]Porting Xentrace to kvm
Avi Kivity wrote: Jan Kiszka wrote: Avi Kivity wrote: Liu, Eric E wrote: Hi, The following patches port xentrace to kvm which is useful for performance tuning and debugging. It is designed to allow debugging traces of kvm to be generated on Up/Smp machines. Each trace entry is outputted in a trace ring buffer for per cpu which is mapped to userspace, and the userspace tools can analyze the data according to some formats definitions. Since we already have had debugfs_entries and some other kernel debug mechanism to use, does this kvmtrace make sense? Any comment is welcomed. This looks very useful. While kvm_stat provides good data, this is much more in depth. The kernel already contains a method of transferring percpu data to userspace; see Documentation/filesystems/relay.txt. It supports mmap() and read(). Please see if it is a good fit. I would also suggest to use the new kernel standard for instrumentation: trace_mark(). This would also allow to reuse the trace points with other tracer and maybe even obsolete a separate transportation channel, e.g. when LTTng is once :-/ merged. Can one have markers automatically recorded? Or do you need to connect the marker with a logging function? Yes, of course you need a probe function. Either your own one, or one provided by other tracers. If the latter, it's too difficult to use. I don't think it is. Check linux/samples/markers/probe-example.c. BTW, RCU-Trace (not yet mainlined) make use of markers as well, see -rt. And in contrast to the suggested implementation, markers have less impact on the code if built-in but disabled. So there would be no reasons for not shipping kvm production binaries that are prepared to be traced. But if you prefer the inlined version, I bet you'll have to hide it from reviewers at LKML. ;) Jan signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] fix reading from character devices
Dor Laor wrote:
On Mon, 2008-01-21 at 12:50 +0200, Avi Kivity wrote:
Dor Laor wrote:
On Mon, 2008-01-21 at 12:13 +0200, Avi Kivity wrote:
Jan Kiszka wrote:
Hi Avi,
commit kvm: qemu: consume all pending I/O in I/O loop
(8ab8bb09f1115b9bf733f885cc92b6c63d83f420) broke reading data bursts
from serial devices (and maybe from other character devices as well) by
guests. Reason: serial devices do input flow control via fd_read_poll,
but qemu now ignores this fact by pushing all data into the virtual
device as soon as it is available.
Patch below is not really nice (just as the whole internal virtual I/O
interface at the moment, IMHO), but it re-enables the serial ports for
now.
I'm worried that it will break Dor's hack that speeds up virtio. Dor?
It should be fine. Tap device without my hack has fd_read_poll null and
I hacked it to have a handler that returns false if virtio is used and
true otherwise.
So Jan's patch should set 'more' to 1 and it will be like before.
But if virtio is used with this patch, it won't set 'more' to 1. Will
virtio handle it or will throughput drop to be related to whatever
timers we have set up?
Virtio+tap with the performance hack does it's own select on the related
fd. Virtio+user will remain as before.
I think this got lost somehow. Find refreshed patch below. Avi, could
you apply it kvm-userland to fix the still existent regression?
Jan
---
qemu/vl.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: b/qemu/vl.c
===
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7786,7 +7786,10 @@ void main_loop_wait(int timeout)
for(ioh = first_io_handler; ioh != NULL; ioh = ioh-next) {
if (!ioh-deleted ioh-fd_read FD_ISSET(ioh-fd, rfds)) {
ioh-fd_read(ioh-opaque);
-more = 1;
+if (!ioh-fd_read_poll || ioh-fd_read_poll(ioh-opaque))
+more = 1;
+else
+FD_CLR(ioh-fd, rfds);
}
if (!ioh-deleted ioh-fd_write FD_ISSET(ioh-fd, wfds)) {
ioh-fd_write(ioh-opaque);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] qemu: fix some warnings
Carlo Marcelo Arenas Belon wrote:
On Mon, Jan 21, 2008 at 01:46:11PM +0100, Jan Kiszka wrote:
Here are 4 more warnings fixes (actually, I should sent 2 of them to
qemu...). Nothing critical, just less noise during compilation.
probably a good idea having them in independent patches as they are unrelated
(other by the fact that they are all warnings in current git).
Will do (later).
Index: b/qemu/vl.c
===
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -8862,7 +8862,7 @@ int main(int argc, char **argv)
if (ram_size = 0)
help(1);
if (ram_size PHYS_RAM_MAX_SIZE) {
-fprintf(stderr, qemu: at most %d MB RAM can be
simulated\n,
+fprintf(stderr, qemu: at most %llu MB RAM can be
simulated\n,
PHYS_RAM_MAX_SIZE / (1024 * 1024));
using TARGET_FMT_lu instead of %llu would seem more appropriate here because
this is meant to reflect a physical memory address, but then the fact that kvm
is using the x64_64 target also for 32 bit will mean that the definition of
PHYS_RAM_MAX_SIZE has to be made somehow also HOST specific.
for my take on that (which will need to be updated with your version of the
exec.c changes and re-tested) look at :
http://tapir.sajinet.com.pe/gentoo/portage/app-emulation/kvm/files/kvm-51-qemu-ramaddr.patch
Ah, that's great. So what about this rebased and extended version:
---
qemu/exec.c | 10 +-
qemu/migration.c |4 ++--
qemu/vl.c|8 ++--
3 files changed, 13 insertions(+), 9 deletions(-)
Index: kvm-userspace/qemu/exec.c
===
--- kvm-userspace.orig/qemu/exec.c
+++ kvm-userspace/qemu/exec.c
@@ -2028,9 +2028,9 @@ static inline void tlb_set_dirty(CPUStat
}
#endif /* defined(CONFIG_USER_ONLY) */
-static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
+static int subpage_register (subpage_t *mmio, ram_addr_t start, ram_addr_t end,
int memory);
-static void *subpage_init (target_phys_addr_t base, uint32_t *phys,
+static void *subpage_init (target_phys_addr_t base, ram_addr_t *phys,
int orig_memory);
#define CHECK_SUBPAGE(addr, start_addr, start_addr2, end_addr, end_addr2, \
need_subpage) \
@@ -2138,7 +2138,7 @@ ram_addr_t qemu_ram_alloc(unsigned long
{
ram_addr_t addr;
if ((phys_ram_alloc_offset + size) phys_ram_size) {
-fprintf(stderr, Not enough memory (requested_size = %lu, max memory =
%d)\n,
+fprintf(stderr, Not enough memory (requested_size = %lu, max memory =
%lu)\n,
size, phys_ram_size);
abort();
}
@@ -2455,7 +2455,7 @@ static CPUWriteMemoryFunc *subpage_write
subpage_writel,
};
-static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
+static int subpage_register (subpage_t *mmio, ram_addr_t start, ram_addr_t end,
int memory)
{
int idx, eidx;
@@ -2478,7 +2478,7 @@ static int subpage_register (subpage_t *
return 0;
}
-static void *subpage_init (target_phys_addr_t base, uint32_t *phys,
+static void *subpage_init (target_phys_addr_t base, ram_addr_t *phys,
int orig_memory)
{
subpage_t *mmio;
Index: kvm-userspace/qemu/migration.c
===
--- kvm-userspace.orig/qemu/migration.c
+++ kvm-userspace/qemu/migration.c
@@ -808,7 +808,7 @@ static int migrate_incoming_fd(int fd)
size = qemu_get_be32(f);
if (size != phys_ram_size) {
-fprintf(stderr, migration: memory size mismatch: recv %u mine %u\n,
+fprintf(stderr, migration: memory size mismatch: recv %u mine %lu\n,
size, phys_ram_size);
return MIG_STAT_DST_MEM_SIZE_MISMATCH;
}
@@ -1063,7 +1063,7 @@ void do_info_migration(void)
term_printf(Transfer rate %3.1f mb/s\n,
(double)s-bps / (1024 * 1024));
term_printf(Iteration %d\n, s-iteration);
- term_printf(Transferred %d/%d pages\n, s-updated_pages,
phys_ram_size TARGET_PAGE_BITS);
+ term_printf(Transferred %d/%lu pages\n, s-updated_pages,
phys_ram_size TARGET_PAGE_BITS);
if (s-iteration)
term_printf(Last iteration found %d dirty pages\n,
s-last_updated_pages);
} else {
Index: kvm-userspace/qemu/vl.c
===
--- kvm-userspace.orig/qemu/vl.c
+++ kvm-userspace/qemu/vl.c
@@ -148,10 +148,14 @@ int inet_aton(const char *cp, struct in_
//#define DEBUG_UNUSED_IOPORT
//#define DEBUG_IOPORT
-#if HOST_LONG_BITS 64
+#if TARGET_LONG_BITS 64
#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024)
#else
+#if HOST_LONG_BITS 64
#define
Re: [kvm-devel] [PATCH] add acpi powerbutton support
Gerd Hoffmann wrote: Hi, Catching ctrl-c sounds like a good idea but ctrl-c, ctrl-c should probably kill qemu then, since the machine might have no acpid running - in that case hitting ctrl-c would have no effect. Good idea. I'm worried about the 30+ second shutdown latency. Is there precedent for SIGTERM or SIGINT requiring this long to take effect? xenner signals a shutdown request to the guest for the first SIGINT (and prints a message to the user saying so). Sending SIGINT twice kills the guest and cleans up. I find that very useful, you can shutdown the guest cleanly with a convenient Ctrl-C and also kill it off quickly by simply pressing Ctrl-C again. Yeah. After having worked with this feature for a few days (I'm mostly running qemu/kvm from command line, w/ and w/o SDL GUI), I can only underline the usefulness of it again. SIGTERM kills the guest instantly. Applictions are expected to react quickly on SIGTERM, there is no way you can wait for a clean guest shutdown then. It is used on (host) shutdown for example, where you'll get a SIGKILL when you don't exit within three seconds. Ack, let's stick with SIGINT. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] system_powerdown via acpi power button
Guido Guenther wrote:
+#if defined(TARGET_I386)
+void qemu_system_powerdown(void)
+{
+if(pm_state-pmen PWRBTN_EN) {
+ pm_state-pmsts |= PWRBTN_EN;
+ pm_update_sci(pm_state);
+}
+}
+#endif
This code should also care about !pm_state, ie. non-PCI systems.
Jan
---
qemu/hw/acpi.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: kvm-userspace/qemu/hw/acpi.c
===
--- kvm-userspace.orig/qemu/hw/acpi.c
+++ kvm-userspace/qemu/hw/acpi.c
@@ -72,7 +72,7 @@ typedef struct PIIX4PMState {
#define SMBHSTDAT1 0x06
#define SMBBLKDAT 0x07
-PIIX4PMState *pm_state;
+PIIX4PMState *pm_state = NULL;
static uint32_t get_pmtmr(PIIX4PMState *s)
{
@@ -527,6 +527,8 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int
#if defined(TARGET_I386)
void qemu_system_powerdown(void)
{
+if (!pm_state)
+exit(0);
if(pm_state-pmen PWRBTN_EN) {
pm_state-pmsts |= PWRBTN_EN;
pm_update_sci(pm_state);
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] system_powerdown via acpi power button
Guido Guenther wrote:
On Tue, Jan 22, 2008 at 11:11:00AM +0100, Jan Kiszka wrote:
#if defined(TARGET_I386)
void qemu_system_powerdown(void)
{
+if (!pm_state)
+exit(0);
if(pm_state-pmen PWRBTN_EN) {
pm_state-pmsts |= PWRBTN_EN;
pm_update_sci(pm_state);
This totally defeats the clean shutdown purpose of system_powerdown.
Think of it like:
system_powerdown: hint the system to shutdown cleanly
SIGTERM: kill the vm
This is how things are wired up in libvirt at the moment.
So how to signal a clean shutdown to the guest if there is no channel
for this?
My idea was to go the PC way: If the OS is not handling ACPI, hitting
power normally switches the PC off - IIRC.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] fix reading from character devices
Hi Avi,
commit kvm: qemu: consume all pending I/O in I/O loop
(8ab8bb09f1115b9bf733f885cc92b6c63d83f420) broke reading data bursts
from serial devices (and maybe from other character devices as well) by
guests. Reason: serial devices do input flow control via fd_read_poll,
but qemu now ignores this fact by pushing all data into the virtual
device as soon as it is available.
Patch below is not really nice (just as the whole internal virtual I/O
interface at the moment, IMHO), but it re-enables the serial ports for
now.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
---
qemu/vl.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: kvm-userspace/qemu/vl.c
===
--- kvm-userspace.orig/qemu/vl.c
+++ kvm-userspace/qemu/vl.c
@@ -7751,7 +7751,10 @@ void main_loop_wait(int timeout)
for(ioh = first_io_handler; ioh != NULL; ioh = ioh-next) {
if (!ioh-deleted ioh-fd_read FD_ISSET(ioh-fd, rfds)) {
ioh-fd_read(ioh-opaque);
-more = 1;
+if (!ioh-fd_read_poll || ioh-fd_read_poll(ioh-opaque))
+more = 1;
+else
+FD_CLR(ioh-fd, rfds);
}
if (!ioh-deleted ioh-fd_write FD_ISSET(ioh-fd, wfds)) {
ioh-fd_write(ioh-opaque);
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC][PATCH 1/2] KVM: In-kernel PIT model
Yang, Sheng wrote: --- /dev/null +++ b/arch/x86/kvm/i8254.h ... +#define PIT_BASE_ADDRESS 0x40 +#define SPEAKER_BASE_ADDRESS 0x61 +#define PIT_MEM_LENGTH 4 +#define PIT_FREQ 1193181 The PIT may not be limited to x86 platforms. So I would propose to make the setup more generic and flexible. And I would move the code out of arch/x86, just the speaker support should remain there. I'm currently struggling with emulating a proprietary platform that has (among other specialties...) a different PIT base frequency, and I already had to patch user space qemu for customizable frequencies. Maybe this kernel extension is a good chance to generalize the PIT setup, and I would be happy to contribute to this if there is a consensus. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC][PATCH 1/2] KVM: In-kernel PIT model
Avi Kivity wrote: Jan Kiszka wrote: The PIT may not be limited to x86 platforms. So I would propose to make the setup more generic and flexible. And I would move the code out of arch/x86, just the speaker support should remain there. I'm currently struggling with emulating a proprietary platform that has (among other specialties...) a different PIT base frequency, and I already had to patch user space qemu for customizable frequencies. Maybe this kernel extension is a good chance to generalize the PIT setup, and I would be happy to contribute to this if there is a consensus. Certainly an ioctl() to configure the PIT can be added. I think that we can leave that to a later patch though. I would rather stuff these parameters into KVM_CREATE_PIT right from the beginning than later breaking the kernel/user ABI or adding a clumsy KVM_CREATE_PIT_SPECIAL_EXTENDED_VERSION. :- Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] add acpi powerbutton support
Hi Guido,
[posting via gmane sucks, just re-enabled mail delivery in this account...]
Guido Guenther wrote:
Hi Jan,
On Sat, Jan 19, 2008 at 04:40:06PM +0100, Jan Kiszka wrote:
What about additionally listening on signals? If you run qemu from the
console, you can then just press ctrl-c to shut the guest down (instead
Catching ctrl-c sounds like a good idea but ctrl-c, ctrl-c should
probably kill qemu then, since the machine might have no acpid running -
in that case hitting ctrl-c would have no effect.
Good idea.
of killing it that way). The same happens on host shutdown (if the guest
is faster than the host's grace period before SIGKILL...).
+signal(SIGINT, qemu_powerdown_sighand);
+signal(SIGTERM, qemu_powerdown_sighand);
We shouldn't catch SIGTERM here since libvirt uses it for
domainDestroy() (in contrast to domainShutdown() which uses
system_powerdown).
Something like this? I also included the SDL window this time, and at
least I like it this way now :-
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
---
qemu/sdl.c|2 +-
qemu/sysemu.h |2 +-
qemu/vl.c | 21 -
3 files changed, 22 insertions(+), 3 deletions(-)
Index: b/qemu/vl.c
===
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7653,9 +7653,21 @@ void qemu_system_shutdown_request(void)
cpu_interrupt(cpu_single_env, CPU_INTERRUPT_EXIT);
}
+/* more than one requests within 2 s = hard powerdown */
+#define HARD_POWERDOWN_WINDOW 2
+
void qemu_system_powerdown_request(void)
{
-powerdown_requested = 1;
+static time_t last_request;
+time_t now, delta;
+
+now = time(NULL);
+delta = now-last_request;
+last_request = now;
+if (delta 0 || delta HARD_POWERDOWN_WINDOW)
+powerdown_requested = 1;
+else
+shutdown_requested = 1;
if (cpu_single_env)
cpu_interrupt(cpu_single_env, CPU_INTERRUPT_EXIT);
}
@@ -8501,6 +8513,11 @@ void qemu_get_launch_info(int *argc, cha
*opt_incoming = incoming;
}
+void qemu_powerdown_sighand(int signal)
+{
+qemu_system_powerdown_request();
+}
+
int main(int argc, char **argv)
{
#ifdef CONFIG_GDBSTUB
@@ -9475,6 +9492,8 @@ int main(int argc, char **argv)
}
}
+signal(SIGINT, qemu_powerdown_sighand);
+
machine-init(ram_size, vga_ram_size, boot_devices, ds,
kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
Index: b/qemu/sysemu.h
===
--- a/qemu/sysemu.h
+++ b/qemu/sysemu.h
@@ -35,7 +35,7 @@ int qemu_reset_requested(void);
int qemu_powerdown_requested(void);
#if !defined(TARGET_SPARC) !defined(TARGET_I386)
// Please implement a power failure function to signal the OS
-#define qemu_system_powerdown() do{}while(0)
+#define qemu_system_powerdown() exit(0)
#else
void qemu_system_powerdown(void);
#endif
Index: b/qemu/sdl.c
===
--- a/qemu/sdl.c
+++ b/qemu/sdl.c
@@ -469,7 +469,7 @@ static void sdl_refresh(DisplayState *ds
break;
case SDL_QUIT:
if (!no_quit) {
-qemu_system_shutdown_request();
+qemu_system_powerdown_request();
vm_start();/* In case we're paused */
}
break;
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] fix reading from character devices
Avi Kivity wrote: Dor Laor wrote: On Mon, 2008-01-21 at 12:13 +0200, Avi Kivity wrote: Jan Kiszka wrote: Hi Avi, commit kvm: qemu: consume all pending I/O in I/O loop (8ab8bb09f1115b9bf733f885cc92b6c63d83f420) broke reading data bursts from serial devices (and maybe from other character devices as well) by guests. Reason: serial devices do input flow control via fd_read_poll, but qemu now ignores this fact by pushing all data into the virtual device as soon as it is available. Patch below is not really nice (just as the whole internal virtual I/O interface at the moment, IMHO), but it re-enables the serial ports for now. I'm worried that it will break Dor's hack that speeds up virtio. Dor? It should be fine. Tap device without my hack has fd_read_poll null and I hacked it to have a handler that returns false if virtio is used and true otherwise. So Jan's patch should set 'more' to 1 and it will be like before. But if virtio is used with this patch, it won't set 'more' to 1. Will virtio handle it or will throughput drop to be related to whatever timers we have set up? As long as virtio_net_can_receive returns 1, the loop will keep on feeding also this device. And if it returns 0, I see no reason for ignoring this signal. Anythings else would be, well, weird. However, the current io-polling loop in git urgently needs fixing, or even a redesign. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] add acpi powerbutton support
Avi Kivity wrote: Jan Kiszka wrote: Guido Guenther wrote: Hi Jan, On Sat, Jan 19, 2008 at 04:40:06PM +0100, Jan Kiszka wrote: What about additionally listening on signals? If you run qemu from the console, you can then just press ctrl-c to shut the guest down (instead Catching ctrl-c sounds like a good idea but ctrl-c, ctrl-c should probably kill qemu then, since the machine might have no acpid running - in that case hitting ctrl-c would have no effect. Good idea. I'm worried about the 30+ second shutdown latency. Is there precedent for SIGTERM or SIGINT requiring this long to take effect? Sorry, can't follow this yet: Are you talking about host system shutdown that should wait on the guest system that long? Maybe we should suspend the VM instead (using qemu suspend, not guest suspend). You mean on SIGTERM? I think Guido's concern was that this signal is expected to actually kill the qemu instance. Therefore I dropped this signal from my second patch. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] janitor: revert accidental type change
While trying to reduce the warning noise (to identify warnings of homebrewed patches), I also came across this bogus but fortunately harmless type change in bdrv_commit. Fix below. Jan Index: kvm-userspace/qemu/block.c === --- kvm-userspace.orig/qemu/block.c +++ kvm-userspace/qemu/block.c @@ -460,7 +460,7 @@ int bdrv_commit(BlockDriverState *bs) BlockDriver *drv = bs-drv; int64_t i, total_sectors; int n, j; -unsigned char *sector[512]; +unsigned char sector[512]; if (!drv) return -ENOMEDIUM; -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] add acpi powerbutton support
Guido Guenther wrote:
On Tue, Jan 08, 2008 at 01:34:30PM +0900, Jun Koi wrote:
Sorry for my ignorance, but what is the effect of this patch? So
I can shutdown guest VM cleanly, or smt else??
system_powerdown in the commmand monitor now simulates the pressing of
the acpi power button. This allows you to shutdown the system cleanly.
This is nice for things like libvirt where you can now do a
virsh shutdown vm
and the machine doesn't simply get killed. You need this patch for
libvirt:
What about additionally listening on signals? If you run qemu from the
console, you can then just press ctrl-c to shut the guest down (instead
of killing it that way). The same happens on host shutdown (if the guest
is faster than the host's grace period before SIGKILL...).
Jan
---
qemu/sysemu.h |2 +-
qemu/vl.c |8
2 files changed, 9 insertions(+), 1 deletion(-)
Index: kvm-userspace/qemu/vl.c
===
--- kvm-userspace.orig/qemu/vl.c
+++ kvm-userspace/qemu/vl.c
@@ -8501,6 +8501,11 @@ void qemu_get_launch_info(int *argc, cha
*opt_incoming = incoming;
}
+void qemu_powerdown_sighand(int signal)
+{
+qemu_system_powerdown_request();
+}
+
int main(int argc, char **argv)
{
#ifdef CONFIG_GDBSTUB
@@ -9475,6 +9480,9 @@ int main(int argc, char **argv)
}
}
+signal(SIGINT, qemu_powerdown_sighand);
+signal(SIGTERM, qemu_powerdown_sighand);
+
machine-init(ram_size, vga_ram_size, boot_devices, ds,
kernel_filename, kernel_cmdline, initrd_filename, cpu_model);
Index: kvm-userspace/qemu/sysemu.h
===
--- kvm-userspace.orig/qemu/sysemu.h
+++ kvm-userspace/qemu/sysemu.h
@@ -35,7 +35,7 @@ int qemu_reset_requested(void);
int qemu_powerdown_requested(void);
#if !defined(TARGET_SPARC) !defined(TARGET_I386)
// Please implement a power failure function to signal the OS
-#define qemu_system_powerdown() do{}while(0)
+#define qemu_system_powerdown() exit(0)
#else
void qemu_system_powerdown(void);
#endif
signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] align gdbstub with QEMU
Avi Kivity wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
We've noticed some problems with current gdbstub in kvm's qemu:
# qemu-system-x86_64 -hda myimage -S -s
# gdb
(gdb) tar re :1234
Remote debugging using :1234
Remote 'g' packet reply is too long:
[...]
This issue did not occur with QEMU from CVS. As I was aware of an
x86_64-related problem in QEMU's gdbstub, I merged its current state
into kvm - and things start to work again. Find the update patch below.
Any feedback on this? Any chance to see this patch (or some similar
version) in kvm-57?
Sorry for the non-response. I am hoping to get qemu-cvs merged for
kvm-57, which will naturally include this. If that doesn't work out
(i.e. we discover regressions), and if this is important for you, I will
apply the patch.
The qemu update did take place for -57, but a bit too mechanically.
Please merge this patch to finally fix the gdbstub.
Thanks,
Jan
Remove left-over from qemu CVS update.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/gdbstub.c | 136 -
1 file changed, 1 insertion(+), 135 deletions(-)
Index: kvm-userspace/qemu/gdbstub.c
===
--- kvm-userspace.orig/qemu/gdbstub.c
+++ kvm-userspace/qemu/gdbstub.c
@@ -225,141 +225,7 @@ static int put_packet(GDBState *s, char
return 0;
}
-#if defined(TARGET_X86_64)
-
-static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
-{
-uint8_t *p = mem_buf;
-int i, fpus;
-
-#define PUTREG(x) do { \
- target_ulong reg = tswapl(x); \
- memcpy(p, reg, sizeof reg); \
- p += sizeof reg; \
-} while (0)
-#define PUTREG32(x) do { \
- uint32_t reg = tswap32(x); \
- memcpy(p, reg, sizeof reg); \
- p += sizeof reg; \
-} while (0)
-#define PUTREGF(x) do { \
- memcpy(p, (x), 10);\
- p += sizeof (x);\
-} while (0)
-
-PUTREG(env-regs[R_EAX]);
-PUTREG(env-regs[R_EBX]);
-PUTREG(env-regs[R_ECX]);
-PUTREG(env-regs[R_EDX]);
-PUTREG(env-regs[R_ESI]);
-PUTREG(env-regs[R_EDI]);
-PUTREG(env-regs[R_EBP]);
-PUTREG(env-regs[R_ESP]);
-PUTREG(env-regs[8]);
-PUTREG(env-regs[9]);
-PUTREG(env-regs[10]);
-PUTREG(env-regs[11]);
-PUTREG(env-regs[12]);
-PUTREG(env-regs[13]);
-PUTREG(env-regs[14]);
-PUTREG(env-regs[15]);
-
-PUTREG(env-eip);
-PUTREG32(env-eflags);
-PUTREG32(env-segs[R_CS].selector);
-PUTREG32(env-segs[R_SS].selector);
-PUTREG32(env-segs[R_DS].selector);
-PUTREG32(env-segs[R_ES].selector);
-PUTREG32(env-segs[R_FS].selector);
-PUTREG32(env-segs[R_GS].selector);
-/* XXX: convert floats */
-for(i = 0; i 8; i++) {
-PUTREGF(env-fpregs[i]);
-}
-PUTREG32(env-fpuc);
-fpus = (env-fpus ~0x3800) | (env-fpstt 0x7) 11;
-PUTREG32(fpus);
-PUTREG32(0); /* XXX: convert tags */
-PUTREG32(0); /* fiseg */
-PUTREG32(0); /* fioff */
-PUTREG32(0); /* foseg */
-PUTREG32(0); /* fooff */
-PUTREG32(0); /* fop */
-
-#undef PUTREG
-#undef PUTREG32
-#undef PUTREGF
-
-return p - mem_buf;
-}
-
-static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int size)
-{
-uint8_t *p = mem_buf;
-uint32_t junk;
-int i, fpus;
-
-#define GETREG(x) do { \
- target_ulong reg; \
- memcpy(reg, p, sizeof reg); \
- x = tswapl(reg); \
- p += sizeof reg; \
-} while (0)
-#define GETREG32(x) do { \
- uint32_t reg; \
- memcpy(reg, p, sizeof reg); \
- x = tswap32(reg);\
- p += sizeof reg; \
-} while (0)
-#define GETREGF(x) do { \
- memcpy((x), p, 10); \
- p += 10; \
-} while (0)
-
-GETREG(env-regs[R_EAX]);
-GETREG(env-regs[R_EBX]);
-GETREG(env-regs[R_ECX]);
-GETREG(env-regs[R_EDX]);
-GETREG(env-regs[R_ESI]);
-GETREG(env-regs[R_EDI]);
-GETREG(env-regs[R_EBP]);
-GETREG(env-regs[R_ESP]);
-GETREG(env-regs[8]);
-GETREG(env-regs[9]);
-GETREG(env-regs[10]);
-GETREG(env-regs[11]);
-GETREG(env-regs[12]);
-GETREG(env-regs[13]);
-GETREG(env-regs[14]);
-GETREG(env-regs[15]);
-
-GETREG(env-eip);
-GETREG32(env-eflags);
-GETREG32(env-segs[R_CS].selector);
-GETREG32(env-segs[R_SS].selector);
-GETREG32(env-segs[R_DS].selector);
-GETREG32(env-segs[R_ES].selector);
-GETREG32(env-segs[R_FS].selector);
-GETREG32(env-segs[R_GS].selector);
-/* XXX: convert floats */
-for(i = 0; i 8; i++) {
-GETREGF(env-fpregs[i]);
-}
-GETREG32(env-fpuc);
-GETREG32(fpus); /* XXX: convert fpus */
-GETREG32(junk); /* XXX: convert tags */
-GETREG32(junk); /* fiseg */
-GETREG32(junk); /* fioff
Re: [kvm-devel] [PATCH] align gdbstub with QEMU
Jan Kiszka wrote:
We've noticed some problems with current gdbstub in kvm's qemu:
# qemu-system-x86_64 -hda myimage -S -s
# gdb
(gdb) tar re :1234
Remote debugging using :1234
Remote 'g' packet reply is too long:
[...]
This issue did not occur with QEMU from CVS. As I was aware of an
x86_64-related problem in QEMU's gdbstub, I merged its current state
into kvm - and things start to work again. Find the update patch below.
Any feedback on this? Any chance to see this patch (or some similar
version) in kvm-57?
Thanks,
Jan
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/gdbstub.c | 290
-
1 file changed, 143 insertions(+), 147 deletions(-)
Index: kvm-54/qemu/gdbstub.c
===
--- kvm-54.orig/qemu/gdbstub.c
+++ kvm-54/qemu/gdbstub.c
@@ -222,146 +222,60 @@ static int put_packet(GDBState *s, char
return 0;
}
-#if defined(TARGET_X86_64)
+#if defined(TARGET_I386)
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
-uint8_t *p = mem_buf;
int i, fpus;
+uint32_t *registers = (uint32_t *)mem_buf;
-#define PUTREG(x) do { \
- target_ulong reg = tswapl(x); \
- memcpy(p, reg, sizeof reg); \
- p += sizeof reg; \
-} while (0)
-#define PUTREG32(x) do { \
- uint32_t reg = tswap32(x); \
- memcpy(p, reg, sizeof reg); \
- p += sizeof reg; \
-} while (0)
-#define PUTREGF(x) do { \
- memcpy(p, (x), 10);\
- p += sizeof (x);\
-} while (0)
-
-PUTREG(env-regs[R_EAX]);
-PUTREG(env-regs[R_EBX]);
-PUTREG(env-regs[R_ECX]);
-PUTREG(env-regs[R_EDX]);
-PUTREG(env-regs[R_ESI]);
-PUTREG(env-regs[R_EDI]);
-PUTREG(env-regs[R_EBP]);
-PUTREG(env-regs[R_ESP]);
-PUTREG(env-regs[8]);
-PUTREG(env-regs[9]);
-PUTREG(env-regs[10]);
-PUTREG(env-regs[11]);
-PUTREG(env-regs[12]);
-PUTREG(env-regs[13]);
-PUTREG(env-regs[14]);
-PUTREG(env-regs[15]);
-
-PUTREG(env-eip);
-PUTREG32(env-eflags);
-PUTREG32(env-segs[R_CS].selector);
-PUTREG32(env-segs[R_SS].selector);
-PUTREG32(env-segs[R_DS].selector);
-PUTREG32(env-segs[R_ES].selector);
-PUTREG32(env-segs[R_FS].selector);
-PUTREG32(env-segs[R_GS].selector);
-/* XXX: convert floats */
-for(i = 0; i 8; i++) {
-PUTREGF(env-fpregs[i]);
-}
-PUTREG32(env-fpuc);
-fpus = (env-fpus ~0x3800) | (env-fpstt 0x7) 11;
-PUTREG32(fpus);
-PUTREG32(0); /* XXX: convert tags */
-PUTREG32(0); /* fiseg */
-PUTREG32(0); /* fioff */
-PUTREG32(0); /* foseg */
-PUTREG32(0); /* fooff */
-PUTREG32(0); /* fop */
-
-#undef PUTREG
-#undef PUTREG32
-#undef PUTREGF
-
-return p - mem_buf;
-}
+#ifdef TARGET_X86_64
+/* This corresponds with amd64_register_info[] in gdb/amd64-tdep.c */
+uint64_t *registers64 = (uint64_t *)mem_buf;
+
+if (env-hflags HF_CS64_MASK) {
+registers64[0] = tswap64(env-regs[R_EAX]);
+registers64[1] = tswap64(env-regs[R_EBX]);
+registers64[2] = tswap64(env-regs[R_ECX]);
+registers64[3] = tswap64(env-regs[R_EDX]);
+registers64[4] = tswap64(env-regs[R_ESI]);
+registers64[5] = tswap64(env-regs[R_EDI]);
+registers64[6] = tswap64(env-regs[R_EBP]);
+registers64[7] = tswap64(env-regs[R_ESP]);
+for(i = 8; i 16; i++) {
+registers64[i] = tswap64(env-regs[i]);
+}
+registers64[16] = tswap64(env-eip);
-static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int
size)
-{
-uint8_t *p = mem_buf;
-uint32_t junk;
-int i, fpus;
+registers = (uint32_t *)registers64[17];
+registers[0] = tswap32(env-eflags);
+registers[1] = tswap32(env-segs[R_CS].selector);
+registers[2] = tswap32(env-segs[R_SS].selector);
+registers[3] = tswap32(env-segs[R_DS].selector);
+registers[4] = tswap32(env-segs[R_ES].selector);
+registers[5] = tswap32(env-segs[R_FS].selector);
+registers[6] = tswap32(env-segs[R_GS].selector);
+/* XXX: convert floats */
+for(i = 0; i 8; i++) {
+memcpy(mem_buf + 16 * 8 + 7 * 4 + i * 10, env-fpregs[i], 10);
+}
+registers[27] = tswap32(env-fpuc); /* fctrl */
+fpus = (env-fpus ~0x3800) | (env-fpstt 0x7) 11;
+registers[28] = tswap32(fpus); /* fstat */
+registers[29] = 0; /* ftag */
+registers[30] = 0; /* fiseg */
+registers[31] = 0; /* fioff */
+registers[32] = 0; /* foseg */
+registers[33] = 0; /* fooff */
+registers[34] = 0; /* fop */
+for(i = 0; i 16; i++) {
+memcpy(mem_buf + 16 * 8 + 35 * 4 + i * 16
Re: [kvm-devel] [PATCH] align gdbstub with QEMU
Avi Kivity wrote: Jan Kiszka wrote: Jan Kiszka wrote: We've noticed some problems with current gdbstub in kvm's qemu: # qemu-system-x86_64 -hda myimage -S -s # gdb (gdb) tar re :1234 Remote debugging using :1234 Remote 'g' packet reply is too long: [...] This issue did not occur with QEMU from CVS. As I was aware of an x86_64-related problem in QEMU's gdbstub, I merged its current state into kvm - and things start to work again. Find the update patch below. Any feedback on this? Any chance to see this patch (or some similar version) in kvm-57? Sorry for the non-response. I am hoping to get qemu-cvs merged for kvm-57, which will naturally include this. If that doesn't work out (i.e. we discover regressions), and if this is important for you, I will apply the patch. OK, great. BTW, are there plans to merge the kvm branch into qemu at some point and continue development unitedly with the qemu people? Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] align gdbstub with QEMU
We've noticed some problems with current gdbstub in kvm's qemu:
# qemu-system-x86_64 -hda myimage -S -s
# gdb
(gdb) tar re :1234
Remote debugging using :1234
Remote 'g' packet reply is too long:
[...]
This issue did not occur with QEMU from CVS. As I was aware of an
x86_64-related problem in QEMU's gdbstub, I merged its current state
into kvm - and things start to work again. Find the update patch below.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/gdbstub.c | 290 -
1 file changed, 143 insertions(+), 147 deletions(-)
Index: kvm-54/qemu/gdbstub.c
===
--- kvm-54.orig/qemu/gdbstub.c
+++ kvm-54/qemu/gdbstub.c
@@ -222,146 +222,60 @@ static int put_packet(GDBState *s, char
return 0;
}
-#if defined(TARGET_X86_64)
+#if defined(TARGET_I386)
static int cpu_gdb_read_registers(CPUState *env, uint8_t *mem_buf)
{
-uint8_t *p = mem_buf;
int i, fpus;
+uint32_t *registers = (uint32_t *)mem_buf;
-#define PUTREG(x) do { \
- target_ulong reg = tswapl(x); \
- memcpy(p, reg, sizeof reg); \
- p += sizeof reg; \
-} while (0)
-#define PUTREG32(x) do { \
- uint32_t reg = tswap32(x); \
- memcpy(p, reg, sizeof reg); \
- p += sizeof reg; \
-} while (0)
-#define PUTREGF(x) do { \
- memcpy(p, (x), 10);\
- p += sizeof (x);\
-} while (0)
-
-PUTREG(env-regs[R_EAX]);
-PUTREG(env-regs[R_EBX]);
-PUTREG(env-regs[R_ECX]);
-PUTREG(env-regs[R_EDX]);
-PUTREG(env-regs[R_ESI]);
-PUTREG(env-regs[R_EDI]);
-PUTREG(env-regs[R_EBP]);
-PUTREG(env-regs[R_ESP]);
-PUTREG(env-regs[8]);
-PUTREG(env-regs[9]);
-PUTREG(env-regs[10]);
-PUTREG(env-regs[11]);
-PUTREG(env-regs[12]);
-PUTREG(env-regs[13]);
-PUTREG(env-regs[14]);
-PUTREG(env-regs[15]);
-
-PUTREG(env-eip);
-PUTREG32(env-eflags);
-PUTREG32(env-segs[R_CS].selector);
-PUTREG32(env-segs[R_SS].selector);
-PUTREG32(env-segs[R_DS].selector);
-PUTREG32(env-segs[R_ES].selector);
-PUTREG32(env-segs[R_FS].selector);
-PUTREG32(env-segs[R_GS].selector);
-/* XXX: convert floats */
-for(i = 0; i 8; i++) {
-PUTREGF(env-fpregs[i]);
-}
-PUTREG32(env-fpuc);
-fpus = (env-fpus ~0x3800) | (env-fpstt 0x7) 11;
-PUTREG32(fpus);
-PUTREG32(0); /* XXX: convert tags */
-PUTREG32(0); /* fiseg */
-PUTREG32(0); /* fioff */
-PUTREG32(0); /* foseg */
-PUTREG32(0); /* fooff */
-PUTREG32(0); /* fop */
-
-#undef PUTREG
-#undef PUTREG32
-#undef PUTREGF
-
-return p - mem_buf;
-}
+#ifdef TARGET_X86_64
+/* This corresponds with amd64_register_info[] in gdb/amd64-tdep.c */
+uint64_t *registers64 = (uint64_t *)mem_buf;
+
+if (env-hflags HF_CS64_MASK) {
+registers64[0] = tswap64(env-regs[R_EAX]);
+registers64[1] = tswap64(env-regs[R_EBX]);
+registers64[2] = tswap64(env-regs[R_ECX]);
+registers64[3] = tswap64(env-regs[R_EDX]);
+registers64[4] = tswap64(env-regs[R_ESI]);
+registers64[5] = tswap64(env-regs[R_EDI]);
+registers64[6] = tswap64(env-regs[R_EBP]);
+registers64[7] = tswap64(env-regs[R_ESP]);
+for(i = 8; i 16; i++) {
+registers64[i] = tswap64(env-regs[i]);
+}
+registers64[16] = tswap64(env-eip);
-static void cpu_gdb_write_registers(CPUState *env, uint8_t *mem_buf, int size)
-{
-uint8_t *p = mem_buf;
-uint32_t junk;
-int i, fpus;
+registers = (uint32_t *)registers64[17];
+registers[0] = tswap32(env-eflags);
+registers[1] = tswap32(env-segs[R_CS].selector);
+registers[2] = tswap32(env-segs[R_SS].selector);
+registers[3] = tswap32(env-segs[R_DS].selector);
+registers[4] = tswap32(env-segs[R_ES].selector);
+registers[5] = tswap32(env-segs[R_FS].selector);
+registers[6] = tswap32(env-segs[R_GS].selector);
+/* XXX: convert floats */
+for(i = 0; i 8; i++) {
+memcpy(mem_buf + 16 * 8 + 7 * 4 + i * 10, env-fpregs[i], 10);
+}
+registers[27] = tswap32(env-fpuc); /* fctrl */
+fpus = (env-fpus ~0x3800) | (env-fpstt 0x7) 11;
+registers[28] = tswap32(fpus); /* fstat */
+registers[29] = 0; /* ftag */
+registers[30] = 0; /* fiseg */
+registers[31] = 0; /* fioff */
+registers[32] = 0; /* foseg */
+registers[33] = 0; /* fooff */
+registers[34] = 0; /* fop */
+for(i = 0; i 16; i++) {
+memcpy(mem_buf + 16 * 8 + 35 * 4 + i * 16, env-xmm_regs[i], 16);
+}
+registers[99] = tswap32(env-mxcsr);
-#define GETREG(x) do { \
- target_ulong reg; \
- memcpy(reg, p, sizeof reg); \
- x = tswapl(reg); \
- p += sizeof reg
Re: [kvm-devel] Unhandled vm exit with old protected mode test
Avi Kivity wrote:
Jan Kiszka wrote:
Hi,
running some oldish 286 protected mode demo in kvm, I came across this
bug of kvm-52:
unhandled vm exit: 0x8021 vcpu_id 0
ds (0010/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
ds.base must equal ds.sel4 when entering real-mode on Intel. See
fix_rmode_seg() in vmx.c which clearly doesn't handle cases where
ds.base = 0x10. You might try forcing bits 20+ of ds.base to zero
in there. This may fix the problem or move it elsewhere.
Yeah, this actually fixed my test case:
Ensure that segment.base == segment.selector 4 when entering the real
mode on Intel so that the CPU will not bark at us.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
kernel/vmx.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: kvm-52/kernel/vmx.c
===
--- kvm-52.orig/kernel/vmx.c
+++ kvm-52/kernel/vmx.c
@@ -1159,12 +1159,14 @@ static gva_t rmode_tss_base(struct kvm *
static void fix_rmode_seg(int seg, struct kvm_save_segment *save)
{
struct kvm_vmx_segment_field *sf = kvm_vmx_segment_fields[seg];
+ unsigned base;
save-selector = vmcs_read16(sf-selector);
- save-base = vmcs_readl(sf-base);
+ save-base = base = vmcs_readl(sf-base);
save-limit = vmcs_read32(sf-limit);
save-ar = vmcs_read32(sf-ar_bytes);
- vmcs_write16(sf-selector, vmcs_readl(sf-base) 4);
+ vmcs_write16(sf-selector, base 4);
+ vmcs_write32(sf-base, base 0xf);
vmcs_write32(sf-limit, 0x);
vmcs_write32(sf-ar_bytes, 0xf3);
}
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Unhandled vm exit with old protected mode test
Hi, running some oldish 286 protected mode demo in kvm, I came across this bug of kvm-52: unhandled vm exit: 0x8021 vcpu_id 0 rax 6010 rbx rcx rdx 0003 rsi 0400 rdi 0008042e rsp 01fa rbp 091e r8 r9 r10 r11 r12 r13 r14 r15 rip 015b rflags 00023002 cs 320e (000320e0/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (0010/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 31cb (00031cb0/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 3226 (00032260/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (fffbd000/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 31cb0/27 idt 0/3ff cr0 6010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 The executed code is from [1] and was running over a FreeDOS image [2]. I found out that the crash happens on leaving the protected mode again. Anyone any ideas already? I can't dig into this on my own right now, but maybe it is simple to fix for people reading such dumps every day... ;) Thanks, Jan [1] http://www.x86.org/articles/pmbasics/tspec_a1_doc.htm [2] http://fabrice.bellard.free.fr/qemu/download.html -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23.1-rt4 and kvm 48
Carsten Emde wrote: Avi Kivity wrote: David Brown wrote: I thought I'd try out the realtime patch set and it didn't work at all with kvm. The console didn't dump anything and the system completely locked up. Up to now, the unmodified kvm module never worked with any RT kernel. This would only change, if RT patched kernels were routinely used in the kvm release tests which is, for the time being, not the case. As far as I understood (but didn't re-test yet), latest kvm release does include all features required to run over -rt. This was at least the case for kvm-git I picked up last week and merged into 2.6.23-rt1. The only issue is that out-of-tree kvm doesn't enable the preemption notifiers (maybe there were one or two further minor issues, I think to recall missing smp_ops exports being one, but these were not -rt related). However, tglx once provided a hand-crafted kvm version that can be used together with a selected RT kernel - see Latest Stable (http://www.osadl.org/Latest-Stable.latest-stable-realtime-kernel.0.html) realtime kernel. It is based on kernel 2.6.21.6-rt21 and kvm-28. We used these modules to carry out a number of proof of concept tests which were very successful. The realtime capabilities of the host system remained unchanged irrespective of whether the kvm guest system (no graphics) was running or not. This was even the case while the guest system was booting. Interesting result - you've read about the wbinvd issues? Is there no wbinvd in the bios shipped with older kvm? Which VM extension did you test, both Intel and AMD? I would bet that your X issues are due to the same effect. X startup/shutdown involves a lot of wbinvd calls on my test boxes. To sum up my findings: kvm over whatever RT kernel is risky (latency-wise) unless you can audit or even para-virtualise your guest OS /wrt wbinvd. Maybe we can discuss this also in Linz by the end of the week. :) Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23.1-rt4 and kvm 48
Avi Kivity wrote: Jan Kiszka wrote: Interesting result - you've read about the wbinvd issues? Is there no wbinvd in the bios shipped with older kvm? Which VM extension did you test, both Intel and AMD? I would bet that your X issues are due to the same effect. X startup/shutdown involves a lot of wbinvd calls on my test boxes. kvm.git now traps invd and wbinvd on amd, so there shouldn't be any issues there. So kvm can then simply ignore the instructions, or what does it do about them? I recall some replies in the related thread that some more work may be required. I hope that Intel will add similar traps in future iterations of VT. Yep. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown
Avi Kivity wrote: Jan Kiszka wrote: I ran user/kvmctl user/test/bootstrap user/test/smp.flat with the busy loop hacked into bootstrap, but I got no latency spots this time. And what should I look for in the output of kvm_stat? The first numeric column is the total number of exits; the second is the rate of change (per second). For a spinning workload, both irq_exits and exits rate should equal the timer frequency. It matches roughly, but this isn't surprising given the lack of latency peaks in this scenario. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown
Gregory Haskins wrote: On Tue, 2007-10-23 at 16:19 +0200, Avi Kivity wrote: Jan Kiszka wrote: Avi, [somehow your mails do not get through to my private account, so I'm switching] Avi Kivity wrote: Jan Kiszka wrote: Clarification: I can't precisely tell what code is executed in VM mode, as I don't have qemu or that guest instrumented. I just see the kernel entering VM mode and leaving it again more than 300 us later. So I wonder why this is allowed while some external IRQ is pending. How do you know an external interrupt is pending? It's the host timer IRQ, programmed to fire in certain intervals (100 us here). Test case is some latency measurement tool like tglx's cyclictest or similar programs we use in Xenomai. kvm programs the hardware to exit when an external interrupt arrives. Here is a latency trace I just managed to capture over 2.6.23.1-rt1 with latest kvm from git hacked into (kvm generally seems to work fine this way): ... qemu-sys-7543 0...1 13897us : vmcs_write16+0xb/0x20 (vmx_save_host_state+0x1a7/0x1c0) qemu-sys-7543 0...1 13897us : vmcs_writel+0xb/0x30 (vmcs_write16+0x1e/0x20) qemu-sys-7543 0...1 13898us : segment_base+0xc/0x70 (vmx_save_host_state+0xa0/0x1c0) qemu-sys-7543 0...1 13898us : vmcs_writel+0xb/0x30 (vmx_save_host_state+0xb0/0x1c0) qemu-sys-7543 0...1 13898us : segment_base+0xc/0x70 (vmx_save_host_state+0xbf/0x1c0) qemu-sys-7543 0...1 13898us : vmcs_writel+0xb/0x30 (vmx_save_host_state+0xcf/0x1c0) qemu-sys-7543 0...1 13898us : load_msrs+0xb/0x40 (vmx_save_host_state+0xe7/0x1c0) qemu-sys-7543 0...1 13898us : kvm_load_guest_fpu+0x8/0x40 (kvm_vcpu_ioctl_run+0xbf/0x570) qemu-sys-7543 0D..1 13899us : vmx_vcpu_run+0xc/0x110 (kvm_vcpu_ioctl_run+0x120/0x570) qemu-sys-7543 0D..1 13899us!: vmcs_writel+0xb/0x30 (vmx_vcpu_run+0x22/0x110) qemu-sys-7543 0D..1 14344us : vmcs_read32+0xb/0x20 (vmx_vcpu_run+0xc7/0x110) qemu-sys-7543 0D..1 14345us : vmcs_readl+0x8/0x10 (vmcs_read32+0x16/0x20) qemu-sys-7543 0D..1 14345us : vmcs_read32+0xb/0x20 (vmx_vcpu_run+0xf4/0x110) qemu-sys-7543 0D..1 14345us+: vmcs_readl+0x8/0x10 (vmcs_read32+0x16/0x20) qemu-sys-7543 0D..1 14349us : irq_enter+0xb/0x30 (do_IRQ+0x45/0xc0) qemu-sys-7543 0D.h1 14350us : do_IRQ+0x73/0xc0 (f8caae24 0 0) qemu-sys-7543 0D.h1 14351us : handle_level_irq+0xe/0x120 (do_IRQ+0x7d/0xc0) qemu-sys-7543 0D.h1 14351us : __spin_lock+0xc/0x30 (handle_level_irq+0x24/0x120) qemu-sys-7543 0D.h2 14352us : mask_and_ack_8259A+0x14/0x120 (handle_level_irq+0x37/0x120) qemu-sys-7543 0D.h2 14352us+: __spin_lock_irqsave+0x11/0x60 (mask_and_ack_8259A+0x2a/0x120) qemu-sys-7543 0D.h3 14357us : __spin_unlock_irqrestore+0xc/0x60 (mask_and_ack_8259A+0x7a/0x120) qemu-sys-7543 0D.h2 14358us : redirect_hardirq+0x8/0x70 (handle_level_irq+0x72/0x120) qemu-sys-7543 0D.h2 14358us : __spin_unlock+0xb/0x40 (handle_level_irq+0x8e/0x120) qemu-sys-7543 0D.h1 14358us : handle_IRQ_event+0xe/0x110 (handle_level_irq+0x9a/0x120) qemu-sys-7543 0D.h1 14359us : timer_interrupt+0xb/0x60 (handle_IRQ_event+0x67/0x110) qemu-sys-7543 0D.h1 14359us : hrtimer_interrupt+0xe/0x1f0 (timer_interrupt+0x20/0x60) ... One can see 345 us latency between vm-enter and vm-exit in vmx_vcpu_run - and this while cyclictest runs at a period of 100 us! I got the same results over Adeos/I-pipe Xenomai with the function tracer there, also pointing to the period while the CPU is in VM mode. Anyone any ideas? Greg, I put you on CC as you said you once saw decent latencies with your patches. Are there still magic bits missing in official kvm? No bits missing as far as I know. It should just work. That could very well be the case these days. I know back when I was looking at it, KVM would not run on VMX + -rt without modification or it would crash/hang (this was around the time I was working on that smp_function_call stuff). And without careful modification it would run very poorly (with high (300us+ latencies) revealed in cyclictest. However, I was able to craft the vmx_vcpu_run path so that a VM could run side-by-side with cyclictest with sub 40us latencies. In fact, normally it was sub 30us, but on an occasional run I would get a spike to ~37us. Unfortunately I am deep into other non-KVM related -rt issues at the moment, so I can't work on it any further for a bit. Do you have some patch fragments left over? At least /me would be interested to study and maybe forward port them. Or can you briefly explain the issue above and/or the general problem behind this delay? Thanks, Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser
Re: [kvm-devel] High vm-exit latencies during kvm boot-up/shutdown
Avi Kivity wrote: Jan Kiszka wrote: Avi Kivity wrote: Please post a disassembly of your vmx_vcpu_run so we can interpret the offsets. Here it comes: 2df0 vmx_vcpu_run: 2df0: 55 push %ebp 2df1: 89 e5 mov%esp,%ebp 2df3: 53 push %ebx 2df4: 83 ec 08sub$0x8,%esp 2df7: e8 fc ff ff ff call 2df8 vmx_vcpu_run+0x8 2dfc: 8b 5d 08mov0x8(%ebp),%ebx 2dff: 0f 20 c0mov%cr0,%eax 2e02: 89 44 24 04 mov%eax,0x4(%esp) 2e06: c7 04 24 00 6c 00 00movl $0x6c00,(%esp) 2e0d: e8 be d8 ff ff call 6d0 vmcs_writel first trace 2e12: 8b 83 80 0d 00 00 mov0xd80(%ebx),%eax 2e18: ba 14 6c 00 00 mov$0x6c14,%edx 2e1d: 89 d9 mov%ebx,%ecx 2e1f: 60 pusha 2e20: 51 push %ecx 2e21: 0f 79 d4vmwrite %esp,%edx 2e24: 83 f8 00cmp$0x0,%eax 2e27: 8b 81 78 01 00 00 mov0x178(%ecx),%eax 2e2d: 0f 22 d0mov%eax,%cr2 2e30: 8b 81 50 01 00 00 mov0x150(%ecx),%eax 2e36: 8b 99 5c 01 00 00 mov0x15c(%ecx),%ebx 2e3c: 8b 91 58 01 00 00 mov0x158(%ecx),%edx 2e42: 8b b1 68 01 00 00 mov0x168(%ecx),%esi 2e48: 8b b9 6c 01 00 00 mov0x16c(%ecx),%edi 2e4e: 8b a9 64 01 00 00 mov0x164(%ecx),%ebp 2e54: 8b 89 54 01 00 00 mov0x154(%ecx),%ecx 2e5a: 75 05 jne2e61 vmx_vcpu_run+0x71 2e5c: 0f 01 c2vmlaunch 2e5f: eb 03 jmp2e64 vmx_vcpu_run+0x74 2e61: 0f 01 c3vmresume 2e64: 87 0c 24xchg %ecx,(%esp) 2e67: 89 81 50 01 00 00 mov%eax,0x150(%ecx) 2e6d: 89 99 5c 01 00 00 mov%ebx,0x15c(%ecx) 2e73: ff 34 24pushl (%esp) 2e76: 8f 81 54 01 00 00 popl 0x154(%ecx) 2e7c: 89 91 58 01 00 00 mov%edx,0x158(%ecx) 2e82: 89 b1 68 01 00 00 mov%esi,0x168(%ecx) 2e88: 89 b9 6c 01 00 00 mov%edi,0x16c(%ecx) 2e8e: 89 a9 64 01 00 00 mov%ebp,0x164(%ecx) 2e94: 0f 20 d0mov%cr2,%eax 2e97: 89 81 78 01 00 00 mov%eax,0x178(%ecx) 2e9d: 8b 0c 24mov(%esp),%ecx 2ea0: 59 pop%ecx 2ea1: 61 popa 2ea2: 0f 96 c0setbe %al 2ea5: 88 83 84 0d 00 00 mov%al,0xd84(%ebx) 2eab: c7 04 24 24 48 00 00movl $0x4824,(%esp) 2eb2: e8 49 d2 ff ff call 100 vmcs_read32 second trace 2eb7: a8 03 test $0x3,%al 2eb9: 0f 94 c0sete %al 2ebc: 0f b6 c0movzbl %al,%eax 2ebf: 89 83 28 01 00 00 mov%eax,0x128(%ebx) 2ec5: b8 7b 00 00 00 mov$0x7b,%eax 2eca: 8e d8 mov%eax,%ds 2ecc: 8e c0 mov%eax,%es 2ece: c7 83 80 0d 00 00 01movl $0x1,0xd80(%ebx) 2ed5: 00 00 00 2ed8: c7 04 24 04 44 00 00movl $0x4404,(%esp) 2edf: e8 1c d2 ff ff call 100 vmcs_read32 2ee4: 25 00 07 00 00 and$0x700,%eax 2ee9: 3d 00 02 00 00 cmp$0x200,%eax 2eee: 75 02 jne2ef2 vmx_vcpu_run+0x102 2ef0: cd 02 int$0x2 2ef2: 83 c4 08add$0x8,%esp 2ef5: 5b pop%ebx 2ef6: 5d pop%ebp 2ef7: c3 ret 2ef8: 90 nop 2ef9: 8d b4 26 00 00 00 00lea0x0(%esi),%esi Note that the first, unresolved call here goes to mcount(). (the -r option to objdump is handy) Great, one never stops learning. :) Exiting on a pending interrupt is controlled by the vmcs word PIN_BASED_EXEC_CONTROL, bit PIN_BASED_EXT_INTR_MASK. Can you check (via vmcs_read32()) that the bit is indeed set? [if not, a guest can just enter a busy loop and kill a processor] I traced it right before and after the asm block, and in all cases (including those with low latency exits) it's just 0x1f, which should be fine. Earlier, I also checked GUEST_INTERRUPTIBILITY_INFO and GUEST_ACTIVITY_STATE, but found neither some suspicious state nor
[kvm-devel] [PATCH] call preempt_notifier_init early enough
As vmx_create_vcpu already makes use of start/end_special_insn, we need
to initialise the emulated preempt_notifier earlier. Let's move it to
kvm_vcpu_init. This should fix an oops I've seen here at least once
during kvm startup - so far the problem did not show up again.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
kernel/kvm_main.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: kvm-48/kernel/kvm_main.c
===
--- kvm-48.orig/kernel/kvm_main.c
+++ kvm-48/kernel/kvm_main.c
@@ -261,6 +261,8 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu,
vcpu-mp_state = VCPU_MP_STATE_UNINITIALIZED;
init_waitqueue_head(vcpu-wq);
+ preempt_notifier_init(vcpu-preempt_notifier, kvm_preempt_ops);
+
page = alloc_page(GFP_KERNEL | __GFP_ZERO);
if (!page) {
r = -ENOMEM;
@@ -2664,8 +2666,6 @@ static int kvm_vm_ioctl_create_vcpu(stru
if (IS_ERR(vcpu))
return PTR_ERR(vcpu);
- preempt_notifier_init(vcpu-preempt_notifier, kvm_preempt_ops);
-
/* We do fxsave: this must be aligned. */
BUG_ON((unsigned long)vcpu-host_fx_image 0xF);
signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] High vm-exit latencies during kvm boot-up/shutdown
Hi, I'm seeing fairly high vm-exit latencies (300-400 us) during and only during qemu/kvm startup and shutdown on a Core2 T5500 in 32-bit mode. It's most probably while the VM runs inside bios code. During the rest of the time, while some Linux guest is running, the exit latencies are within microseconds, thus perfectly fine for the real-time scenarios I have in mind. Has anyone some idea what goes on there? As those hundreds of micros precisely frame the assembly block in vmx_vcpu_run, I wonder what guest code could cause such long delays. A quick glance at the bochs bios code did not enlighten me yet. Thanks, Jan signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
