From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takuya Yoshikawa Subject: Re: Frame buffer corruptions with KVM >= 2.6.36 Date: Fri, 15 Oct 2010 15:41:37 +0900 Message-ID: <4CB7F7A1.4030409@oss.ntt.co.jp> References: <4CB6B0FB.7080100@web.de> <4CB6F33E.3020009@siemens.com> <4CB6F3F1.9060409@redhat.com> <4CB6F932.8030605@siemens.com> <4CB6F9DE.6060008@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , kvm To: Avi Kivity Return-path: Received: from serv2.oss.ntt.co.jp ([222.151.198.100]:33538 "EHLO serv2.oss.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756157Ab0JOGkD (ORCPT ); Fri, 15 Oct 2010 02:40:03 -0400 In-Reply-To: <4CB6F9DE.6060008@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: (2010/10/14 21:38), Avi Kivity wrote: > On 10/14/2010 02:36 PM, Jan Kiszka wrote: >> > >> >> and this commit just makes the >> >> corruptions more likely. This may even be a QEMU issue in the cirrus/vga >> >> model (both qemu-kvm and upstream show the effect). >> >> >> > >> > What about -no-kvm? >> >> Just booted it (took ages), and the result was actually a completely >> black screen. Kind of persistent corruption. This really looks like a >> qemu issue now, maybe even a regression as I don't remember running into >> such effects a while back. > > Worked fine for me (though yes it was slow - did tcg regress?). > I reread my commit but could not find any reason to make this corruption in kernel side. But at least, I want to make it clear whether my commit was just a magnifier of this problem, I know that magnifier itself is bad, or not. Though I'm now trying some debugging but have not got a way to show kvm_vm_ioctl_get_dirty_log() is 100% correct yet. If you have any idea please tell me! Takuya