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: Guy Zana <guy@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] VMXAssist: Bug fix (selector initialization)
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sun, 20 May 2007 18:56:39 +0100
Delivery-date: Sun, 20 May 2007 10:52:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <9392A06CB0FDC847B3A530B3DC174E7B02960F60@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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: Acea8NzqwaJQXijoT0OJdI8E07f9aAAF1ozo
Thread-topic: [Xen-devel] [PATCH] VMXAssist: Bug fix (selector initialization)
User-agent: Microsoft-Entourage/
On 20/5/07 16:09, "Guy Zana" <guy@xxxxxxxxxxxx> wrote:

> The TSS limit is initialized to be sizeof(tss)-1, this leaves the last
> byte of the I/O permission bitmap out, and accesses to ioports above
> 0xFFF8 causes the emulation to halt (the bits that were left out are
> treated as being set and a #GPF is generated but not treated for outw,
> for example).
> Besides that, all other selectors are initialized in the same way (idt,
> gdt).
> I'm guessing that way way way back, the TSS was not a structure but
> rather a null-terminated string.

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

I will put together and apply a patch for this.

 -- Keir

Xen-devel mailing list