On 08/21/12 10:23, Stefan Hajnoczi wrote:
On Tue, Aug 21, 2012 at 8:21 AM, Jan Kiszkajan.kis...@siemens.com wrote:
On 2012-08-19 11:42, Avi Kivity wrote:
On 08/17/2012 06:04 PM, Jan Kiszka wrote:
Can anyone imagine that such a barrier may actually be required? If it
is currently possible
On 2012-08-19 11:42, Avi Kivity wrote:
On 08/17/2012 06:04 PM, Jan Kiszka wrote:
Can anyone imagine that such a barrier may actually be required? If it
is currently possible that env-stop is evaluated before we called into
sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the
On Tue, Aug 21, 2012 at 8:21 AM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-08-19 11:42, Avi Kivity wrote:
On 08/17/2012 06:04 PM, Jan Kiszka wrote:
Can anyone imagine that such a barrier may actually be required? If it
is currently possible that env-stop is evaluated before we called
On 08/17/2012 06:04 PM, Jan Kiszka wrote:
Can anyone imagine that such a barrier may actually be required? If it
is currently possible that env-stop is evaluated before we called into
sigtimedwait in qemu_kvm_eat_signals, then we could actually eat the
signal without properly processing its
On 2012-08-06 17:11, Stefan Hajnoczi wrote:
On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven p...@dlhnet.de wrote:
i debugged my initial problem further and found out that the problem happens
to be that
the main thread is stuck in pause_all_vcpus() on reset or quit commands in
the monitor
if
On 2012-08-17 15:11, Jan Kiszka wrote:
On 2012-08-06 17:11, Stefan Hajnoczi wrote:
On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven p...@dlhnet.de wrote:
i debugged my initial problem further and found out that the problem happens
to be that
the main thread is stuck in pause_all_vcpus() on reset
On 2012-08-17 16:36, Jan Kiszka wrote:
On 2012-08-17 15:11, Jan Kiszka wrote:
On 2012-08-06 17:11, Stefan Hajnoczi wrote:
On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven p...@dlhnet.de wrote:
i debugged my initial problem further and found out that the problem
happens
to be that
the main
On 2012-08-17 16:41, Jan Kiszka wrote:
On 2012-08-17 16:36, Jan Kiszka wrote:
On 2012-08-17 15:11, Jan Kiszka wrote:
On 2012-08-06 17:11, Stefan Hajnoczi wrote:
On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven p...@dlhnet.de wrote:
i debugged my initial problem further and found out that the
On Thu, Jun 28, 2012 at 2:05 PM, Peter Lieven p...@dlhnet.de wrote:
i debugged my initial problem further and found out that the problem happens
to be that
the main thread is stuck in pause_all_vcpus() on reset or quit commands in
the monitor
if one cpu is stuck in the do-while loop
On 07/05/2012 07:12 AM, Peter Lieven wrote:
On 07/03/12 15:13, Avi Kivity wrote:
On 07/03/2012 04:01 PM, Peter Lieven wrote:
Further output from my testing.
Working:
Linux 2.6.38 with included kvm module
Linux 3.0.0 with included kvm module
Not-Working:
Linux 3.2.0 with included kvm
On 06/28/2012 05:11 PM, Peter Lieven wrote:
that here is bascially whats going on:
qemu-kvm-1.0-2506 [010] 60996.908000: kvm_mmio: mmio read len
3 gpa 0xa val 0x10ff
qemu-kvm-1.0-2506 [010] 60996.908000: vcpu_match_mmio: gva 0xa
gpa 0xa Read GPA
On 05.07.2012 10:51, Xiao Guangrong wrote:
On 06/28/2012 05:11 PM, Peter Lieven wrote:
that here is bascially whats going on:
qemu-kvm-1.0-2506 [010] 60996.908000: kvm_mmio: mmio read len 3
gpa 0xa val 0x10ff
qemu-kvm-1.0-2506 [010] 60996.908000: vcpu_match_mmio:
On 07/03/12 17:54, Marcelo Tosatti wrote:
On Wed, Jun 27, 2012 at 12:35:22PM +0200, Peter Lieven wrote:
Hi,
we recently came across multiple VMs racing and stopping working. It
seems to happen when the system is at 100% cpu.
One way to reproduce this is:
qemu-kvm-1.0.1 with vnc-thread enabled
appreciate help.
if anyone wants to reproduce:
a) v3.2 from git.kernel.org
b) qemu-kvm 1.0.1 from sourceforge
c) ubuntu 64-bit 12.04 server cd
d) empty (e.g. all zero) hard disk image
cmdline:
./qemu-system-x86_64 -m 512 -cdrom
/home/lieven/Downloads/ubuntu-12.04-server-amd64.iso -hda
/dev/hd1/vmtest
On 07/03/12 15:13, Avi Kivity wrote:
On 07/03/2012 04:01 PM, Peter Lieven wrote:
Further output from my testing.
Working:
Linux 2.6.38 with included kvm module
Linux 3.0.0 with included kvm module
Not-Working:
Linux 3.2.0 with included kvm module
Linux 2.6.28 with kvm-kmod 3.4
Linux 3.0.0
way to reproduce this is:
qemu-kvm-1.0.1 with vnc-thread enabled
cmdline (or similar):
/usr/bin/qemu-kvm-1.0.1 -net
tap,vlan=141,script=no,downscript=no,ifname=tap15,vnet_hdr -net
nic,vlan=141,model=virtio,macaddr=52:54:00:ff:00:f7 -drive
format=host_device,file=/dev/mapper/iqn.2001-05
Further output from my testing.
Working:
Linux 2.6.38 with included kvm module
Linux 3.0.0 with included kvm module
Not-Working:
Linux 3.2.0 with included kvm module
Linux 2.6.28 with kvm-kmod 3.4
Linux 3.0.0 with kvm-kmod 3.4
Linux 3.2.0 with kvm-kmod 3.4
I can trigger the race with any of
On 07/03/2012 04:01 PM, Peter Lieven wrote:
Further output from my testing.
Working:
Linux 2.6.38 with included kvm module
Linux 3.0.0 with included kvm module
Not-Working:
Linux 3.2.0 with included kvm module
Linux 2.6.28 with kvm-kmod 3.4
Linux 3.0.0 with kvm-kmod 3.4
Linux 3.2.0
On 03.07.2012 15:13, Avi Kivity wrote:
On 07/03/2012 04:01 PM, Peter Lieven wrote:
Further output from my testing.
Working:
Linux 2.6.38 with included kvm module
Linux 3.0.0 with included kvm module
Not-Working:
Linux 3.2.0 with included kvm module
Linux 2.6.28 with kvm-kmod 3.4
Linux 3.0.0
On 07/03/2012 04:15 PM, Peter Lieven wrote:
On 03.07.2012 15:13, Avi Kivity wrote:
On 07/03/2012 04:01 PM, Peter Lieven wrote:
Further output from my testing.
Working:
Linux 2.6.38 with included kvm module
Linux 3.0.0 with included kvm module
Not-Working:
Linux 3.2.0 with included kvm
On Wed, Jun 27, 2012 at 12:35:22PM +0200, Peter Lieven wrote:
Hi,
we recently came across multiple VMs racing and stopping working. It
seems to happen when the system is at 100% cpu.
One way to reproduce this is:
qemu-kvm-1.0.1 with vnc-thread enabled
cmdline (or similar):
/usr/bin/qemu
On 2012-07-01 21:18, Peter Lieven wrote:
Am 01.07.2012 um 10:19 schrieb Avi Kivity:
On 06/28/2012 10:27 PM, Peter Lieven wrote:
Am 28.06.2012 um 18:32 schrieb Avi Kivity:
On 06/28/2012 07:29 PM, Peter Lieven wrote:
Yes. A signal is sent, and KVM returns from the guest to userspace on
On 02.07.2012 09:05, Jan Kiszka wrote:
On 2012-07-01 21:18, Peter Lieven wrote:
Am 01.07.2012 um 10:19 schrieb Avi Kivity:
On 06/28/2012 10:27 PM, Peter Lieven wrote:
Am 28.06.2012 um 18:32 schrieb Avi Kivity:
On 06/28/2012 07:29 PM, Peter Lieven wrote:
Yes. A signal is sent, and KVM
On 06/28/2012 12:38 PM, Peter Lieven wrote:
does anyone know whats that here in handle_mmio?
/* hack: Red Hat 7.1 generates these weird accesses. */
if ((addr 0xa-4 addr = 0xa) kvm_run-mmio.len == 3)
return 0;
Just what it says. There is a 4-byte access to
still
see the issue. If I use the kvm Module provided with the kernel it is
working correctly. If I use kvm-kmod-3.4 with qemu-kvm-1.0.1 (both
from sourceforge) I can reproduce the race condition.
I will keep you posted when I have more evidence.
Thanks,
Peter
--
To unsubscribe from this list: send
On 06/28/2012 10:27 PM, Peter Lieven wrote:
Am 28.06.2012 um 18:32 schrieb Avi Kivity:
On 06/28/2012 07:29 PM, Peter Lieven wrote:
Yes. A signal is sent, and KVM returns from the guest to userspace on
pending signals.
is there a description available how this process exactly works?
The
Am 01.07.2012 um 10:19 schrieb Avi Kivity:
On 06/28/2012 10:27 PM, Peter Lieven wrote:
Am 28.06.2012 um 18:32 schrieb Avi Kivity:
On 06/28/2012 07:29 PM, Peter Lieven wrote:
Yes. A signal is sent, and KVM returns from the guest to userspace on
pending signals.
is there a description
On 27.06.2012 18:54, Jan Kiszka wrote:
On 2012-06-27 17:39, Peter Lieven wrote:
Hi all,
i debugged this further and found out that kvm-kmod-3.0 is working with
qemu-kvm-1.0.1 while kvm-kmod-3.3 and kvm-kmod-3.4 are not. What is
working as well is kvm-kmod-3.4 with an old userspace (qemu-kvm
On 2012-06-28 11:11, Peter Lieven wrote:
On 27.06.2012 18:54, Jan Kiszka wrote:
On 2012-06-27 17:39, Peter Lieven wrote:
Hi all,
i debugged this further and found out that kvm-kmod-3.0 is working with
qemu-kvm-1.0.1 while kvm-kmod-3.3 and kvm-kmod-3.4 are not. What is
working as well is kvm
On 28.06.2012 11:21, Jan Kiszka wrote:
On 2012-06-28 11:11, Peter Lieven wrote:
On 27.06.2012 18:54, Jan Kiszka wrote:
On 2012-06-27 17:39, Peter Lieven wrote:
Hi all,
i debugged this further and found out that kvm-kmod-3.0 is working with
qemu-kvm-1.0.1 while kvm-kmod-3.3 and kvm-kmod-3.4
:
On 2012-06-28 11:11, Peter Lieven wrote:
On 27.06.2012 18:54, Jan Kiszka wrote:
On 2012-06-27 17:39, Peter Lieven wrote:
Hi all,
i debugged this further and found out that kvm-kmod-3.0 is working
with
qemu-kvm-1.0.1 while kvm-kmod-3.3 and kvm-kmod-3.4 are not. What is
working as well is kvm-kmod
On 2012-06-28 11:31, Peter Lieven wrote:
On 28.06.2012 11:21, Jan Kiszka wrote:
On 2012-06-28 11:11, Peter Lieven wrote:
On 27.06.2012 18:54, Jan Kiszka wrote:
On 2012-06-27 17:39, Peter Lieven wrote:
Hi all,
i debugged this further and found out that kvm-kmod-3.0 is working with
qemu-kvm
that kvm-kmod-3.0 is working with
qemu-kvm-1.0.1 while kvm-kmod-3.3 and kvm-kmod-3.4 are not. What is
working as well is kvm-kmod-3.4 with an old userspace (qemu-kvm-0.13.0).
Has anyone a clue which new KVM feature could cause this if a vcpu is in
an infinite loop?
Before accusing kvm-kmod ;), can you
that kvm-kmod-3.0 is working with
qemu-kvm-1.0.1 while kvm-kmod-3.3 and kvm-kmod-3.4 are not. What is
working as well is kvm-kmod-3.4 with an old userspace (qemu-kvm-0.13.0).
Has anyone a clue which new KVM feature could cause this if a vcpu is in
an infinite loop?
Before accusing kvm-kmod ;), can you
Hi,
i debugged my initial problem further and found out that the problem
happens to be that
the main thread is stuck in pause_all_vcpus() on reset or quit commands
in the monitor
if one cpu is stuck in the do-while loop kvm_cpu_exec. If I modify the
condition from while (ret == 0)
to while
On 2012-06-28 15:05, Peter Lieven wrote:
Hi,
i debugged my initial problem further and found out that the problem
happens to be that
the main thread is stuck in pause_all_vcpus() on reset or quit commands
in the monitor
if one cpu is stuck in the do-while loop kvm_cpu_exec. If I modify the
, and which commit
introduced or fixed it?
qemu-kvm-1.0.1 from sourceforge. to get into the scenario it
is not sufficient to boot from an empty harddisk. to reproduce
i have use a live cd like ubuntu-server 12.04 and choose to
boot from the first harddisk. i think the isolinux loader does
not check
compile a more recent kvm-kmod 3.3 or 3.4 on these machines,
it is no longer working.
I was asking for kernel 3.3 or 3.4 without kvm-kmod.
- with which qemu-kvm version is it reproducible, and which commit
introduced or fixed it?
qemu-kvm-1.0.1 from sourceforge. to get into the scenario
On 28.06.2012 17:22, Jan Kiszka wrote:
On 2012-06-28 17:02, Peter Lieven wrote:
On 28.06.2012 15:25, Jan Kiszka wrote:
On 2012-06-28 15:05, Peter Lieven wrote:
Hi,
i debugged my initial problem further and found out that the problem
happens to be that
the main thread is stuck in
On 06/28/2012 07:29 PM, Peter Lieven wrote:
Yes. A signal is sent, and KVM returns from the guest to userspace on
pending signals.
is there a description available how this process exactly works?
The kernel part is in vcpu_enter_guest(), see the check for
signal_pending(). But this hasn't
Hi,
we recently came across multiple VMs racing and stopping working. It
seems to happen when the system is at 100% cpu.
One way to reproduce this is:
qemu-kvm-1.0.1 with vnc-thread enabled
cmdline (or similar):
/usr/bin/qemu-kvm-1.0.1 -net
tap,vlan=141,script=no,downscript=no,ifname=tap15
On 2012-06-27 17:39, Peter Lieven wrote:
Hi all,
i debugged this further and found out that kvm-kmod-3.0 is working with
qemu-kvm-1.0.1 while kvm-kmod-3.3 and kvm-kmod-3.4 are not. What is
working as well is kvm-kmod-3.4 with an old userspace (qemu-kvm-0.13.0).
Has anyone a clue which new
qemu-kvm-1.0.1 is now available. This release is based on the upstream
qemu 1.0.1, plus kvm-specific enhancements. Please see the
original QEMU 1.0.1 release announcement [1] for details.
This release can be used with the kvm kernel modules provided by your
distribution kernel, or by the modules
Hi,
i was wondering if there will be a qemu-kvm version 1.0.1?
The last tag I see here is 1.0:
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=summary
Any hints?
Thanks,
Peter
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
44 matches
Mail list logo
