|
xen-devel
Re: [Xen-devel] Real-mode bug with AMD, gPXE, and 32-bit rep movs
Keir Fraser wrote:
On 26/03/2009 12:25, "George Dunlap" <George.Dunlap@xxxxxxxxxxxxx> wrote:
There are three possibilities I came up with:
1) The same thing would happen outside of SVM; in which case it's
(sort of) a gPXE bug for using an instruction that won't work on AMD
boxes.
2) Xen is subtly screwing up the VM state, causing the AMD hardware
not to recognize that this shouldn't cause a #GP
3) AMD hardware (at least some of it) doesn't handle 32-bit rep movs
instructions in 16-bit mode.
It must surely be a Xen bug. Doing 32-bit ops in 16-bit mode is a completely
standard thing that all processors will support. The other alternative is
perhaps we have somehow managed to build ourselves a bogus gpxe image.
for #3, I meant that perhaps the AMD hardware didn't handle it properly
in non-root mode (as opposed to #1, which suggested it may not work on
AMD hardware at all). I'm not that familiar with this level of the x86
architecture at all, so I'll take your word for it. :-)
Your assertion that it causes GP on Intel is weird. We should be running in
the emulator already since for the movs to 0x200000 to work we must be
running in big real mode (i.e., one of the segment registers has a limit
greater than 0xffff) and so we cannot be emulating that by running the guest
in vm86 mode.
Maybe I wasn't clear, or didn't use the technical terms properly; in any
case, here's a trace from an Intel box about the code in question. I
added some extra tracing to gather information about what happened in
the emulation. You see:
* An io port write (the last thing before the instruction).
* An EXCEPTION_NMI exit at the code in question (cs=c900 eip=1cb, linear
address = c91cb) caused by a trap 13 (GP fault)
* The emulator copies 1 page from c9000 to 200000
* Repeats for ca000 -> 201000
! 4.110129337 -x vmentry
] 4.110130683 -x vmexit exit_reason IO_INSTRUCTION eip 7b16
4.110130683 -x io write port 981 val 40
4.110133785 -x runstate_change d2v0 running->offline
[dom0 handles the io write]
4.110142327 -x runstate_change d2v0 runnable->running
! 4.110144371 -x vmentry
] 4.110145950 -x vmexit exit_reason EXCEPTION_NMI eip 1cb
4.110145950 -x realmode (trap 13)
4.110145950 -x rep_mov sseg 2 soff 0 dseg 3 doff 200000
4.110145950 -x rep_mov2 saddr c9000 sgpa c9000 daddr 200000 dgpa 200000
] 4.110156960 -x vmentry cycles 26424 !
] 4.110158295 -x vmexit exit_reason EXCEPTION_NMI eip 1cb
4.110158295 -x realmode (trap 13)
4.110158295 -x rep_mov sseg 2 soff 1000 dseg 3 doff 201000
4.110158295 -x rep_mov2 saddr ca000 sgpa ca000 daddr 201000 dgpa 201000
] 4.110162836 -x vmentry cycles 10899 !
So it seems clear that:
* it was not in all-emulation mode
* it took a GP fault at that instruction
* it emulated it successfully.
Is this not what's expected?
I can give some help tracking this down when I'm back next week, if it's not
resolved by then. It's also the sort of thing which may interest Tim Deegan,
who has also worked on real mode support on the Intel side in the past.
Tim gave me a hand to get this far. I'm going to try to get the rep
movs instruction into Gianluca's "xentest" framework when he comes back
next week, so we can isolate different variables better.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home