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 patch 'fixes' it, and I think it might even be correct in itself,
> > but I don't think it's a correct fix for the problem we're discussing.
> > And I certainly want to know what's different on my laptop that makes it
> > work *without* this patch.
> >
> > Either there's some weirdness with setting the high CS base address, on
> > CPU reset. Or perhaps the contents of the memory region at 0xfffffff0
> > have *really* been changed along with the sub-1MiB range. Or maybe the
> > universe just hates us...
>
> We're ending up in the wrong place, under 1MB (which is consistent with
> your "reset the PAMs" patch -- state of PAMs should only matter below
> 1MB).
>
> 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 issue
> the following in virsh:
>
> # qemu-monitor-command --domain \
> fw-mixed.g-f18xfce2012121716.e-upstream --hmp --cmd \
> cpu 0
>
> # qemu-monitor-command --domain \
> fw-mixed.g-f18xfce2012121716.e-upstream --hmp --cmd \
> info registers
>
> for EIP and CS I get (from cpu_x86_dump_seg_cache(), in the
> "HF_CS64_MASK clear" branch):
>
> EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000623
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
> EIP=0000fff0 EFL=00000002 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
> ES =0000 00000000 0000ffff 0000f300
> CS =f000 000f0000 0000ffff 0000f300
> ^ ^ ^ ^
> | base limit flags
> selector
>
This is because real mode is emulated as vm86 mode on intel cpus without
"unrestricted guest" flag.
--
Gleb.
