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] RE: [Xen-changelog] [xen-unstable] [HVM][SVM] Obtaining

To: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RE: [Xen-changelog] [xen-unstable] [HVM][SVM] Obtaining instruction address needs to mask to 32 bits
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 02 Oct 2006 12:41:44 +0100
Delivery-date: Mon, 02 Oct 2006 04:41:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0B018E15AF@xxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acbkj2Ycm+fX3Gs5TrexzyyKH0xy7gBfZ8EgAAKtui4=
Thread-topic: [Xen-devel] RE: [Xen-changelog] [xen-unstable] [HVM][SVM] Obtaining instruction address needs to mask to 32 bits
User-agent: Microsoft-Entourage/11.2.5.060620
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?

 -- Keir



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