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

In VMXAssist (setup.c), the function setup_ctx() initializes the various
selectors, especially, the TSS is being set up like this:
 
    c->tr_sel = TSS_SELECTOR;
    c->tr_limit = sizeof(tss)-1;
    c->tr_base = (unsigned long) &tss;
    c->tr_arbytes.fields.seg_type = 0xb; /* 0x9 | 0x2 (busy) */
 
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.

We encountered this problem while developing PCI pass-through support
for Xen.

Signed-off-by: Alex Novik <alex@neocleus.com>
Signed-off-by: Guy Zana <guy@neocleus.com>
 
Thanks,
Guy.


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

On 20/5/07 16:09, "Guy Zana" <guy@neocleus.com> 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
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
> Sent: Sunday, May 20, 2007 8:57 PM
> To: Guy Zana; xen-devel@lists.xensource.com
> 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
3A),
(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.

Thanks,
Guy.

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

On 20/5/07 21:23, "Guy Zana" <guy@neocleus.com> wrote:
> The limit should specify the number of bytes in the segment (Section 2.4.4
Vol
> 3A),
> (Which is exactly the sizeof of the struct :))
> Maybe the VMCS are treated differently?
No, it''s just one of many examples of lazy wording in the Intel
manuals. I
am certain that my original explanation is correct.

 -- Keir



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