[Qemu-devel] [PATCH 08/18] kvm: Handle kvm_init_vcpu errors
From: Jan Kiszka
Do not ignore errors of kvm_init_vcpu, they are fatal.
Signed-off-by: Jan Kiszka
---
cpus.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/cpus.c b/cpus.c
index b6f1cfb..33b604e 100644
--- a/cpus.c
+++ b/cpus.c
@@ -412,14 +412,19 @@ void qemu_main_loop_start(void)
void qemu_init_vcpu(void *_env)
{
CPUState *env = _env;
+int r;
env->nr_cores = smp_cores;
env->nr_threads = smp_threads;
if (kvm_enabled()) {
kvm_init_vcpu(env);
+r = kvm_init_vcpu(env);
+if (r < 0) {
+fprintf(stderr, "kvm_init_vcpu failed: %s\n", strerror(r));
+exit(1);
+}
qemu_kvm_init_cpu_signals(env);
}
-return;
}
int qemu_cpu_self(void *env)
@@ -710,11 +715,16 @@ static int qemu_cpu_exec(CPUState *env);
static void *kvm_cpu_thread_fn(void *arg)
{
CPUState *env = arg;
+int r;
qemu_mutex_lock(&qemu_global_mutex);
qemu_thread_self(env->thread);
-kvm_init_vcpu(env);
+r = kvm_init_vcpu(env);
+if (r < 0) {
+fprintf(stderr, "kvm_init_vcpu failed: %s\n", strerror(r));
+exit(1);
+}
qemu_kvm_init_cpu_signals(env);
/* signal CPU creation */
--
1.7.1
[Qemu-devel] [PATCH 09/18] Refactor kvm&tcg function names in cpus.c
From: Jan Kiszka
Pure interface cosmetics: Ensure that only kvm core services (as
declared in kvm.h) start with "kvm_". Prepend "qemu_" to those that
violate this rule in cpus.c. Also rename the corresponding tcg functions
for the sake of consistency.
Signed-off-by: Jan Kiszka
---
cpus.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/cpus.c b/cpus.c
index 33b604e..e482fdb 100644
--- a/cpus.c
+++ b/cpus.c
@@ -712,7 +712,7 @@ static void qemu_kvm_wait_io_event(CPUState *env)
static int qemu_cpu_exec(CPUState *env);
-static void *kvm_cpu_thread_fn(void *arg)
+static void *qemu_kvm_cpu_thread_fn(void *arg)
{
CPUState *env = arg;
int r;
@@ -744,7 +744,7 @@ static void *kvm_cpu_thread_fn(void *arg)
return NULL;
}
-static void *tcg_cpu_thread_fn(void *arg)
+static void *qemu_tcg_cpu_thread_fn(void *arg)
{
CPUState *env = arg;
@@ -850,7 +850,7 @@ void resume_all_vcpus(void)
}
}
-static void tcg_init_vcpu(void *_env)
+static void qemu_tcg_init_vcpu(void *_env)
{
CPUState *env = _env;
/* share a single thread for all cpus with TCG */
@@ -858,7 +858,7 @@ static void tcg_init_vcpu(void *_env)
env->thread = qemu_mallocz(sizeof(QemuThread));
env->halt_cond = qemu_mallocz(sizeof(QemuCond));
qemu_cond_init(env->halt_cond);
-qemu_thread_create(env->thread, tcg_cpu_thread_fn, env);
+qemu_thread_create(env->thread, qemu_tcg_cpu_thread_fn, env);
while (env->created == 0)
qemu_cond_timedwait(&qemu_cpu_cond, &qemu_global_mutex, 100);
tcg_cpu_thread = env->thread;
@@ -869,12 +869,12 @@ static void tcg_init_vcpu(void *_env)
}
}
-static void kvm_start_vcpu(CPUState *env)
+static void qemu_kvm_start_vcpu(CPUState *env)
{
env->thread = qemu_mallocz(sizeof(QemuThread));
env->halt_cond = qemu_mallocz(sizeof(QemuCond));
qemu_cond_init(env->halt_cond);
-qemu_thread_create(env->thread, kvm_cpu_thread_fn, env);
+qemu_thread_create(env->thread, qemu_kvm_cpu_thread_fn, env);
while (env->created == 0)
qemu_cond_timedwait(&qemu_cpu_cond, &qemu_global_mutex, 100);
}
@@ -886,9 +886,9 @@ void qemu_init_vcpu(void *_env)
env->nr_cores = smp_cores;
env->nr_threads = smp_threads;
if (kvm_enabled())
-kvm_start_vcpu(env);
+qemu_kvm_start_vcpu(env);
else
-tcg_init_vcpu(env);
+qemu_tcg_init_vcpu(env);
}
void qemu_notify_event(void)
--
1.7.1
[Qemu-devel] [PATCH 00/18] [uq/master] MCE & IO exit fixes, prepare for VCPU loop reuse
This series has three major topics: - add required kernel reentry after IO exits - provide MCE forwarding under !CONFIG_IOTHREAD - prepare kvm_cpu_exec for qemu-kvm reuse Along these lines, several cleanups and simplifcations are applied to cpus.c and the KVM VCPU execution bits. The first patch should of course be dropped if uq/master is applied without "kvm: Drop return value of kvm_cpu_exec". Note that I did not yet to test the MCE support. Is there an easy way to trigger valid MCE events at kernel level? Or do I need to fake SIGBUS at qemu level? Jan Kiszka (18): Revert "kvm: Drop return value of kvm_cpu_exec" kvm: Drop redundant kvm_enabled from kvm_cpu_thread_fn kvm: Provide sigbus services arch-independently Refactor signal setup functions in cpus.c kvm: Set up signal mask also for !CONFIG_IOTHREAD kvm: Refactor qemu_kvm_eat_signals kvm: Add MCE signal support for !CONFIG_IOTHREAD kvm: Handle kvm_init_vcpu errors Refactor kvm&tcg function names in cpus.c Fix a few coding style violations in cpus.c Introduce VCPU self-signaling service kvm: Move irqchip event processing out of inner loop kvm: Unconditionally reenter kernel after IO exits kvm: Remove static return code of kvm_handle_io kvm: Leave kvm_cpu_exec directly after KVM_EXIT_SHUTDOWN kvm: Separate TCG from KVM cpu execution kvm: x86: Prepare VCPU loop for in-kernel irqchip kvm: Drop return values from kvm_arch_pre/post_run cpu-exec.c | 19 +-- cpus.c | 521 +++- kvm-all.c | 76 + kvm-stub.c |9 +- kvm.h | 14 +- qemu-common.h |1 + target-i386/kvm.c | 90 +- target-ppc/kvm.c | 16 ++- target-s390x/kvm.c | 16 ++- 9 files changed, 444 insertions(+), 318 deletions(-)
[Qemu-devel] [PATCH 03/18] kvm: Provide sigbus services arch-independently
From: Jan Kiszka
Provide arch-independent kvm_on_sigbus* stubs to remove the #ifdef'ery
from cpus.c. This patch also fixes --disable-kvm build by providing the
missing kvm_on_sigbus_vcpu kvm-stub.
Signed-off-by: Jan Kiszka
CC: Huang Ying
CC: Alexander Graf
---
cpus.c | 10 --
kvm-all.c | 10 ++
kvm-stub.c |5 +
kvm.h |7 +--
target-i386/kvm.c |4 ++--
target-ppc/kvm.c | 10 ++
target-s390x/kvm.c | 10 ++
7 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/cpus.c b/cpus.c
index 8af53a9..081ac30 100644
--- a/cpus.c
+++ b/cpus.c
@@ -527,10 +527,9 @@ static void sigbus_reraise(void)
static void sigbus_handler(int n, struct qemu_signalfd_siginfo *siginfo,
void *ctx)
{
-#if defined(TARGET_I386)
-if (kvm_on_sigbus(siginfo->ssi_code, (void *)(intptr_t)siginfo->ssi_addr))
-#endif
+if (kvm_on_sigbus(siginfo->ssi_code, (void *)(intptr_t)siginfo->ssi_addr))
{
sigbus_reraise();
+}
}
static void qemu_kvm_eat_signal(CPUState *env, int timeout)
@@ -563,10 +562,9 @@ static void qemu_kvm_eat_signal(CPUState *env, int timeout)
switch (r) {
case SIGBUS:
-#ifdef TARGET_I386
-if (kvm_on_sigbus_vcpu(env, siginfo.si_code, siginfo.si_addr))
-#endif
+if (kvm_on_sigbus_vcpu(env, siginfo.si_code, siginfo.si_addr)) {
sigbus_reraise();
+}
break;
default:
break;
diff --git a/kvm-all.c b/kvm-all.c
index 4ab5f5c..a8e9f2c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1284,3 +1284,13 @@ int kvm_set_ioeventfd_pio_word(int fd, uint16_t addr,
uint16_t val, bool assign)
return -ENOSYS;
#endif
}
+
+int kvm_on_sigbus_vcpu(CPUState *env, int code, void *addr)
+{
+return kvm_on_sigbus_vcpu(env, code, addr);
+}
+
+int kvm_on_sigbus(int code, void *addr)
+{
+return kvm_on_sigbus(code, addr);
+}
diff --git a/kvm-stub.c b/kvm-stub.c
index 1fcfc1e..572380c 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -142,6 +142,11 @@ int kvm_set_ioeventfd_mmio_long(int fd, uint32_t adr,
uint32_t val, bool assign)
return -ENOSYS;
}
+int kvm_on_sigbus_vcpu(CPUState *env, int code, void *addr)
+{
+return 1;
+}
+
int kvm_on_sigbus(int code, void *addr)
{
return 1;
diff --git a/kvm.h b/kvm.h
index 7bf9cc8..0a4db28 100644
--- a/kvm.h
+++ b/kvm.h
@@ -80,6 +80,9 @@ int kvm_set_signal_mask(CPUState *env, const sigset_t
*sigset);
int kvm_pit_in_kernel(void);
int kvm_irqchip_in_kernel(void);
+int kvm_on_sigbus_vcpu(CPUState *env, int code, void *addr);
+int kvm_on_sigbus(int code, void *addr);
+
/* internal API */
int kvm_ioctl(int type, ...);
@@ -117,8 +120,8 @@ int kvm_arch_init_vcpu(CPUState *env);
void kvm_arch_reset_vcpu(CPUState *env);
-int kvm_on_sigbus_vcpu(CPUState *env, int code, void *addr);
-int kvm_on_sigbus(int code, void *addr);
+int kvm_arch_on_sigbus_vcpu(CPUState *env, int code, void *addr);
+int kvm_arch_on_sigbus(int code, void *addr);
struct kvm_guest_debug;
struct kvm_debug_exit_arch;
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index af79526..a7acd53 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -1918,7 +1918,7 @@ static void kvm_mce_inj_srao_memscrub2(CPUState *env,
target_phys_addr_t paddr)
#endif
-int kvm_on_sigbus_vcpu(CPUState *env, int code, void *addr)
+int kvm_arch_on_sigbus_vcpu(CPUState *env, int code, void *addr)
{
#if defined(KVM_CAP_MCE)
void *vaddr;
@@ -1968,7 +1968,7 @@ int kvm_on_sigbus_vcpu(CPUState *env, int code, void
*addr)
return 0;
}
-int kvm_on_sigbus(int code, void *addr)
+int kvm_arch_on_sigbus(int code, void *addr)
{
#if defined(KVM_CAP_MCE)
if ((first_cpu->mcg_cap & MCG_SER_P) && addr && code == BUS_MCEERR_AO) {
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 7918426..8349045 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -404,3 +404,13 @@ bool kvm_arch_stop_on_emulation_error(CPUState *env)
{
return true;
}
+
+int kvm_arch_on_sigbus_vcpu(CPUState *env, int code, void *addr)
+{
+return 1;
+}
+
+int kvm_arch_on_sigbus(int code, void *addr)
+{
+return 1;
+}
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index 29fcd46..b7f644b 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -501,3 +501,13 @@ bool kvm_arch_stop_on_emulation_error(CPUState *env)
{
return true;
}
+
+int kvm_arch_on_sigbus_vcpu(CPUState *env, int code, void *addr)
+{
+return 1;
+}
+
+int kvm_arch_on_sigbus(int code, void *addr)
+{
+return 1;
+}
--
1.7.1
[Qemu-devel] [PATCH 04/18] Refactor signal setup functions in cpus.c
From: Jan Kiszka
Move {tcg,kvm}_init_ipi and block_io_signals to avoid prototypes, rename
the former two to clarify that they deal with more than SIG_IPI. No
functional changes.
The forward declaration of sigbus_handler is just temporarily, it will
be moved in a succeeding patch. qemu_kvm_init_cpu_signals is moved into
the !_WIN32 block as we will soon need it also for !CONFIG_IOTHREAD.
Signed-off-by: Jan Kiszka
---
cpus.c | 162 ---
1 files changed, 82 insertions(+), 80 deletions(-)
diff --git a/cpus.c b/cpus.c
index 081ac30..a21e2d6 100644
--- a/cpus.c
+++ b/cpus.c
@@ -222,7 +222,35 @@ fail:
close(fds[1]);
return err;
}
-#else
+
+#ifdef CONFIG_IOTHREAD
+static void dummy_signal(int sig)
+{
+}
+
+static void qemu_kvm_init_cpu_signals(CPUState *env)
+{
+int r;
+sigset_t set;
+struct sigaction sigact;
+
+memset(&sigact, 0, sizeof(sigact));
+sigact.sa_handler = dummy_signal;
+sigaction(SIG_IPI, &sigact, NULL);
+
+pthread_sigmask(SIG_BLOCK, NULL, &set);
+sigdelset(&set, SIG_IPI);
+sigdelset(&set, SIGBUS);
+r = kvm_set_signal_mask(env, &set);
+if (r) {
+fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(r));
+exit(1);
+}
+}
+#endif
+
+#else /* _WIN32 */
+
HANDLE qemu_event_handle;
static void dummy_event_handler(void *opaque)
@@ -248,7 +276,7 @@ static void qemu_event_increment(void)
exit (1);
}
}
-#endif
+#endif /* _WIN32 */
#ifndef CONFIG_IOTHREAD
int qemu_init_main_loop(void)
@@ -337,10 +365,6 @@ static QemuCond qemu_system_cond;
static QemuCond qemu_pause_cond;
static QemuCond qemu_work_cond;
-static void tcg_init_ipi(void);
-static void kvm_init_ipi(CPUState *env);
-static sigset_t block_io_signals(void);
-
/* If we have signalfd, we mask out the signals we want to handle and then
* use signalfd to listen for them. We rely on whatever the current signal
* handler is to dispatch the signals when we receive them.
@@ -376,6 +400,56 @@ static void sigfd_handler(void *opaque)
}
}
+static void cpu_signal(int sig)
+{
+if (cpu_single_env)
+cpu_exit(cpu_single_env);
+exit_request = 1;
+}
+
+static void qemu_tcg_init_cpu_signals(void)
+{
+sigset_t set;
+struct sigaction sigact;
+
+memset(&sigact, 0, sizeof(sigact));
+sigact.sa_handler = cpu_signal;
+sigaction(SIG_IPI, &sigact, NULL);
+
+sigemptyset(&set);
+sigaddset(&set, SIG_IPI);
+pthread_sigmask(SIG_UNBLOCK, &set, NULL);
+}
+
+static void sigbus_handler(int n, struct qemu_signalfd_siginfo *siginfo,
+ void *ctx);
+
+static sigset_t block_io_signals(void)
+{
+sigset_t set;
+struct sigaction action;
+
+/* SIGUSR2 used by posix-aio-compat.c */
+sigemptyset(&set);
+sigaddset(&set, SIGUSR2);
+pthread_sigmask(SIG_UNBLOCK, &set, NULL);
+
+sigemptyset(&set);
+sigaddset(&set, SIGIO);
+sigaddset(&set, SIGALRM);
+sigaddset(&set, SIG_IPI);
+sigaddset(&set, SIGBUS);
+pthread_sigmask(SIG_BLOCK, &set, NULL);
+
+memset(&action, 0, sizeof(action));
+action.sa_flags = SA_SIGINFO;
+action.sa_sigaction = (void (*)(int, siginfo_t*, void*))sigbus_handler;
+sigaction(SIGBUS, &action, NULL);
+prctl(PR_MCE_KILL, 1, 1, 0, 0);
+
+return set;
+}
+
static int qemu_signalfd_init(sigset_t mask)
{
int sigfd;
@@ -597,8 +671,7 @@ static void *kvm_cpu_thread_fn(void *arg)
qemu_thread_self(env->thread);
kvm_init_vcpu(env);
-
-kvm_init_ipi(env);
+qemu_kvm_init_cpu_signals(env);
/* signal CPU creation */
env->created = 1;
@@ -621,7 +694,7 @@ static void *tcg_cpu_thread_fn(void *arg)
{
CPUState *env = arg;
-tcg_init_ipi();
+qemu_tcg_init_cpu_signals();
qemu_thread_self(env->thread);
/* signal CPU creation */
@@ -659,77 +732,6 @@ int qemu_cpu_self(void *_env)
return qemu_thread_equal(&this, env->thread);
}
-static void cpu_signal(int sig)
-{
-if (cpu_single_env)
-cpu_exit(cpu_single_env);
-exit_request = 1;
-}
-
-static void tcg_init_ipi(void)
-{
-sigset_t set;
-struct sigaction sigact;
-
-memset(&sigact, 0, sizeof(sigact));
-sigact.sa_handler = cpu_signal;
-sigaction(SIG_IPI, &sigact, NULL);
-
-sigemptyset(&set);
-sigaddset(&set, SIG_IPI);
-pthread_sigmask(SIG_UNBLOCK, &set, NULL);
-}
-
-static void dummy_signal(int sig)
-{
-}
-
-static void kvm_init_ipi(CPUState *env)
-{
-int r;
-sigset_t set;
-struct sigaction sigact;
-
-memset(&sigact, 0, sizeof(sigact));
-sigact.sa_handler = dummy_signal;
-sigaction(SIG_IPI, &sigact, NULL);
-
-pthread_sigmask(SIG_BLOCK, NULL, &set);
-sigdelset(&set, SIG_IPI);
-sigdelset(&set, SIGBUS);
-r = kvm_set_signal_mask(env, &set);
-if (r) {
-fprintf(stderr, "kvm_set_signal_mask: %s\n", strerror(r));
-exit(1);
-}
-}
-
-static sigset_t block_io_signals(void)
-{
-
[Qemu-devel] [PATCH 06/18] kvm: Refactor qemu_kvm_eat_signals
From: Jan Kiszka
We do not use the timeout, so drop its logic. As we always poll our
signals, we do not need to drop the global lock. Removing those calls
allows some further simplifications. Also fix the error processing of
sigpending at this chance.
Signed-off-by: Jan Kiszka
---
cpus.c | 23 +++
1 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/cpus.c b/cpus.c
index bf0fb85..6da0f8f 100644
--- a/cpus.c
+++ b/cpus.c
@@ -617,31 +617,22 @@ static void sigbus_handler(int n, struct
qemu_signalfd_siginfo *siginfo,
}
}
-static void qemu_kvm_eat_signal(CPUState *env, int timeout)
+static void qemu_kvm_eat_signals(CPUState *env)
{
-struct timespec ts;
-int r, e;
+struct timespec ts = { 0, 0 };
siginfo_t siginfo;
sigset_t waitset;
sigset_t chkset;
-
-ts.tv_sec = timeout / 1000;
-ts.tv_nsec = (timeout % 1000) * 100;
+int r;
sigemptyset(&waitset);
sigaddset(&waitset, SIG_IPI);
sigaddset(&waitset, SIGBUS);
do {
-qemu_mutex_unlock(&qemu_global_mutex);
-
r = sigtimedwait(&waitset, &siginfo, &ts);
-e = errno;
-
-qemu_mutex_lock(&qemu_global_mutex);
-
-if (r == -1 && !(e == EAGAIN || e == EINTR)) {
-fprintf(stderr, "sigtimedwait: %s\n", strerror(e));
+if (r == -1 && !(errno == EAGAIN || errno == EINTR)) {
+perror("sigtimedwait");
exit(1);
}
@@ -657,7 +648,7 @@ static void qemu_kvm_eat_signal(CPUState *env, int timeout)
r = sigpending(&chkset);
if (r == -1) {
-fprintf(stderr, "sigpending: %s\n", strerror(e));
+perror("sigpending");
exit(1);
}
} while (sigismember(&chkset, SIG_IPI) || sigismember(&chkset, SIGBUS));
@@ -668,7 +659,7 @@ static void qemu_kvm_wait_io_event(CPUState *env)
while (!cpu_has_work(env))
qemu_cond_timedwait(env->halt_cond, &qemu_global_mutex, 1000);
-qemu_kvm_eat_signal(env, 0);
+qemu_kvm_eat_signals(env);
qemu_wait_io_event_common(env);
}
--
1.7.1
[Qemu-devel] [PATCH 17/18] kvm: x86: Prepare VCPU loop for in-kernel irqchip
From: Jan Kiszka
Effectively no functional change yet as kvm_irqchip_in_kernel still only
returns 0, but this patch will allow qemu-kvm to adopt the VCPU loop of
upsteam KVM.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c | 78 -
1 files changed, 41 insertions(+), 37 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 16dacb8..da7482f 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -1515,35 +1515,38 @@ int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
kvm_vcpu_ioctl(env, KVM_NMI);
}
-/* Try to inject an interrupt if the guest can accept it */
-if (run->ready_for_interrupt_injection &&
-(env->interrupt_request & CPU_INTERRUPT_HARD) &&
-(env->eflags & IF_MASK)) {
-int irq;
-
-env->interrupt_request &= ~CPU_INTERRUPT_HARD;
-irq = cpu_get_pic_interrupt(env);
-if (irq >= 0) {
-struct kvm_interrupt intr;
-intr.irq = irq;
-/* FIXME: errors */
-DPRINTF("injected interrupt %d\n", irq);
-kvm_vcpu_ioctl(env, KVM_INTERRUPT, &intr);
+if (!kvm_irqchip_in_kernel()) {
+/* Try to inject an interrupt if the guest can accept it */
+if (run->ready_for_interrupt_injection &&
+(env->interrupt_request & CPU_INTERRUPT_HARD) &&
+(env->eflags & IF_MASK)) {
+int irq;
+
+env->interrupt_request &= ~CPU_INTERRUPT_HARD;
+irq = cpu_get_pic_interrupt(env);
+if (irq >= 0) {
+struct kvm_interrupt intr;
+
+intr.irq = irq;
+/* FIXME: errors */
+DPRINTF("injected interrupt %d\n", irq);
+kvm_vcpu_ioctl(env, KVM_INTERRUPT, &intr);
+}
}
-}
-/* If we have an interrupt but the guest is not ready to receive an
- * interrupt, request an interrupt window exit. This will
- * cause a return to userspace as soon as the guest is ready to
- * receive interrupts. */
-if ((env->interrupt_request & CPU_INTERRUPT_HARD)) {
-run->request_interrupt_window = 1;
-} else {
-run->request_interrupt_window = 0;
-}
+/* If we have an interrupt but the guest is not ready to receive an
+ * interrupt, request an interrupt window exit. This will
+ * cause a return to userspace as soon as the guest is ready to
+ * receive interrupts. */
+if ((env->interrupt_request & CPU_INTERRUPT_HARD)) {
+run->request_interrupt_window = 1;
+} else {
+run->request_interrupt_window = 0;
+}
-DPRINTF("setting tpr\n");
-run->cr8 = cpu_get_apic_tpr(env->apic_state);
+DPRINTF("setting tpr\n");
+run->cr8 = cpu_get_apic_tpr(env->apic_state);
+}
return 0;
}
@@ -1563,18 +1566,19 @@ int kvm_arch_post_run(CPUState *env, struct kvm_run
*run)
int kvm_arch_process_irqchip_events(CPUState *env)
{
-if (env->interrupt_request & (CPU_INTERRUPT_HARD | CPU_INTERRUPT_NMI)) {
-env->halted = 0;
-}
-if (env->interrupt_request & CPU_INTERRUPT_INIT) {
-kvm_cpu_synchronize_state(env);
-do_cpu_init(env);
-}
-if (env->interrupt_request & CPU_INTERRUPT_SIPI) {
-kvm_cpu_synchronize_state(env);
-do_cpu_sipi(env);
+if (!kvm_irqchip_in_kernel()) {
+if (env->interrupt_request & (CPU_INTERRUPT_HARD | CPU_INTERRUPT_NMI))
{
+env->halted = 0;
+}
+if (env->interrupt_request & CPU_INTERRUPT_INIT) {
+kvm_cpu_synchronize_state(env);
+do_cpu_init(env);
+}
+if (env->interrupt_request & CPU_INTERRUPT_SIPI) {
+kvm_cpu_synchronize_state(env);
+do_cpu_sipi(env);
+}
}
-
return env->halted;
}
--
1.7.1
[Qemu-devel] [PATCH 10/18] Fix a few coding style violations in cpus.c
From: Jan Kiszka
No functional changes.
Signed-off-by: Jan Kiszka
---
cpus.c | 96 ++-
1 files changed, 58 insertions(+), 38 deletions(-)
diff --git a/cpus.c b/cpus.c
index e482fdb..89b4bd7 100644
--- a/cpus.c
+++ b/cpus.c
@@ -130,25 +130,26 @@ static void do_vm_stop(int reason)
static int cpu_can_run(CPUState *env)
{
-if (env->stop)
+if (env->stop) {
return 0;
-if (env->stopped || !vm_running)
+}
+if (env->stopped || !vm_running) {
return 0;
+}
return 1;
}
static int cpu_has_work(CPUState *env)
{
-if (env->stop)
+if (env->stop || env->queued_work_first) {
return 1;
-if (env->queued_work_first)
-return 1;
-if (env->stopped || !vm_running)
+}
+if (env->stopped || !vm_running) {
return 0;
-if (!env->halted)
-return 1;
-if (qemu_cpu_has_work(env))
+}
+if (!env->halted || qemu_cpu_has_work(env)) {
return 1;
+}
return 0;
}
@@ -156,9 +157,11 @@ static int any_cpu_has_work(void)
{
CPUState *env;
-for (env = first_cpu; env != NULL; env = env->next_cpu)
-if (cpu_has_work(env))
+for (env = first_cpu; env != NULL; env = env->next_cpu) {
+if (cpu_has_work(env)) {
return 1;
+}
+}
return 0;
}
@@ -234,9 +237,9 @@ static void qemu_event_increment(void)
static const uint64_t val = 1;
ssize_t ret;
-if (io_thread_fd == -1)
+if (io_thread_fd == -1) {
return;
-
+}
do {
ret = write(io_thread_fd, &val, sizeof(val));
} while (ret < 0 && errno == EINTR);
@@ -267,17 +270,17 @@ static int qemu_event_init(void)
int fds[2];
err = qemu_eventfd(fds);
-if (err == -1)
+if (err == -1) {
return -errno;
-
+}
err = fcntl_setfl(fds[0], O_NONBLOCK);
-if (err < 0)
+if (err < 0) {
goto fail;
-
+}
err = fcntl_setfl(fds[1], O_NONBLOCK);
-if (err < 0)
+if (err < 0) {
goto fail;
-
+}
qemu_set_fd_handler2(fds[0], NULL, qemu_event_read, NULL,
(void *)(unsigned long)fds[0]);
@@ -598,13 +601,15 @@ int qemu_init_main_loop(void)
blocked_signals = block_io_signals();
ret = qemu_signalfd_init(blocked_signals);
-if (ret)
+if (ret) {
return ret;
+}
/* Note eventfd must be drained before signalfd handlers run */
ret = qemu_event_init();
-if (ret)
+if (ret) {
return ret;
+}
qemu_cond_init(&qemu_pause_cond);
qemu_cond_init(&qemu_system_cond);
@@ -634,10 +639,11 @@ void run_on_cpu(CPUState *env, void (*func)(void *data),
void *data)
wi.func = func;
wi.data = data;
-if (!env->queued_work_first)
+if (!env->queued_work_first) {
env->queued_work_first = &wi;
-else
+} else {
env->queued_work_last->next = &wi;
+}
env->queued_work_last = &wi;
wi.next = NULL;
wi.done = false;
@@ -655,8 +661,9 @@ static void flush_queued_work(CPUState *env)
{
struct qemu_work_item *wi;
-if (!env->queued_work_first)
+if (!env->queued_work_first) {
return;
+}
while ((wi = env->queued_work_first)) {
env->queued_work_first = wi->next;
@@ -681,8 +688,9 @@ static void qemu_tcg_wait_io_event(void)
{
CPUState *env;
-while (!any_cpu_has_work())
+while (!any_cpu_has_work()) {
qemu_cond_timedwait(tcg_halt_cond, &qemu_global_mutex, 1000);
+}
qemu_mutex_unlock(&qemu_global_mutex);
@@ -703,9 +711,9 @@ static void qemu_tcg_wait_io_event(void)
static void qemu_kvm_wait_io_event(CPUState *env)
{
-while (!cpu_has_work(env))
+while (!cpu_has_work(env)) {
qemu_cond_timedwait(env->halt_cond, &qemu_global_mutex, 1000);
-
+}
qemu_kvm_eat_signals(env);
qemu_wait_io_event_common(env);
}
@@ -732,12 +740,14 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
qemu_cond_signal(&qemu_cpu_cond);
/* and wait for machine initialization */
-while (!qemu_system_ready)
+while (!qemu_system_ready) {
qemu_cond_timedwait(&qemu_system_cond, &qemu_global_mutex, 100);
+}
while (1) {
-if (cpu_can_run(env))
+if (cpu_can_run(env)) {
qemu_cpu_exec(env);
+}
qemu_kvm_wait_io_event(env);
}
@@ -753,13 +763,15 @@ static void *qemu_tcg_cpu_thread_fn(void *arg)
/* signal CPU creation */
qemu_mutex_lock(&qemu_global_mutex);
-for (env = first_cpu; env != NULL; env = env->next_cpu)
+for (env = first_cpu; env != NULL; env = env->next_cpu) {
env->created = 1;
+}
qemu_cond_signal(&qemu_cpu_cond);
/* and wait for machine initialization */
-while (!qemu_system_ready)
+while (!qemu_system_ready) {
qemu_cond_timedwait(&qemu_system_cond, &qemu_global_mutex, 100);
+}
while (1) {
c
[Qemu-devel] [PATCH 15/18] kvm: Leave kvm_cpu_exec directly after KVM_EXIT_SHUTDOWN
From: Jan Kiszka
The reset we issue on KVM_EXIT_SHUTDOWN implies that we should also
leave the VCPU loop. As we now check for exit_request which is set by
qemu_system_reset_request, this bug is no longer critical. Still it's an
unneeded extra turn.
Signed-off-by: Jan Kiszka
---
kvm-all.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index fb4d73e..0abe088 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -891,7 +891,6 @@ int kvm_cpu_exec(CPUState *env)
case KVM_EXIT_SHUTDOWN:
DPRINTF("shutdown\n");
qemu_system_reset_request();
-ret = 1;
break;
case KVM_EXIT_UNKNOWN:
fprintf(stderr, "KVM: unknown exit, hardware reason %" PRIx64 "\n",
--
1.7.1
[Qemu-devel] [PATCH 13/18] kvm: Unconditionally reenter kernel after IO exits
From: Jan Kiszka
KVM requires to reenter the kernel after IO exits in order to complete
instruction emulation. Failing to do so will leave the kernel state
inconsistently behind. To ensure that we will get back ASAP, we issue a
self-signal that will cause KVM_RUN to return once the pending
operations are completed.
This patch also fixes the missing exit_request check in kvm_cpu_exec in
the CONFIG_IOTHREAD case.
Signed-off-by: Jan Kiszka
CC: Gleb Natapov
---
kvm-all.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index f3c8375..429ab7a 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -188,7 +188,6 @@ int kvm_pit_in_kernel(void)
return kvm_state.pit_in_kernel;
}
-
int kvm_init_vcpu(CPUState *env)
{
long mmap_size;
@@ -831,23 +830,26 @@ int kvm_cpu_exec(CPUState *env)
}
do {
-#ifndef CONFIG_IOTHREAD
-if (env->exit_request) {
-DPRINTF("interrupt exit requested\n");
-ret = 0;
-break;
-}
-#endif
-
if (env->kvm_vcpu_dirty) {
kvm_arch_put_registers(env, KVM_PUT_RUNTIME_STATE);
env->kvm_vcpu_dirty = 0;
}
kvm_arch_pre_run(env, run);
+if (env->exit_request) {
+DPRINTF("interrupt exit requested\n");
+/*
+ * KVM requires us to reenter the kernel after IO exits to complete
+ * instruction emulation. This self-signal will ensure that we
+ * leave ASAP again.
+ */
+qemu_cpu_kick_self();
+}
cpu_single_env = NULL;
qemu_mutex_unlock_iothread();
+
ret = kvm_vcpu_ioctl(env, KVM_RUN, 0);
+
qemu_mutex_lock_iothread();
cpu_single_env = env;
kvm_arch_post_run(env, run);
--
1.7.1
[Qemu-devel] [PATCH 02/18] kvm: Drop redundant kvm_enabled from kvm_cpu_thread_fn
From: Jan Kiszka Signed-off-by: Jan Kiszka --- cpus.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cpus.c b/cpus.c index 4c9928e..8af53a9 100644 --- a/cpus.c +++ b/cpus.c @@ -597,8 +597,8 @@ static void *kvm_cpu_thread_fn(void *arg) qemu_mutex_lock(&qemu_global_mutex); qemu_thread_self(env->thread); -if (kvm_enabled()) -kvm_init_vcpu(env); + +kvm_init_vcpu(env); kvm_init_ipi(env); -- 1.7.1
[Qemu-devel] [PATCH 05/18] kvm: Set up signal mask also for !CONFIG_IOTHREAD
From: Jan Kiszka
Block SIG_IPI and SIGBUS, unblock them during KVM_RUN, just like in
io-thread mode. This will be required to process SIGBUS and for
self-IPIs. As Windows doesn't support signal services, we need to
provide a stub for the init function.
Signed-off-by: Jan Kiszka
---
cpus.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/cpus.c b/cpus.c
index a21e2d6..bf0fb85 100644
--- a/cpus.c
+++ b/cpus.c
@@ -223,7 +223,6 @@ fail:
return err;
}
-#ifdef CONFIG_IOTHREAD
static void dummy_signal(int sig)
{
}
@@ -238,6 +237,13 @@ static void qemu_kvm_init_cpu_signals(CPUState *env)
sigact.sa_handler = dummy_signal;
sigaction(SIG_IPI, &sigact, NULL);
+#ifndef CONFIG_IOTHREAD
+sigemptyset(&set);
+sigaddset(&set, SIG_IPI);
+sigaddset(&set, SIGBUS);
+pthread_sigmask(SIG_BLOCK, &set, NULL);
+#endif
+
pthread_sigmask(SIG_BLOCK, NULL, &set);
sigdelset(&set, SIG_IPI);
sigdelset(&set, SIGBUS);
@@ -247,7 +253,6 @@ static void qemu_kvm_init_cpu_signals(CPUState *env)
exit(1);
}
}
-#endif
#else /* _WIN32 */
@@ -276,6 +281,10 @@ static void qemu_event_increment(void)
exit (1);
}
}
+
+static void qemu_kvm_init_cpu_signals(CPUState *env)
+{
+}
#endif /* _WIN32 */
#ifndef CONFIG_IOTHREAD
@@ -296,8 +305,10 @@ void qemu_init_vcpu(void *_env)
env->nr_cores = smp_cores;
env->nr_threads = smp_threads;
-if (kvm_enabled())
+if (kvm_enabled()) {
kvm_init_vcpu(env);
+qemu_kvm_init_cpu_signals(env);
+}
return;
}
--
1.7.1
[Qemu-devel] [PATCH 18/18] kvm: Drop return values from kvm_arch_pre/post_run
From: Jan Kiszka
We do not check them, and the only arch with non-empty implementations
always returns 0 (this is also true for qemu-kvm).
Signed-off-by: Jan Kiszka
CC: Alexander Graf
---
kvm.h |5 ++---
target-i386/kvm.c |8 ++--
target-ppc/kvm.c |6 ++
target-s390x/kvm.c |6 ++
4 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/kvm.h b/kvm.h
index 0a4db28..80c54bc 100644
--- a/kvm.h
+++ b/kvm.h
@@ -95,12 +95,11 @@ int kvm_vcpu_ioctl(CPUState *env, int type, ...);
extern const KVMCapabilityInfo kvm_arch_required_capabilities[];
-int kvm_arch_post_run(CPUState *env, struct kvm_run *run);
+void kvm_arch_pre_run(CPUState *env, struct kvm_run *run);
+void kvm_arch_post_run(CPUState *env, struct kvm_run *run);
int kvm_arch_handle_exit(CPUState *env, struct kvm_run *run);
-int kvm_arch_pre_run(CPUState *env, struct kvm_run *run);
-
int kvm_arch_process_irqchip_events(CPUState *env);
int kvm_arch_get_registers(CPUState *env);
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index da7482f..214b1bc 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -1506,7 +1506,7 @@ int kvm_arch_get_registers(CPUState *env)
return 0;
}
-int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
+void kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
{
/* Inject NMI */
if (env->interrupt_request & CPU_INTERRUPT_NMI) {
@@ -1547,11 +1547,9 @@ int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
DPRINTF("setting tpr\n");
run->cr8 = cpu_get_apic_tpr(env->apic_state);
}
-
-return 0;
}
-int kvm_arch_post_run(CPUState *env, struct kvm_run *run)
+void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
{
if (run->if_flag) {
env->eflags |= IF_MASK;
@@ -1560,8 +1558,6 @@ int kvm_arch_post_run(CPUState *env, struct kvm_run *run)
}
cpu_set_apic_tpr(env->apic_state, run->cr8);
cpu_set_apic_base(env->apic_state, run->apic_base);
-
-return 0;
}
int kvm_arch_process_irqchip_events(CPUState *env)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 8349045..e885f8d 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -256,14 +256,12 @@ int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
return 0;
}
-int kvm_arch_post_run(CPUState *env, struct kvm_run *run)
+void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
{
-return 0;
}
-int kvm_arch_process_irqchip_events(CPUState *env)
+void kvm_arch_process_irqchip_events(CPUState *env)
{
-return 0;
}
static int kvmppc_handle_halt(CPUState *env)
diff --git a/target-s390x/kvm.c b/target-s390x/kvm.c
index b7f644b..6f316df 100644
--- a/target-s390x/kvm.c
+++ b/target-s390x/kvm.c
@@ -169,14 +169,12 @@ int kvm_arch_remove_sw_breakpoint(CPUState *env, struct
kvm_sw_breakpoint *bp)
return 0;
}
-int kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
+void kvm_arch_pre_run(CPUState *env, struct kvm_run *run)
{
-return 0;
}
-int kvm_arch_post_run(CPUState *env, struct kvm_run *run)
+void kvm_arch_post_run(CPUState *env, struct kvm_run *run)
{
-return 0;
}
int kvm_arch_process_irqchip_events(CPUState *env)
--
1.7.1
[Qemu-devel] [PATCH 01/18] Revert "kvm: Drop return value of kvm_cpu_exec"
From: Jan Kiszka
This reverts commit e60806755e2b74a34813c73ec61c33d38d102286.
---
kvm-all.c |6 --
kvm-stub.c |4 ++--
kvm.h |2 +-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index a5e9246..4ab5f5c 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -817,7 +817,7 @@ void kvm_cpu_synchronize_post_init(CPUState *env)
env->kvm_vcpu_dirty = 0;
}
-void kvm_cpu_exec(CPUState *env)
+int kvm_cpu_exec(CPUState *env)
{
struct kvm_run *run = env->kvm_run;
int ret;
@@ -906,7 +906,7 @@ void kvm_cpu_exec(CPUState *env)
#ifdef KVM_CAP_SET_GUEST_DEBUG
if (kvm_arch_debug(&run->debug.arch)) {
env->exception_index = EXCP_DEBUG;
-return;
+return 0;
}
/* re-enter, this exception was guest-internal */
ret = 1;
@@ -928,6 +928,8 @@ void kvm_cpu_exec(CPUState *env)
env->exit_request = 0;
env->exception_index = EXCP_INTERRUPT;
}
+
+return ret;
}
int kvm_ioctl(int type, ...)
diff --git a/kvm-stub.c b/kvm-stub.c
index e00d7df..1fcfc1e 100644
--- a/kvm-stub.c
+++ b/kvm-stub.c
@@ -79,9 +79,9 @@ void kvm_cpu_synchronize_post_init(CPUState *env)
{
}
-void kvm_cpu_exec(CPUState *env)
+int kvm_cpu_exec(CPUState *env)
{
-abort();
+abort ();
}
int kvm_has_sync_mmu(void)
diff --git a/kvm.h b/kvm.h
index 153d7b9..7bf9cc8 100644
--- a/kvm.h
+++ b/kvm.h
@@ -54,7 +54,7 @@ int kvm_has_xcrs(void);
#ifdef NEED_CPU_H
int kvm_init_vcpu(CPUState *env);
-void kvm_cpu_exec(CPUState *env);
+int kvm_cpu_exec(CPUState *env);
#if !defined(CONFIG_USER_ONLY)
int kvm_log_start(target_phys_addr_t phys_addr, ram_addr_t size);
--
1.7.1
[Qemu-devel] [PATCH 11/18] Introduce VCPU self-signaling service
From: Jan Kiszka
Introduce qemu_cpu_kick_self to send SIG_IPI to the calling VCPU
context. First user will be kvm.
Signed-off-by: Jan Kiszka
---
cpus.c| 19 ++-
qemu-common.h |1 +
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/cpus.c b/cpus.c
index 89b4bd7..4a4d130 100644
--- a/cpus.c
+++ b/cpus.c
@@ -450,7 +450,17 @@ void pause_all_vcpus(void)
void qemu_cpu_kick(void *env)
{
-return;
+}
+
+void qemu_cpu_kick_self(void)
+{
+#ifndef _WIN32
+assert(cpu_single_env);
+
+raise(SIG_IPI);
+#else
+abort();
+#endif
}
void qemu_notify_event(void)
@@ -789,6 +799,13 @@ void qemu_cpu_kick(void *_env)
qemu_thread_signal(env->thread, SIG_IPI);
}
+void qemu_cpu_kick_self(void)
+{
+assert(cpu_single_env);
+
+qemu_thread_signal(cpu_single_env->thread, SIG_IPI);
+}
+
int qemu_cpu_self(void *_env)
{
CPUState *env = _env;
diff --git a/qemu-common.h b/qemu-common.h
index 63d9943..220c8c8 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -287,6 +287,7 @@ void qemu_notify_event(void);
/* Unblock cpu */
void qemu_cpu_kick(void *env);
+void qemu_cpu_kick_self(void);
int qemu_cpu_self(void *env);
/* work queue */
--
1.7.1
[Qemu-devel] [PATCH 07/18] kvm: Add MCE signal support for !CONFIG_IOTHREAD
From: Jan Kiszka
Currently, we only configure and process MCE-related SIGBUS events if
CONFIG_IOTHREAD is enabled. Fix this by factoring out the required
handler registration and system configuration. Make sure that events
happening over a VCPU context in non-threaded mode get dispatched as
VCPU MCEs.
We also need to call qemu_kvm_eat_signals in non-threaded mode now, so
move it (unmodified) and add the required Windows stub.
Signed-off-by: Jan Kiszka
CC: Huang Ying
---
cpus.c | 200 +++
1 files changed, 124 insertions(+), 76 deletions(-)
diff --git a/cpus.c b/cpus.c
index 6da0f8f..b6f1cfb 100644
--- a/cpus.c
+++ b/cpus.c
@@ -34,9 +34,6 @@
#include "cpus.h"
#include "compatfd.h"
-#ifdef CONFIG_LINUX
-#include
-#endif
#ifdef SIGRTMIN
#define SIG_IPI (SIGRTMIN+4)
@@ -44,10 +41,24 @@
#define SIG_IPI SIGUSR1
#endif
+#ifdef CONFIG_LINUX
+
+#include
+
#ifndef PR_MCE_KILL
#define PR_MCE_KILL 33
#endif
+#ifndef PR_MCE_KILL_SET
+#define PR_MCE_KILL_SET 1
+#endif
+
+#ifndef PR_MCE_KILL_EARLY
+#define PR_MCE_KILL_EARLY 1
+#endif
+
+#endif /* CONFIG_LINUX */
+
static CPUState *next_cpu;
/***/
@@ -158,6 +169,62 @@ static void cpu_debug_handler(CPUState *env)
vm_stop(EXCP_DEBUG);
}
+#ifdef CONFIG_LINUX
+static void sigbus_reraise(void)
+{
+sigset_t set;
+struct sigaction action;
+
+memset(&action, 0, sizeof(action));
+action.sa_handler = SIG_DFL;
+if (!sigaction(SIGBUS, &action, NULL)) {
+raise(SIGBUS);
+sigemptyset(&set);
+sigaddset(&set, SIGBUS);
+sigprocmask(SIG_UNBLOCK, &set, NULL);
+}
+perror("Failed to re-raise SIGBUS!\n");
+abort();
+}
+
+static void sigbus_handler(int n, struct qemu_signalfd_siginfo *siginfo,
+ void *ctx)
+{
+#ifndef CONFIG_IOTHREAD
+if (cpu_single_env) {
+if (kvm_on_sigbus_vcpu(cpu_single_env, siginfo->ssi_code,
+ (void *)(intptr_t)siginfo->ssi_addr)) {
+sigbus_reraise();
+}
+return;
+}
+#endif
+
+if (kvm_on_sigbus(siginfo->ssi_code,
+ (void *)(intptr_t)siginfo->ssi_addr)) {
+sigbus_reraise();
+}
+}
+
+static void qemu_init_sigbus(void)
+{
+struct sigaction action;
+
+memset(&action, 0, sizeof(action));
+action.sa_flags = SA_SIGINFO;
+action.sa_sigaction = (void (*)(int, siginfo_t*, void*))sigbus_handler;
+sigaction(SIGBUS, &action, NULL);
+
+prctl(PR_MCE_KILL, PR_MCE_KILL_SET, PR_MCE_KILL_EARLY, 0, 0);
+}
+
+#else /* !CONFIG_LINUX */
+
+static void qemu_init_sigbus(void)
+{
+}
+#endif /* !CONFIG_LINUX */
+
#ifndef _WIN32
static int io_thread_fd = -1;
@@ -254,6 +321,43 @@ static void qemu_kvm_init_cpu_signals(CPUState *env)
}
}
+static void qemu_kvm_eat_signals(CPUState *env)
+{
+struct timespec ts = { 0, 0 };
+siginfo_t siginfo;
+sigset_t waitset;
+sigset_t chkset;
+int r;
+
+sigemptyset(&waitset);
+sigaddset(&waitset, SIG_IPI);
+sigaddset(&waitset, SIGBUS);
+
+do {
+r = sigtimedwait(&waitset, &siginfo, &ts);
+if (r == -1 && !(errno == EAGAIN || errno == EINTR)) {
+perror("sigtimedwait");
+exit(1);
+}
+
+switch (r) {
+case SIGBUS:
+if (kvm_on_sigbus_vcpu(env, siginfo.si_code, siginfo.si_addr)) {
+sigbus_reraise();
+}
+break;
+default:
+break;
+}
+
+r = sigpending(&chkset);
+if (r == -1) {
+perror("sigpending");
+exit(1);
+}
+} while (sigismember(&chkset, SIG_IPI) || sigismember(&chkset, SIGBUS));
+}
+
#else /* _WIN32 */
HANDLE qemu_event_handle;
@@ -285,6 +389,10 @@ static void qemu_event_increment(void)
static void qemu_kvm_init_cpu_signals(CPUState *env)
{
}
+
+static void qemu_kvm_eat_signals(CPUState *env)
+{
+}
#endif /* _WIN32 */
#ifndef CONFIG_IOTHREAD
@@ -292,6 +400,8 @@ int qemu_init_main_loop(void)
{
cpu_set_debug_excp_handler(cpu_debug_handler);
+qemu_init_sigbus();
+
return qemu_event_init();
}
@@ -432,13 +542,9 @@ static void qemu_tcg_init_cpu_signals(void)
pthread_sigmask(SIG_UNBLOCK, &set, NULL);
}
-static void sigbus_handler(int n, struct qemu_signalfd_siginfo *siginfo,
- void *ctx);
-
static sigset_t block_io_signals(void)
{
sigset_t set;
-struct sigaction action;
/* SIGUSR2 used by posix-aio-compat.c */
sigemptyset(&set);
@@ -449,15 +555,11 @@ static sigset_t block_io_signals(void)
sigaddset(&set, SIGIO);
sigaddset(&set, SIGALRM);
sigaddset(&set, SIG_IPI);
+#ifdef CONFIG_LINUX
sigaddset(&set, SIGBUS);
+#endif
pthread_sigmask(SIG_BLOCK, &set, NULL);
-memset(&action, 0, sizeof(action));
-action.sa_flags = SA_SIGINFO;
-action.sa_sigaction =
[Qemu-devel] [PATCH 14/18] kvm: Remove static return code of kvm_handle_io
From: Jan Kiszka
Improve the readability of the exit dispatcher by moving the static
return value of kvm_handle_io to its caller.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 429ab7a..fb4d73e 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -703,8 +703,8 @@ err:
return ret;
}
-static int kvm_handle_io(uint16_t port, void *data, int direction, int size,
- uint32_t count)
+static void kvm_handle_io(uint16_t port, void *data, int direction, int size,
+ uint32_t count)
{
int i;
uint8_t *ptr = data;
@@ -738,8 +738,6 @@ static int kvm_handle_io(uint16_t port, void *data, int
direction, int size,
ptr += size;
}
-
-return 1;
}
#ifdef KVM_CAP_INTERNAL_ERROR_DATA
@@ -872,11 +870,12 @@ int kvm_cpu_exec(CPUState *env)
switch (run->exit_reason) {
case KVM_EXIT_IO:
DPRINTF("handle_io\n");
-ret = kvm_handle_io(run->io.port,
-(uint8_t *)run + run->io.data_offset,
-run->io.direction,
-run->io.size,
-run->io.count);
+kvm_handle_io(run->io.port,
+ (uint8_t *)run + run->io.data_offset,
+ run->io.direction,
+ run->io.size,
+ run->io.count);
+ret = 1;
break;
case KVM_EXIT_MMIO:
DPRINTF("handle_mmio\n");
--
1.7.1
[Qemu-devel] [PATCH 12/18] kvm: Move irqchip event processing out of inner loop
From: Jan Kiszka
Align with qemu-kvm and prepare for IO exit fix: There is no need to run
kvm_arch_process_irqchip_events in the inner VCPU loop. Any state change
this service processes will first cause an exit from kvm_cpu_exec
anyway. And we will have to reenter the kernel on IO exits
unconditionally, something that the current logic prevents.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index a8e9f2c..f3c8375 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -824,6 +824,12 @@ int kvm_cpu_exec(CPUState *env)
DPRINTF("kvm_cpu_exec()\n");
+if (kvm_arch_process_irqchip_events(env)) {
+env->exit_request = 0;
+env->exception_index = EXCP_HLT;
+return 0;
+}
+
do {
#ifndef CONFIG_IOTHREAD
if (env->exit_request) {
@@ -833,11 +839,6 @@ int kvm_cpu_exec(CPUState *env)
}
#endif
-if (kvm_arch_process_irqchip_events(env)) {
-ret = 0;
-break;
-}
-
if (env->kvm_vcpu_dirty) {
kvm_arch_put_registers(env, KVM_PUT_RUNTIME_STATE);
env->kvm_vcpu_dirty = 0;
--
1.7.1
[Qemu-devel] [PATCH 16/18] kvm: Separate TCG from KVM cpu execution
From: Jan Kiszka
Mixing up TCG bits with KVM already led to problems around eflags
emulation on x86. Moreover, quite some code that TCG requires on cpu
enty/exit is useless for KVM. So dispatch between tcg_cpu_exec and
kvm_cpu_exec as early as possible.
The core logic of cpu_halted from cpu_exec is added to
kvm_arch_process_irqchip_events. Moving away from cpu_exec makes
exception_index meaningless for KVM, we can simply pass the exit reason
directly (only "EXCP_DEBUG vs. rest" is relevant).
Signed-off-by: Jan Kiszka
---
cpu-exec.c| 19 ++-
cpus.c| 10 +-
kvm-all.c | 19 +--
target-i386/kvm.c |6 +++---
4 files changed, 23 insertions(+), 31 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index 8c9fb8b..e4fe4f8 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -248,13 +248,11 @@ int cpu_exec(CPUState *env1)
}
#if defined(TARGET_I386)
-if (!kvm_enabled()) {
-/* put eflags in CPU temporary format */
-CC_SRC = env->eflags & (CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
-DF = 1 - (2 * ((env->eflags >> 10) & 1));
-CC_OP = CC_OP_EFLAGS;
-env->eflags &= ~(DF_MASK | CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
-}
+/* put eflags in CPU temporary format */
+CC_SRC = env->eflags & (CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
+DF = 1 - (2 * ((env->eflags >> 10) & 1));
+CC_OP = CC_OP_EFLAGS;
+env->eflags &= ~(DF_MASK | CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
#elif defined(TARGET_SPARC)
#elif defined(TARGET_M68K)
env->cc_op = CC_OP_FLAGS;
@@ -279,7 +277,7 @@ int cpu_exec(CPUState *env1)
if (setjmp(env->jmp_env) == 0) {
#if defined(__sparc__) && !defined(CONFIG_SOLARIS)
#undef env
-env = cpu_single_env;
+env = cpu_single_env;
#define env cpu_single_env
#endif
/* if an exception is pending, we execute it here */
@@ -340,11 +338,6 @@ int cpu_exec(CPUState *env1)
}
}
-if (kvm_enabled()) {
-kvm_cpu_exec(env);
-longjmp(env->jmp_env, 1);
-}
-
next_tb = 0; /* force lookup of first TB */
for(;;) {
interrupt_request = env->interrupt_request;
diff --git a/cpus.c b/cpus.c
index 4a4d130..e4ff314 100644
--- a/cpus.c
+++ b/cpus.c
@@ -728,8 +728,6 @@ static void qemu_kvm_wait_io_event(CPUState *env)
qemu_wait_io_event_common(env);
}
-static int qemu_cpu_exec(CPUState *env);
-
static void *qemu_kvm_cpu_thread_fn(void *arg)
{
CPUState *env = arg;
@@ -756,7 +754,7 @@ static void *qemu_kvm_cpu_thread_fn(void *arg)
while (1) {
if (cpu_can_run(env)) {
-qemu_cpu_exec(env);
+kvm_cpu_exec(env);
}
qemu_kvm_wait_io_event(env);
}
@@ -959,7 +957,7 @@ void vm_stop(int reason)
#endif
-static int qemu_cpu_exec(CPUState *env)
+static int tcg_cpu_exec(CPUState *env)
{
int ret;
#ifdef CONFIG_PROFILER
@@ -1014,9 +1012,11 @@ bool cpu_exec_all(void)
break;
}
if (cpu_can_run(env)) {
-r = qemu_cpu_exec(env);
if (kvm_enabled()) {
+r = kvm_cpu_exec(env);
qemu_kvm_eat_signals(env);
+} else {
+r = tcg_cpu_exec(env);
}
if (r == EXCP_DEBUG) {
break;
diff --git a/kvm-all.c b/kvm-all.c
index 0abe088..fd5a137 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -823,10 +823,11 @@ int kvm_cpu_exec(CPUState *env)
if (kvm_arch_process_irqchip_events(env)) {
env->exit_request = 0;
-env->exception_index = EXCP_HLT;
-return 0;
+return EXCP_HLT;
}
+cpu_single_env = env;
+
do {
if (env->kvm_vcpu_dirty) {
kvm_arch_put_registers(env, KVM_PUT_RUNTIME_STATE);
@@ -855,7 +856,6 @@ int kvm_cpu_exec(CPUState *env)
kvm_flush_coalesced_mmio_buffer();
if (ret == -EINTR || ret == -EAGAIN) {
-cpu_exit(env);
DPRINTF("io window exit\n");
ret = 0;
break;
@@ -906,8 +906,8 @@ int kvm_cpu_exec(CPUState *env)
DPRINTF("kvm_exit_debug\n");
#ifdef KVM_CAP_SET_GUEST_DEBUG
if (kvm_arch_debug(&run->debug.arch)) {
-env->exception_index = EXCP_DEBUG;
-return 0;
+ret = EXCP_DEBUG;
+goto out;
}
/* re-enter, this exception was guest-internal */
ret = 1;
@@ -923,13 +923,12 @@ int kvm_cpu_exec(CPUState *env)
if (ret < 0) {
cpu_dump_state(env, stderr, fprintf, CPU_DUMP_CODE);
vm_stop(0);
-env->exit_request = 1;
-}
-if (env->exit_request) {
-env->exit_request = 0;
-env->exception_index = EXCP_INTERRUPT;
}
+ret = EXCP_INTERRUPT;
+out:
+env->exit_request = 0;
+cpu_single_env = NULL;
retu
[Qemu-devel] Re: [PATCH] add event queueing to USB HID
On 01/07/2011 08:59 AM, Gerd Hoffmann wrote:
On 12/23/10 15:57, Paolo Bonzini wrote:
The polling nature of the USB HID device makes it very hard to double
click or drag while on a high-latency VNC connection. This patch,
based on work done in the Xen qemu-dm tree by Ian Jackson, fixes this
bug by adding an event queue to the device. The event queue associates
each movement with the correct button state (and each button state change
with the correct location); it also remembers all button presses and
releases as well.
@@ -68,7 +77,7 @@ typedef struct USBHIDState {
int protocol;
uint8_t idle;
int64_t next_idle_clock;
- int changed;
+ int have_data, changed;
What is the difference between have_data and changed?
The difference is that after a reset have_data is zero (the queue is
empty) but changed will still be 1 if the poll routine has never run.
This matches the behavior of current QEMU. I also think Windows 2003
didn't boot without it, but I may remember wrong.
Do you need both? And can't you just compare head and tail of the ring
instead?
I don't think that would allow me to distinguish an entirely empty queue
and an entirely full queue? I added have_data after reading this this
code from Ian's patch:
+if (s->tail == s->head) {
+use_slot= s->tail;
+QUEUE_INCR(s->tail);
+usb_pointer_event_clear(&s->queue[use_slot], buttons_state);
+} else if (use_slot == s->head ||
+ s->queue[use_slot].buttons_state != buttons_state ||
+ s->queue[previous_slot].buttons_state != buttons_state) {
+ /* can't or shouldn't combine this event with previous one */
+ use_slot= s->tail;
+ QUEUE_INCR(s->tail);
+ if (use_slot == s->head) {
+ /* queue full, oh well, discard something */
The first "if" tests the empty-queue case. Then, in the else, the same
test "value of s->tail on entry == value of s->head on entry" is used to
test for a full queue. The invariants on the queue were not documented
in the Xen patch; so, without unit testing and without an easy way to
test the full-queue case I preferred to be safe.
I think it makes sense to do the same for the keyboard, which might even
simplify the code overall as both mouse and keyboard will work in a
simliar way then.
That would be a bit different because the keyboard events cannot be
merged. I thought about it, but it would be pretty much a completely
different patch.
Also, I couldn't even send Ctrl-Alt-Del to an USB keyboard on VNC in my
testing, which decreased substantially the priority of USB keyboard
buffering. It is possible that buffering would fix this, but then it
means that likely nobody is using the USB keyboard. In practice, the
USB tablet is very useful for Windows but the PS/2 keyboard is usually
good enough for everything.
+ /* When the buffer is empty, return the last event.
Why can this happen in the first place? Shouldn't the device NAK polls
when it has no events to deliver?
See reply from Ian.
By the way, on further review this code:
+} else if (use_slot == s->head ||
+ s->queue[use_slot].buttons_state != buttons_state ||
+ s->queue[previous_slot].buttons_state != buttons_state) {
looks like it should be instead
/* Only one event in queue */
use_slot == s->head ||
/* This is a button press or release */
s->queue[use_slot].buttons_state != buttons_state ||
/* use_slot was a button press or release */
s->queue[previous_slot].buttons_state !=
s->queue[use_slot].buttons_state
Any ideas?
Paolo
Re: [Qemu-devel] [PATCH 2/2] qcow2: fix unaligned access
Am 01.01.2011 21:50, schrieb Aurelien Jarno: > cpu_to_be64w() is called with an obviously non-aligned pointer. Use > cpu_to_be64wu() instead. It fixes unaligned accesses errors on IA64 > hosts. > > Cc: Kevin Wolf > Signed-off-by: Aurelien Jarno Thanks, applied to the block branch. Kevin
[Qemu-devel] Re: [PATCH] cris: remove a write-only variable
On Sun, Jan 09, 2011 at 04:56:59PM +, Blue Swirl wrote:
> Avoid a warning with GCC 4.6.0:
> /src/qemu/target-cris/translate.c: In function
> 'gen_intermediate_code_internal':
> /src/qemu/target-cris/translate.c:3185:25: error: variable
> 'orig_flags' set but not used [-Werror=unused-but-set-variable]
Hi,
Looks good but you are using spaces in a tab only file. I don't mind
much but it's maybe better to switch to entirely to spaces or not
at all.
Cheers
> Signed-off-by: Blue Swirl
> ---
> target-cris/translate.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/target-cris/translate.c b/target-cris/translate.c
> index 5184155..21983eb 100644
> --- a/target-cris/translate.c
> +++ b/target-cris/translate.c
> @@ -3182,7 +3182,7 @@ gen_intermediate_code_internal(CPUState *env,
> TranslationBlock *tb,
> {
> uint16_t *gen_opc_end;
> uint32_t pc_start;
> - unsigned int insn_len, orig_flags;
> +unsigned int insn_len;
> int j, lj;
> struct DisasContext ctx;
> struct DisasContext *dc = &ctx;
> @@ -3224,8 +3224,8 @@ gen_intermediate_code_internal(CPUState *env,
> TranslationBlock *tb,
> dc->cc_size_uptodate = -1;
>
> /* Decode TB flags. */
> - orig_flags = dc->tb_flags = tb->flags & (S_FLAG | P_FLAG | U_FLAG \
> - | X_FLAG | PFIX_FLAG);
> +dc->tb_flags = tb->flags & (S_FLAG | P_FLAG | U_FLAG | X_FLAG \
> +| PFIX_FLAG);
> dc->delayed_branch = !!(tb->flags & 7);
> if (dc->delayed_branch)
> dc->jmp = JMP_INDIRECT;
> --
> 1.6.2.4
[Qemu-devel] [PATCH V5 1/4] nmi: convert cpu_index to cpu-index
"cpu-index" is better name.
Signed-off-by: Lai Jiangshan
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index df134f8..99b96a8 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -721,7 +721,7 @@ ETEXI
#if defined(TARGET_I386)
{
.name = "nmi",
-.args_type = "cpu_index:i",
+.args_type = "cpu-index:i",
.params = "cpu",
.help = "inject an NMI on the given CPU",
.mhandler.cmd = do_inject_nmi,
diff --git a/monitor.c b/monitor.c
index f258000..fd18887 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2520,7 +2520,7 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
static void do_inject_nmi(Monitor *mon, const QDict *qdict)
{
CPUState *env;
-int cpu_index = qdict_get_int(qdict, "cpu_index");
+int cpu_index = qdict_get_int(qdict, "cpu-index");
for (env = first_cpu; env != NULL; env = env->next_cpu)
if (env->cpu_index == cpu_index) {
[Qemu-devel] [PATCH V5 4/4] nmi: report error(QError) when the cpu-index is invalid
When cpu-index is found invalid in runtime, it will report QERR_INVALID_PARAMETER_VALUE. Signed-off-by: Lai Jiangshan --- diff --git a/monitor.c b/monitor.c index 1bee840..7402c0f 100644 --- a/monitor.c +++ b/monitor.c @@ -2535,6 +2535,7 @@ static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data) return 0; } +qerror_report(QERR_INVALID_PARAMETER_VALUE, "cpu-index", "a CPU number"); return -1; } #endif
[Qemu-devel] [PATCH V5 3/4] qmp, nmi: convert do_inject_nmi() to QObject
Make we can inject NMI via qemu-monitor-protocol.
We use "inject-nmi" for the qmp command name, the meaning is clearer.
Signed-off-by: Lai Jiangshan
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index a49fcd4..4db413d 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -724,7 +724,8 @@ ETEXI
.args_type = "cpu-index:i?",
.params = "[cpu]",
.help = "inject an NMI on all CPUs or the given CPU",
-.mhandler.cmd = do_inject_nmi,
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
},
#endif
STEXI
diff --git a/monitor.c b/monitor.c
index 952f67f..1bee840 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2517,7 +2517,7 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
#endif
#if defined(TARGET_I386)
-static void do_inject_nmi(Monitor *mon, const QDict *qdict)
+static int do_inject_nmi(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
CPUState *env;
int cpu_index;
@@ -2525,15 +2525,17 @@ static void do_inject_nmi(Monitor *mon, const QDict
*qdict)
if (!qdict_get(qdict, "cpu-index")) {
for (env = first_cpu; env != NULL; env = env->next_cpu)
cpu_interrupt(env, CPU_INTERRUPT_NMI);
-return;
+return 0;
}
cpu_index = qdict_get_int(qdict, "cpu-index");
for (env = first_cpu; env != NULL; env = env->next_cpu)
if (env->cpu_index == cpu_index) {
cpu_interrupt(env, CPU_INTERRUPT_NMI);
-break;
+return 0;
}
+
+return -1;
}
#endif
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 56c4d8b..c2d619c 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -429,6 +429,33 @@ Example:
EQMP
+#if defined(TARGET_I386)
+{
+.name = "inject_nmi",
+.args_type = "cpu-index:i?",
+.params = "[cpu]",
+.help = "inject an NMI on all CPUs or the given CPU",
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = do_inject_nmi,
+},
+#endif
+SQMP
+inject_nmi
+--
+
+Inject an NMI on the given CPU (x86 only).
+
+Arguments:
+
+- "cpu_index": the index of the CPU to be injected NMI (json-int)
+
+Example:
+
+-> { "execute": "inject_nmi", "arguments": { "cpu-index": 0 } }
+<- { "return": {} }
+
+EQMP
+
{
.name = "migrate",
.args_type = "detach:-d,blk:-b,inc:-i,uri:s",
[Qemu-devel] [PATCH V5 2/4] nmi: make cpu-index argument optional
When the argument "cpu-index" is not given,
then "nmi" command will inject NMI on all CPUs.
This simulate the nmi button on physical machine.
Thanks to Markus Armbruster for correcting the logic
detecting "cpu-index" is given or not.
Signed-off-by: Lai Jiangshan
---
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 99b96a8..a49fcd4 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -721,9 +721,9 @@ ETEXI
#if defined(TARGET_I386)
{
.name = "nmi",
-.args_type = "cpu-index:i",
-.params = "cpu",
-.help = "inject an NMI on the given CPU",
+.args_type = "cpu-index:i?",
+.params = "[cpu]",
+.help = "inject an NMI on all CPUs or the given CPU",
.mhandler.cmd = do_inject_nmi,
},
#endif
diff --git a/monitor.c b/monitor.c
index fd18887..952f67f 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2520,8 +2520,15 @@ static void do_wav_capture(Monitor *mon, const QDict
*qdict)
static void do_inject_nmi(Monitor *mon, const QDict *qdict)
{
CPUState *env;
-int cpu_index = qdict_get_int(qdict, "cpu-index");
+int cpu_index;
+if (!qdict_get(qdict, "cpu-index")) {
+for (env = first_cpu; env != NULL; env = env->next_cpu)
+cpu_interrupt(env, CPU_INTERRUPT_NMI);
+return;
+}
+
+cpu_index = qdict_get_int(qdict, "cpu-index");
for (env = first_cpu; env != NULL; env = env->next_cpu)
if (env->cpu_index == cpu_index) {
cpu_interrupt(env, CPU_INTERRUPT_NMI);
[Qemu-devel] Re: [PATCH 00/18] [uq/master] MCE & IO exit fixes, prepare for VCPU loop reuse
Am 10.01.2011 09:31, Jan Kiszka wrote: > This series has three major topics: > - add required kernel reentry after IO exits > - provide MCE forwarding under !CONFIG_IOTHREAD > - prepare kvm_cpu_exec for qemu-kvm reuse > > Along these lines, several cleanups and simplifcations are applied to > cpus.c and the KVM VCPU execution bits. The first patch should of course > be dropped if uq/master is applied without "kvm: Drop return value of > kvm_cpu_exec". > > Note that I did not yet to test the MCE support. Is there an easy way to > trigger valid MCE events at kernel level? Or do I need to fake SIGBUS at > qemu level? > > Jan Kiszka (18): > Revert "kvm: Drop return value of kvm_cpu_exec" > kvm: Drop redundant kvm_enabled from kvm_cpu_thread_fn > kvm: Provide sigbus services arch-independently > Refactor signal setup functions in cpus.c > kvm: Set up signal mask also for !CONFIG_IOTHREAD > kvm: Refactor qemu_kvm_eat_signals > kvm: Add MCE signal support for !CONFIG_IOTHREAD > kvm: Handle kvm_init_vcpu errors Ugh, I did it again: Forgot to test this "trivial" patch. Promptly, it turned out to be buggy, and it also revealed some potential issues in the kvm init code. Need to look into this later. The rest of the series is unaffected, though. Jan > Refactor kvm&tcg function names in cpus.c > Fix a few coding style violations in cpus.c > Introduce VCPU self-signaling service > kvm: Move irqchip event processing out of inner loop > kvm: Unconditionally reenter kernel after IO exits > kvm: Remove static return code of kvm_handle_io > kvm: Leave kvm_cpu_exec directly after KVM_EXIT_SHUTDOWN > kvm: Separate TCG from KVM cpu execution > kvm: x86: Prepare VCPU loop for in-kernel irqchip > kvm: Drop return values from kvm_arch_pre/post_run > > cpu-exec.c | 19 +-- > cpus.c | 521 > +++- > kvm-all.c | 76 + > kvm-stub.c |9 +- > kvm.h | 14 +- > qemu-common.h |1 + > target-i386/kvm.c | 90 +- > target-ppc/kvm.c | 16 ++- > target-s390x/kvm.c | 16 ++- > 9 files changed, 444 insertions(+), 318 deletions(-) > -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] Re: [PATCH 03/18] kvm: Provide sigbus services arch-independently
On 01/10/2011 09:31 AM, Jan Kiszka wrote:
+int kvm_on_sigbus_vcpu(CPUState *env, int code, void *addr)
+{
+return kvm_on_sigbus_vcpu(env, code, addr);
+}
+
+int kvm_on_sigbus(int code, void *addr)
+{
+return kvm_on_sigbus(code, addr);
+}
Missing arch_ here?
Paolo
[Qemu-devel] Re: [PATCH 06/18] kvm: Refactor qemu_kvm_eat_signals
On 01/10/2011 09:31 AM, Jan Kiszka wrote:
From: Jan Kiszka
We do not use the timeout, so drop its logic. As we always poll our
signals, we do not need to drop the global lock. Removing those calls
allows some further simplifications. Also fix the error processing of
sigpending at this chance.
Signed-off-by: Jan Kiszka
---
cpus.c | 23 +++
1 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/cpus.c b/cpus.c
index bf0fb85..6da0f8f 100644
--- a/cpus.c
+++ b/cpus.c
@@ -617,31 +617,22 @@ static void sigbus_handler(int n, struct
qemu_signalfd_siginfo *siginfo,
}
}
-static void qemu_kvm_eat_signal(CPUState *env, int timeout)
+static void qemu_kvm_eat_signals(CPUState *env)
{
-struct timespec ts;
-int r, e;
+struct timespec ts = { 0, 0 };
siginfo_t siginfo;
sigset_t waitset;
sigset_t chkset;
-
-ts.tv_sec = timeout / 1000;
-ts.tv_nsec = (timeout % 1000) * 100;
+int r;
sigemptyset(&waitset);
sigaddset(&waitset, SIG_IPI);
sigaddset(&waitset, SIGBUS);
do {
-qemu_mutex_unlock(&qemu_global_mutex);
-
r = sigtimedwait(&waitset,&siginfo,&ts);
-e = errno;
-
-qemu_mutex_lock(&qemu_global_mutex);
-
-if (r == -1&& !(e == EAGAIN || e == EINTR)) {
-fprintf(stderr, "sigtimedwait: %s\n", strerror(e));
+if (r == -1&& !(errno == EAGAIN || errno == EINTR)) {
+perror("sigtimedwait");
exit(1);
}
@@ -657,7 +648,7 @@ static void qemu_kvm_eat_signal(CPUState *env, int timeout)
r = sigpending(&chkset);
if (r == -1) {
-fprintf(stderr, "sigpending: %s\n", strerror(e));
+perror("sigpending");
exit(1);
}
} while (sigismember(&chkset, SIG_IPI) || sigismember(&chkset, SIGBUS));
@@ -668,7 +659,7 @@ static void qemu_kvm_wait_io_event(CPUState *env)
while (!cpu_has_work(env))
qemu_cond_timedwait(env->halt_cond,&qemu_global_mutex, 1000);
-qemu_kvm_eat_signal(env, 0);
+qemu_kvm_eat_signals(env);
qemu_wait_io_event_common(env);
}
Reviewed-by: Paolo Bonzini
Paolo
[Qemu-devel] Re: [PATCH 0/5] Fix migration with NFS & iscsi/Fiber channel
Juan Quintela wrote: > Hi Nack myself :-( After discussions with hch on irc, he "convinced" me that only way to fix the problem is forcing O_DIRECT if migration is going to happen. So, changing patchset to check that cache=none is used in all read/write devices. Later, Juan. > This patch set creates infrastructure to invalidate buffers on > migration target machine. The best way to see the problems is: > > # create a new qcow2 image > qemu-img create -f qcow2 foo.img > # start the destination host > qemu path=foo.img > # start the source host with one installation > qemu path=foo.img > # migrate after lots of disk writes > > Destination will have "read" the beggining of the blocks of the file > (where the headers are). There are two bugs here: > a- we need to re-read the image after migration, to have the new values >(reopening fixes it) > b- we need to be sure that we read the new blocks that are on the server, >not the buffered ones locally from the start of the run. >NFS: flush on source and close + open on target invalidates the cache >Block devices: on linux, BLKFLSBUF invalidates all the buffers for that >device. This fixes iSCSI & FiberChannel. > > I tested iSCSI & NFS. NFS patch have been on RHEL5 kvm forever (I just > forget to send the patch upstream). Our NFS gurus & cluster gurus told > that this is enough for linux to ensure consistence. > > Once there, I fixed a couple of minor bugs (the first 3 patches): > - migration should exit with error 1 as everything else. > - memory leak on drive_uninit. > - fix cleanup on error on drive_init() > > Later, Juan. > > Juan Quintela (5): > migration: exit with error code > blockdev: don't leak id on removal > blockdev: release resources in the error case > Reopen files after migration > drive_open: Add invalidate option for block devices > > block.h |2 ++ > block/raw-posix.c | 24 > blockdev.c| 53 > + > blockdev.h|6 ++ > migration.c |8 +++- > vl.c |2 +- > 6 files changed, 85 insertions(+), 10 deletions(-)
[Qemu-devel] KVM call agenda for Jan 11
Please send any agenda items you are interested in covering. - KVM Forum 2011 (Jes). thanks, Juan.
[Qemu-devel] Re: [PATCH v4] savevm: Fix no_migrate
On Fri, Jan 07, 2011 at 03:13:25PM -0700, Alex Williamson wrote: > The no_migrate save state flag is currently only checked in the > last phase of migration. This means that we potentially waste > a lot of time and bandwidth with the live state handlers before > we ever check the no_migrate flags. The error message printed > when we catch a non-migratable device doesn't get printed for > a detached migration. And, no_migrate does nothing to prevent > an incoming migration to a target that includes a non-migratable > device. This attempts to fix all of these. > > One notable difference in behavior is that an outgoing migration > now checks for non-migratable devices before ever connecting to > the target system. This means the target will remain listening > rather than exit from failure. > > Signed-off-by: Alex Williamson > --- > > v4: > - fix braces noted by Jan > - return error from qemu_savevm_state_blocked rather than fixed EINVAL > at qemu_loadvm_state(), since it'a already using errno values > > v3: > > Daniel, adding you to see if libvirt cares about the difference in > whether the target exits on migration failure as noted above. If the 'migrate' command on the source QEMU returns an error, then libvirt will teardown the target QEMU automatically, so that's not a problem. Regards, Daniel
[Qemu-devel] [PATCH] cutils: Use int64_t instead of ssize_t for strtosz()
The strtosz() function parses byte count strings and converts K, M, G
units. The ssize_t type is not appropriate because block devices need
64-bit range even on 32-bit hosts. Switch from ssize_t to int64_t.
Signed-off-by: Stefan Hajnoczi
---
cutils.c |8
monitor.c |2 +-
qemu-common.h |4 ++--
qemu-img.c|2 +-
vl.c |4 ++--
5 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/cutils.c b/cutils.c
index 7984bc1..7f1c05e 100644
--- a/cutils.c
+++ b/cutils.c
@@ -291,9 +291,9 @@ int fcntl_setfl(int fd, int flag)
* value must be terminated by whitespace, ',' or '\0'. Return -1 on
* error.
*/
-ssize_t strtosz_suffix(const char *nptr, char **end, const char default_suffix)
+int64_t strtosz_suffix(const char *nptr, char **end, const char default_suffix)
{
-ssize_t retval = -1;
+int64_t retval = -1;
char *endptr, c, d;
int mul_required = 0;
double val, mul, integral, fraction;
@@ -365,7 +365,7 @@ ssize_t strtosz_suffix(const char *nptr, char **end, const
char default_suffix)
goto fail;
}
}
-if ((val * mul >= ~(size_t)0) || val < 0) {
+if ((val * mul >= ~(uint64_t)0) || val < 0) {
goto fail;
}
retval = val * mul;
@@ -378,7 +378,7 @@ fail:
return retval;
}
-ssize_t strtosz(const char *nptr, char **end)
+int64_t strtosz(const char *nptr, char **end)
{
return strtosz_suffix(nptr, end, STRTOSZ_DEFSUFFIX_MB);
}
diff --git a/monitor.c b/monitor.c
index f258000..fcdae15 100644
--- a/monitor.c
+++ b/monitor.c
@@ -4162,7 +4162,7 @@ static const mon_cmd_t *monitor_parse_command(Monitor
*mon,
break;
case 'o':
{
-ssize_t val;
+int64_t val;
char *end;
while (qemu_isspace(*p)) {
diff --git a/qemu-common.h b/qemu-common.h
index 63d9943..cce6e61 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -158,8 +158,8 @@ int fcntl_setfl(int fd, int flag);
#define STRTOSZ_DEFSUFFIX_MB 'M'
#define STRTOSZ_DEFSUFFIX_KB 'K'
#define STRTOSZ_DEFSUFFIX_B'B'
-ssize_t strtosz(const char *nptr, char **end);
-ssize_t strtosz_suffix(const char *nptr, char **end, const char
default_suffix);
+int64_t strtosz(const char *nptr, char **end);
+int64_t strtosz_suffix(const char *nptr, char **end, const char
default_suffix);
/* path.c */
void init_paths(const char *prefix);
diff --git a/qemu-img.c b/qemu-img.c
index afd9ed2..6af2a4c 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -320,7 +320,7 @@ static int img_create(int argc, char **argv)
/* Get image size, if specified */
if (optind < argc) {
-ssize_t sval;
+int64_t sval;
sval = strtosz_suffix(argv[optind++], NULL, STRTOSZ_DEFSUFFIX_B);
if (sval < 0) {
error_report("Invalid image size specified! You may use k, M, G or
"
diff --git a/vl.c b/vl.c
index 78fcef1..93425f4 100644
--- a/vl.c
+++ b/vl.c
@@ -804,7 +804,7 @@ static void numa_add(const char *optarg)
if (get_param_value(option, 128, "mem", optarg) == 0) {
node_mem[nodenr] = 0;
} else {
-ssize_t sval;
+int64_t sval;
sval = strtosz(option, NULL);
if (sval < 0) {
fprintf(stderr, "qemu: invalid numa mem size: %s\n", optarg);
@@ -2245,7 +2245,7 @@ int main(int argc, char **argv, char **envp)
exit(0);
break;
case QEMU_OPTION_m: {
-ssize_t value;
+int64_t value;
value = strtosz(optarg, NULL);
if (value < 0) {
--
1.7.2.3
[Qemu-devel] Re: [PATCH 03/18] kvm: Provide sigbus services arch-independently
Am 10.01.2011 11:13, Paolo Bonzini wrote:
> On 01/10/2011 09:31 AM, Jan Kiszka wrote:
>> +int kvm_on_sigbus_vcpu(CPUState *env, int code, void *addr)
>> +{
>> +return kvm_on_sigbus_vcpu(env, code, addr);
>> +}
>> +
>> +int kvm_on_sigbus(int code, void *addr)
>> +{
>> +return kvm_on_sigbus(code, addr);
>> +}
>
> Missing arch_ here?
Well, I said that I didn't test those bits... :)
Thanks, will fix.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
[Qemu-devel] Re: [PATCH] cutils: Use int64_t instead of ssize_t for strtosz()
On 01/10/11 11:29, Stefan Hajnoczi wrote: > The strtosz() function parses byte count strings and converts K, M, G > units. The ssize_t type is not appropriate because block devices need > 64-bit range even on 32-bit hosts. Switch from ssize_t to int64_t. Hmmm I think this is identical to the patch I posted last week :) Cheers, Jes
Re: [Qemu-devel] Re: [PATCH] cutils: Use int64_t instead of ssize_t for strtosz()
On Mon, Jan 10, 2011 at 10:33 AM, Jes Sorensen wrote: > On 01/10/11 11:29, Stefan Hajnoczi wrote: >> The strtosz() function parses byte count strings and converts K, M, G >> units. The ssize_t type is not appropriate because block devices need >> 64-bit range even on 32-bit hosts. Switch from ssize_t to int64_t. > > Hmmm I think this is identical to the patch I posted last week :) Sorry for the duplication. Someone on IRC discovered the issue and I wrote up the patch this morning. No worries :). Stefan
Re: [Qemu-devel] [RFC][PATCH] lsi53c895a: Update dnad when skipping MSGOUT bytes
On Sun, Jan 9, 2011 at 11:19 PM, Nicholas A. Bellinger wrote: > It's also worth mentioning that the sym53c8xx driver still works without > this patch, which may be attributed to the Win2003 driver perhaps > either: > > *) Sending contiguous 'Extended Messages' instead of individual messages > (as sym53c8xx_2 appears to do) to cause the sanity check in > lsi_add_msg_byte() and trigger the BUG > > *) Sending a different/wrong sized MSG out or Extended message length > for SDTR / WDTR negoitation messages > > In any event, I think your change looks good and thanks for tracking > this one down. Please add my: > > Reviewed-by: Nicholas A. Bellinger Thanks for the review, I'll resend as [PATCH] and will try to find a Windows 2003 Server guest for testing. Stefan
Re: [Qemu-devel] Linux as VirtualBox quest OS with QEMU running Solaris
On 07/01/11 17:36, Michal Suchanek wrote: On 7 January 2011 18:28, Mateusz Loskot wrote: Hi, First, I'm sorry if my question does not belong here. The qemu-devel says it's "devel", but I can't find any qemu-users mailing list. I have seen it once but could not find it either when searching for a qemu mailing list to subscribe to. I see. I have found the "QEMU on Winows" [1] but I'm not sure if this is an official project and if it's "production ready". I need to have fairly stable environment for building and testing software on SPARC architecture. If you can find a build of recent qemu for Windows it should preform as well as qemu on Linux for emulating a SPARC (= different architecture). I will try to find or build it. Adding another layer of virtualization is going to hurt performance at least and could potentially introduce additional issues. Yes, that's what I am worried about. However, the device emulation is different on Windows compared to Linux so you may find that networking and screen emulation works differently compared to Linux. I see. Actually, I do not need to access Solaris with any GUI, text mode will do well. Thanks for the hints. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Re: [Qemu-devel] Linux as VirtualBox quest OS with QEMU running Solaris
On 07/01/11 18:15, Stefan Weil wrote: Am 07.01.2011 18:28, schrieb Mateusz Loskot: Hi, First, I'm sorry if my question does not belong here. The qemu-devel says it's "devel", but I can't find any qemu-users mailing list. I have no experience with QEMU. I've been using x86-only virtualization software like VirtualBox, VMWare and others. I need to run Solaris (SPARC) OS and I'd like to do it under QEMU. Due to hardware constraints, I'm wondering if the following setup would work at all: 1. Quad-core workstation with 16GB RAM with Windows Vista 64-bit as host OS 2. The Windows runs VirtualBox with Linux installed as guest OS. 3. The Linux guest OS runs QEMU 4. QEMU runs Solaris (SPARC) The Linux guest OS can be either Linux x86-32 or x86-64, depending which one is recommended and would perform better. Is this configuration reasonable? Would it work well? I have found the "QEMU on Winows" [1] but I'm not sure if this is an official project and if it's "production ready". I need to have fairly stable environment for building and testing software on SPARC architecture. [1] http://www.h7.dion.ne.jp/~qemu-win/ I'd appreciate any help and sugestions. Using a native windows version of qemu would be more reasonable. OK, makes sense to me. There are no precompiled windows binaries of current qemu, so you will have to compile them yourself (which is not difficult once you have the correct mingw environment). Great. I think I should be able to do that. Which version of QEMU source code should I grab? Latest stable or development version from Git repo? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Re: [Qemu-devel] Linux as VirtualBox quest OS with QEMU running Solaris
On 07/01/11 20:37, Blue Swirl wrote: On Fri, Jan 7, 2011 at 5:28 PM, Mateusz Loskot wrote: Hi, First, I'm sorry if my question does not belong here. The qemu-devel says it's "devel", but I can't find any qemu-users mailing list. A forum exists: http://qemu-forum.ipi.fi/ Good to know. Though, I may be old, but I prefer mailing list than Web-based forums. Anyway, if I understand it well, there is nothing wrong with posting non-development questions to qmenu-devel, is it? I have no experience with QEMU. I've been using x86-only virtualization software like VirtualBox, VMWare and others. I need to run Solaris (SPARC) OS and I'd like to do it under QEMU. Due to hardware constraints, I'm wondering if the following setup would work at all: 1. Quad-core workstation with 16GB RAM with Windows Vista 64-bit as host OS 2. The Windows runs VirtualBox with Linux installed as guest OS. 3. The Linux guest OS runs QEMU 4. QEMU runs Solaris (SPARC) The Linux guest OS can be either Linux x86-32 or x86-64, depending which one is recommended and would perform better. Is this configuration reasonable? Would it work well? Sparc32 Solaris can run with recent QEMU: http://tyom.blogspot.com/ Fantastic! Sparc64 is not ready yet. I can stick to 32-bit. I have found the "QEMU on Winows" [1] but I'm not sure if this is an official project and if it's "production ready". I need to have fairly stable environment for building and testing software on SPARC architecture. Someone should step up as Win32 maintainer, also making Windows builds available. I can't help, I regret. Thanks for help! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
[Qemu-devel] Re: KVM call agenda for Jan 11
Juan Quintela wrote: Now sent it to the right kvm list. Sorry for the second sent. > Please send any agenda items you are interested in covering. > > - KVM Forum 2011 (Jes). > > thanks, Juan.
Re: [Qemu-devel] [PATCH 0/5] usb-ccid (v14)
On 01/08/11 11:28, Alon Levy wrote: This patchset adds three new devices, usb-ccid, ccid-card-passthru and ccid-card-emulated, providing a CCID bus, a simple passthru protocol implementing card requiring a client, and a standalone emulated card. It also introduces a new directory libcaccard with CAC card emulation, CAC is a type of ISO 7816 smart card. Tree for pull: git://anongit.freedesktop.org/~alon/qemu usb_ccid.v14 One nit left which I didn't notice on previous reviews: It can't be disabled at compile time, there is no --disable-smartcard switch. The nss detection needs some tweaks too. The usual configure behavior in qemu is this: [ no smarccard option specified ] autodetect, i.e. enable smartcard if nss support is found, otherwise disable (i.e. what your patch does now). --disable-smartcard turn off smartcard support. --enable-smartcard force smartcard support on, if nss isn't present abort configure with an error message. Otherwise it looks works nicely. Good job. cheers, Gerd
Re: [Qemu-devel] [PATCH 6/7] lan9118: fix a buffer overflow
Blue Swirl writes:
> Fix a buffer overflow, reported by cppcheck:
> [/src/qemu/hw/lan9118.c:849]: (error) Buffer access out-of-bounds: s.eeprom
>
> All eeprom handling code assumes that the size of eeprom is 128.
>
> Signed-off-by: Blue Swirl
> ---
> hw/lan9118.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hw/lan9118.c b/hw/lan9118.c
> index a988664..1bb829e 100644
> --- a/hw/lan9118.c
> +++ b/hw/lan9118.c
> @@ -187,7 +187,7 @@ typedef struct {
> uint32_t phy_int_mask;
>
> int eeprom_writable;
> -uint8_t eeprom[8];
> +uint8_t eeprom[128];
>
> int tx_fifo_size;
> LAN9118Packet *txp;
Covers all the obvious accesses except for a couple of s->eeprom[addr]
in lan9118_eeprom_cmd(). addr is a parameter there, and the actual
argument is val & 0xff, in lan9118_writel(). What if val & 0xff >= 128?
Re: [Qemu-devel] [PATCH 0/7] cppcheck fixes
Blue Swirl writes: > This patch set fixes bugs found by cppcheck. > > http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page > > Blue Swirl (7): > vnc-auth-sasl: fix a memory leak > loader: fix a file descriptor leak > vvfat: fix a file descriptor leak > qemu-io: fix a memory leak > vpc: fix a file descriptor leak > lan9118: fix a buffer overflow > ppc405_uc: fix a buffer overflow 6/7 may not be complete (see my reply). Rest looks good.
Re: [Qemu-devel] Re: KVM call agenda for Jan 11
On 01/10/11 12:59, Juan Quintela wrote: > Juan Quintela wrote: > > Now sent it to the right kvm list. Sorry for the second sent. > >> Please send any agenda items you are interested in covering. >> >> - KVM Forum 2011 (Jes). Just to add a bit more background. Last year we discussed the issue of whether to aim for a KVM Forum in the same style as we had in 2010, or whether to try to aim for a broader multi-track Virtualization conference that covers the whole stack. Linux Foundation is happy to help host such an event, but they are asking for what our plans are. I posted a mock-proposal for tracks here: http://www.linux-kvm.org/page/KVM_Forum_2011 Cheers, Jes
[Qemu-devel] [PATCH] linux-user: Add configure check for linux/fiemap.h and IOC_FS_FIEMAP
Add a configure check for the existence of linux/fiemap.h and the
IOC_FS_FIEMAP ioctl. This fixes a compilation failure on Linux
systems which don't have that header file.
Signed-off-by: Peter Maydell
---
configure| 20
linux-user/ioctls.h |2 +-
linux-user/syscall.c |4
3 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 831a741..438219b 100755
--- a/configure
+++ b/configure
@@ -2090,6 +2090,23 @@ if compile_prog "$ARCH_CFLAGS" "" ; then
sync_file_range=yes
fi
+# check for linux/fiemap.h and FS_IOC_FIEMAP
+fiemap=no
+cat > $TMPC << EOF
+#include
+#include
+#include
+
+int main(void)
+{
+ioctl(0, FS_IOC_FIEMAP, 0);
+return 0;
+}
+EOF
+if compile_prog "$ARCH_CFLAGS" "" ; then
+ fiemap=yes
+fi
+
# check for dup3
dup3=no
cat > $TMPC << EOF
@@ -2631,6 +2648,9 @@ fi
if test "$sync_file_range" = "yes" ; then
echo "CONFIG_SYNC_FILE_RANGE=y" >> $config_host_mak
fi
+if test "$fiemap" = "yes" ; then
+ echo "CONFIG_FIEMAP=y" >> $config_host_mak
+fi
if test "$dup3" = "yes" ; then
echo "CONFIG_DUP3=y" >> $config_host_mak
fi
diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h
index 538e257..acff781 100644
--- a/linux-user/ioctls.h
+++ b/linux-user/ioctls.h
@@ -76,7 +76,7 @@
#ifdef FIGETBSZ
IOCTL(FIGETBSZ, IOC_R, MK_PTR(TYPE_LONG))
#endif
-#ifdef FS_IOC_FIEMAP
+#ifdef CONFIG_FIEMAP
IOCTL_SPECIAL(FS_IOC_FIEMAP, IOC_W | IOC_R, do_ioctl_fs_ioc_fiemap,
MK_PTR(MK_STRUCT(STRUCT_fiemap)))
#endif
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index f10e17a..499c4d7 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -83,7 +83,9 @@ int __clone2(int (*fn)(void *), void *child_stack_base,
#include
#include
#include
+#if defined(CONFIG_FIEMAP)
#include
+#endif
#include
#include
#include "linux_loop.h"
@@ -2986,6 +2988,7 @@ struct IOCTLEntry {
#define MAX_STRUCT_SIZE 4096
+#ifdef CONFIG_FIEMAP
/* So fiemap access checks don't overflow on 32 bit systems.
* This is very slightly smaller than the limit imposed by
* the underlying kernel.
@@ -3072,6 +3075,7 @@ static abi_long do_ioctl_fs_ioc_fiemap(const IOCTLEntry
*ie, uint8_t *buf_temp,
}
return ret;
}
+#endif
static IOCTLEntry ioctl_entries[] = {
#define IOCTL(cmd, access, ...) \
--
1.6.3.3
[Qemu-devel] [PATCH 4/6] vnc/spice: fix "never" and "now" expire_time
From: Marc-André Lureau
Signed-off-by: Gerd Hoffmann
---
monitor.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/monitor.c b/monitor.c
index f258000..038d532 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1136,9 +1136,9 @@ static int expire_password(Monitor *mon, const QDict
*qdict, QObject **ret_data)
time_t when;
int rc;
-if (strcmp(whenstr, "now")) {
+if (strcmp(whenstr, "now") == 0) {
when = 0;
-} else if (strcmp(whenstr, "never")) {
+} else if (strcmp(whenstr, "never") == 0) {
when = TIME_MAX;
} else if (whenstr[0] == '+') {
when = time(NULL) + strtoull(whenstr+1, NULL, 10);
--
1.7.1
[Qemu-devel] [PATCH 2/6] spice: client migration.
Handle spice client migration, i.e. inform a spice client connected
about the new host and connection parameters, so it can move over the
connection automatically.
Signed-off-by: Gerd Hoffmann
---
hmp-commands.hx | 20
qmp-commands.hx | 35 +++
ui/qemu-spice.h |1 +
ui/spice-core.c | 40
4 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index df134f8..e6d8f36 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -815,6 +815,26 @@ ETEXI
},
STEXI
+...@item spice_migrate_info @var{hostname} @var{port} @var{tls-port}
@var{cert-subject}
+...@findex spice_migrate_info
+Set the spice connection info for the migration target. The spice
+server will ask the spice client to automatically reconnect using the
+new parameters (if specified) once the vm migration finished
+successfully.
+ETEXI
+
+#if defined(CONFIG_SPICE)
+{
+.name = "spice_migrate_info",
+.args_type = "hostname:s,port:i?,tls-port:i?,cert-subject:s?",
+.params = "hostname port tls-port cert-subject",
+.help = "send migration info to spice client",
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = mon_spice_migrate,
+},
+#endif
+
+STEXI
@item snapshot_blkdev
@findex snapshot_blkdev
Snapshot device, using snapshot file as target if provided
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 56c4d8b..24ada04 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -503,6 +503,41 @@ EQMP
},
SQMP
+spice_migrate_info
+--
+
+Set the spice connection info for the migration target. The spice
+server will ask the spice client to automatically reconnect using the
+new parameters (if specified) once the vm migration finished
+successfully.
+
+Arguments:
+
+- "hostname": migration target hostname (json-string)
+- "port": spice tcp port for plaintext channels (json-int, optional)
+- "tls-port": spice tcp port for tls-secured channels (json-int, optional)
+- "cert-subject": server certificate subject (json-string, optional)
+
+Example:
+
+-> { "execute": "spice_migrate_info",
+ "arguments": { "hostname": "virt42.lab.kraxel.org", "port": 1234 } }
+<- { "return": {} }
+
+EQMP
+
+#if defined(CONFIG_SPICE)
+{
+.name = "spice_migrate_info",
+.args_type = "hostname:s,port:i?,tls-port:i?,cert-subject:s?",
+.params = "hostname port tls-port cert-subject",
+.help = "send migration info to spice client",
+.user_print = monitor_user_noop,
+.mhandler.cmd_new = mon_spice_migrate,
+},
+#endif
+
+SQMP
migrate_set_speed
-
diff --git a/ui/qemu-spice.h b/ui/qemu-spice.h
index 48239c3..13de5ad 100644
--- a/ui/qemu-spice.h
+++ b/ui/qemu-spice.h
@@ -38,6 +38,7 @@ int qemu_spice_set_pw_expire(time_t expires);
void do_info_spice_print(Monitor *mon, const QObject *data);
void do_info_spice(Monitor *mon, QObject **ret_data);
+int mon_spice_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data);
#else /* CONFIG_SPICE */
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 27a1ced..95116cc 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -30,11 +30,15 @@
#include "qbool.h"
#include "qstring.h"
#include "qjson.h"
+#include "notify.h"
+#include "migration.h"
#include "monitor.h"
+#include "hw/hw.h"
/* core bits */
static SpiceServer *spice_server;
+static Notifier migration_state;
static const char *auth = "spice";
static char *auth_passwd;
static time_t auth_expires = TIME_MAX;
@@ -416,6 +420,39 @@ void do_info_spice(Monitor *mon, QObject **ret_data)
*ret_data = QOBJECT(server);
}
+static void migration_state_notifier(Notifier *notifier)
+{
+int state = get_migration_state();
+
+if (state == MIG_STATE_COMPLETED) {
+#if SPICE_SERVER_VERSION >= 0x000701 /* 0.7.1 */
+spice_server_migrate_switch(spice_server);
+#endif
+}
+}
+
+int mon_spice_migrate(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+const char *hostname = qdict_get_str(qdict, "hostname");
+const char *subject = qdict_get_try_str(qdict, "cert-subject");
+int port = qdict_get_try_int(qdict, "port", -1);
+int tls_port = qdict_get_try_int(qdict, "tls-port", -1);
+int ret;
+
+if (!spice_server) {
+qerror_report(QERR_DEVICE_NOT_ACTIVE, "spice");
+return -1;
+}
+
+ret = spice_server_migrate_info(spice_server, hostname,
+port, tls_port, subject);
+if (ret != 0) {
+qerror_report(QERR_UNDEFINED_ERROR);
+return -1;
+}
+return 0;
+}
+
static int add_channel(const char *name, const char *value, void *opaque)
{
int security = 0;
@@ -573,6 +610,9 @@ void qemu_spice_init(void)
spice_server_init(spice_server, &core_interface);
using_spice = 1;
+migratio
[Qemu-devel] [PULL 0/6] spice patch queue
Hi, Here is a bunch of spice patches accumuled this year, they all have been on the list for review. please pull, Gerd The following changes since commit 8aaf42ed0f203da63860b0a3ab3ff2bdfe9b4cb0: slirp: fix unaligned access in bootp code (2011-01-10 10:56:25 +0100) are available in the git repository at: git://anongit.freedesktop.org/spice/qemu spice.v27.pull Alon Levy (1): spice: add chardev (v4) Gerd Hoffmann (4): add migration state change notifiers spice: client migration. spice: MAINTAINERS update spice/qxl: zap spice 0.4 migration compatibility bits Marc-André Lureau (1): vnc/spice: fix "never" and "now" expire_time MAINTAINERS |8 ++ Makefile.objs |2 +- hmp-commands.hx | 20 ++ hw/qxl.c | 79 +++ hw/qxl.h |4 - migration.c | 28 migration.h |5 ++ monitor.c |4 +- qemu-char.c |4 + qemu-config.c |6 ++ qemu-options.hx | 16 - qmp-commands.hx | 35 ++ spice-qemu-char.c | 185 + ui/qemu-spice.h |4 + ui/spice-core.c | 40 15 files changed, 363 insertions(+), 77 deletions(-) create mode 100644 spice-qemu-char.c
[Qemu-devel] [PATCH 5/6] spice/qxl: zap spice 0.4 migration compatibility bits
Live migration from and to spice 0.4 qxl devices isn't going to work.
Rip out the bits which attempt to support that. Zap the subsection
logic which is obsolete now. Bumb the version to make a clean cut.
This should obviously go in before 0.14 is released.
Signed-off-by: Gerd Hoffmann
---
hw/qxl.c | 79 --
hw/qxl.h |4 ---
2 files changed, 10 insertions(+), 73 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 207aa63..81be592 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1418,43 +1418,10 @@ static int qxl_post_load(void *opaque, int version)
}
dprint(d, 1, "%s: done\n", __FUNCTION__);
-/* spice 0.4 compatibility -- accept but ignore */
-qemu_free(d->worker_data);
-d->worker_data = NULL;
-d->worker_data_size = 0;
-
return 0;
}
-#define QXL_SAVE_VERSION 20
-
-static bool qxl_test_worker_data(void *opaque, int version_id)
-{
-PCIQXLDevice* d = opaque;
-
-if (d->revision != 1) {
-return false;
-}
-if (!d->worker_data_size) {
-return false;
-}
-if (!d->worker_data) {
-d->worker_data = qemu_malloc(d->worker_data_size);
-}
-return true;
-}
-
-static bool qxl_test_spice04(void *opaque, int version_id)
-{
-PCIQXLDevice* d = opaque;
-return d->revision == 1;
-}
-
-static bool qxl_test_spice06(void *opaque)
-{
-PCIQXLDevice* d = opaque;
-return d->revision > 1;
-}
+#define QXL_SAVE_VERSION 21
static VMStateDescription qxl_memslot = {
.name = "qxl-memslot",
@@ -1486,24 +1453,6 @@ static VMStateDescription qxl_surface = {
}
};
-static VMStateDescription qxl_vmstate_spice06 = {
-.name = "qxl/spice06",
-.version_id = QXL_SAVE_VERSION,
-.minimum_version_id = QXL_SAVE_VERSION,
-.fields = (VMStateField []) {
-VMSTATE_INT32_EQUAL(num_memslots, PCIQXLDevice),
-VMSTATE_STRUCT_ARRAY(guest_slots, PCIQXLDevice, NUM_MEMSLOTS, 0,
- qxl_memslot, struct guest_slots),
-VMSTATE_STRUCT(guest_primary.surface, PCIQXLDevice, 0,
- qxl_surface, QXLSurfaceCreate),
-VMSTATE_INT32_EQUAL(num_surfaces, PCIQXLDevice),
-VMSTATE_ARRAY(guest_surfaces.cmds, PCIQXLDevice, NUM_SURFACES, 0,
- vmstate_info_uint64, uint64_t),
-VMSTATE_UINT64(guest_cursor, PCIQXLDevice),
-VMSTATE_END_OF_LIST()
-},
-};
-
static VMStateDescription qxl_vmstate = {
.name = "qxl",
.version_id = QXL_SAVE_VERSION,
@@ -1519,25 +1468,17 @@ static VMStateDescription qxl_vmstate = {
VMSTATE_UINT32(last_release_offset, PCIQXLDevice),
VMSTATE_UINT32(mode, PCIQXLDevice),
VMSTATE_UINT32(ssd.unique, PCIQXLDevice),
-
-/* spice 0.4 sends/expects them */
-VMSTATE_VBUFFER_UINT32(vga.vram_ptr, PCIQXLDevice, 0,
qxl_test_spice04, 0,
- vga.vram_size),
-VMSTATE_UINT32_TEST(worker_data_size, PCIQXLDevice, qxl_test_spice04),
-VMSTATE_VBUFFER_UINT32(worker_data, PCIQXLDevice, 0,
qxl_test_worker_data, 0,
- worker_data_size),
-
+VMSTATE_INT32_EQUAL(num_memslots, PCIQXLDevice),
+VMSTATE_STRUCT_ARRAY(guest_slots, PCIQXLDevice, NUM_MEMSLOTS, 0,
+ qxl_memslot, struct guest_slots),
+VMSTATE_STRUCT(guest_primary.surface, PCIQXLDevice, 0,
+ qxl_surface, QXLSurfaceCreate),
+VMSTATE_INT32_EQUAL(num_surfaces, PCIQXLDevice),
+VMSTATE_ARRAY(guest_surfaces.cmds, PCIQXLDevice, NUM_SURFACES, 0,
+ vmstate_info_uint64, uint64_t),
+VMSTATE_UINT64(guest_cursor, PCIQXLDevice),
VMSTATE_END_OF_LIST()
},
-.subsections = (VMStateSubsection[]) {
-{
-/* additional spice 0.6 state */
-.vmsd = &qxl_vmstate_spice06,
-.needed = qxl_test_spice06,
-},{
-/* end of list */
-},
-},
};
static PCIDeviceInfo qxl_info_primary = {
diff --git a/hw/qxl.h b/hw/qxl.h
index 98e11ce..f6c450d 100644
--- a/hw/qxl.h
+++ b/hw/qxl.h
@@ -80,10 +80,6 @@ typedef struct PCIQXLDevice {
/* io bar */
uint32_t io_base;
-
-/* spice 0.4 loadvm compatibility */
-void *worker_data;
-uint32_t worker_data_size;
} PCIQXLDevice;
#define PANIC_ON(x) if ((x)) { \
--
1.7.1
[Qemu-devel] [PATCH 3/6] spice: MAINTAINERS update
Signed-off-by: Gerd Hoffmann --- MAINTAINERS |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 59effc7..25103dd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -383,6 +383,14 @@ S: Odd Fixes F: gdbstub* F: gdb-xml/ +SPICE +M: Gerd Hoffmann +S: Supported +F: ui/qemu-spice.h +F: ui/spice-*.c +F: audio/spiceaudio.c +F: hw/qxl* + Graphics M: Anthony Liguori S: Maintained -- 1.7.1
[Qemu-devel] Re: KVM call agenda for Jan 11
Juan Quintela wrote: > Juan Quintela wrote: > > Now sent it to the right kvm list. Sorry for the second sent. > >> Please send any agenda items you are interested in covering. >> >> - KVM Forum 2011 (Jes). >> >> thanks, Juan. - migration and block devices: a mess. * patches I sent last week: only work for root (for some definition of work) * qemu is used as non-root user. * forcing to have cache=none solves the issue * we use migrate not only for live migration, but also for save/resume. At this point only 4 ideas remaining: * -incoming-this-is-a-live-migration (or the opposite -incoming-this-is-a-restore-operation) * just forche cache=none if you want to call migration code. * let management app to do the right thing (it can check for cache=none) * do nothing and pray? Later, Juan.
[Qemu-devel] [PATCH 1/6] add migration state change notifiers
This patch adds functions to register and unregister notifiers for
migration state changes and a function to query the migration state.
The notifier is called on every state change. Once after establishing a
new migration object (which is in active state then) and once when the
state changes from active to completed, canceled or error.
Signed-off-by: Gerd Hoffmann
---
migration.c | 28
migration.h |5 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/migration.c b/migration.c
index e5ba51c..3f88666 100644
--- a/migration.c
+++ b/migration.c
@@ -36,6 +36,9 @@ static int64_t max_throttle = (32 << 20);
static MigrationState *current_migration;
+static NotifierList migration_state_notifiers =
+NOTIFIER_LIST_INITIALIZER(migration_state_notifiers);
+
int qemu_start_incoming_migration(const char *uri)
{
const char *p;
@@ -117,6 +120,7 @@ int do_migrate(Monitor *mon, const QDict *qdict, QObject
**ret_data)
}
current_migration = s;
+notifier_list_notify(&migration_state_notifiers);
return 0;
}
@@ -268,6 +272,7 @@ void migrate_fd_error(FdMigrationState *s)
{
DPRINTF("setting error state\n");
s->state = MIG_STATE_ERROR;
+notifier_list_notify(&migration_state_notifiers);
migrate_fd_cleanup(s);
}
@@ -325,6 +330,7 @@ ssize_t migrate_fd_put_buffer(void *opaque, const void
*data, size_t size)
monitor_resume(s->mon);
}
s->state = MIG_STATE_ERROR;
+notifier_list_notify(&migration_state_notifiers);
}
return ret;
@@ -385,6 +391,7 @@ void migrate_fd_put_ready(void *opaque)
state = MIG_STATE_ERROR;
}
s->state = state;
+notifier_list_notify(&migration_state_notifiers);
}
}
@@ -404,6 +411,7 @@ void migrate_fd_cancel(MigrationState *mig_state)
DPRINTF("cancelling migration\n");
s->state = MIG_STATE_CANCELLED;
+notifier_list_notify(&migration_state_notifiers);
qemu_savevm_state_cancel(s->mon, s->file);
migrate_fd_cleanup(s);
@@ -417,6 +425,7 @@ void migrate_fd_release(MigrationState *mig_state)
if (s->state == MIG_STATE_ACTIVE) {
s->state = MIG_STATE_CANCELLED;
+notifier_list_notify(&migration_state_notifiers);
migrate_fd_cleanup(s);
}
qemu_free(s);
@@ -448,3 +457,22 @@ int migrate_fd_close(void *opaque)
qemu_set_fd_handler2(s->fd, NULL, NULL, NULL, NULL);
return s->close(s);
}
+
+void add_migration_state_change_notifier(Notifier *notify)
+{
+notifier_list_add(&migration_state_notifiers, notify);
+}
+
+void remove_migration_state_change_notifier(Notifier *notify)
+{
+notifier_list_remove(&migration_state_notifiers, notify);
+}
+
+int get_migration_state(void)
+{
+if (current_migration) {
+return migrate_fd_get_status(current_migration);
+} else {
+return MIG_STATE_ERROR;
+}
+}
diff --git a/migration.h b/migration.h
index d13ed4f..2170792 100644
--- a/migration.h
+++ b/migration.h
@@ -16,6 +16,7 @@
#include "qdict.h"
#include "qemu-common.h"
+#include "notify.h"
#define MIG_STATE_ERROR-1
#define MIG_STATE_COMPLETED0
@@ -134,4 +135,8 @@ static inline FdMigrationState
*migrate_to_fms(MigrationState *mig_state)
return container_of(mig_state, FdMigrationState, mig_state);
}
+void add_migration_state_change_notifier(Notifier *notify);
+void remove_migration_state_change_notifier(Notifier *notify);
+int get_migration_state(void);
+
#endif
--
1.7.1
[Qemu-devel] [PATCH 6/6] spice: add chardev (v4)
From: Alon Levy
Adding a chardev backend for spice, where spice determines what
to do with it based on the name attribute given during chardev creation.
For usage by spice vdagent in conjunction with a properly named
virtio-serial device, and future smartcard channel usage.
Example usage:
qemu -device virtio-serial -chardev spicevmc,name=vdagent,id=vdagent \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0
v3->v4:
* updated commit message
v1->v3 changes: (v2 had a wrong commit message)
* removed spice-qemu-char.h, folded into ui/qemu-spice.h
* removed dead IOCTL code
* removed comment
* removed ifdef CONFIG_SPICE from qemu-config.c and qemu-options.hx help.
Signed-off-by: Gerd Hoffmann
---
Makefile.objs |2 +-
qemu-char.c |4 +
qemu-config.c |6 ++
qemu-options.hx | 16 -
spice-qemu-char.c | 185 +
ui/qemu-spice.h |3 +
6 files changed, 214 insertions(+), 2 deletions(-)
create mode 100644 spice-qemu-char.c
diff --git a/Makefile.objs b/Makefile.objs
index d6b3d60..d01a644 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -105,7 +105,7 @@ common-obj-$(CONFIG_BRLAPI) += baum.o
common-obj-$(CONFIG_POSIX) += migration-exec.o migration-unix.o migration-fd.o
common-obj-$(CONFIG_WIN32) += version.o
-common-obj-$(CONFIG_SPICE) += ui/spice-core.o ui/spice-input.o
ui/spice-display.o
+common-obj-$(CONFIG_SPICE) += ui/spice-core.o ui/spice-input.o
ui/spice-display.o spice-qemu-char.o
audio-obj-y = audio.o noaudio.o wavaudio.o mixeng.o
audio-obj-$(CONFIG_SDL) += sdlaudio.o
diff --git a/qemu-char.c b/qemu-char.c
index edc9ad6..acc7130 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -97,6 +97,7 @@
#endif
#include "qemu_socket.h"
+#include "ui/qemu-spice.h"
#define READ_BUF_LEN 4096
@@ -2495,6 +2496,9 @@ static const struct {
|| defined(__FreeBSD_kernel__)
{ .name = "parport", .open = qemu_chr_open_pp },
#endif
+#ifdef CONFIG_SPICE
+{ .name = "spicevmc", .open = qemu_chr_open_spice },
+#endif
};
CharDriverState *qemu_chr_open_opts(QemuOpts *opts,
diff --git a/qemu-config.c b/qemu-config.c
index 965fa46..323d3c2 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -146,6 +146,12 @@ static QemuOptsList qemu_chardev_opts = {
},{
.name = "signal",
.type = QEMU_OPT_BOOL,
+},{
+.name = "name",
+.type = QEMU_OPT_STRING,
+},{
+.name = "debug",
+.type = QEMU_OPT_NUMBER,
},
{ /* end of list */ }
},
diff --git a/qemu-options.hx b/qemu-options.hx
index 898561d..e0b76bd 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1368,6 +1368,9 @@ DEF("chardev", HAS_ARG, QEMU_OPTION_chardev,
#if defined(__linux__) || defined(__FreeBSD__) || defined(__DragonFly__)
"-chardev parport,id=id,path=path[,mux=on|off]\n"
#endif
+#if defined(CONFIG_SPICE)
+"-chardev spicevmc,id=id,debug=debug,name=name\n"
+#endif
, QEMU_ARCH_ALL
)
@@ -1392,7 +1395,8 @@ Backend is one of:
@option{stdio},
@option{braille},
@option{tty},
-...@option{parport}.
+...@option{parport}
+...@option{spicevmc}.
The specific backend will determine the applicable options.
All devices must have an id, which can be any string up to 127 characters long.
@@ -1568,6 +1572,16 @@ Connect to a local parallel port.
@option{path} specifies the path to the parallel port device. @option{path} is
required.
+#if defined(CONFIG_SPICE)
+...@item -chardev spicevmc ,i...@var{id} ,deb...@var{debug}, na...@var{name}
+
+...@option{debug} debug level for spicevmc
+
+...@option{name} name of spice channel to connect to
+
+Connect to a spice virtual machine channel, such as vdiport.
+#endif
+
@end table
ETEXI
diff --git a/spice-qemu-char.c b/spice-qemu-char.c
new file mode 100644
index 000..0ffa674
--- /dev/null
+++ b/spice-qemu-char.c
@@ -0,0 +1,185 @@
+#include "config-host.h"
+#include "ui/qemu-spice.h"
+#include
+#include
+
+#include "osdep.h"
+
+#define dprintf(_scd, _level, _fmt, ...)\
+do {\
+static unsigned __dprintf_counter = 0; \
+if (_scd->debug >= _level) {\
+fprintf(stderr, "scd: %3d: " _fmt, ++__dprintf_counter, ##
__VA_ARGS__);\
+} \
+} while (0)
+
+#define VMC_MAX_HOST_WRITE2048
+
+typedef struct SpiceCharDriver {
+CharDriverState* chr;
+SpiceCharDeviceInstance sin;
+char *subtype;
+bool active;
+uint8_t *buffer;
+uint8_t *datapos;
+ssize_t bufsize, datalen;
+uint32_t debug;
+} SpiceCharDriver;
+
+static int vmc_write(SpiceCharDeviceInstance *sin, const uint8_t *buf, int len)
+{
+
Re: [Qemu-devel] Re: KVM call agenda for Jan 11
On Mon, Jan 10, 2011 at 1:05 PM, Jes Sorensen wrote: > On 01/10/11 12:59, Juan Quintela wrote: >> Juan Quintela wrote: >> >> Now sent it to the right kvm list. Sorry for the second sent. >> >>> Please send any agenda items you are interested in covering. >>> >>> - KVM Forum 2011 (Jes). > > Just to add a bit more background. Last year we discussed the issue of > whether to aim for a KVM Forum in the same style as we had in 2010, or > whether to try to aim for a broader multi-track Virtualization > conference that covers the whole stack. > > Linux Foundation is happy to help host such an event, but they are > asking for what our plans are. I posted a mock-proposal for tracks here: > http://www.linux-kvm.org/page/KVM_Forum_2011 I thought having both KVM and Xen people at Linux Plumbers 2010 worked out well. Doing that with libvirt, OpenStack, etc has a lot of potential. Stefan
[Qemu-devel] Re: tcg/{ppc, s390, sparc}: branch target and code retranslation
On Mon, Jan 10, 2011 at 01:13:25PM +0100, Alexander Graf wrote: > > On 06.01.2011, at 23:12, Aurelien Jarno wrote: > > > Hi, > > > > I have just sent a tcg/arm patch concerning code retranslation. You > > might want to look at the description (copied below), as from a first > > glance ppc, s390 and sparc TCG targets might be affected. If you see > > guest kernel panics, some segmentation fault of qemu or in the guest, > > strange behaviors, that happen randomly and that looks difficult to > > debug it might be the issue. > > > > Aurelien > > > > > > | QEMU uses code retranslation to restore the CPU state when an exception > > | happens. For it to work the retranslation must not modify the generated > > | code. This is what is currently implemented in ARM TCG. > > | > > | However on CPU that don't have icache/dcache/memory synchronised like > > | ARM, this requirement is stronger and code retranslation must not modify > > | the generated code "atomically", as the cache line might be flushed > > | at any moment (interrupt, exception, task switching), even if not > > | triggered by QEMU. The probability for this to happen is very low, and > > | depends on cache size and associativiy, machine load, interrupts, so the > > | symptoms are might happen randomly. > > | > > | This requirement is currently not followed in tcg/arm, for the > > | load/store code, which basically has the following structure: > > | 1) tlb access code is written > > | 2) conditional fast path code is written > > | 3) branch is written with a temporary target > > | 4) slow path code is written > > | 5) branch target is updated > > | The cache lines corresponding to the retranslated code is not flushed > > | after code retranslation as the generated code is supposed to be the > > | same. However if the cache line corresponding to the branch instruction > > | is flushed between step 3 and 5, and is not flushed again before the > > | code is executed again, the branch target is wrong. In the guest, the > > | symptoms are MMU page fault at a random addresses, which leads to > > | kernel page fault or segmentation faults. > > I don't see the problem. If you have separate icache from dcache, the code in > question doesn't get executed during the rewrite, so all should be fine. If > you have both combined, the data write should automatically modify the cache > line, so all is great too. As far as I understand, this is what happens to the branch target instruction, or at least one possibility: operation | icache | dcache | mem/L2 | --++++ tlb access code is written| absent | absent | ok | conditional fast path code is written | absent | absent | ok | branch is written with a temporary target | absent | wrong | ok | cache line is flushed to memory | absent | absent | wrong | slow path code is written | absent | absent | wrong | branch target is updated | absent | ok | wrong | TB is re-executed | wrong | ok | wrong | Note that the issue is real, the patch really fixes the issue on ARM and MIPS. It's not impossible that I don't fully understand it given I can't analyse the cache values at a given time. However, when QEMU crashes because of that, we have seen that the executed code doesn't match what GDB says, and changing the temporary branch value also changes the way QEMU or the guest crash. The problem doesn't happens very often though (for sure less than 1 every few millions). The other way to fix it is to issue a cache flush after a code retranslation, however, it is something very costly on some architectures. > As long as the code in question doesn't get run in between, I don't see where > breakage could occur? The breakage can occur, because the same TB can be re-executed later, and we don't have an explicit cache flush after the retranslation. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: tcg/{ppc, s390, sparc}: branch target and code retranslation
On 10.01.2011, at 15:00, Aurelien Jarno wrote: > On Mon, Jan 10, 2011 at 01:13:25PM +0100, Alexander Graf wrote: >> >> On 06.01.2011, at 23:12, Aurelien Jarno wrote: >> >>> Hi, >>> >>> I have just sent a tcg/arm patch concerning code retranslation. You >>> might want to look at the description (copied below), as from a first >>> glance ppc, s390 and sparc TCG targets might be affected. If you see >>> guest kernel panics, some segmentation fault of qemu or in the guest, >>> strange behaviors, that happen randomly and that looks difficult to >>> debug it might be the issue. >>> >>> Aurelien >>> >>> >>> | QEMU uses code retranslation to restore the CPU state when an exception >>> | happens. For it to work the retranslation must not modify the generated >>> | code. This is what is currently implemented in ARM TCG. >>> | >>> | However on CPU that don't have icache/dcache/memory synchronised like >>> | ARM, this requirement is stronger and code retranslation must not modify >>> | the generated code "atomically", as the cache line might be flushed >>> | at any moment (interrupt, exception, task switching), even if not >>> | triggered by QEMU. The probability for this to happen is very low, and >>> | depends on cache size and associativiy, machine load, interrupts, so the >>> | symptoms are might happen randomly. >>> | >>> | This requirement is currently not followed in tcg/arm, for the >>> | load/store code, which basically has the following structure: >>> | 1) tlb access code is written >>> | 2) conditional fast path code is written >>> | 3) branch is written with a temporary target >>> | 4) slow path code is written >>> | 5) branch target is updated >>> | The cache lines corresponding to the retranslated code is not flushed >>> | after code retranslation as the generated code is supposed to be the >>> | same. However if the cache line corresponding to the branch instruction >>> | is flushed between step 3 and 5, and is not flushed again before the >>> | code is executed again, the branch target is wrong. In the guest, the >>> | symptoms are MMU page fault at a random addresses, which leads to >>> | kernel page fault or segmentation faults. >> >> I don't see the problem. If you have separate icache from dcache, the code >> in question doesn't get executed during the rewrite, so all should be fine. >> If you have both combined, the data write should automatically modify the >> cache line, so all is great too. > > As far as I understand, this is what happens to the branch target > instruction, or at least one possibility: > > operation | icache | dcache | mem/L2 | > --++++ > tlb access code is written| absent | absent | ok | > conditional fast path code is written | absent | absent | ok | > branch is written with a temporary target | absent | wrong | ok | > cache line is flushed to memory | absent | absent | wrong | > slow path code is written | absent | absent | wrong | > branch target is updated | absent | ok | wrong | > TB is re-executed | wrong | ok | wrong | > > Note that the issue is real, the patch really fixes the issue on ARM and > MIPS. It's not impossible that I don't fully understand it given I can't > analyse the cache values at a given time. However, when QEMU crashes > because of that, we have seen that the executed code doesn't match what > GDB says, and changing the temporary branch value also changes the way > QEMU or the guest crash. > > The problem doesn't happens very often though (for sure less than 1 > every few millions). The other way to fix it is to issue a cache flush > after a code retranslation, however, it is something very costly on some > architectures. I'd guess it only happens when code is overwritten. Only then icache can still be stale in that code region. Can't we just invalidate the icache on every tb flush? That should also fix the issue I'd guess. > >> As long as the code in question doesn't get run in between, I don't see >> where breakage could occur? > > The breakage can occur, because the same TB can be re-executed later, > and we don't have an explicit cache flush after the retranslation. Oh, I think I'm starting to understand the issue. Have you seen this with system or user emulation? I'd guess with user it makes sense: [T1] trap [T2] run code [T1] write branch code to find guest IP [T2] run exactly that branch code [T1] rewrite branch code [T2] has invalid code in its cache If that's the case, a global lock on retranslation should do the trick, no? If it was during system emulation, I'm still puzzled :). Alex
[Qemu-devel] Re: tcg/{ppc, s390, sparc}: branch target and code retranslation
On Mon, Jan 10, 2011 at 03:07:52PM +0100, Alexander Graf wrote: > > On 10.01.2011, at 15:00, Aurelien Jarno wrote: > > > On Mon, Jan 10, 2011 at 01:13:25PM +0100, Alexander Graf wrote: > >> > >> On 06.01.2011, at 23:12, Aurelien Jarno wrote: > >> > >>> Hi, > >>> > >>> I have just sent a tcg/arm patch concerning code retranslation. You > >>> might want to look at the description (copied below), as from a first > >>> glance ppc, s390 and sparc TCG targets might be affected. If you see > >>> guest kernel panics, some segmentation fault of qemu or in the guest, > >>> strange behaviors, that happen randomly and that looks difficult to > >>> debug it might be the issue. > >>> > >>> Aurelien > >>> > >>> > >>> | QEMU uses code retranslation to restore the CPU state when an exception > >>> | happens. For it to work the retranslation must not modify the generated > >>> | code. This is what is currently implemented in ARM TCG. > >>> | > >>> | However on CPU that don't have icache/dcache/memory synchronised like > >>> | ARM, this requirement is stronger and code retranslation must not modify > >>> | the generated code "atomically", as the cache line might be flushed > >>> | at any moment (interrupt, exception, task switching), even if not > >>> | triggered by QEMU. The probability for this to happen is very low, and > >>> | depends on cache size and associativiy, machine load, interrupts, so the > >>> | symptoms are might happen randomly. > >>> | > >>> | This requirement is currently not followed in tcg/arm, for the > >>> | load/store code, which basically has the following structure: > >>> | 1) tlb access code is written > >>> | 2) conditional fast path code is written > >>> | 3) branch is written with a temporary target > >>> | 4) slow path code is written > >>> | 5) branch target is updated > >>> | The cache lines corresponding to the retranslated code is not flushed > >>> | after code retranslation as the generated code is supposed to be the > >>> | same. However if the cache line corresponding to the branch instruction > >>> | is flushed between step 3 and 5, and is not flushed again before the > >>> | code is executed again, the branch target is wrong. In the guest, the > >>> | symptoms are MMU page fault at a random addresses, which leads to > >>> | kernel page fault or segmentation faults. > >> > >> I don't see the problem. If you have separate icache from dcache, the code > >> in question doesn't get executed during the rewrite, so all should be > >> fine. If you have both combined, the data write should automatically > >> modify the cache line, so all is great too. > > > > As far as I understand, this is what happens to the branch target > > instruction, or at least one possibility: > > > > operation | icache | dcache | mem/L2 | > > --++++ > > tlb access code is written| absent | absent | ok | > > conditional fast path code is written | absent | absent | ok | > > branch is written with a temporary target | absent | wrong | ok | > > cache line is flushed to memory | absent | absent | wrong | > > slow path code is written | absent | absent | wrong | > > branch target is updated | absent | ok | wrong | > > TB is re-executed | wrong | ok | wrong | > > > > Note that the issue is real, the patch really fixes the issue on ARM and > > MIPS. It's not impossible that I don't fully understand it given I can't > > analyse the cache values at a given time. However, when QEMU crashes > > because of that, we have seen that the executed code doesn't match what > > GDB says, and changing the temporary branch value also changes the way > > QEMU or the guest crash. > > > > The problem doesn't happens very often though (for sure less than 1 > > every few millions). The other way to fix it is to issue a cache flush > > after a code retranslation, however, it is something very costly on some > > architectures. > > I'd guess it only happens when code is overwritten. Only then icache can > still be stale in that code region. Can't we just invalidate the icache on > every tb flush? That should also fix the issue I'd guess. That's a solution that works (tested). However making sure that the retranslation doesn't change the code looks better. > > > >> As long as the code in question doesn't get run in between, I don't see > >> where breakage could occur? > > > > The breakage can occur, because the same TB can be re-executed later, > > and we don't have an explicit cache flush after the retranslation. > > Oh, I think I'm starting to understand the issue. Have you seen this with > system or user emulation? I'd guess with user it makes sense: > > [T1] trap > [T2] run code > [T1] write branch code to find guest IP > [T2] run exactly that branch code > [T1] rewrite branch code > [T2] has invalid
[Qemu-devel] Re: tcg/{ppc, s390, sparc}: branch target and code retranslation
On 10.01.2011, at 15:15, Aurelien Jarno wrote: > On Mon, Jan 10, 2011 at 03:07:52PM +0100, Alexander Graf wrote: >> >> On 10.01.2011, at 15:00, Aurelien Jarno wrote: >> >>> On Mon, Jan 10, 2011 at 01:13:25PM +0100, Alexander Graf wrote: On 06.01.2011, at 23:12, Aurelien Jarno wrote: > Hi, > > I have just sent a tcg/arm patch concerning code retranslation. You > might want to look at the description (copied below), as from a first > glance ppc, s390 and sparc TCG targets might be affected. If you see > guest kernel panics, some segmentation fault of qemu or in the guest, > strange behaviors, that happen randomly and that looks difficult to > debug it might be the issue. > > Aurelien > > > | QEMU uses code retranslation to restore the CPU state when an exception > | happens. For it to work the retranslation must not modify the generated > | code. This is what is currently implemented in ARM TCG. > | > | However on CPU that don't have icache/dcache/memory synchronised like > | ARM, this requirement is stronger and code retranslation must not modify > | the generated code "atomically", as the cache line might be flushed > | at any moment (interrupt, exception, task switching), even if not > | triggered by QEMU. The probability for this to happen is very low, and > | depends on cache size and associativiy, machine load, interrupts, so the > | symptoms are might happen randomly. > | > | This requirement is currently not followed in tcg/arm, for the > | load/store code, which basically has the following structure: > | 1) tlb access code is written > | 2) conditional fast path code is written > | 3) branch is written with a temporary target > | 4) slow path code is written > | 5) branch target is updated > | The cache lines corresponding to the retranslated code is not flushed > | after code retranslation as the generated code is supposed to be the > | same. However if the cache line corresponding to the branch instruction > | is flushed between step 3 and 5, and is not flushed again before the > | code is executed again, the branch target is wrong. In the guest, the > | symptoms are MMU page fault at a random addresses, which leads to > | kernel page fault or segmentation faults. I don't see the problem. If you have separate icache from dcache, the code in question doesn't get executed during the rewrite, so all should be fine. If you have both combined, the data write should automatically modify the cache line, so all is great too. >>> >>> As far as I understand, this is what happens to the branch target >>> instruction, or at least one possibility: >>> >>> operation | icache | dcache | mem/L2 | >>> --++++ >>> tlb access code is written| absent | absent | ok | >>> conditional fast path code is written | absent | absent | ok | >>> branch is written with a temporary target | absent | wrong | ok | >>> cache line is flushed to memory | absent | absent | wrong | >>> slow path code is written | absent | absent | wrong | >>> branch target is updated | absent | ok | wrong | >>> TB is re-executed | wrong | ok | wrong | >>> >>> Note that the issue is real, the patch really fixes the issue on ARM and >>> MIPS. It's not impossible that I don't fully understand it given I can't >>> analyse the cache values at a given time. However, when QEMU crashes >>> because of that, we have seen that the executed code doesn't match what >>> GDB says, and changing the temporary branch value also changes the way >>> QEMU or the guest crash. >>> >>> The problem doesn't happens very often though (for sure less than 1 >>> every few millions). The other way to fix it is to issue a cache flush >>> after a code retranslation, however, it is something very costly on some >>> architectures. >> >> I'd guess it only happens when code is overwritten. Only then icache can >> still be stale in that code region. Can't we just invalidate the icache on >> every tb flush? That should also fix the issue I'd guess. > > That's a solution that works (tested). However making sure that the > retranslation doesn't change the code looks better. Yeah, I agree. Temporary retranslation really shouldn't modify existing code. We really do need an icache flush on tb flushes still though as that's a separate issue? Or are these already in? Alex
[Qemu-devel] Re: tcg/{ppc, s390, sparc}: branch target and code retranslation
On Mon, Jan 10, 2011 at 03:20:40PM +0100, Alexander Graf wrote: > > On 10.01.2011, at 15:15, Aurelien Jarno wrote: > > > On Mon, Jan 10, 2011 at 03:07:52PM +0100, Alexander Graf wrote: > >> > >> On 10.01.2011, at 15:00, Aurelien Jarno wrote: > >> > >>> On Mon, Jan 10, 2011 at 01:13:25PM +0100, Alexander Graf wrote: > > On 06.01.2011, at 23:12, Aurelien Jarno wrote: > > > Hi, > > > > I have just sent a tcg/arm patch concerning code retranslation. You > > might want to look at the description (copied below), as from a first > > glance ppc, s390 and sparc TCG targets might be affected. If you see > > guest kernel panics, some segmentation fault of qemu or in the guest, > > strange behaviors, that happen randomly and that looks difficult to > > debug it might be the issue. > > > > Aurelien > > > > > > | QEMU uses code retranslation to restore the CPU state when an > > exception > > | happens. For it to work the retranslation must not modify the > > generated > > | code. This is what is currently implemented in ARM TCG. > > | > > | However on CPU that don't have icache/dcache/memory synchronised like > > | ARM, this requirement is stronger and code retranslation must not > > modify > > | the generated code "atomically", as the cache line might be flushed > > | at any moment (interrupt, exception, task switching), even if not > > | triggered by QEMU. The probability for this to happen is very low, and > > | depends on cache size and associativiy, machine load, interrupts, so > > the > > | symptoms are might happen randomly. > > | > > | This requirement is currently not followed in tcg/arm, for the > > | load/store code, which basically has the following structure: > > | 1) tlb access code is written > > | 2) conditional fast path code is written > > | 3) branch is written with a temporary target > > | 4) slow path code is written > > | 5) branch target is updated > > | The cache lines corresponding to the retranslated code is not flushed > > | after code retranslation as the generated code is supposed to be the > > | same. However if the cache line corresponding to the branch > > instruction > > | is flushed between step 3 and 5, and is not flushed again before the > > | code is executed again, the branch target is wrong. In the guest, the > > | symptoms are MMU page fault at a random addresses, which leads to > > | kernel page fault or segmentation faults. > > I don't see the problem. If you have separate icache from dcache, the > code in question doesn't get executed during the rewrite, so all should > be fine. If you have both combined, the data write should automatically > modify the cache line, so all is great too. > >>> > >>> As far as I understand, this is what happens to the branch target > >>> instruction, or at least one possibility: > >>> > >>> operation | icache | dcache | mem/L2 | > >>> --++++ > >>> tlb access code is written| absent | absent | ok | > >>> conditional fast path code is written | absent | absent | ok | > >>> branch is written with a temporary target | absent | wrong | ok | > >>> cache line is flushed to memory | absent | absent | wrong | > >>> slow path code is written | absent | absent | wrong | > >>> branch target is updated | absent | ok | wrong | > >>> TB is re-executed | wrong | ok | wrong | > >>> > >>> Note that the issue is real, the patch really fixes the issue on ARM and > >>> MIPS. It's not impossible that I don't fully understand it given I can't > >>> analyse the cache values at a given time. However, when QEMU crashes > >>> because of that, we have seen that the executed code doesn't match what > >>> GDB says, and changing the temporary branch value also changes the way > >>> QEMU or the guest crash. > >>> > >>> The problem doesn't happens very often though (for sure less than 1 > >>> every few millions). The other way to fix it is to issue a cache flush > >>> after a code retranslation, however, it is something very costly on some > >>> architectures. > >> > >> I'd guess it only happens when code is overwritten. Only then icache can > >> still be stale in that code region. Can't we just invalidate the icache on > >> every tb flush? That should also fix the issue I'd guess. > > > > That's a solution that works (tested). However making sure that the > > retranslation doesn't change the code looks better. > > Yeah, I agree. Temporary retranslation really shouldn't modify existing code. > We really do need an icache flush on tb flushes still though as that's a > separate issue? Or are these already in? > We already ha
[Qemu-devel] Re: tcg/{ppc, s390, sparc}: branch target and code retranslation
On 10.01.2011, at 15:23, Aurelien Jarno wrote: > On Mon, Jan 10, 2011 at 03:20:40PM +0100, Alexander Graf wrote: >> >> On 10.01.2011, at 15:15, Aurelien Jarno wrote: >> >>> On Mon, Jan 10, 2011 at 03:07:52PM +0100, Alexander Graf wrote: On 10.01.2011, at 15:00, Aurelien Jarno wrote: > On Mon, Jan 10, 2011 at 01:13:25PM +0100, Alexander Graf wrote: >> >> On 06.01.2011, at 23:12, Aurelien Jarno wrote: >> >>> Hi, >>> >>> I have just sent a tcg/arm patch concerning code retranslation. You >>> might want to look at the description (copied below), as from a first >>> glance ppc, s390 and sparc TCG targets might be affected. If you see >>> guest kernel panics, some segmentation fault of qemu or in the guest, >>> strange behaviors, that happen randomly and that looks difficult to >>> debug it might be the issue. >>> >>> Aurelien >>> >>> >>> | QEMU uses code retranslation to restore the CPU state when an >>> exception >>> | happens. For it to work the retranslation must not modify the >>> generated >>> | code. This is what is currently implemented in ARM TCG. >>> | >>> | However on CPU that don't have icache/dcache/memory synchronised like >>> | ARM, this requirement is stronger and code retranslation must not >>> modify >>> | the generated code "atomically", as the cache line might be flushed >>> | at any moment (interrupt, exception, task switching), even if not >>> | triggered by QEMU. The probability for this to happen is very low, and >>> | depends on cache size and associativiy, machine load, interrupts, so >>> the >>> | symptoms are might happen randomly. >>> | >>> | This requirement is currently not followed in tcg/arm, for the >>> | load/store code, which basically has the following structure: >>> | 1) tlb access code is written >>> | 2) conditional fast path code is written >>> | 3) branch is written with a temporary target >>> | 4) slow path code is written >>> | 5) branch target is updated >>> | The cache lines corresponding to the retranslated code is not flushed >>> | after code retranslation as the generated code is supposed to be the >>> | same. However if the cache line corresponding to the branch >>> instruction >>> | is flushed between step 3 and 5, and is not flushed again before the >>> | code is executed again, the branch target is wrong. In the guest, the >>> | symptoms are MMU page fault at a random addresses, which leads to >>> | kernel page fault or segmentation faults. >> >> I don't see the problem. If you have separate icache from dcache, the >> code in question doesn't get executed during the rewrite, so all should >> be fine. If you have both combined, the data write should automatically >> modify the cache line, so all is great too. > > As far as I understand, this is what happens to the branch target > instruction, or at least one possibility: > > operation | icache | dcache | mem/L2 | > --++++ > tlb access code is written| absent | absent | ok | > conditional fast path code is written | absent | absent | ok | > branch is written with a temporary target | absent | wrong | ok | > cache line is flushed to memory | absent | absent | wrong | > slow path code is written | absent | absent | wrong | > branch target is updated | absent | ok | wrong | > TB is re-executed | wrong | ok | wrong | > > Note that the issue is real, the patch really fixes the issue on ARM and > MIPS. It's not impossible that I don't fully understand it given I can't > analyse the cache values at a given time. However, when QEMU crashes > because of that, we have seen that the executed code doesn't match what > GDB says, and changing the temporary branch value also changes the way > QEMU or the guest crash. > > The problem doesn't happens very often though (for sure less than 1 > every few millions). The other way to fix it is to issue a cache flush > after a code retranslation, however, it is something very costly on some > architectures. I'd guess it only happens when code is overwritten. Only then icache can still be stale in that code region. Can't we just invalidate the icache on every tb flush? That should also fix the issue I'd guess. >>> >>> That's a solution that works (tested). However making sure that the >>> retranslation doesn't change the code looks better. >> >> Yeah, I agree. Temporary retranslation really shouldn't modify existing >> code. We really do need an icache flush on tb flushes still though as that's >> a
Re: [Qemu-devel] [PATCH 1/4] qdev: Add a description field for qdev properties for documentation
Amit Shah writes:
[...]
> diff --git a/hw/qdev.c b/hw/qdev.c
> index 6fc9b02..168d0f6 100644
> --- a/hw/qdev.c
> +++ b/hw/qdev.c
> @@ -185,7 +185,8 @@ int qdev_device_help(QemuOpts *opts)
> if (!prop->info->parse) {
> continue; /* no way to set it, don't show */
> }
> -error_printf("%s.%s=%s\n", info->name, prop->name, prop->info->name);
> +error_printf("%s.%s=%s, %s\n", info->name, prop->name,
> + prop->info->name, prop->desc ?: "");
> }
> return 1;
> }
Output could be made prettier (align the help texts). Preferrably in a
follow-up commit, because this one's seen enough respins already.
[...]
Re: [Qemu-devel] [PATCH 0/5] usb-ccid (v14)
On Mon, Jan 10, 2011 at 01:44:32PM +0100, Gerd Hoffmann wrote: > On 01/08/11 11:28, Alon Levy wrote: > >This patchset adds three new devices, usb-ccid, ccid-card-passthru and > >ccid-card-emulated, providing a CCID bus, a simple passthru protocol > >implementing card requiring a client, and a standalone emulated card. > > > >It also introduces a new directory libcaccard with CAC card emulation, > >CAC is a type of ISO 7816 smart card. > > > >Tree for pull: git://anongit.freedesktop.org/~alon/qemu usb_ccid.v14 > > One nit left which I didn't notice on previous reviews: It can't be > disabled at compile time, there is no --disable-smartcard switch. > The nss detection needs some tweaks too. The usual configure > behavior in qemu is this: > > [ no smarccard option specified ] > autodetect, i.e. enable smartcard if nss support is found, > otherwise disable (i.e. what your patch does now). > --disable-smartcard > turn off smartcard support. > --enable-smartcard > force smartcard support on, if nss isn't present abort > configure with an error message. > > Otherwise it looks works nicely. Good job. Blue Swirl asked me to remove them at v8, so v9+ don't have them. Blue Swirl - with or without? > > cheers, > Gerd
[Qemu-devel] Re: tcg/{ppc, s390, sparc}: branch target and code retranslation
On Mon, Jan 10, 2011 at 03:29:28PM +0100, Alexander Graf wrote: > > On 10.01.2011, at 15:23, Aurelien Jarno wrote: > > > On Mon, Jan 10, 2011 at 03:20:40PM +0100, Alexander Graf wrote: > >> > >> On 10.01.2011, at 15:15, Aurelien Jarno wrote: > >> > >>> On Mon, Jan 10, 2011 at 03:07:52PM +0100, Alexander Graf wrote: > > On 10.01.2011, at 15:00, Aurelien Jarno wrote: > > > On Mon, Jan 10, 2011 at 01:13:25PM +0100, Alexander Graf wrote: > >> > >> On 06.01.2011, at 23:12, Aurelien Jarno wrote: > >> > >>> Hi, > >>> > >>> I have just sent a tcg/arm patch concerning code retranslation. You > >>> might want to look at the description (copied below), as from a first > >>> glance ppc, s390 and sparc TCG targets might be affected. If you see > >>> guest kernel panics, some segmentation fault of qemu or in the guest, > >>> strange behaviors, that happen randomly and that looks difficult to > >>> debug it might be the issue. > >>> > >>> Aurelien > >>> > >>> > >>> | QEMU uses code retranslation to restore the CPU state when an > >>> exception > >>> | happens. For it to work the retranslation must not modify the > >>> generated > >>> | code. This is what is currently implemented in ARM TCG. > >>> | > >>> | However on CPU that don't have icache/dcache/memory synchronised > >>> like > >>> | ARM, this requirement is stronger and code retranslation must not > >>> modify > >>> | the generated code "atomically", as the cache line might be flushed > >>> | at any moment (interrupt, exception, task switching), even if not > >>> | triggered by QEMU. The probability for this to happen is very low, > >>> and > >>> | depends on cache size and associativiy, machine load, interrupts, > >>> so the > >>> | symptoms are might happen randomly. > >>> | > >>> | This requirement is currently not followed in tcg/arm, for the > >>> | load/store code, which basically has the following structure: > >>> | 1) tlb access code is written > >>> | 2) conditional fast path code is written > >>> | 3) branch is written with a temporary target > >>> | 4) slow path code is written > >>> | 5) branch target is updated > >>> | The cache lines corresponding to the retranslated code is not > >>> flushed > >>> | after code retranslation as the generated code is supposed to be the > >>> | same. However if the cache line corresponding to the branch > >>> instruction > >>> | is flushed between step 3 and 5, and is not flushed again before the > >>> | code is executed again, the branch target is wrong. In the guest, > >>> the > >>> | symptoms are MMU page fault at a random addresses, which leads to > >>> | kernel page fault or segmentation faults. > >> > >> I don't see the problem. If you have separate icache from dcache, the > >> code in question doesn't get executed during the rewrite, so all > >> should be fine. If you have both combined, the data write should > >> automatically modify the cache line, so all is great too. > > > > As far as I understand, this is what happens to the branch target > > instruction, or at least one possibility: > > > > operation | icache | dcache | mem/L2 | > > --++++ > > tlb access code is written| absent | absent | ok | > > conditional fast path code is written | absent | absent | ok | > > branch is written with a temporary target | absent | wrong | ok | > > cache line is flushed to memory | absent | absent | wrong | > > slow path code is written | absent | absent | wrong | > > branch target is updated | absent | ok | wrong | > > TB is re-executed | wrong | ok | wrong | > > > > Note that the issue is real, the patch really fixes the issue on ARM and > > MIPS. It's not impossible that I don't fully understand it given I can't > > analyse the cache values at a given time. However, when QEMU crashes > > because of that, we have seen that the executed code doesn't match what > > GDB says, and changing the temporary branch value also changes the way > > QEMU or the guest crash. > > > > The problem doesn't happens very often though (for sure less than 1 > > every few millions). The other way to fix it is to issue a cache flush > > after a code retranslation, however, it is something very costly on some > > architectures. > > I'd guess it only happens when code is overwritten. Only then icache can > still be stale in that code region. Can't we just invalidate the icache > on every tb flush? That should also fix the issue I'd guess. > >>>
Re: [Qemu-devel] [PATCH 2/4] virtio-serial: Add description fields for qdev properties
Amit Shah writes:
> Document the parameters for the virtserialport and virtioconsole
> devices.
>
> Example:
>
> $ ./x86_64-softmmu/qemu-system-x86_64 -device virtserialport,?
> virtserialport.nr=uint32, The 'number' for the port for \
> predictable port numbers. Use this to spawn ports if you \
> plan to migrate the guest.
>
> virtserialport.chardev=chr, The chardev to associate this port with.
>
> virtserialport.name=string, Name for the port that's exposed to \
> the guest for port discovery.
>
> Signed-off-by: Amit Shah
> ---
> hw/virtio-console.c | 17 ++---
> hw/virtio-serial.h | 13 +
> 2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/hw/virtio-console.c b/hw/virtio-console.c
> index ccd277a..8a99a99 100644
> --- a/hw/virtio-console.c
> +++ b/hw/virtio-console.c
> @@ -95,11 +95,13 @@ static VirtIOSerialPortInfo virtconsole_info = {
> .init = virtconsole_initfn,
> .exit = virtconsole_exitfn,
> .qdev.props = (Property[]) {
> -DEFINE_PROP_UINT8("is_console", VirtConsole, port.is_console, 1, ""),
> +DEFINE_PROP_UINT8("is_console", VirtConsole, port.is_console, 1,
> + PROP_VIRTSERIAL_IS_CONSOLE_DESC),
> DEFINE_PROP_UINT32("nr", VirtConsole, port.id, VIRTIO_CONSOLE_BAD_ID,
> - ""),
> -DEFINE_PROP_CHR("chardev", VirtConsole, chr, ""),
> -DEFINE_PROP_STRING("name", VirtConsole, port.name, ""),
> + PROP_VIRTSERIAL_NR_DESC),
> +DEFINE_PROP_CHR("chardev", VirtConsole, chr,
> PROP_VIRTSERIAL_CHR_DESC),
> +DEFINE_PROP_STRING("name", VirtConsole, port.name,
> + PROP_VIRTSERIAL_NAME_DESC),
> DEFINE_PROP_END_OF_LIST(),
> },
> };
> @@ -133,9 +135,10 @@ static VirtIOSerialPortInfo virtserialport_info = {
> .exit = virtconsole_exitfn,
> .qdev.props = (Property[]) {
> DEFINE_PROP_UINT32("nr", VirtConsole, port.id, VIRTIO_CONSOLE_BAD_ID,
> - ""),
> -DEFINE_PROP_CHR("chardev", VirtConsole, chr, ""),
> -DEFINE_PROP_STRING("name", VirtConsole, port.name, ""),
> + PROP_VIRTSERIAL_NR_DESC),
> +DEFINE_PROP_CHR("chardev", VirtConsole, chr,
> PROP_VIRTSERIAL_CHR_DESC),
> +DEFINE_PROP_STRING("name", VirtConsole, port.name,
> + PROP_VIRTSERIAL_NAME_DESC),
> DEFINE_PROP_END_OF_LIST(),
> },
> };
> diff --git a/hw/virtio-serial.h b/hw/virtio-serial.h
> index ff08c40..187d5e4 100644
> --- a/hw/virtio-serial.h
> +++ b/hw/virtio-serial.h
> @@ -57,6 +57,19 @@ struct virtio_console_control {
>
> /* == In-qemu interface == */
>
> +#define PROP_VIRTSERIAL_IS_CONSOLE_DESC \
> +"An hvc console will be spawned in the guest if this is set."
> +
> +#define PROP_VIRTSERIAL_NR_DESC \
> +"The 'number' for the port for predictable port numbers. Use this to " \
> +"spawn ports if you plan to migrate the guest."
> +
> +#define PROP_VIRTSERIAL_CHR_DESC\
> +"The chardev to associate this port with."
> +
> +#define PROP_VIRTSERIAL_NAME_DESC\
> +"Name for the port that's exposed to the guest for port discovery."
> +
> typedef struct VirtIOSerial VirtIOSerial;
> typedef struct VirtIOSerialBus VirtIOSerialBus;
> typedef struct VirtIOSerialPort VirtIOSerialPort;
Let me elaborate on my comment asking for prettier output. Here's how I
expect -virtconsole,\? look like with your code:
virtconsole.is_console=uint8, An hvc console will be spawned in the guest if
this is set.
virtconsole.nr=uint32, The 'number' for the port for predictable port numbers.
Use this to spawn ports if you plan to migrate the guest.
virtconsole.chardev=chr, The chardev to associate this port with.
virtconsole.name=string, Name for the port that's exposed to the guest for port
discovery.
Long lines, hard to read.
By the way, properties without a description are printed with a trailing
", ". I find that irritating.
We can do better by adopting suitable conventions for the help text, say
"first line is a brief description (50 characters max), like a headline
(no sentence-ending period), following lines (if any) are 70 characters
max."
Then we print it like this:
virtconsole.nr=uint32First line, 50 characters max., just like this one
More lines (if any)
When the X=Y part is long, we can break like this:
virtconsole.is_console=uint8
First line, 50 characters max., just like this one
More lines (if any)
or maybe
virtconsole.is_console=uint8
First line, 50 characters max., just like this one
More lines (if any)
Re: [Qemu-devel] [PATCH 0/4] [RESEND] [REBASE] Auto-document qdev devices
Amit Shah writes: > Hello, > > This is yet another rebase of the patchset I'd sent earlier. > > Changes: > - fixups and new strings for the bootorder patches > - new string for the discard property for block devices. > > The usual notes apply: this is just the start, just getting the > framework in place and a few examples so that people can then pick up > and start documenting their devices and options. We want to see all > of the devices covered, and hopefully turn on build_bug_on() on an > empty doc string. > > Maintainers should perhaps also look for patches that introduce > options without documentation. > > That's the long-term goal (over 0.14). For short-term, I'll be > preparing follow-on patches that add doc strings for a few more > options and perhaps bug people based on git history as to what > documentation is to be added for some options. > > The earlier this patchset goes in the better since it'll reduce > conflicts and rebases needed. > > If this looks acceptable, please apply! This has been stuck since forever. No idea why, it's neither hairy nor controversial. Quoting from my review of v2(?) last September: For QMP, we'll need to cover more than just device properties, and in more detail than just a help text, but this looks like a sensible step forward. I'm fine with committing it as is. We can polish in follow-up commits.
Re: [Qemu-devel] Re: tcg/{ppc, s390, sparc}: branch target and code retranslation
On Mon, Jan 10, 2011 at 03:20:40PM +0100, Alexander Graf wrote: > > On 10.01.2011, at 15:15, Aurelien Jarno wrote: > > > On Mon, Jan 10, 2011 at 03:07:52PM +0100, Alexander Graf wrote: > >> > >> On 10.01.2011, at 15:00, Aurelien Jarno wrote: > >> > >>> On Mon, Jan 10, 2011 at 01:13:25PM +0100, Alexander Graf wrote: > > On 06.01.2011, at 23:12, Aurelien Jarno wrote: > > > Hi, > > > > I have just sent a tcg/arm patch concerning code retranslation. You > > might want to look at the description (copied below), as from a first > > glance ppc, s390 and sparc TCG targets might be affected. If you see > > guest kernel panics, some segmentation fault of qemu or in the guest, > > strange behaviors, that happen randomly and that looks difficult to > > debug it might be the issue. > > > > Aurelien > > > > > > | QEMU uses code retranslation to restore the CPU state when an > > exception > > | happens. For it to work the retranslation must not modify the > > generated > > | code. This is what is currently implemented in ARM TCG. > > | > > | However on CPU that don't have icache/dcache/memory synchronised like > > | ARM, this requirement is stronger and code retranslation must not > > modify > > | the generated code "atomically", as the cache line might be flushed > > | at any moment (interrupt, exception, task switching), even if not > > | triggered by QEMU. The probability for this to happen is very low, and > > | depends on cache size and associativiy, machine load, interrupts, so > > the > > | symptoms are might happen randomly. > > | > > | This requirement is currently not followed in tcg/arm, for the > > | load/store code, which basically has the following structure: > > | 1) tlb access code is written > > | 2) conditional fast path code is written > > | 3) branch is written with a temporary target > > | 4) slow path code is written > > | 5) branch target is updated > > | The cache lines corresponding to the retranslated code is not flushed > > | after code retranslation as the generated code is supposed to be the > > | same. However if the cache line corresponding to the branch > > instruction > > | is flushed between step 3 and 5, and is not flushed again before the > > | code is executed again, the branch target is wrong. In the guest, the > > | symptoms are MMU page fault at a random addresses, which leads to > > | kernel page fault or segmentation faults. > > I don't see the problem. If you have separate icache from dcache, the > code in question doesn't get executed during the rewrite, so all should > be fine. If you have both combined, the data write should automatically > modify the cache line, so all is great too. > >>> > >>> As far as I understand, this is what happens to the branch target > >>> instruction, or at least one possibility: > >>> > >>> operation | icache | dcache | mem/L2 | > >>> --++++ > >>> tlb access code is written| absent | absent | ok | > >>> conditional fast path code is written | absent | absent | ok | > >>> branch is written with a temporary target | absent | wrong | ok | > >>> cache line is flushed to memory | absent | absent | wrong | > >>> slow path code is written | absent | absent | wrong | > >>> branch target is updated | absent | ok | wrong | > >>> TB is re-executed | wrong | ok | wrong | > >>> > >>> Note that the issue is real, the patch really fixes the issue on ARM and > >>> MIPS. It's not impossible that I don't fully understand it given I can't > >>> analyse the cache values at a given time. However, when QEMU crashes > >>> because of that, we have seen that the executed code doesn't match what > >>> GDB says, and changing the temporary branch value also changes the way > >>> QEMU or the guest crash. > >>> > >>> The problem doesn't happens very often though (for sure less than 1 > >>> every few millions). The other way to fix it is to issue a cache flush > >>> after a code retranslation, however, it is something very costly on some > >>> architectures. > >> > >> I'd guess it only happens when code is overwritten. Only then icache can > >> still be stale in that code region. Can't we just invalidate the icache on > >> every tb flush? That should also fix the issue I'd guess. > > > > That's a solution that works (tested). However making sure that the > > retranslation doesn't change the code looks better. > > Yeah, I agree. Temporary retranslation really shouldn't modify existing code. > We really do need an icache flush on tb flushes still though as that's a > separate issue? Or are these already in? I don't think it
[Qemu-devel] Re: [PATCH v4] savevm: Fix no_migrate
On Mon, 2011-01-10 at 10:24 +, Daniel P. Berrange wrote: > On Fri, Jan 07, 2011 at 03:13:25PM -0700, Alex Williamson wrote: > > The no_migrate save state flag is currently only checked in the > > last phase of migration. This means that we potentially waste > > a lot of time and bandwidth with the live state handlers before > > we ever check the no_migrate flags. The error message printed > > when we catch a non-migratable device doesn't get printed for > > a detached migration. And, no_migrate does nothing to prevent > > an incoming migration to a target that includes a non-migratable > > device. This attempts to fix all of these. > > > > One notable difference in behavior is that an outgoing migration > > now checks for non-migratable devices before ever connecting to > > the target system. This means the target will remain listening > > rather than exit from failure. > > > > Signed-off-by: Alex Williamson > > --- > > > > v4: > > - fix braces noted by Jan > > - return error from qemu_savevm_state_blocked rather than fixed EINVAL > > at qemu_loadvm_state(), since it'a already using errno values > > > > v3: > > > > Daniel, adding you to see if libvirt cares about the difference in > > whether the target exits on migration failure as noted above. > > If the 'migrate' command on the source QEMU returns an error, > then libvirt will teardown the target QEMU automatically, so > that's not a problem. Thanks, that's the way I was hoping it would work. Alex
Re: [Qemu-devel] Re: tcg/{ppc, s390, sparc}: branch target and code retranslation
On 10.01.2011, at 15:51, Edgar E. Iglesias wrote: > On Mon, Jan 10, 2011 at 03:20:40PM +0100, Alexander Graf wrote: >> >> On 10.01.2011, at 15:15, Aurelien Jarno wrote: >> >>> On Mon, Jan 10, 2011 at 03:07:52PM +0100, Alexander Graf wrote: On 10.01.2011, at 15:00, Aurelien Jarno wrote: > On Mon, Jan 10, 2011 at 01:13:25PM +0100, Alexander Graf wrote: >> >> On 06.01.2011, at 23:12, Aurelien Jarno wrote: >> >>> Hi, >>> >>> I have just sent a tcg/arm patch concerning code retranslation. You >>> might want to look at the description (copied below), as from a first >>> glance ppc, s390 and sparc TCG targets might be affected. If you see >>> guest kernel panics, some segmentation fault of qemu or in the guest, >>> strange behaviors, that happen randomly and that looks difficult to >>> debug it might be the issue. >>> >>> Aurelien >>> >>> >>> | QEMU uses code retranslation to restore the CPU state when an >>> exception >>> | happens. For it to work the retranslation must not modify the >>> generated >>> | code. This is what is currently implemented in ARM TCG. >>> | >>> | However on CPU that don't have icache/dcache/memory synchronised like >>> | ARM, this requirement is stronger and code retranslation must not >>> modify >>> | the generated code "atomically", as the cache line might be flushed >>> | at any moment (interrupt, exception, task switching), even if not >>> | triggered by QEMU. The probability for this to happen is very low, and >>> | depends on cache size and associativiy, machine load, interrupts, so >>> the >>> | symptoms are might happen randomly. >>> | >>> | This requirement is currently not followed in tcg/arm, for the >>> | load/store code, which basically has the following structure: >>> | 1) tlb access code is written >>> | 2) conditional fast path code is written >>> | 3) branch is written with a temporary target >>> | 4) slow path code is written >>> | 5) branch target is updated >>> | The cache lines corresponding to the retranslated code is not flushed >>> | after code retranslation as the generated code is supposed to be the >>> | same. However if the cache line corresponding to the branch >>> instruction >>> | is flushed between step 3 and 5, and is not flushed again before the >>> | code is executed again, the branch target is wrong. In the guest, the >>> | symptoms are MMU page fault at a random addresses, which leads to >>> | kernel page fault or segmentation faults. >> >> I don't see the problem. If you have separate icache from dcache, the >> code in question doesn't get executed during the rewrite, so all should >> be fine. If you have both combined, the data write should automatically >> modify the cache line, so all is great too. > > As far as I understand, this is what happens to the branch target > instruction, or at least one possibility: > > operation | icache | dcache | mem/L2 | > --++++ > tlb access code is written| absent | absent | ok | > conditional fast path code is written | absent | absent | ok | > branch is written with a temporary target | absent | wrong | ok | > cache line is flushed to memory | absent | absent | wrong | > slow path code is written | absent | absent | wrong | > branch target is updated | absent | ok | wrong | > TB is re-executed | wrong | ok | wrong | > > Note that the issue is real, the patch really fixes the issue on ARM and > MIPS. It's not impossible that I don't fully understand it given I can't > analyse the cache values at a given time. However, when QEMU crashes > because of that, we have seen that the executed code doesn't match what > GDB says, and changing the temporary branch value also changes the way > QEMU or the guest crash. > > The problem doesn't happens very often though (for sure less than 1 > every few millions). The other way to fix it is to issue a cache flush > after a code retranslation, however, it is something very costly on some > architectures. I'd guess it only happens when code is overwritten. Only then icache can still be stale in that code region. Can't we just invalidate the icache on every tb flush? That should also fix the issue I'd guess. >>> >>> That's a solution that works (tested). However making sure that the >>> retranslation doesn't change the code looks better. >> >> Yeah, I agree. Temporary retranslation really shouldn't modify existing >> code. We really do need an icache flush on tb flushes still though as that's >>
Re: [Qemu-devel] [PATCH 2/6] spice: client migration.
On Mon, Jan 10, 2011 at 02:31:47PM +0100, Gerd Hoffmann wrote:
> Handle spice client migration, i.e. inform a spice client connected
> about the new host and connection parameters, so it can move over the
> connection automatically.
>
> Signed-off-by: Gerd Hoffmann
> ---
> hmp-commands.hx | 20
> qmp-commands.hx | 35 +++
> ui/qemu-spice.h |1 +
> ui/spice-core.c | 40
> 4 files changed, 96 insertions(+), 0 deletions(-)
>
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index df134f8..e6d8f36 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -815,6 +815,26 @@ ETEXI
> },
>
> STEXI
> +...@item spice_migrate_info @var{hostname} @var{port} @var{tls-port}
> @var{cert-subject}
> +...@findex spice_migrate_info
> +Set the spice connection info for the migration target. The spice
> +server will ask the spice client to automatically reconnect using the
> +new parameters (if specified) once the vm migration finished
> +successfully.
> +ETEXI
> +
> +#if defined(CONFIG_SPICE)
> +{
> +.name = "spice_migrate_info",
> +.args_type = "hostname:s,port:i?,tls-port:i?,cert-subject:s?",
> +.params = "hostname port tls-port cert-subject",
> +.help = "send migration info to spice client",
> +.user_print = monitor_user_noop,
> +.mhandler.cmd_new = mon_spice_migrate,
> +},
> +#endif
> +
> +STEXI
> @item snapshot_blkdev
> @findex snapshot_blkdev
> Snapshot device, using snapshot file as target if provided
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index 56c4d8b..24ada04 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -503,6 +503,41 @@ EQMP
> },
>
> SQMP
> +spice_migrate_info
> +--
> +
> +Set the spice connection info for the migration target. The spice
> +server will ask the spice client to automatically reconnect using the
> +new parameters (if specified) once the vm migration finished
> +successfully.
> +
> +Arguments:
> +
> +- "hostname": migration target hostname (json-string)
> +- "port": spice tcp port for plaintext channels (json-int, optional)
> +- "tls-port": spice tcp port for tls-secured channels (json-int,
> optional)
> +- "cert-subject": server certificate subject (json-string, optional)
> +
> +Example:
> +
> +-> { "execute": "spice_migrate_info",
> + "arguments": { "hostname": "virt42.lab.kraxel.org", "port": 1234 } }
> +<- { "return": {} }
I'm wondering whether we should make this command more
generic, because I could likely write up a VNC extension
that provides the same functionality that SPICE has here.
so, 'graphics_migrate_info @var{spice|vnc|...} ...other vars..'
Regards,
Daniel
Re: [Qemu-devel] [PATCH 2/6] spice: client migration.
On Mon, Jan 10, 2011 at 03:49:34PM +, Daniel P. Berrange wrote:
> On Mon, Jan 10, 2011 at 02:31:47PM +0100, Gerd Hoffmann wrote:
> > Handle spice client migration, i.e. inform a spice client connected
> > about the new host and connection parameters, so it can move over the
> > connection automatically.
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
> > hmp-commands.hx | 20
> > qmp-commands.hx | 35 +++
> > ui/qemu-spice.h |1 +
> > ui/spice-core.c | 40
> > 4 files changed, 96 insertions(+), 0 deletions(-)
> >
> > diff --git a/hmp-commands.hx b/hmp-commands.hx
> > index df134f8..e6d8f36 100644
> > --- a/hmp-commands.hx
> > +++ b/hmp-commands.hx
> > @@ -815,6 +815,26 @@ ETEXI
> > },
> >
> > STEXI
> > +...@item spice_migrate_info @var{hostname} @var{port} @var{tls-port}
> > @var{cert-subject}
> > +...@findex spice_migrate_info
> > +Set the spice connection info for the migration target. The spice
> > +server will ask the spice client to automatically reconnect using the
> > +new parameters (if specified) once the vm migration finished
> > +successfully.
> > +ETEXI
>
>
> > +
> > +#if defined(CONFIG_SPICE)
> > +{
> > +.name = "spice_migrate_info",
> > +.args_type = "hostname:s,port:i?,tls-port:i?,cert-subject:s?",
> > +.params = "hostname port tls-port cert-subject",
> > +.help = "send migration info to spice client",
> > +.user_print = monitor_user_noop,
> > +.mhandler.cmd_new = mon_spice_migrate,
> > +},
> > +#endif
> > +
> > +STEXI
> > @item snapshot_blkdev
> > @findex snapshot_blkdev
> > Snapshot device, using snapshot file as target if provided
> > diff --git a/qmp-commands.hx b/qmp-commands.hx
> > index 56c4d8b..24ada04 100644
> > --- a/qmp-commands.hx
> > +++ b/qmp-commands.hx
> > @@ -503,6 +503,41 @@ EQMP
> > },
> >
> > SQMP
> > +spice_migrate_info
> > +--
> > +
> > +Set the spice connection info for the migration target. The spice
> > +server will ask the spice client to automatically reconnect using the
> > +new parameters (if specified) once the vm migration finished
> > +successfully.
> > +
> > +Arguments:
> > +
> > +- "hostname": migration target hostname (json-string)
> > +- "port": spice tcp port for plaintext channels (json-int,
> > optional)
> > +- "tls-port": spice tcp port for tls-secured channels (json-int,
> > optional)
> > +- "cert-subject": server certificate subject (json-string, optional)
> > +
> > +Example:
> > +
> > +-> { "execute": "spice_migrate_info",
> > + "arguments": { "hostname": "virt42.lab.kraxel.org", "port": 1234 } }
> > +<- { "return": {} }
>
> I'm wondering whether we should make this command more
> generic, because I could likely write up a VNC extension
> that provides the same functionality that SPICE has here.
> so, 'graphics_migrate_info @var{spice|vnc|...} ...other vars..'
Considering it isn't actually just graphics how about client_migrate_info?
>
> Regards,
> Daniel
>
Re: [Qemu-devel] KVM call agenda for Jan 11
On 01/10/2011 04:17 AM, Juan Quintela wrote: Please send any agenda items you are interested in covering. - KVM Forum 2011 (Jes). - Spice guest agent (Alon) Regards, Anthony Liguori thanks, Juan.
Re: [Qemu-devel] [PATCH 2/6] spice: client migration.
On 01/10/11 16:57, Alon Levy wrote:
+spice_migrate_info
+--
+
+Set the spice connection info for the migration target. The spice
+server will ask the spice client to automatically reconnect using the
+new parameters (if specified) once the vm migration finished
+successfully.
+
+Arguments:
+
+- "hostname": migration target hostname (json-string)
+- "port": spice tcp port for plaintext channels (json-int, optional)
+- "tls-port": spice tcp port for tls-secured channels (json-int, optional)
+- "cert-subject": server certificate subject (json-string, optional)
+
+Example:
+
+-> { "execute": "spice_migrate_info",
+ "arguments": { "hostname": "virt42.lab.kraxel.org", "port": 1234 } }
+<- { "return": {} }
I'm wondering whether we should make this command more
generic, because I could likely write up a VNC extension
that provides the same functionality that SPICE has here.
so, 'graphics_migrate_info @var{spice|vnc|...} ...other vars..'
Considering it isn't actually just graphics how about client_migrate_info?
I like client_migrate_info and it fits both spice+vnc naming too.
Given that vnc just needs hostname and port (which are present already)
and the arguments not used by vnc are optional all we need to do is
rename the command and add a "protocol" argument similar to
"set_password", correct?
cheers,
Gerd
Re: [Qemu-devel] [PATCH 2/6] spice: client migration.
On Mon, Jan 10, 2011 at 05:08:40PM +0100, Gerd Hoffmann wrote:
> On 01/10/11 16:57, Alon Levy wrote:
> >>>+spice_migrate_info
> >>>+--
> >>>+
> >>>+Set the spice connection info for the migration target. The spice
> >>>+server will ask the spice client to automatically reconnect using the
> >>>+new parameters (if specified) once the vm migration finished
> >>>+successfully.
> >>>+
> >>>+Arguments:
> >>>+
> >>>+- "hostname": migration target hostname (json-string)
> >>>+- "port": spice tcp port for plaintext channels (json-int,
> >>>optional)
> >>>+- "tls-port": spice tcp port for tls-secured channels (json-int,
> >>>optional)
> >>>+- "cert-subject": server certificate subject (json-string, optional)
> >>>+
> >>>+Example:
> >>>+
> >>>+-> { "execute": "spice_migrate_info",
> >>>+ "arguments": { "hostname": "virt42.lab.kraxel.org", "port": 1234 } }
> >>>+<- { "return": {} }
> >>
> >>I'm wondering whether we should make this command more
> >>generic, because I could likely write up a VNC extension
> >>that provides the same functionality that SPICE has here.
> >>so, 'graphics_migrate_info @var{spice|vnc|...} ...other vars..'
> >
> >Considering it isn't actually just graphics how about client_migrate_info?
>
> I like client_migrate_info and it fits both spice+vnc naming too.
>
> Given that vnc just needs hostname and port (which are present
> already) and the arguments not used by vnc are optional all we need
> to do is rename the command and add a "protocol" argument similar to
> "set_password", correct?
Yeah, that sounds sufficient to me.
Regards,
Daniel
Re: [Qemu-devel] [PATCH] linux-user: fix for loopmount ioctl
On 01/09/2011 12:25 AM, Martin Mohring wrote: > Hi, > > I had fixed the loopmount ioctl for linux-user, working correctly for arm, > mips, ppc32 and sh4. > > Martin > > ping Aurelien, Riku, is that patch ok? Its only 2 lines of change to activate an ioctl.
[Qemu-devel] [PATCH] arm-dis: Include opcode hex when doing disassembly
Enhance the ARM disassembler used for debugging so that it includes
the hex dump of the opcode as well as the symbolic disassembly.
Signed-off-by: Peter Maydell
---
This is based on meego-qemu commit e548a60c with a change suggested
last time that patch was sent to qemu-devel:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg28258.html
http://www.mail-archive.com/qemu-devel@nongnu.org/msg29235.html
I have used GNU-style indent conventions in this change because
the rest of this file consistently does so (being from libopcode
originally).
arm-dis.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arm-dis.c b/arm-dis.c
index af21739..3ece02c 100644
--- a/arm-dis.c
+++ b/arm-dis.c
@@ -4101,6 +4101,30 @@ print_insn_arm (bfd_vma pc, struct disassemble_info
*info)
addresses, since the addend is not currently pc-relative. */
pc = 0;
+ /* We include the hexdump of the instruction. The format here
+ matches that used by objdump and the ARM ARM (in particular,
+ 32 bit Thumb instructions are displayed as pairs of halfwords,
+ not as a single word.) */
+ if (is_thumb)
+{
+ if (size == 2)
+ {
+ info->fprintf_func(info->stream, "%04lx ",
+((unsigned long)given) & 0x);
+ }
+ else
+ {
+ info->fprintf_func(info->stream, "%04lx %04lx ",
+(((unsigned long)given) >> 16) & 0x,
+((unsigned long)given) & 0x);
+ }
+}
+ else
+{
+ info->fprintf_func(info->stream, "%08lx ",
+((unsigned long)given) & 0x);
+}
+
printer (pc, info, given);
if (is_thumb)
--
1.7.1
Re: [Qemu-devel] [PATCH 2/6] spice: client migration.
Hi,
I like client_migrate_info and it fits both spice+vnc naming too.
Given that vnc just needs hostname and port (which are present
already) and the arguments not used by vnc are optional all we need
to do is rename the command and add a "protocol" argument similar to
"set_password", correct?
Yeah, that sounds sufficient to me.
Quick incremental patch attached. Became a bit larger than initially
expected due to some code reorganization (move out of ui/spice-core.c)
needed.
comments?
cheers,
Gerd
diff --git a/hmp-commands.hx b/hmp-commands.hx
index e6d8f36..05b777b 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -815,24 +815,21 @@ ETEXI
},
STEXI
-...@item spice_migrate_info @var{hostname} @var{port} @var{tls-port}
@var{cert-subject}
-...@findex spice_migrate_info
-Set the spice connection info for the migration target. The spice
-server will ask the spice client to automatically reconnect using the
-new parameters (if specified) once the vm migration finished
-successfully.
+...@item client_migrate_info @var{protocol} @var{hostname} @var{port}
@var{tls-port} @var{cert-subject}
+...@findex client_migrate_info
+Set the spice/vnc connection info for the migration target. The spice/vnc
+server will ask the spice/vnc client to automatically reconnect using the
+new parameters (if specified) once the vm migration finished successfully.
ETEXI
-#if defined(CONFIG_SPICE)
{
-.name = "spice_migrate_info",
-.args_type = "hostname:s,port:i?,tls-port:i?,cert-subject:s?",
-.params = "hostname port tls-port cert-subject",
-.help = "send migration info to spice client",
+.name = "client_migrate_info",
+.args_type =
"protocol:s,hostname:s,port:i?,tls-port:i?,cert-subject:s?",
+.params = "protocol hostname port tls-port cert-subject",
+.help = "send migration info to spice/vnc client",
.user_print = monitor_user_noop,
-.mhandler.cmd_new = mon_spice_migrate,
+.mhandler.cmd_new = client_migrate_info,
},
-#endif
STEXI
@item snapshot_blkdev
diff --git a/monitor.c b/monitor.c
index 038d532..6f5ee14 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1173,6 +1173,33 @@ static int expire_password(Monitor *mon, const QDict
*qdict, QObject **ret_data)
return -1;
}
+static int client_migrate_info(Monitor *mon, const QDict *qdict, QObject
**ret_data)
+{
+const char *protocol = qdict_get_str(qdict, "protocol");
+const char *hostname = qdict_get_str(qdict, "hostname");
+const char *subject = qdict_get_try_str(qdict, "cert-subject");
+int port = qdict_get_try_int(qdict, "port", -1);
+int tls_port = qdict_get_try_int(qdict, "tls-port", -1);
+int ret;
+
+if (strcmp(protocol, "spice") == 0) {
+if (!using_spice) {
+qerror_report(QERR_DEVICE_NOT_ACTIVE, "spice");
+return -1;
+}
+
+ret = qemu_spice_migrate_info(hostname, port, tls_port, subject);
+if (ret != 0) {
+qerror_report(QERR_UNDEFINED_ERROR);
+return -1;
+}
+return 0;
+}
+
+qerror_report(QERR_INVALID_PARAMETER, "protocol");
+return -1;
+}
+
static int do_screen_dump(Monitor *mon, const QDict *qdict, QObject **ret_data)
{
vga_hw_screen_dump(qdict_get_str(qdict, "filename"));
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 24ada04..2ed8f44 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -503,39 +503,39 @@ EQMP
},
SQMP
-spice_migrate_info
+client_migrate_info
--
-Set the spice connection info for the migration target. The spice
-server will ask the spice client to automatically reconnect using the
-new parameters (if specified) once the vm migration finished
-successfully.
+Set the spice/vnc connection info for the migration target. The spice/vnc
+server will ask the spice/vnc client to automatically reconnect using the
+new parameters (if specified) once the vm migration finished successfully.
Arguments:
+- "protocol": protocol: "spice" or "vnc" (json-string)
- "hostname": migration target hostname (json-string)
-- "port": spice tcp port for plaintext channels (json-int, optional)
+- "port": spice/vnc tcp port for plaintext channels (json-int,
optional)
- "tls-port": spice tcp port for tls-secured channels (json-int, optional)
- "cert-subject": server certificate subject (json-string, optional)
Example:
--> { "execute": "spice_migrate_info",
- "arguments": { "hostname": "virt42.lab.kraxel.org", "port": 1234 } }
+-> { "execute": "client_migrate_info",
+ "arguments": { "protocol": "spice",
+"hostname": "virt42.lab.kraxel.org",
+"port": 1234 } }
<- { "return": {} }
EQMP
-#if defined(CONFIG_SPICE)
{
-.name = "spice_migrate_info",
-.args_type = "hostname:s,port:i?,tls-port:i?,cert-subject:s?",
-
[Qemu-devel] [PATCH applied] virtio: move vmstate change tracking to core
Move tracking vmstate change from virtio-net to virtio.c
as it is going to be used by virito-blk and virtio-pci
for the ioeventfd support.
Signed-off-by: Michael S. Tsirkin
---
Just wanted to call attention to this patch
which is part of the ioeventfd series
(was part of a larger patch but I split it out).
It's applied on my tree, but if anyone objects
here's the last chance to.
hw/virtio-net.c | 28 +++-
hw/virtio.c | 22 ++
hw/virtio.h |3 +++
3 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index ec1bf8d..ccb3e63 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -54,8 +54,6 @@ typedef struct VirtIONet
uint8_t nouni;
uint8_t nobcast;
uint8_t vhost_started;
-bool vm_running;
-VMChangeStateEntry *vmstate;
struct {
int in_use;
int first_multi;
@@ -102,7 +100,7 @@ static void virtio_net_set_config(VirtIODevice *vdev, const
uint8_t *config)
static bool virtio_net_started(VirtIONet *n, uint8_t status)
{
return (status & VIRTIO_CONFIG_S_DRIVER_OK) &&
-(n->status & VIRTIO_NET_S_LINK_UP) && n->vm_running;
+(n->status & VIRTIO_NET_S_LINK_UP) && n->vdev.vm_running;
}
static void virtio_net_vhost_status(VirtIONet *n, uint8_t status)
@@ -453,7 +451,7 @@ static void virtio_net_handle_rx(VirtIODevice *vdev,
VirtQueue *vq)
static int virtio_net_can_receive(VLANClientState *nc)
{
VirtIONet *n = DO_UPCAST(NICState, nc, nc)->opaque;
-if (!n->vm_running) {
+if (!n->vdev.vm_running) {
return 0;
}
@@ -708,7 +706,7 @@ static int32_t virtio_net_flush_tx(VirtIONet *n, VirtQueue
*vq)
return num_packets;
}
-assert(n->vm_running);
+assert(n->vdev.vm_running);
if (n->async_tx.elem.out_num) {
virtio_queue_set_notification(n->tx_vq, 0);
@@ -769,7 +767,7 @@ static void virtio_net_handle_tx_timer(VirtIODevice *vdev,
VirtQueue *vq)
VirtIONet *n = to_virtio_net(vdev);
/* This happens when device was stopped but VCPU wasn't. */
-if (!n->vm_running) {
+if (!n->vdev.vm_running) {
n->tx_waiting = 1;
return;
}
@@ -796,7 +794,7 @@ static void virtio_net_handle_tx_bh(VirtIODevice *vdev,
VirtQueue *vq)
}
n->tx_waiting = 1;
/* This happens when device was stopped but VCPU wasn't. */
-if (!n->vm_running) {
+if (!n->vdev.vm_running) {
return;
}
virtio_queue_set_notification(vq, 0);
@@ -806,7 +804,7 @@ static void virtio_net_handle_tx_bh(VirtIODevice *vdev,
VirtQueue *vq)
static void virtio_net_tx_timer(void *opaque)
{
VirtIONet *n = opaque;
-assert(n->vm_running);
+assert(n->vdev.vm_running);
n->tx_waiting = 0;
@@ -823,7 +821,7 @@ static void virtio_net_tx_bh(void *opaque)
VirtIONet *n = opaque;
int32_t ret;
-assert(n->vm_running);
+assert(n->vdev.vm_running);
n->tx_waiting = 0;
@@ -988,16 +986,6 @@ static NetClientInfo net_virtio_info = {
.link_status_changed = virtio_net_set_link_status,
};
-static void virtio_net_vmstate_change(void *opaque, int running, int reason)
-{
-VirtIONet *n = opaque;
-n->vm_running = running;
-/* This is called when vm is started/stopped,
- * it will start/stop vhost backend if appropriate
- * e.g. after migration. */
-virtio_net_set_status(&n->vdev, n->vdev.status);
-}
-
VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf,
virtio_net_conf *net)
{
@@ -1052,7 +1040,6 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf
*conf,
n->qdev = dev;
register_savevm(dev, "virtio-net", -1, VIRTIO_NET_VM_VERSION,
virtio_net_save, virtio_net_load, n);
-n->vmstate = qemu_add_vm_change_state_handler(virtio_net_vmstate_change,
n);
add_boot_device_path(conf->bootindex, dev, "/ethernet-...@0");
@@ -1062,7 +1049,6 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf
*conf,
void virtio_net_exit(VirtIODevice *vdev)
{
VirtIONet *n = DO_UPCAST(VirtIONet, vdev, vdev);
-qemu_del_vm_change_state_handler(n->vmstate);
/* This will stop vhost backend if appropriate. */
virtio_net_set_status(vdev, 0);
diff --git a/hw/virtio.c b/hw/virtio.c
index 07dbf86..1d20be2 100644
--- a/hw/virtio.c
+++ b/hw/virtio.c
@@ -743,11 +743,31 @@ int virtio_load(VirtIODevice *vdev, QEMUFile *f)
void virtio_cleanup(VirtIODevice *vdev)
{
+qemu_del_vm_change_state_handler(vdev->vmstate);
if (vdev->config)
qemu_free(vdev->config);
qemu_free(vdev->vq);
}
+static void virtio_vmstate_change(void *opaque, int running, int reason)
+{
+VirtIODevice *vdev = opaque;
+bool backend_run = running && (vdev->status & VIRTIO_CONFIG_S_DRIVER_OK);
+vdev->vm_running = running;
+
+if (backend_run) {
+virtio_set_status(vdev, vdev->status);
+}
+
+if (vdev->binding->vmstate_change)
Re: [Qemu-devel] [PATCH] arm-dis: Include opcode hex when doing disassembly
On Mon, Jan 10, 2011 at 04:16:26PM +, Peter Maydell wrote: > Enhance the ARM disassembler used for debugging so that it includes > the hex dump of the opcode as well as the symbolic disassembly. > > Signed-off-by: Peter Maydell > --- > This is based on meego-qemu commit e548a60c with a change suggested > last time that patch was sent to qemu-devel: > http://www.mail-archive.com/qemu-devel@nongnu.org/msg28258.html > http://www.mail-archive.com/qemu-devel@nongnu.org/msg29235.html > > I have used GNU-style indent conventions in this change because > the rest of this file consistently does so (being from libopcode > originally). > > arm-dis.c | 24 > 1 files changed, 24 insertions(+), 0 deletions(-) Strangely on arm host, the opcode hex is already included, as shown below: | OUT: [size=308] | 0x01001ec0: e5974004 ldr r4, [r7, #4] | 0x01001ec4: e1a04804 lsl r4, r4, #16 | 0x01001ec8: e1a04824 lsr r4, r4, #16 | 0x01001ecc: e1a04404 lsl r4, r4, #8 Maybe there is just an option to enable to allow that? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] Re: [PATCH 5/7] tcg-i386: Implement deposit operation.
On Sun, Jan 09, 2011 at 04:43:22PM -0800, Richard Henderson wrote: > On 01/09/2011 04:16 PM, Aurelien Jarno wrote: > > The code being written now or latter doesn't change the question to know > > if it is always possible to allocate one scratch register here on i386. > > Yes. > > Here there's only one register that needs to remain live. In the > worst case, we'll spill one live register. Which we can always do > via a simple store via AREG0 + offset. Oh right correct we are inside the instruction and in a case we have very few arguments, and only 32-bit. If we allow the target to allocate scratch registers themselves, it's probably better to do that via a function. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] [RFC][PATCH 2/2] qcow2: Use QcowCache
Use the new functions of qcow2-cache.c for everything that works on refcount
block and L2 tables.
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c | 206 ++--
block/qcow2-refcount.c | 249 +++-
block/qcow2.c | 43 -
block/qcow2.h | 12 ++-
4 files changed, 216 insertions(+), 294 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 6928c63..626a331 100644
--- a/block/qcow2-cluster.c
+++ b/block/qcow2-cluster.c
@@ -67,7 +67,11 @@ int qcow2_grow_l1_table(BlockDriverState *bs, int min_size,
bool exact_size)
qemu_free(new_l1_table);
return new_l1_table_offset;
}
-bdrv_flush(bs->file);
+
+ret = qcow2_cache_flush(bs, s->refcount_block_cache);
+if (ret < 0) {
+return ret;
+}
BLKDBG_EVENT(bs->file, BLKDBG_L1_GROW_WRITE_TABLE);
for(i = 0; i < s->l1_size; i++)
@@ -98,63 +102,6 @@ int qcow2_grow_l1_table(BlockDriverState *bs, int min_size,
bool exact_size)
return ret;
}
-void qcow2_l2_cache_reset(BlockDriverState *bs)
-{
-BDRVQcowState *s = bs->opaque;
-
-memset(s->l2_cache, 0, s->l2_size * L2_CACHE_SIZE * sizeof(uint64_t));
-memset(s->l2_cache_offsets, 0, L2_CACHE_SIZE * sizeof(uint64_t));
-memset(s->l2_cache_counts, 0, L2_CACHE_SIZE * sizeof(uint32_t));
-}
-
-static inline int l2_cache_new_entry(BlockDriverState *bs)
-{
-BDRVQcowState *s = bs->opaque;
-uint32_t min_count;
-int min_index, i;
-
-/* find a new entry in the least used one */
-min_index = 0;
-min_count = 0x;
-for(i = 0; i < L2_CACHE_SIZE; i++) {
-if (s->l2_cache_counts[i] < min_count) {
-min_count = s->l2_cache_counts[i];
-min_index = i;
-}
-}
-return min_index;
-}
-
-/*
- * seek_l2_table
- *
- * seek l2_offset in the l2_cache table
- * if not found, return NULL,
- * if found,
- * increments the l2 cache hit count of the entry,
- * if counter overflow, divide by two all counters
- * return the pointer to the l2 cache entry
- *
- */
-
-static uint64_t *seek_l2_table(BDRVQcowState *s, uint64_t l2_offset)
-{
-int i, j;
-
-for(i = 0; i < L2_CACHE_SIZE; i++) {
-if (l2_offset == s->l2_cache_offsets[i]) {
-/* increment the hit count */
-if (++s->l2_cache_counts[i] == 0x) {
-for(j = 0; j < L2_CACHE_SIZE; j++) {
-s->l2_cache_counts[j] >>= 1;
-}
-}
-return s->l2_cache + (i << s->l2_bits);
-}
-}
-return NULL;
-}
-
/*
* l2_load
*
@@ -169,33 +116,12 @@ static int l2_load(BlockDriverState *bs, uint64_t
l2_offset,
uint64_t **l2_table)
{
BDRVQcowState *s = bs->opaque;
-int min_index;
int ret;
-/* seek if the table for the given offset is in the cache */
-
-*l2_table = seek_l2_table(s, l2_offset);
-if (*l2_table != NULL) {
-return 0;
-}
-
-/* not found: load a new entry in the least used one */
-
-min_index = l2_cache_new_entry(bs);
-*l2_table = s->l2_cache + (min_index << s->l2_bits);
-
BLKDBG_EVENT(bs->file, BLKDBG_L2_LOAD);
-ret = bdrv_pread(bs->file, l2_offset, *l2_table,
-s->l2_size * sizeof(uint64_t));
-if (ret < 0) {
-qcow2_l2_cache_reset(bs);
-return ret;
-}
+ret = qcow2_cache_get(bs, s->l2_table_cache, l2_offset, (void**) l2_table);
-s->l2_cache_offsets[min_index] = l2_offset;
-s->l2_cache_counts[min_index] = 1;
-
-return 0;
+return ret;
}
/*
@@ -238,7 +164,6 @@ static int write_l1_entry(BlockDriverState *bs, int
l1_index)
static int l2_allocate(BlockDriverState *bs, int l1_index, uint64_t **table)
{
BDRVQcowState *s = bs->opaque;
-int min_index;
uint64_t old_l2_offset;
uint64_t *l2_table;
int64_t l2_offset;
@@ -252,29 +177,48 @@ static int l2_allocate(BlockDriverState *bs, int
l1_index, uint64_t **table)
if (l2_offset < 0) {
return l2_offset;
}
-bdrv_flush(bs->file);
+
+ret = qcow2_cache_flush(bs, s->refcount_block_cache);
+if (ret < 0) {
+goto fail;
+}
/* allocate a new entry in the l2 cache */
-min_index = l2_cache_new_entry(bs);
-l2_table = s->l2_cache + (min_index << s->l2_bits);
+ret = qcow2_cache_get(bs, s->l2_table_cache, l2_offset, (void**) table);
+if (ret < 0) {
+return ret;
+}
+
+l2_table = *table;
if (old_l2_offset == 0) {
/* if there was no old l2 table, clear the new table */
memset(l2_table, 0, s->l2_size * sizeof(uint64_t));
} else {
+uint64_t* old_table;
+
/* if there was an old l2 table, read it from the disk */
BLKDBG_EVENT(bs->file, BLKDBG_L2_ALLOC_COW_READ);
-ret = bdrv_pread(bs->file, old_l2_offset, l2_table,
-s->l2_size * sizeof(uint64_t));
+ret = qcow2_cache_get(bs,
[Qemu-devel] [RFC][PATCH 0/2] qcow2 metadata cache
block-queue turned out to be too big effort to be useful for quickly fixing the performance problems that qcow2 got since we introduced the metadata flushes. While I still think the idea is right, it needs more time and qcow2 doesn't have more time. Let's come back to block-queue later when the most urgent qcow2 problems are fixed. So this is the idea of block-queue applied to the very specific case of qcow2. Whereas block-queue tried to be a generic solution for all kind of things and tried to make all writes asynchronous at the same time, this is only about batching writes to refcount blocks and L2 tables in qcow2 and getting the dependencies right. (Yes, the L1 table and refcount table is left alone. They are almost never written to anyway.) This should be much easier to understand and review, and I myself feel a bit more confident about it than with block-queue, too. Reviews and comments are appreciated. Kevin Wolf (2): qcow2: Add QcowCache qcow2: Use QcowCache Makefile.objs |2 +- block/qcow2-cache.c| 270 block/qcow2-cluster.c | 206 + block/qcow2-refcount.c | 249 +--- block/qcow2.c | 43 +++- block/qcow2.h | 29 +- 6 files changed, 504 insertions(+), 295 deletions(-) create mode 100644 block/qcow2-cache.c -- 1.7.2.3
[Qemu-devel] [PATCH] qemu-img snapshot: Use writeback caching
None of the other qemu-img subcommands uses writethrough, and there's no reason
why snapshot should be special.
Signed-off-by: Kevin Wolf
---
qemu-img.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index afd9ed2..1e65ea8 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -1068,7 +1068,7 @@ static int img_snapshot(int argc, char **argv)
int action = 0;
qemu_timeval tv;
-bdrv_oflags = BDRV_O_RDWR;
+bdrv_oflags = BDRV_O_FLAGS | BDRV_O_RDWR;
/* Parse commandline parameters */
for(;;) {
c = getopt(argc, argv, "la:c:d:h");
--
1.7.2.3
Re: [Qemu-devel] [PULL] piix, pci, qdev
On 12/27/2010 11:21 AM, Michael S. Tsirkin wrote: The sysbus change is already in master, but I didn't want to rebase the tree. I verified there's no conflict when merging. The only thing that might be controversial here is the bridge migration path, but the patch was out for pretty long without comments (besides a style comment by Stefan Weil, fixed that), and it's not changing anything that isn't already broken. Maybe it's fine, or maybe merging it will make people notice ;). The following changes since commit 4cdc1cd137e0b98766916a7cdf2d5a9b3c6632fa: target-mips: fix host CPU consumption when guest is idle (2010-12-27 00:58:06 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git for_anthony Pulled. Thanks. Regards, Anthony Liguori Isaku Yamahata (7): qbus: register reset handler for qbus whose parent is NULL pc/piix: fix mismerge of b1aeb92666d2fde413c34578b3b42bbfe5f2a506 pcie: add flr support build, pci: remove QMP dependency on core PCI code qdev: export qdev_find_recursive() for later use pci: introduce a helper function to convert qdev id to PCIDevice pcie/aer: glue aer error injection into qemu monitor Michael S. Tsirkin (3): pci: don't use bus number in migration, stub out qdev: remove an unused function pci: fix migration path for devices behind bridges Stefan Weil (1): qdev: sysbus_get_default must not return a NULL pointer (fix regression) Makefile.objs |4 +- Makefile.target |2 + hmp-commands.hx | 25 + hw/pc_piix.c| 12 +-- hw/pci-stub.c | 50 +++ hw/pci.c| 82 -- hw/pci.h|2 + hw/pcie.c | 11 +-- hw/pcie.h |2 - hw/pcie_aer.c | 223 +++ hw/qdev.c | 22 +++-- hw/qdev.h |5 +- hw/xio3130_downstream.c |2 +- hw/xio3130_upstream.c |3 - sysemu.h|5 + vl.c|4 +- 16 files changed, 415 insertions(+), 39 deletions(-) create mode 100644 hw/pci-stub.c
Re: [Qemu-devel] Linux as VirtualBox quest OS with QEMU running Solaris
Am 10.01.2011 12:19, schrieb Mateusz Loskot: On 07/01/11 18:15, Stefan Weil wrote: Am 07.01.2011 18:28, schrieb Mateusz Loskot: Hi, First, I'm sorry if my question does not belong here. The qemu-devel says it's "devel", but I can't find any qemu-users mailing list. I have no experience with QEMU. I've been using x86-only virtualization software like VirtualBox, VMWare and others. I need to run Solaris (SPARC) OS and I'd like to do it under QEMU. Due to hardware constraints, I'm wondering if the following setup would work at all: 1. Quad-core workstation with 16GB RAM with Windows Vista 64-bit as host OS 2. The Windows runs VirtualBox with Linux installed as guest OS. 3. The Linux guest OS runs QEMU 4. QEMU runs Solaris (SPARC) The Linux guest OS can be either Linux x86-32 or x86-64, depending which one is recommended and would perform better. Is this configuration reasonable? Would it work well? I have found the "QEMU on Winows" [1] but I'm not sure if this is an official project and if it's "production ready". I need to have fairly stable environment for building and testing software on SPARC architecture. [1] http://www.h7.dion.ne.jp/~qemu-win/ I'd appreciate any help and sugestions. Using a native windows version of qemu would be more reasonable. OK, makes sense to me. There are no precompiled windows binaries of current qemu, so you will have to compile them yourself (which is not difficult once you have the correct mingw environment). Great. I think I should be able to do that. Which version of QEMU source code should I grab? Latest stable or development version from Git repo? Best regards, I suggest using QEMU git master. You could try the binaries from my website: http://www.weilnetz.de/qemu/ Kind regards, Stefan Weil
[Qemu-devel] [RFC][PATCH 1/2] qcow2: Add QcowCache
This adds some new cache functions to qcow2 which can be used for caching
refcount blocks and L2 tables. When used with cache=writethrough they work
like the old caching code which is spread all over qcow2, so for this case we
have merely a cleanup.
The interesting case is with writeback caching (this includes cache=none) where
data isn't written to disk immediately but only kept in cache initially. This
leads to some form of metadata write batching which avoids the current "write
to refcount block, flush, write to L2 table" pattern for each single request
when a lot of cluster allocations happen. Instead, cache entries are only
written out if its required to maintain the right order. In the pure cluster
allocation case this means that all metadata updates for requests are done in
memory initially and on sync, first the refcount blocks are written to disk,
then fsync, then L2 tables.
This improves performance of scenarios with lots of cluster allocations
noticably (e.g. installation or after taking a snapshot).
Signed-off-by: Kevin Wolf
---
Makefile.objs |2 +-
block/qcow2-cache.c | 270 +++
block/qcow2.h | 17 +++
3 files changed, 288 insertions(+), 1 deletions(-)
create mode 100644 block/qcow2-cache.c
diff --git a/Makefile.objs b/Makefile.objs
index d6b3d60..4f499c8 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -19,7 +19,7 @@ block-obj-$(CONFIG_POSIX) += posix-aio-compat.o
block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
block-nested-y += raw.o cow.o qcow.o vdi.o vmdk.o cloop.o dmg.o bochs.o vpc.o
vvfat.o
-block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
+block-nested-y += qcow2.o qcow2-refcount.o qcow2-cluster.o qcow2-snapshot.o
qcow2-cache.o
block-nested-y += qed.o qed-gencb.o qed-l2-cache.o qed-table.o qed-cluster.o
block-nested-y += qed-check.o
block-nested-y += parallels.o nbd.o blkdebug.o sheepdog.o blkverify.o
diff --git a/block/qcow2-cache.c b/block/qcow2-cache.c
new file mode 100644
index 000..8767632
--- /dev/null
+++ b/block/qcow2-cache.c
@@ -0,0 +1,270 @@
+/*
+ * L2/refcount table cache for the QCOW2 format
+ *
+ * Copyright (c) 2010 Kevin Wolf
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "block_int.h"
+#include "qemu-common.h"
+#include "qcow2.h"
+
+typedef struct QcowCachedTable {
+void* table;
+int64_t offset;
+booldirty;
+int cache_hits;
+int ref;
+} QcowCachedTable;
+
+struct QcowCache {
+int size;
+QcowCachedTable*entries;
+struct QcowCache* depends;
+boolwritethrough;
+};
+
+QcowCache *qcow2_cache_create(BlockDriverState *bs, int num_tables,
+bool writethrough)
+{
+BDRVQcowState *s = bs->opaque;
+QcowCache *c;
+int i;
+
+c = qemu_mallocz(sizeof(*c));
+c->size = num_tables;
+c->entries = qemu_mallocz(sizeof(*c->entries) * num_tables);
+c->writethrough = writethrough;
+
+for (i = 0; i < c->size; i++) {
+c->entries[i].table = qemu_blockalign(bs, s->cluster_size);
+}
+
+return c;
+}
+
+int qcow2_cache_destroy(BlockDriverState* bs, QcowCache *c)
+{
+int i;
+int ret;
+
+ret = qcow2_cache_flush(bs, c);
+
+for (i = 0; i < c->size; i++) {
+assert(c->entries[i].ref == 0);
+qemu_vfree(c->entries[i].table);
+}
+qemu_free(c->entries);
+
+bdrv_flush(bs->file);
+
+return ret;
+}
+
+static int qcow2_cache_flush_dependency(BlockDriverState *bs, QcowCache *c)
+{
+int ret;
+
+ret = qcow2_cache_flush(bs, c->depends);
+if (ret < 0) {
+return ret;
+}
+
+c->depends = NULL;
+return 0;
+}
+
+static int qcow2_cache_entry_flush(BlockDriverState *bs, QcowCache *c, int i)
+{
+BDRVQcowState *s = bs->opaque;
+int ret;
+
+if (!c->entries[i].dirty || !c->entries[i].offset) {
+return 0;
+}
+
+if (c->d
Re: [Qemu-devel] [PATCH] arm-dis: Include opcode hex when doing disassembly
On 10 January 2011 10:49, Aurelien Jarno wrote: > Strangely on arm host, the opcode hex is already included, as shown > below: > > | OUT: [size=308] > | 0x01001ec0: e5974004 ldr r4, [r7, #4] > | 0x01001ec4: e1a04804 lsl r4, r4, #16 > | 0x01001ec8: e1a04824 lsr r4, r4, #16 > | 0x01001ecc: e1a04404 lsl r4, r4, #8 > > Maybe there is just an option to enable to allow that? It looks like that's just an ugly #ifdef in disas.c:disas(): #ifdef __arm__ /* since data is included in the code, it is better to display code data too */ fprintf(out, "%08x ", (int)bfd_getl32((const bfd_byte *)pc)); #endif ...so I guess if we commit the patch I submitted we should just delete that #ifdef. -- PMM
Re: [Qemu-devel] [PATCH] arm-dis: Include opcode hex when doing disassembly
On Mon, Jan 10, 2011 at 11:09:28AM -0600, Peter Maydell wrote: > On 10 January 2011 10:49, Aurelien Jarno wrote: > > Strangely on arm host, the opcode hex is already included, as shown > > below: > > > > | OUT: [size=308] > > | 0x01001ec0: e5974004 ldr r4, [r7, #4] > > | 0x01001ec4: e1a04804 lsl r4, r4, #16 > > | 0x01001ec8: e1a04824 lsr r4, r4, #16 > > | 0x01001ecc: e1a04404 lsl r4, r4, #8 > > > > Maybe there is just an option to enable to allow that? > > It looks like that's just an ugly #ifdef in disas.c:disas(): > #ifdef __arm__ > /* since data is included in the code, it is better to >display code data too */ > fprintf(out, "%08x ", (int)bfd_getl32((const bfd_byte *)pc)); > #endif > > ...so I guess if we commit the patch I submitted we should > just delete that #ifdef. > Agreed. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] [PATCH 1/3] MAINTAINERS: fix typos
Signed-off-by: Aurelien Jarno --- MAINTAINERS |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 59effc7..98af4ab 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -202,7 +202,7 @@ M: Edgar E. Iglesias S: Maintained F: hw/etraxfs.c -M86K Machines +M68K Machines - an5206 M: Paul Brook @@ -279,7 +279,7 @@ F: hw/r2d.c Shix M: Magnus Damm -S: Oprhan +S: Orphan F: hw/shix.c SPARC Machines -- 1.7.2.3
[Qemu-devel] [PATCH 2/3] MAINTAINERS: Change MIPS and SH4 maintainers
Since nobody else seems interested in maintaining MIPS and SH4 targets, and as I have done most of the recent code changes, let officialize that. Signed-off-by: Aurelien Jarno --- MAINTAINERS |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 98af4ab..3f15b21 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -81,8 +81,8 @@ S: Maintained F: target-microblaze/ MIPS -M: qemu-devel@nongnu.org -S: Orphan +M: Aurelien Jarno +S: Maintained F: target-mips/ PowerPC @@ -96,8 +96,8 @@ S: Maintained F: target-s390x/ SH4 -M: qemu-devel@nongnu.org -S: Orphan +M: Aurelien Jarno +S: Maintained F: target-sh4/ SPARC -- 1.7.2.3
[Qemu-devel] [PATCH] tcg arm/mips/ia64: add a comment about retranslation and caches
Add a comment about cache coherency and retranslation, so that people
developping new targets based on existing ones are warned of the issue.
Cc: Alexander Graf
Cc: Edgar E. Iglesias
Signed-off-by: Aurelien Jarno
---
tcg/arm/tcg-target.c |3 +++
tcg/ia64/tcg-target.c |3 +++
tcg/mips/tcg-target.c |4 +++-
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
index 1eb5605..918e2f7 100644
--- a/tcg/arm/tcg-target.c
+++ b/tcg/arm/tcg-target.c
@@ -352,6 +352,9 @@ static inline void tcg_out_b(TCGContext *s, int cond,
int32_t offset)
static inline void tcg_out_b_noaddr(TCGContext *s, int cond)
{
+/* We pay attention here to not modify the branch target by skipping
+ the corresponding bytes. This ensure that caches and memory are
+ kept coherent during retranslation. */
#ifdef HOST_WORDS_BIGENDIAN
tcg_out8(s, (cond << 4) | 0x0a);
s->code_ptr += 3;
diff --git a/tcg/ia64/tcg-target.c b/tcg/ia64/tcg-target.c
index e2e44f7..8dac7f7 100644
--- a/tcg/ia64/tcg-target.c
+++ b/tcg/ia64/tcg-target.c
@@ -871,6 +871,9 @@ static void tcg_out_br(TCGContext *s, int label_index)
{
TCGLabel *l = &s->labels[label_index];
+/* We pay attention here to not modify the branch target by reading
+ the existing value and using it again. This ensure that caches and
+ memory are kept coherent during retranslation. */
tcg_out_bundle(s, mmB,
tcg_opc_m48(TCG_REG_P0, OPC_NOP_M48, 0),
tcg_opc_m48(TCG_REG_P0, OPC_NOP_M48, 0),
diff --git a/tcg/mips/tcg-target.c b/tcg/mips/tcg-target.c
index 4e92a50..e04b0dc 100644
--- a/tcg/mips/tcg-target.c
+++ b/tcg/mips/tcg-target.c
@@ -351,7 +351,9 @@ static inline void tcg_out_opc_imm(TCGContext *s, int opc,
int rt, int rs, int i
*/
static inline void tcg_out_opc_br(TCGContext *s, int opc, int rt, int rs)
{
-/* We need to keep the offset unchanged for retranslation */
+/* We pay attention here to not modify the branch target by reading
+ the existing value and using it again. This ensure that caches and
+ memory are kept coherent during retranslation. */
uint16_t offset = (uint16_t)(*(uint32_t *) s->code_ptr);
tcg_out_opc_imm(s, opc, rt, rs, offset);
--
1.7.2.3
[Qemu-devel] [PATCH 3/3] MAINTAINERS: add entries for TCG
The MAINTAINERS file was lacking entries concerning the TCG code, add them based on the git history. For the common TCG code, is probably better to keep qemu-de...@non-gnu.org as this code can break easily, so it's better to get it reviewed by a few persons. v1 -> v2: - Changed i386 as maintained (community maintenance) - Add Richard Henderson as the second s390 maintainer Cc: Alexander Graf Cc: Andrzej Zaborowski Cc: Aurelien Jarno Cc: Blue Swirl Cc: Richard Henderson Cc: Vassili Karpov (malc) Signed-off-by: Aurelien Jarno --- MAINTAINERS | 53 + 1 files changed, 53 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3f15b21..41cf429 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -426,3 +426,56 @@ Linux user M: Riku Voipio S: Maintained F: linux-user/ + +Tiny Code Generator (TCG) +- +Common code +M: qemu-devel@nongnu.org +S: Maintained +F: tcg/ + +ARM target +M: Andrzej Zaborowski +S: Maintained +F: tcg/arm/ + +HPPA target +M: qemu-devel@nongnu.org +S: Orphan +F: tcg/hppa/ + +i386 target +M: qemu-devel@nongnu.org +S: Maintained +F: tcg/i386/ + +IA64 target +M: Aurelien Jarno +S: Maintained +F: tcg/ia64/ + +MIPS target +M: Aurelien Jarno +S: Maintained +F: tcg/mips/ + +PPC +M: Vassili Karpov (malc) +S: Maintained +F: tcg/ppc/ + +PPC64 target +M: Vassili Karpov (malc) +S: Maintained +F: tcg/ppc64/ + +S390 target +M: Alexander Graf +M: Richard Henderson +S: Maintained +F: tcg/s390/ + +SPARC target +M: Blue Swirl +S: Maintained +F: tcg/sparc/ -- 1.7.2.3
[Qemu-devel] Re: [PATCH 3/3] MAINTAINERS: add entries for TCG
On 10.01.2011, at 18:34, Aurelien Jarno wrote: > The MAINTAINERS file was lacking entries concerning the TCG code, add > them based on the git history. > > For the common TCG code, is probably better to keep qemu-de...@non-gnu.org > as this code can break easily, so it's better to get it reviewed by a few > persons. > > v1 -> v2: > - Changed i386 as maintained (community maintenance) > - Add Richard Henderson as the second s390 maintainer > > Cc: Alexander Graf > Cc: Andrzej Zaborowski > Cc: Aurelien Jarno > Cc: Blue Swirl > Cc: Richard Henderson > Cc: Vassili Karpov (malc) > Signed-off-by: Aurelien Jarno Acked-by: Alexander Graf Alex
[Qemu-devel] Re: [PATCH v4] savevm: Fix no_migrate
On Sun, 2011-01-09 at 12:47 +0200, Michael S. Tsirkin wrote:
> On Fri, Jan 07, 2011 at 03:13:25PM -0700, Alex Williamson wrote:
> > The no_migrate save state flag is currently only checked in the
> > last phase of migration. This means that we potentially waste
> > a lot of time and bandwidth with the live state handlers before
> > we ever check the no_migrate flags. The error message printed
> > when we catch a non-migratable device doesn't get printed for
> > a detached migration. And, no_migrate does nothing to prevent
> > an incoming migration to a target that includes a non-migratable
> > device. This attempts to fix all of these.
> >
> > One notable difference in behavior is that an outgoing migration
> > now checks for non-migratable devices before ever connecting to
> > the target system. This means the target will remain listening
> > rather than exit from failure.
> >
> > Signed-off-by: Alex Williamson
>
> Minor nit:
>
> The API of qemu_savevm_state_blocked is a bit strange.
> functions should either return 0/1 values or 0 on success
> negative on failure or a bool.
> This API asks "is it blocked" and returns -EINVAL to
> mean "yes". _blocked is also a bit ambigious:
> it seems to imply a temporary condition.
But it very well could be a temporary condition. If I have an assigned
device, it will block migration/savevm, but removing the device allows
it to proceed.
> How about we reverse the logic, call the new API
> qemu_savevm_state_supported, qemu_savevm_state_enabled,
> something like this?
> Then you can return 0 if migration is possible,
> -1 if not.
I tend to like qemu_savevm_state_blocked() as "supported" and "enabled"
invoke different ideas for me. I will concede that the errno return
value is a little awkward. How about if I make it a bool function
instead? Thanks,
Alex
> > ---
> >
> > v4:
> > - fix braces noted by Jan
> > - return error from qemu_savevm_state_blocked rather than fixed EINVAL
> > at qemu_loadvm_state(), since it'a already using errno values
> >
> > v3:
> >
> > Daniel, adding you to see if libvirt cares about the difference in
> > whether the target exits on migration failure as noted above.
> >
> > Also adding Michael as he's complained about the no_migrate check
> > happening so late in the process.
> >
> > migration.c |4
> > savevm.c| 41 +++--
> > sysemu.h|1 +
> > 3 files changed, 32 insertions(+), 14 deletions(-)
> >
> > diff --git a/migration.c b/migration.c
> > index e5ba51c..d593b1d 100644
> > --- a/migration.c
> > +++ b/migration.c
> > @@ -88,6 +88,10 @@ int do_migrate(Monitor *mon, const QDict *qdict, QObject
> > **ret_data)
> > return -1;
> > }
> >
> > +if (qemu_savevm_state_blocked(mon)) {
> > +return -1;
> > +}
> > +
> > if (strstart(uri, "tcp:", &p)) {
> > s = tcp_start_outgoing_migration(mon, p, max_throttle, detach,
> > blk, inc);
> > diff --git a/savevm.c b/savevm.c
> > index 90aa237..34c0d1a 100644
> > --- a/savevm.c
> > +++ b/savevm.c
> > @@ -1401,19 +1401,13 @@ static int vmstate_load(QEMUFile *f, SaveStateEntry
> > *se, int version_id)
> > return vmstate_load_state(f, se->vmsd, se->opaque, version_id);
> > }
> >
> > -static int vmstate_save(QEMUFile *f, SaveStateEntry *se)
> > +static void vmstate_save(QEMUFile *f, SaveStateEntry *se)
> > {
> > -if (se->no_migrate) {
> > -return -1;
> > -}
> > -
> > if (!se->vmsd) { /* Old style */
> > se->save_state(f, se->opaque);
> > -return 0;
> > +return;
> > }
> > vmstate_save_state(f,se->vmsd, se->opaque);
> > -
> > -return 0;
> > }
> >
> > #define QEMU_VM_FILE_MAGIC 0x5145564d
> > @@ -1427,6 +1421,20 @@ static int vmstate_save(QEMUFile *f, SaveStateEntry
> > *se)
> > #define QEMU_VM_SECTION_FULL 0x04
> > #define QEMU_VM_SUBSECTION 0x05
> >
> > +int qemu_savevm_state_blocked(Monitor *mon)
> > +{
> > +SaveStateEntry *se;
> > +
> > +QTAILQ_FOREACH(se, &savevm_handlers, entry) {
> > +if (se->no_migrate) {
> > +monitor_printf(mon, "state blocked by non-migratable device
> > '%s'\n",
> > + se->idstr);
> > +return -EINVAL;
> > +}
> > +}
> > +return 0;
> > +}
> > +
> > int qemu_savevm_state_begin(Monitor *mon, QEMUFile *f, int blk_enable,
> > int shared)
> > {
> > @@ -1508,7 +1516,6 @@ int qemu_savevm_state_iterate(Monitor *mon, QEMUFile
> > *f)
> > int qemu_savevm_state_complete(Monitor *mon, QEMUFile *f)
> > {
> > SaveStateEntry *se;
> > -int r;
> >
> > cpu_synchronize_all_states();
> >
> > @@ -1541,11 +1548,7 @@ int qemu_savevm_state_complete(Monitor *mon,
> > QEMUFile *f)
> > qemu_put_be32(f, se->instance_id);
> > qemu_put_be32(f, se->version_id);
> >
> > -r =
[Qemu-devel] Re: [PATCH 3/3] MAINTAINERS: add entries for TCG
On 10.01.2011, at 18:34, Aurelien Jarno wrote: > Cc: Andrzej Zaborowski ^- That email address always bounces for me. Are you sure it's still valid? Alex
[Qemu-devel] Re: [PATCH] tcg arm/mips/ia64: add a comment about retranslation and caches
On 10.01.2011, at 18:34, Aurelien Jarno wrote: > Add a comment about cache coherency and retranslation, so that people > developping new targets based on existing ones are warned of the issue. > > Cc: Alexander Graf > Cc: Edgar E. Iglesias > Signed-off-by: Aurelien Jarno Thanks :) Acked-by: Alexander Graf Alex
Re: [Qemu-devel] Linux as VirtualBox quest OS with QEMU running Solaris
On 10/01/11 17:08, Stefan Weil wrote: Am 10.01.2011 12:19, schrieb Mateusz Loskot: On 07/01/11 18:15, Stefan Weil wrote: There are no precompiled windows binaries of current qemu, so you will have to compile them yourself (which is not difficult once you have the correct mingw environment). Great. I think I should be able to do that. Which version of QEMU source code should I grab? Latest stable or development version from Git repo? I suggest using QEMU git master. You could try the binaries from my website: http://www.weilnetz.de/qemu/ Stefan, Thank you very much! So far, I have tried to use versions of QEMU from Qemu Manager 0.7 as well as QEMU 0.13 from http://homepage3.nifty.com/takeda-toshiya/ but without any luck. I suppose it's because these versions do not have most recent OpenBIOS usable with SPARC. I quickly tried your binaries and it looks I have to run them from within MSYS environment, isn't it? I'm getting runtime error reporting msys-z.dll is missing. I tried to find instructions on building QEMU with MinGW. No luck. Is there anything available? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Re: [Qemu-devel] Re: [PATCH 3/3] MAINTAINERS: add entries for TCG
On 10 January 2011 18:46, Alexander Graf wrote: > > On 10.01.2011, at 18:34, Aurelien Jarno wrote: > >> Cc: Andrzej Zaborowski > > ^- That email address always bounces for me. Are you sure it's still valid? It is outdated, please use or alternatively just the mailling list. Cheers
Re: [Qemu-devel] Re: [PATCH 3/3] MAINTAINERS: add entries for TCG
On Mon, Jan 10, 2011 at 07:01:47PM +0100, andrzej zaborowski wrote: > On 10 January 2011 18:46, Alexander Graf wrote: > > > > On 10.01.2011, at 18:34, Aurelien Jarno wrote: > > > >> Cc: Andrzej Zaborowski > > > > ^- That email address always bounces for me. Are you sure it's still valid? > > It is outdated, please use or alternatively just > the mailling list. > Ok, fixed locally. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] [Bug 544527] Re: usbfs is bugged with >2.6.32.9 and <=2.6.33 (breaks VMWare, Qemu, sane scanners, ...)
** Changed in: linux (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/544527 Title: usbfs is bugged with >2.6.32.9 and <=2.6.33 (breaks VMWare, Qemu, sane scanners, ...) Status in QEMU: Fix Committed Status in SANE-backends - Backends for SANE: Fix Committed Status in Tv Time: Fix Committed Status in Virtualbox: Fix Committed Status in “linux” package in Ubuntu: Fix Released Bug description: Binary package hint: tvtime There's a problem with isochronous and usbfs, suse tried to improve usbfs but it end up that it broke usbfs. For isochronous the entire packet needs to be copied and not only a part of it. http://lkml.org/lkml/2010/2/26/490 (Report) http://lkml.org/lkml/2010/2/27/226 (Bugfix) please merge this bugfix asap. ProblemType: Bug Architecture: amd64 Date: Mon Mar 22 21:09:00 2010 DistroRelease: Ubuntu 10.04 LiveMediaBuild: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100322) Package: tvtime 1.0.2-5ubuntu2 ProcEnviron: LANG=de_DE.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.32-16.25-generic SourcePackage: tvtime Uname: Linux 2.6.32-16-generic x86_64
