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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

So it turns out this is actually a bug in gPXE, combined with a
limit-check bug in HVM emulation.  The segment limit was only set to
16 bits, but was clearly trying to use a 32-bit address, so the AMD
hardware was doing exactly what it should have done.

The reason it worked on an Intel box was that the hvm address checking
logic doesn't do *any* limit checking when in real mode.  If you add a
real-mode segment limit check in hvm.c:hvm_virtual_to_linear_addr(),
then it the VM has the exact same issue.

So one thing is clear, we need to re-compile the gPXE "binary" that
comes in xen so that it doesn't violate segment limits.

We might think about checking some limits in real mode as well, just
for good measure.

 -George

On Thu, Mar 26, 2009 at 5:31 PM, Tim Deegan <Tim.Deegan@xxxxxxxxxx> wrote:
> At 16:24 +0000 on 26 Mar (1238084646), Christoph Egger wrote:
>> I think it's #2. Look at the #GP causes in APM
>> Volume 2 for MOVSx: the only one in real mode is if the address
>> exceeded a data segment limit.  And the comment from Deegan about
>> clipping segment limits to 16 bits makes me think that the clipping is
>> happening on AMD machines and it shouldn't be.
>
> That particular clipping happens in vmx.c so I certainly hope it doesn't
> get called on AMD machines. :)  But yes, it's likely that some
> big-real-mode segment state has got lost somewhere.
>
> Tim.
>
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, Citrix Systems (R&D) Ltd.
> [Company #02300071, SL9 0DZ, UK.]
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel