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
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
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:
> 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:
> 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 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
>
> # vi
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
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? :)
On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote:
> On 02/15/13 02:22, Kevin O'Connor wrote:
> > On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote:
> > By chance, are you using an older version of kvm? There was a bug in
> > kvm that caused changes to memory mapped at 0xe0
15.02.2013 07:43, Kevin O'Connor wrote:
> On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote:
>> On 02/15/13 02:22, Kevin O'Connor wrote:
>>> On Thu, Feb 14, 2013 at 08:16:02PM -0500, Kevin O'Connor wrote:
>>> By chance, are you using an older version of kvm? There was a bug in
>>> kvm t
(removing edk2-devel, adding Jan)
On 02/15/13 08:19, Michael Tokarev wrote:
> 15.02.2013 07:43, Kevin O'Connor wrote:
>> On Fri, Feb 15, 2013 at 04:10:59AM +0100, Laszlo Ersek wrote:
>>> 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 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 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/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 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
15 matches
Mail list logo
