On 02/15/13 02:22, Kevin O'Connor wrote: > On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote: >> On Fri, Feb 15, 2013 at 12:01:38AM +0100, Laszlo Ersek wrote: >>> On 02/14/13 21:55, David Woodhouse wrote: >>> >>>> Thanks for testing this, btw. Are you looking at suspend/resume too? :) >>> >>> Entering S3 seemed OK (except the screen was not cleared; using Cirrus). >>> I woke up the guest with >>> >>> # virsh qemu-monitor-command fw-ovmf.g-f18xfce2012121716.e-rhel63 \ >>> --hmp --cmd system_wakeup >>> >>> Trailing portion of the log: >>> >>> In resume (status=254) >>> In 32bit resume >>> rsdp=0x00000000 >>> No resume vector set! >> >> That is strange. As noted elsewhere, on a resume or reboot the cpu >> should have started execution at 0xfffffff0 which is OVMF and not >> SeaBIOS. I don't understand why/how SeaBIOS would be involved in the >> resume code path at all. > > By chance, are you using an older version of kvm? There was a bug in > kvm that caused changes to memory mapped at 0xe0000-0xfffff to also be > reflected in the "rom" image at 0xfffe0000-0xffffffff. It was my > understand that this bug was fixed though.
You are great! Disabling KVM for the guest (/domain/@type='qemu') made the reboot work on both the RHEL-6 devel version of qemu and on upstream 1.3.1. (I didn't try suspend/resume yet.) Do you recall the precise commit that fixed the "reflection"? I've been eyeballing kvm commit messages for a few ten minutes now, but of course in vain. (CC'ing Gleb and Marcelo.) Thank you, Laszlo
