Re: Real-mode bug with AMD, gPXE, and 32-bit rep movs

[George Dunlap <george.dunlap@eu.citrix.com>]

Keir Fraser wrote:
> On 26/03/2009 12:25, "George Dunlap" <George.Dunlap@eu.citrix.com> 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