On 02/18/13 13:53, David Woodhouse wrote:
> Nevertheless, on my workstation as on yours, we do seem to end up
> executing from the CSM in RAM when we reset. But on my laptop, it
> executes the *ROM* as it should.
>
> This patch 'fixes' it, and I think it might even be correct in itself,
> but I do
Il 18/02/2013 16:00, David Woodhouse ha scritto:
> On Mon, 2013-02-18 at 15:46 +0100, Paolo Bonzini wrote:
>> > If you want to submit this patch for upstream QEMU (I agree it is a
>> > good idea), please set dc->reset instead in i440fx_class_init.
> Thanks.
>
> I just copied the way that PIIX3 doe
On Mon, 2013-02-18 at 15:46 +0100, Paolo Bonzini wrote:
> If you want to submit this patch for upstream QEMU (I agree it is a
> good idea), please set dc->reset instead in i440fx_class_init.
Thanks.
I just copied the way that PIIX3 does it... is that something that
piix3_class_init() should be do
Il 18/02/2013 13:53, David Woodhouse ha scritto:
>
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 6c77e49..6dcf1c5 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -171,6 +171,23 @@ static int i440fx_load_old(QEMUFile* f, void *opaque,
> int version_id)
> return 0;
> }
>
> +s
On Mon, 2013-02-18 at 10:40 +, David Woodhouse wrote:
> 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-
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 Fri, 2013-02-15 at 00:01 +0100, Laszlo Ersek wrote:
>
> 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 l
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 02/14/13 21:54, H. Peter Anvin wrote:
> On 02/14/2013 12:41 PM, Laszlo Ersek wrote:
>>
>> ). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
>> the exact address of... reset_vector() in SeaBIOS.
>>
>
> This would be a bug, but it isn't quite true.
>
> If you look at x86_cp
On Thu, 2013-02-14 at 12:54 -0800, H. Peter Anvin wrote:
> This would be a bug, but it isn't quite true.
>
> If you look at x86_cpu_reset() you will note that it sets the code
> segment base to 0x, not 0xf as one could expect from the
> above. This is also true of a physical x86.
>
>
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/2013 12:41 PM, Laszlo Ersek wrote:
>
> ). cpu_reset() [target-i386/helper.c] sets CS:IP to f000:fff0, which is
> the exact address of... reset_vector() in SeaBIOS.
>
This would be a bug, but it isn't quite true.
If you look at x86_cpu_reset() you will note that it sets the code
segment
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
18 matches
Mail list logo
