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.
q
On 02/15/13 21:57, David Woodhouse wrote:
> 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).
- host CPU: Xeon W3550 (family/model/stepping = 6/26/5)
-
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 traditiona
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 frag
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 --
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:
>
>
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 f
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
hardware-a
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 re
