WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH] Fixing PAE SMP dom0 hang at boot time

To: "Ryan Harper" <ryanh@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Fixing PAE SMP dom0 hang at boot time
From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
Date: Wed, 16 Nov 2005 09:42:00 -0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 16 Nov 2005 17:42:05 +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: AcXqzIWO7h3zr+VaTOepFJieMYqifgAAFuTg
Thread-topic: [Xen-devel] [PATCH] Fixing PAE SMP dom0 hang at boot time
Ryan Harper wrote:
> * Nakajima, Jun <jun.nakajima@xxxxxxxxx> [2005-11-15 19:56]:
>> This patch fixes a hang with PAE SMP dom0 on big SMP machines. As
>> far as I tested, 8-way PAE SMP dom0 boots fine on >=8-way machines.
>> The fix is not PAE specific, and I made the equivent changes to
>> x86_64 xenlinux. Tested on both PAE and x86_64 dom0 xenlinux on
>> >=8-way SMP machines with 
>>> 6GB.
> 
> Jun,  could you explain the patch a bit more?
> 
> Why wouldn't we want to initialize the per-cpu gdt area for cpus other
> than CPU0 ?
> 
> -       cpu_gdt_init(&cpu_gdt_descr[cpu]);
> +       if (!cpu)
> +           cpu_gdt_init(&cpu_gdt_descr[cpu]);

CPU0 creates the (virutal) gdt for other CPUs in advance at
VCPUOP_initalise, and the propoer selector values are set up at the
same. So it's redundant. It also avoids spurious page faults caused by
make_page_readonly() against the gdt page. 

> 
> 
> And why would we need to take interrupts between loading esp0 and LDT?
> 
>         load_esp0(t, thread);
> 
> +       local_irq_enable();
> +
>         load_LDT(&init_mm.context);

I thought it's required to get IPI working (for load_LDT and the other
on-going flush TLB actitivies), but looks bogus after sleeping on it.
I'm pretty sure that it resolves the hang, and it's hiding an underlying
bug. 

Jun
---
Intel Open Source Technology Center

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