WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Real-mode bug with AMD, gPXE, and 32-bit rep movs

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Real-mode bug with AMD, gPXE, and 32-bit rep movs
From: George Dunlap <george.dunlap@xxxxxxxxxxxxx>
Date: Thu, 26 Mar 2009 15:15:06 +0000
Cc: Christoph Egger <Christoph.Egger@xxxxxxx>, "Huang2, Wei" <Wei.Huang2@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 26 Mar 2009 08:15:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C5F14523.501B%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C5F14523.501B%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (X11/20090318)
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