[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
> -----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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |