As vmx_create_vcpu already makes use of start/end_special_insn, we need
to initialise the emulated preempt_notifier earlier. Let's move it to
kvm_vcpu_init. This should fix an oops I've seen here at least once
during kvm startup - so far the problem did not show up again.
Signed-off-by: Jan
Hi,
I'm seeing fairly high vm-exit latencies (300-400 us) during and only
during qemu/kvm startup and shutdown on a Core2 T5500 in 32-bit mode.
It's most probably while the VM runs inside bios code. During the rest
of the time, while some Linux guest is running, the exit latencies are
within
Gregory Haskins wrote:
On Tue, 2007-10-23 at 16:19 +0200, Avi Kivity wrote:
Jan Kiszka wrote:
Avi,
[somehow your mails do not get through to my private account, so I'm
switching]
Avi Kivity wrote:
Jan Kiszka wrote:
Clarification: I can't precisely tell what code is executed
Avi Kivity wrote:
Jan Kiszka wrote:
Avi Kivity wrote:
Please post a disassembly of your vmx_vcpu_run so we can interpret the
offsets.
Here it comes:
2df0 vmx_vcpu_run:
2df0: 55 push %ebp
2df1: 89 e5 mov%esp,%ebp
Avi Kivity wrote:
Jan Kiszka wrote:
I ran
user/kvmctl user/test/bootstrap user/test/smp.flat
with the busy loop hacked into bootstrap, but I got no latency spots
this time. And what should I look for in the output of kvm_stat?
The first numeric column is the total number of exits
Carsten Emde wrote:
Avi Kivity wrote:
David Brown wrote:
I thought I'd try out the realtime patch set and it didn't work at all
with kvm. The console didn't dump anything and the system completely
locked up.
Up to now, the unmodified kvm module never worked with any RT kernel.
This would
Avi Kivity wrote:
Jan Kiszka wrote:
Interesting result - you've read about the wbinvd issues? Is there no
wbinvd in the bios shipped with older kvm? Which VM extension did you
test, both Intel and AMD? I would bet that your X issues are due to the
same effect. X startup/shutdown involves
Hi,
running some oldish 286 protected mode demo in kvm, I came across this
bug of kvm-52:
unhandled vm exit: 0x8021 vcpu_id 0
rax 6010 rbx rcx rdx
0003
rsi 0400 rdi 0008042e rsp 01fa rbp
Avi Kivity wrote:
Jan Kiszka wrote:
Hi,
running some oldish 286 protected mode demo in kvm, I came across this
bug of kvm-52:
unhandled vm exit: 0x8021 vcpu_id 0
ds (0010/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0)
ds.base must equal ds.sel4 when entering real
was aware of an
x86_64-related problem in QEMU's gdbstub, I merged its current state
into kvm - and things start to work again. Find the update patch below.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/gdbstub.c | 290 -
1 file changed, 143
Jan Kiszka wrote:
We've noticed some problems with current gdbstub in kvm's qemu:
# qemu-system-x86_64 -hda myimage -S -s
# gdb
(gdb) tar re :1234
Remote debugging using :1234
Remote 'g' packet reply is too long:
[...]
This issue did not occur
Avi Kivity wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
We've noticed some problems with current gdbstub in kvm's qemu:
# qemu-system-x86_64 -hda myimage -S -s
# gdb
(gdb) tar re :1234
Remote debugging using :1234
Remote 'g' packet reply is too long
Avi Kivity wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
We've noticed some problems with current gdbstub in kvm's qemu:
# qemu-system-x86_64 -hda myimage -S -s
# gdb
(gdb) tar re :1234
Remote debugging using :1234
Remote 'g' packet reply is too long
Guido Guenther wrote:
On Tue, Jan 08, 2008 at 01:34:30PM +0900, Jun Koi wrote:
Sorry for my ignorance, but what is the effect of this patch? So
I can shutdown guest VM cleanly, or smt else??
system_powerdown in the commmand monitor now simulates the pressing of
the acpi power button.
Hi Avi,
commit kvm: qemu: consume all pending I/O in I/O loop
(8ab8bb09f1115b9bf733f885cc92b6c63d83f420) broke reading data bursts
from serial devices (and maybe from other character devices as well) by
guests. Reason: serial devices do input flow control via fd_read_poll,
but qemu now ignores
Yang, Sheng wrote:
--- /dev/null
+++ b/arch/x86/kvm/i8254.h
...
+#define PIT_BASE_ADDRESS 0x40
+#define SPEAKER_BASE_ADDRESS 0x61
+#define PIT_MEM_LENGTH 4
+#define PIT_FREQ 1193181
The PIT may not be limited to x86 platforms. So I would propose to make
the
Avi Kivity wrote:
Jan Kiszka wrote:
The PIT may not be limited to x86 platforms. So I would propose to make
the setup more generic and flexible. And I would move the code out of
arch/x86, just the speaker support should remain there.
I'm currently struggling with emulating a proprietary
Hi Guido,
[posting via gmane sucks, just re-enabled mail delivery in this account...]
Guido Guenther wrote:
Hi Jan,
On Sat, Jan 19, 2008 at 04:40:06PM +0100, Jan Kiszka wrote:
What about additionally listening on signals? If you run qemu from the
console, you can then just press ctrl-c
Avi Kivity wrote:
Dor Laor wrote:
On Mon, 2008-01-21 at 12:13 +0200, Avi Kivity wrote:
Jan Kiszka wrote:
Hi Avi,
commit kvm: qemu: consume all pending I/O in I/O loop
(8ab8bb09f1115b9bf733f885cc92b6c63d83f420) broke reading data bursts
from serial devices (and maybe from other
Avi Kivity wrote:
Jan Kiszka wrote:
Guido Guenther wrote:
Hi Jan,
On Sat, Jan 19, 2008 at 04:40:06PM +0100, Jan Kiszka wrote:
What about additionally listening on signals? If you run qemu from the
console, you can then just press ctrl-c to shut the guest down (instead
While trying to reduce the warning noise (to identify warnings of
homebrewed patches), I also came across this bogus but fortunately
harmless type change in bdrv_commit. Fix below.
Jan
Index: kvm-userspace/qemu/block.c
===
---
Carlo Marcelo Arenas Belon wrote:
On Mon, Jan 21, 2008 at 01:46:11PM +0100, Jan Kiszka wrote:
Here are 4 more warnings fixes (actually, I should sent 2 of them to
qemu...). Nothing critical, just less noise during compilation.
probably a good idea having them in independent patches
Gerd Hoffmann wrote:
Hi,
Catching ctrl-c sounds like a good idea but ctrl-c, ctrl-c should
probably kill qemu then, since the machine might have no acpid running -
in that case hitting ctrl-c would have no effect.
Good idea.
I'm worried about the 30+ second shutdown latency.
Guido Guenther wrote:
+#if defined(TARGET_I386)
+void qemu_system_powerdown(void)
+{
+if(pm_state-pmen PWRBTN_EN) {
+ pm_state-pmsts |= PWRBTN_EN;
+ pm_update_sci(pm_state);
+}
+}
+#endif
This code should also care about !pm_state, ie. non-PCI systems.
Jan
---
Guido Guenther wrote:
On Tue, Jan 22, 2008 at 11:11:00AM +0100, Jan Kiszka wrote:
#if defined(TARGET_I386)
void qemu_system_powerdown(void)
{
+if (!pm_state)
+exit(0);
if(pm_state-pmen PWRBTN_EN) {
pm_state-pmsts |= PWRBTN_EN;
pm_update_sci(pm_state
Dor Laor wrote:
On Mon, 2008-01-21 at 12:50 +0200, Avi Kivity wrote:
Dor Laor wrote:
On Mon, 2008-01-21 at 12:13 +0200, Avi Kivity wrote:
Jan Kiszka wrote:
Hi Avi,
commit kvm: qemu: consume all pending I/O in I/O loop
(8ab8bb09f1115b9bf733f885cc92b6c63d83f420) broke reading data
Avi Kivity wrote:
Liu, Eric E wrote:
Hi,
The following patches port xentrace to kvm which is useful for
performance tuning and debugging.
It is designed to allow debugging traces of kvm to be generated on
Up/Smp machines. Each trace entry is outputted in a trace ring buffer
for per cpu
Avi Kivity wrote:
Jan Kiszka wrote:
Avi Kivity wrote:
Liu, Eric E wrote:
Hi,
The following patches port xentrace to kvm which is useful for
performance tuning and debugging.
It is designed to allow debugging traces of kvm to be generated on
Up/Smp machines. Each trace entry
Yang, Sheng wrote:
...
BTW: I am working on NMI supporting now.
That's good news! Some weeks ago I posted a NMI infrastructure patch [1]
to qemu-devel already, for now only to support IOAPIC NMI watchdogs [1,
2]. Maybe you can make use of this. Please keep us posted about your
approach!
Jan
Hi,
I saw kvm-userspace recently merged qemu's new CPU_INTERRUPT_NMI
support. But the required infrastructure to use this in kvm mode is not
yet visible. Is anyone working on this? Sheng? IIRC, you once said to
work on it.
Currently I just need the basic mechanism for injecting NMIs into the
==by 0x461313: pc_init_pci (pc.c:1149)
==5801==by 0x43081B: main (vl.c:9845)
This silences valgrind and may even be correct (if I got the code path
right):
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
--- a/libkvm/libkvm.c
+++ b/libkvm/libkvm.c
@@ -328,9 +328,10 @@ static int
Joerg Roedel wrote:
On Tue, Apr 29, 2008 at 10:38:41AM +0200, Jan Kiszka wrote:
Joerg Roedel wrote:
Hmm, seems we have to check for DF and triple faults in the
kvm_queue_exception functions too. Does the attached patch fix the
problem (patch is against kvm-66).
Thanks, it indeed fixes
Hi,
looks like we are getting better and better here in hitting yet
unsupported corner-case features of KVM :). This time our guest fiddles
with hardware debugging registers, but quickly gets unhappy as they do
not yet have the expected effect.
Joerg, I found you SVM-related patch series in the
Joerg Roedel wrote:
On Tue, Apr 29, 2008 at 03:07:25PM +0200, Jan Kiszka wrote:
Hi,
looks like we are getting better and better here in hitting yet
unsupported corner-case features of KVM :). This time our guest fiddles
with hardware debugging registers, but quickly gets unhappy as they do
Avi Kivity wrote:
Jan Kiszka wrote:
Joerg Roedel wrote:
The current KVM x86 exception code handles double and triple faults
only for
page fault exceptions. This patch extends this detection for every
exception
that gets queued for the guest.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED
Joerg Roedel wrote:
The current KVM x86 exception code handles double and triple faults only for
page fault exceptions. This patch extends this detection for every exception
that gets queued for the guest.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
Cc: Jan Kiszka [EMAIL PROTECTED
Minor cleanup I came across while reverting printf instrumentations.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
libkvm/libkvm-x86.c |4 ++--
libkvm/libkvm.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
Index: b/libkvm/libkvm-x86.c
This looks bogus, but it is so far without practical impact (phys_start
is always 0 when we do the calculation).
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
libkvm/libkvm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/libkvm/libkvm.c
Avi Kivity wrote:
Jan Kiszka wrote:
Clear the pending original exception when raising a triple fault. This
allows to re-use the vcpu instance, e.g. after a reset which is
typically issued as reaction on the triple fault.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
arch/x86/kvm/x86.c
at least for the QEMU use case. If the callback complains
about the given address, we then fall back to RAM access.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
libkvm/libkvm-x86.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
Index: b/libkvm/libkvm-x86.c
Avi Kivity wrote:
Jan Kiszka wrote:
Userland-located ROM memory is not available via kvm-physical_memory +
guest_address. To let kvm_show_code also dump useful information when
some problem in ROM (BIOS...) occurs, this patch first tries to obtain
the memory content via the mmio_read callback
Avi Kivity wrote:
Jan Kiszka wrote:
This still leaves me with the question how to handle the case when the
host sets and arms some debug registers to debug the guest and the
latter does the same to debug itself. Guest access will be trapped, OK,
but KVM will then have to decide which value
, this patch now allows to break into the BIOS or
other guest code spinning in the vcpu (*) and to use things like info
cpus in the monitor.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/gdbstub.c | 12
qemu/monitor.c |3 +--
qemu/qemu-kvm.c | 39
Yang, Sheng wrote:
Hi
This patchset enabled NMI support for KVM.
The first three patches enabled NMI for in-kernel irqchip and NMI supporting
on VMX. The last patch enabled NMI watchdog in linux, can be used to test the
NMI injection.
In fact, this series should also included Jan
Jan Kiszka wrote:
Yang, Sheng wrote:
Hi
This patchset enabled NMI support for KVM.
The first three patches enabled NMI for in-kernel irqchip and NMI supporting
on VMX. The last patch enabled NMI watchdog in linux, can be used to test
the
NMI injection.
In fact, this series should
Marcelo Tosatti wrote:
Hi Jan,
On Thu, May 08, 2008 at 10:29:32AM +0200, Jan Kiszka wrote:
Resetting guests used to be racy, deadlock-prone, or simply broken (for
SMP). This patch fixes the issues - at least for me on x86 (tested on
Intel SMP host, UP and SMP guest, in-kernel und user space
Anthony Liguori wrote:
Marcelo Tosatti wrote:
diff --git a/qemu/qemu-kvm-ia64.c b/qemu/qemu-kvm-ia64.c
index 4d0ddd7..d227d22 100644
--- a/qemu/qemu-kvm-ia64.c
+++ b/qemu/qemu-kvm-ia64.c
@@ -61,3 +61,7 @@ int kvm_arch_try_push_interrupts(void *opaque)
void
(as
kvm_mutex_unlock clears cpu_single_env).
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/qemu-kvm.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
Index: b/qemu/qemu-kvm.c
===
--- a/qemu/qemu-kvm.c
-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/qemu-kvm-ia64.c|4
qemu/qemu-kvm-powerpc.c |4
qemu/qemu-kvm-x86.c | 16
qemu/qemu-kvm.c | 34 +-
qemu/qemu-kvm.h |1 +
qemu/vl.c |6
Having both kvm_eat_signal and kvm_eat_signals makes the code harder to
read. Moreover, given the single caller of kvm_eat_signals, there is no
real reason to keep it in a separate function.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/qemu-kvm.c | 11 ---
1 file changed, 4
info cpus in
the monitor.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/gdbstub.c | 12
qemu/monitor.c |3 +--
qemu/qemu-kvm.c | 41 +++--
qemu/vl.c |2 +-
4 files changed, 33 insertions(+), 25 deletions(-)
Index: b/qemu
Hi,
before going wild with my idea, I would like to collect some comments on
this approach:
While doing first kernel debugging with my debug register patches for
kvm, I quickly ran into the 4-breakpoints-only limitation that comes
from the fact that we blindly map software to hardware
Avi Kivity wrote:
Jan Kiszka wrote:
Resetting guests used to be racy, deadlock-prone, or simply broken (for
SMP). This patch fixes the issues, following Marcelo's suggestion to
consolidate the reset activity in the I/O thread. All vcpus are cleanly
stopped before the emulated hardware
Avi Kivity wrote:
Jan Kiszka wrote:
Having both kvm_eat_signal and kvm_eat_signals makes the code harder to
read. Moreover, given the single caller of kvm_eat_signals, there is no
real reason to keep it in a separate function.
Given that with the iothread we spend very little time
Jerone Young wrote:
On Mon, 2008-05-12 at 13:34 +0200, Jan Kiszka wrote:
Hi,
before going wild with my idea, I would like to collect some comments on
this approach:
While doing first kernel debugging with my debug register patches for
kvm, I quickly ran into the 4-breakpoints-only
Hollis Blanchard wrote:
On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote:
So gdb on power relies only on those few hw-breakpoints? With x86 you
can perfectly run gdb (with soft BPs) in parallel with the gdbstub
(currently based on hw-BPs, but the same would be true for soft-BPs
inserted
Hollis Blanchard wrote:
On Wednesday 14 May 2008 14:10:06 Jan Kiszka wrote:
Hollis Blanchard wrote:
On Wednesday 14 May 2008 10:28:51 Jan Kiszka wrote:
So gdb on power relies only on those few hw-breakpoints? With x86 you
can perfectly run gdb (with soft BPs) in parallel with the gdbstub
Dead code since it was introduced. Is it planned to use it in the near
future? Then I would suggest to put it under #if 0 for now. Otherwise,
please pick up this patch.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/kvm-tpr-opt.c | 13 -
1 file changed, 13 deletions(-)
Index
These warnings continued to bug me (while scanning for my own mess).
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/migration.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: b/qemu/migration.c
Here comes the second revision of the attempt to consolidate
kvm_eat_signal[s]. It follows the suggestions to remove looping over
kvm_eat_signal and folds everything into kvm_main_loop_wait.
Signed-off-by: Jan Kiszka [EMAIL PROTECTED]
---
qemu/qemu-kvm.c | 43
Avi Kivity wrote:
[I forgot to do this last weekend, so it's postponed to Saturday]
During the upcoming Saturday, the various kvm lists will move to
vger.kenel.org. This will improve responsiveness, and reduce spam and
advertising.
Please subscribe to the lists you are interested in as
Jan Kiszka wrote:
Avi Kivity wrote:
[I forgot to do this last weekend, so it's postponed to Saturday]
During the upcoming Saturday, the various kvm lists will move to
vger.kenel.org. This will improve responsiveness, and reduce spam and
advertising.
Please subscribe to the lists you
This is yet only a proof of concept; more cleanups, generalizations,
full arch support, and some care for ABI consistency are needed.
However, this series allows to actually _use_ guest debugging with kvm
on x86 (Intel only so far). There is no more limitation on how many
breakpoints can be used
[ Should apply against vanilla QEMU, but not ATM due to ongoing
constructions in gdbstub. ]
This patch prepares the QEMU cpu_watchpoint/breakpoint API to allow us
hooking in with KVM and doing guest debugging differently (maybe
QEMUAccel should provide appropriate callbacks for this, too). But it
In order to allow the gdbstub of QEMU to push (soft) breakpoint handling
completely into the gdb frontend, this patch enables guest exits also
for #BP exceptions - in case guest debugging was turned on.
Along this enhancement, this patch also fixes the flag manipulation for
the singlestep mode.
This adds an arch field to kvm_run.debug, the payload that is returned
to user space on KVM_EXIT_DEBUG guest exits. For x86, this field is now
supposed to report the precise debug exception (#DB or #BP) and the
current state of the debug registers (the latter is not yet
implemented).
---
With this patch applied, kvm is able to ignore breakpoint requests of an
attached gdb frontend so that the latter is motivated to insert soft
breakpoints into the guest code. All we need to do for this is to catch
and forward #BP exceptions which are now provided by the kernel module.
Along this,
67 matches
Mail list logo
