From owner-freebsd-xen@FreeBSD.ORG Fri Dec 16 19:49:00 2011 Return-Path: Delivered-To: xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30B0E1065675 for ; Fri, 16 Dec 2011 19:49:00 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id F31128FC12 for ; Fri, 16 Dec 2011 19:48:59 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id E7DAE290FFA; Fri, 16 Dec 2011 13:32:31 -0600 (CST) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id D4EE3290FFC; Fri, 16 Dec 2011 13:32:31 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id S2ElfrLKQ8Ew; Fri, 16 Dec 2011 13:32:31 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id 42C93290FFA; Fri, 16 Dec 2011 13:32:31 -0600 (CST) Message-ID: <4EEB9CCE.6090701@rice.edu> Date: Fri, 16 Dec 2011 13:32:30 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: xen@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Cox Subject: PV i386 patch X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 19:49:00 -0000 Is anyone here actively working on fixing problems with SMP support under PV i386? While doing some other maintenance on the vm_page_alloc() callers in the source tree, I happened to take a look at cpu_initialize_context() in mp_machdep.c. This function is involved in bringing up the 2nd, 3rd, etc. CPUs on an SMP system. I spotted a couple obvious errors. First, the size parameter given to kmem_*() functions is expected to be in terms of bytes and not pages. Second, I believe that PV i386 requires PAE to be used. If so, there are out of range accesses to the array m[]. Index: i386/xen/mp_machdep.c =================================================================== --- i386/xen/mp_machdep.c (revision 228561) +++ i386/xen/mp_machdep.c (working copy) @@ -810,7 +810,7 @@ cpu_initialize_context(unsigned int cpu) { /* vcpu_guest_context_t is too large to allocate on the stack. * Hence we allocate statically and protect it with a lock */ - vm_page_t m[4]; + vm_page_t m[NPGPTD + 2]; static vcpu_guest_context_t ctxt; vm_offset_t boot_stack; vm_offset_t newPTD; @@ -831,8 +831,8 @@ cpu_initialize_context(unsigned int cpu) pmap_zero_page(m[i]); } - boot_stack = kmem_alloc_nofault(kernel_map, 1); - newPTD = kmem_alloc_nofault(kernel_map, NPGPTD); + boot_stack = kmem_alloc_nofault(kernel_map, PAGE_SIZE); + newPTD = kmem_alloc_nofault(kernel_map, NPGPTD * PAGE_SIZE); ma[0] = VM_PAGE_TO_MACH(m[0])|PG_V; #ifdef PAE @@ -854,7 +854,7 @@ cpu_initialize_context(unsigned int cpu) nkpt*sizeof(vm_paddr_t)); pmap_qremove(newPTD, 4); - kmem_free(kernel_map, newPTD, 4); + kmem_free(kernel_map, newPTD, 4 * PAGE_SIZE); /* * map actual idle stack to boot_stack */