|
From: | Peter Lieven |
Subject: | Re: [Qemu-devel] race between kvm-kmod-3.0 and kvm-kmod-3.3 // was: race condition in qemu-kvm-1.0.1 |
Date: | Mon, 02 Jul 2012 17:57:32 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 |
On 02.07.2012 17:05, Avi Kivity wrote:
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> 0xa0000-4&& addr<= 0xa0000)&& kvm_run->mmio.len == 3) return 0;Just what it says. There is a 4-byte access to address 0x9ffff. The first byte lies in RAM, the next three bytes are in mmio. qemu is geared to power-of-two accesses even though x86 can generate accesses to any number of bytes between 1 and 8.
I just stumbled across the word "hack" in the comment. When the race occurs the CPU is basically reading from 0xa0000 in an endless loop.
It appears that this has happened with your guest. It's not impossible that it's genuine.
I had a lot to do the last days, but I update our build environment to Ubuntu LTS 12.04 64-bit Server which is based on Linux 3.2.0. I 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
[Prev in Thread] | Current Thread | [Next in Thread] |