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] Re: x86_64 SMP support (status update)

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] Re: x86_64 SMP support (status update)
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Mon, 27 Jun 2005 15:15:49 -0700
Cc: Chris Wright <chrisw@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 27 Jun 2005 22:14:51 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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: AcV7ZIxlWfcv6GilQy6N91LDCigTngAADxbw
Thread-topic: [Xen-devel] Re: x86_64 SMP support (status update)
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


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;

Intel Open Source Technology Center

Xen-devel mailing list