> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
> Sent: 02 October 2006 12:42
> To: Petersson, Mats; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] RE: [Xen-changelog] [xen-unstable]
> [HVM][SVM] Obtaining instruction address needs to mask to 32 bits
>
> On 2/10/06 11:34, "Petersson, Mats" <Mats.Petersson@xxxxxxx> wrote:
>
> > Actually, no. On a 8086, the address is 20 bits, 80286 would have 24
> > address bits and 32-bits in a 386 onwards. Real-mode
> (without trickery)
> > can't generate an address much higher than 20 bits
> [0xFFFF0+0xFFFF is
> > just over 20 bits, and it depends on the state of the
> A20-gate [do we
> > simulate that anywhere?] whether this is masked to near zero or just
> > over 1MB). Since big realmode only really works for data
> segments (it's
> > hard to avoid the CS segment being reloaded when you go back to
> > real-mode from protected mode - and should the processor take an
> > interrupt, it's game-over on the "big code-segment").
> >
> > So as a conclusion, I think the comment on masking 16-bit modes is
> > incorrect - any code that is INTENDED to run on a 286 and
> still can be
> > run on anything better would automatically use the 286
> addressing which
> > automatically limits the segment registers base address + limit to
> > 24-bits with no wrap-around - or it would break on a 386,
> and they would
> > have been around long enough that most people have fixed
> the code... ;-)
>
> Doesn't it depend on the D flag in the hidden CS segment
> state? If D==0 then
> should use IP instead of EIP (i.e., mask to 16 bits)? I agree
> that this
> would involve masking eip before adding to the base, rather
> than masking to
> 16 bits after adding to the base, so my comment is wrong
> either way. As a
> side note, updates to the program counter would also not
> affect the high 16
> bits of EIP if D==0, right?
Ah, good point - however, the processor should do this right for the
function in question [we're not adding anything to the rIP in the
relevant code, besides adding the base of the segment, which is not
directly related to the bitsize of the current mode].
Where we're adding to EIP we probably should take this into acocunt -
although most code wouldn't naturally wrap the IP (in fact, I think it's
a fault to do so - but I can't confirm that from any of my books), so
it's probably a very obscure corner-case - but it's probably a bit
nightmarish to debug so it's possibly better to have code that deals
with it correctly. I'll figure out if it's a fault or "wrap" that is the
correct operation first...
--
Mats
>
> -- Keir
>
>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home