(2010/10/15 15:41), Takuya Yoshikawa wrote:
(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.
I tried some tests and found another issue.
I opened a terminal in one workspace and did "find /" on it. Then I switched
to another workspace. When I switched back to the first one, the display of
"find /" result was frozen.
I also replaced kvm_vm_ioctl_get_dirty_log() with the version before my patch was
applied and got the same result.
I don't know this is related to your report, but something seems wrong.
Thanks,
Takuya
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
