On Sat, 2013-02-16 at 02:37 +0100, Laszlo Ersek wrote:
I give up. Thanks for the help sorry about spamming three lists.
I've managed to reproduce this on a clean F18 system. This is the stock
qemu 1.2.2-6.fc18 on kernel 3.7.6-201.fc18.x86_64 with a newly-installed
Fedora 18 VM in the guest.
On 02/14/13 23:24, David Woodhouse wrote:
On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
reset requested by the guest doesn't work as expected. The behavior is
an infinite loop, with the following debug fragment
On Fri, 2013-02-15 at 19:54 +0100, Laszlo Ersek wrote:
Same infinite loop, alas...
(i) What is your host kernel exactly?
3.7.5-201.fc18.x86_64 (booted from EFI on a MacBookPro 8,3).
(ii) And when you say you did a legacy boot, does that mean you installed
the guest OS as a traditional one?
Hi,
I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
reset requested by the guest doesn't work as expected. The behavior is
an infinite loop, with the following debug fragment repeated by the
CSM-ized SeaBIOS:
In resume (status=0)
In 32bit resume
Attempting a hard
On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
Can we dumb down ^W^W generalize this code? :) Or maybe should qemu
introduce a reset handler for PAMs?
In the UEFI+CSM model, I believe the handling of PAM stuff is left
*entirely* to the UEFI side and the CSM is supposed to be
On 02/14/13 21:55, David Woodhouse wrote:
So, if real hardware would reset the PAMs on reset and avoid the need
for SeaBIOS to do so, I think we should be doing the same in qemu too.
That's what I couldn't figure out from the i440FX spec, but I believe
one could argue that reset should in fact
On Thu, 2013-02-14 at 21:41 +0100, Laszlo Ersek wrote:
I noticed that under OVMF + SeaBIOS CSM + your related patches for both,
reset requested by the guest doesn't work as expected. The behavior is
an infinite loop, with the following debug fragment repeated by the
CSM-ized SeaBIOS:
In
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
