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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf 
> Of Xen patchbot-unstable
> Sent: 29 September 2006 13:50
> To: xen-changelog@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-changelog] [xen-unstable] [HVM][SVM] Obtaining 
> instruction address needs to mask to 32 bits
> 
> # HG changeset patch
> # User kfraser@xxxxxxxxxxxxxxxxxxxxx
> # Node ID 792fb641ea7b2a7bdd65ac3c959f92b7528e157a
> # Parent  e229687561cff6d4daa0548c746c07e549bbc0ca
> [HVM][SVM] Obtaining instruction address needs to mask to 32 bits
> if not running in 64-bit mode.
> Signed-off-by: Keir Fraser <keir@xxxxxxxxxxxxx>
> ---
>  xen/arch/x86/hvm/svm/emulate.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff -r e229687561cf -r 792fb641ea7b xen/arch/x86/hvm/svm/emulate.c
> --- a/xen/arch/x86/hvm/svm/emulate.c  Fri Sep 29 11:25:25 2006 +0100
> +++ b/xen/arch/x86/hvm/svm/emulate.c  Fri Sep 29 11:50:51 2006 +0100
> @@ -341,7 +341,11 @@ unsigned long svm_rip2pointer(struct vmc
>       * %cs is update, but fortunately, base contain the 
> valid base address
>       * no matter what kind of addressing is used.
>       */
> -    return vmcb->cs.base + vmcb->rip;
> +    unsigned long p = vmcb->cs.base + vmcb->rip;
> +    if (!(vmcb->cs.attributes.fields.l && vmcb->efer & EFER_LMA))
> +        return (u32)p; /* mask to 32 bits */
> +    /* NB. Should mask to 16 bits if in real mode or 16-bit 
> protected mode. */

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... ;-)

--
Mats


> +    return p;
>  }
>  
>  
> 
> _______________________________________________
> Xen-changelog mailing list
> Xen-changelog@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-changelog
> 
> 
> 



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