On 09/19/2010 11:54 PM, Kevin O'Connor wrote:
On Thu, Sep 16, 2010 at 07:31:46PM -0400, Kevin O'Connor wrote:
On Thu, Sep 16, 2010 at 06:34:04PM +0200, Avi Kivity wrote:
On 09/16/2010 04:31 AM, Kevin O'Connor wrote:
Unfortunately, both qemu and kvm don't appear to have a reliable way to hard-reboot - normal reboots don't reset the 0xc0000-0xfffff memory. I've worked around this on qemu by manually resetting that memory. However, kvm doesn't keep a pristine copy of the bios at 0xffff0000. Until this is fixed, this patch series will cause a soft-reboot on kvm to result in a shutdown instead of a reboot.
[...]
To work around this, patch 7 does a copy from 0xffff0000 to 0xf0000 to manually clear the f-segment (qemu_prep_reset). This hack works okay for qemu. Unfortunately, it doesn't work for kvm - even after the copy HaveRunPost is still set. Normally, 0xffff0000 would have a pristine copy of the bios - changes to 0xf0000 should not also change 0xffff0000, but it looks like kvm does something different.
Hi Avi,
Are you okay with me applying this patch series to seabios? It will cause kvm guest reboots to turn into shutdowns until kvm can be changed.
Well, we can change development versions of kvm, but not deployed ones. If we apply this then we break many kvm installations.
However, if the problem is in qemu-kvm (not unlikely) then we can update qemu simultaneously with seabios. Since seabios is deployed together with qemu, that shouldn't break installations.
Can you post a git tree for me to test? I'd like to understand the issue better.