[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Guy Zana <guy@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acea8NzqwaJQXijoT0OJdI8E07f9aAAF1ozo
  • Thread-topic: [Xen-devel] [PATCH] VMXAssist: Bug fix (selector initialization)

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.