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/
Home Products Support Community News


RE: [Xen-devel] [PATCH] VMXAssist: Bug fix (selector initialization)

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] VMXAssist: Bug fix (selector initialization)
From: "Guy Zana" <guy@xxxxxxxxxxxx>
Date: Sun, 20 May 2007 16:23:24 -0400
Delivery-date: Sun, 20 May 2007 13:25:27 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2764A67.7B05%Keir.Fraser@xxxxxxxxxxxx>
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: Acea8NzqwaJQXijoT0OJdI8E07f9aAAF1ozoAARQuiA=
Thread-topic: [Xen-devel] [PATCH] VMXAssist: Bug fix (selector initialization)

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
> Sent: Sunday, May 20, 2007 8:57 PM
> To: Guy Zana; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] VMXAssist: Bug fix (selector 
> initialization)
> They are all set up this way because segment limits always 
> indicate the last accessible byte. Hence the limit is one 
> byte less than the size. You can see this clearly when 
> running a VMX guest: hit the 'v' debug key and look at the 
> contents of VMCS fields 0x4800-0x4812. You will see that all 
> these 32-bit limit fields contain odd numbers.

The limit should specify the number of bytes in the segment (Section 2.4.4 Vol 
(Which is exactly the sizeof of the struct :))
Maybe the VMCS are treated differently?

> The problem here is that the I/O bitmap should always be 
> terminated with an extra all-1s byte. See Section 13.5.2 of 
> Vol.1 the Intel PRM.

Missed that.


Xen-devel mailing list