RE: [Xen-devel] Re: x86_64 SMP support (status update)

["Nakajima, Jun" <jun.nakajima@xxxxxxxxx>]

Keir Fraser wrote:
> On 27 Jun 2005, at 22:55, Keir Fraser wrote:
> 
>> Xen makes a shadow mapping of the per-vcpu gdt in its own address
>> space. This, coupled with Xen reserving the last 2 pages of GDT
>> entries for itself, requires every GDT to start on a page boundary.
>> So, even though per-cpu gdts are not page-aligned they must be at
>> least one page in size.
> 
> Last sentence should be "per-cpu gdts have to be page-aligned, so each
> one burns a page". :-)
> 
>   -- Keir

BTW, 

I'm debugging nptl01 in LTP when running in domU. Most of the test cases
pass except this one; kernel build was a piece of cake there :-). It
uses the FS base for TLS on x86_64, and does a number of domain
switching. I think this is a race condition with GDT switching, but what
happens is Xen sometimes causes #GP at => below because the entry does
not exist in GDT (fs = 0x5b). The nptl01 runs fine on dom0 as long as it
runs _alone_. It starts failing with presence of domUs. I feel this
implies some problems with GDT switching. Is there any race you think of
where modifications to GDT (done by do_update_descriptor) are not be
visible or deferred?

static void load_segments(struct vcpu *p, struct vcpu *n)
{
    struct vcpu_guest_context *pctxt = &p->arch.guest_context;
    struct vcpu_guest_context *nctxt = &n->arch.guest_context;

...

    /*
     * Either selector != 0 ==> reload.
     * Also reload to reset FS_BASE if it was non-zero.
     */
    if ( unlikely(pctxt->user_regs.fs |
                  pctxt->fs_base |
                  nctxt->user_regs.fs) )
    {
 =>       all_segs_okay &= loadsegment(fs, nctxt->user_regs.fs);
        if ( pctxt->user_regs.fs ) /* != 0 selector kills fs_base */
            pctxt->fs_base = 0;
    }



Jun
---
Intel Open Source Technology Center

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