[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] RE: [Xen-changelog] [xen-unstable] [HVM][SVM] Obtaining instruction address needs to mask to 32 bits


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Mon, 2 Oct 2006 13:56:26 +0200
  • Delivery-date: Mon, 02 Oct 2006 04:57:13 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acbkj2Ycm+fX3Gs5TrexzyyKH0xy7gBfZ8EgAAKtui4AAAQ+oA==
  • Thread-topic: [Xen-devel] RE: [Xen-changelog] [xen-unstable] [HVM][SVM] Obtaining instruction address needs to mask to 32 bits

 

> -----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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.