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, Feb 18, 2013 at 06:12:55PM +0100, Laszlo Ersek wrote:
> 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
On Mon, Feb 18, 2013 at 07:16:25PM +0100, Laszlo Ersek wrote:
> On 02/18/13 18:45, Gleb Natapov wrote:
> > On Mon, Feb 18, 2013 at 06:12:55PM +0100, Laszlo Ersek wrote:
>
> >> CS =f000 000f f300
> >> ^^^^
> >> |base limitflags
> >> selec
On Mon, 2013-02-18 at 19:16 +0100, Laszlo Ersek wrote:
> On 02/18/13 18:45, Gleb Natapov wrote:
> > On Mon, Feb 18, 2013 at 06:12:55PM +0100, Laszlo Ersek wrote:
>
> >> CS =f000 000f f300
> >> ^^^^
> >> |base limitflags
> >> selector
> >
On 02/18/13 18:45, Gleb Natapov wrote:
> On Mon, Feb 18, 2013 at 06:12:55PM +0100, Laszlo Ersek wrote:
>> CS =f000 000f f300
>> ^^^^
>> |base limitflags
>> selector
>>
> This is because real mode is emulated as vm86 mode on intel cpus wi
On Mon, Feb 18, 2013 at 06:12:55PM +0100, Laszlo Ersek wrote:
> On 02/18/13 13:53, David Woodhouse wrote:
> I single-stepped qemu-1.3.1 in x86_cpu_reset() /
> cpu_x86_load_seg_cache(), and we seem to set the correct base. However
> when I pause the VM when it's spinning in the reset loop, and I iss
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
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 Feb 14, 2013, at 2:09 PM, "H. Peter Anvin" wrote:
> On 02/14/2013 01:27 PM, David Woodhouse wrote:
>>
>> So it *is* jumping to 0xfff0 but the memory at that location isn't
>> what we expect? Do the PAM registers affect *that* too, or only the
>> region from 0xc-0xf? Surely the co
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 22:27, David Woodhouse wrote:
> On Thu, 2013-02-14 at 22:14 +0100, Laszlo Ersek wrote:
>> 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.
On 02/14/2013 01:27 PM, David Woodhouse wrote:
So it *is* jumping to 0xfff0 but the memory at that location isn't
what we expect? Do the PAM registers affect *that* too, or only the
region from 0xc-0xf? Surely the contents at 4GiB-δ should be
unchanged by *anything* we do with the PA
On Thu, 2013-02-14 at 22:14 +0100, Laszlo Ersek wrote:
> 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.
> >>
> >
> > T
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
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.
>
>
18 matches
Mail list logo
