Hi Kuwamura-san.
Could you try the attached patch?
At least I can boot VTi domain with PV-on-HVM drivers
on c/s 18084:0b72d16e794b with the patch applied.
[IA64] allocate percpu area in xen va area.
To guarantee that the percpu are is pinned down,
move its virtual address from xen identity mapped area
to xen va area which is pinned by DTR[IA64_TR_KERNEL].
Then unnecessary tlb miss fault can be avoided.
Sometimes per cpu area is called from very critial
point where such a tlb miss isn't allowed.
Signed-off-by: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
diff -r 9feafce8afc5 xen/arch/ia64/linux-xen/mm_contig.c
--- a/xen/arch/ia64/linux-xen/mm_contig.c Wed Aug 06 11:55:56 2008 +0900
+++ b/xen/arch/ia64/linux-xen/mm_contig.c Wed Aug 06 16:08:06 2008 +0900
@@ -175,6 +175,41 @@
#endif
#ifdef CONFIG_SMP
+#ifdef XEN
+#include <asm/elf.h>
+
+void *percpu_area __initdata = NULL;
+
+void* __init
+per_cpu_allocate(void *xen_heap_start, unsigned long end_in_pa)
+{
+ int order = get_order(NR_CPUS * PERCPU_PAGE_SIZE);
+ unsigned long size = (1UL << order) * PAGE_SIZE;
+ unsigned long start = ALIGN_UP((unsigned long)xen_heap_start,
+ PERCPU_PAGE_SIZE);
+ unsigned long end = start + size;
+
+ if (__pa(end) < end_in_pa) {
+ /* it is desirable to free up unused area...
+ but we have to cope with freeing __init, ... */
+ /* init_xenheap_pages(__pa(xen_heap_start), __pa(start));*/
+ xen_heap_start = (void*)end;
+ percpu_area = (void*)virt_to_xenva(start);
+ printk("allocate percpu area 0x%lx@0x%lx 0x%p\n",
+ size, start, percpu_area);
+ } else {
+ panic("can't allocate percpu area. size 0x%lx\n", size);
+ }
+ return xen_heap_start;
+}
+
+static void* __init
+get_per_cpu_area(void)
+{
+ return percpu_area;
+}
+#endif
+
/**
* per_cpu_init - setup per-cpu variables
*
@@ -193,13 +228,7 @@
*/
if (smp_processor_id() == 0) {
#ifdef XEN
- struct page_info *page;
- page = alloc_domheap_pages(NULL,
- get_order(NR_CPUS *
- PERCPU_PAGE_SIZE), 0);
- if (page == NULL)
- panic("can't allocate per cpu area.\n");
- cpu_data = page_to_virt(page);
+ cpu_data = get_per_cpu_area();
#else
cpu_data = __alloc_bootmem(PERCPU_PAGE_SIZE * NR_CPUS,
PERCPU_PAGE_SIZE,
__pa(MAX_DMA_ADDRESS));
diff -r 9feafce8afc5 xen/arch/ia64/xen/xensetup.c
--- a/xen/arch/ia64/xen/xensetup.c Wed Aug 06 11:55:56 2008 +0900
+++ b/xen/arch/ia64/xen/xensetup.c Wed Aug 06 16:08:06 2008 +0900
@@ -566,6 +566,13 @@
if (vmx_enabled)
xen_heap_start = vmx_init_env(xen_heap_start, xenheap_phys_end);
+ /* allocate memory for percpu area
+ * per_cpu_init() called from late_set_arch() is called after
+ * end_boot_allocate(). It's too late to allocate memory in
+ * xenva.
+ */
+ xen_heap_start = per_cpu_allocate(xen_heap_start, xenheap_phys_end);
+
heap_desc.xen_heap_start = xen_heap_start;
heap_desc.xenheap_phys_end = xenheap_phys_end;
heap_desc.kern_md = kern_md;
diff -r 9feafce8afc5 xen/include/asm-ia64/linux-xen/asm/percpu.h
--- a/xen/include/asm-ia64/linux-xen/asm/percpu.h Wed Aug 06 11:55:56
2008 +0900
+++ b/xen/include/asm-ia64/linux-xen/asm/percpu.h Wed Aug 06 16:08:06
2008 +0900
@@ -50,12 +50,22 @@
extern void percpu_modcopy(void *pcpudst, const void *src, unsigned long size);
extern void setup_per_cpu_areas (void);
extern void *per_cpu_init(void);
+#ifdef XEN
+extern void *per_cpu_allocate(void *xen_heap_start, unsigned long end_in_pa);
+#endif
#else /* ! SMP */
#define per_cpu(var, cpu) (*((void)(cpu),
&per_cpu__##var))
#define __get_cpu_var(var) per_cpu__##var
#define per_cpu_init() (__phys_per_cpu_start)
+#ifdef XEN
+static inline void *per_cpu_allocate(void *xen_heap_start,
+ unsigned long end_in_pa)
+{
+ return xen_heap_start;
+}
+#endif
#endif /* SMP */
On Wed, Aug 06, 2008 at 11:19:18AM +0900, Isaku Yamahata wrote:
> Hi. FYI.
> I've been working on this panic, however it seems a difficult bug.
> I resorted hg bisect which told me the following change set.
>
> changeset: 18084:0b72d16e794b
> summary: [IA64] kexec: Unpin the correct VHPT TR in ia64_do_tlb_purge
>
>
> I had expected that the EFI mapping patch caused the panic,
> but now I'm beginning to suspect that the panic is a long hidden
> bug and the patch just shook out it. (Please NOTE I'm not sure...)
> I haven't reproduce the panic with c/s 18083 though...
>
>
> On Fri, Jul 25, 2008 at 04:37:25PM +0900, KUWAMURA Shin'ya wrote:
> > Hi,
> >
> > On cset:18134, creating DomVTi with PV-on-HVM drivers causes the
> > hypervisor panic on both hp rx2620 and Tiger4.
> > I attached the panic message on hp rx2620.
> >
> > (XEN) ia64_fault, vector=0x18, ifa=0xf0000040fb8a0010,
> > iip=0xf4000000040638e0,
> > ipsr=0x0000101008226038, isr=0x0000008000000030
> > (XEN) General Exception: IA-64 Reserved Register/Field fault (data access).
> > (XEN) d 0xf000000004118080 domid 6
> > (XEN) vcpu 0xf0000002bd318000 vcpu 1
> > (XEN)
> > (XEN) CPU 0
> > (XEN) psr : 0000101008226038 ifs : 8000000000000710 ip :
> > [<f4000000040638e0>]
> > (XEN) ip is at flush_vtlb_for_context_switch+0x20/0x370
> >
> > Instructions:
> > f4000000040638e0: 08 00 01 40 18 10 [MMI] ld8 r32=[r32]
> > f4000000040638e6: 20 01 38 20 20 00 ld4 r18=[r14]
> > f4000000040638ec: f2 07 fc 93 mov r16=32767
> >
> > TEST ENVIRONMENT #1
> > Machine : Tiger4
> > Changeset : 18134:1970781956c7 (ia64/xen-unstable)
> > 609:8a3dc4fdb478 (ia64/linux-2.6.18-xen)
> > 126:d255b2cfdd5a (efi-vfirmware)
> > Dom0 OS : RHEL4 U2 (2P)
> > DomVTi OS : RHEL4 U2 (8P, with PV-on-HVM drivers)
> > CONFIG_QEMU : ioemu
> >
> > TEST ENVIRONMENT #2
> > Machine : hp rx2620
> > Changeset : 18134:1970781956c7 (ia64/xen-unstable)
> > 609:8a3dc4fdb478 (ia64/linux-2.6.18-xen)
> > 126:d255b2cfdd5a (efi-vfirmware)
> > Dom0 OS : RHEL5.2 (2P)
> > DomVTi OS : RHEL5.2 (2P, with PV-on-HVM drivers)
> > CONFIG_QEMU : ioemu
> >
> > Best regards,
>
> > (XEN) ia64_fault, vector=0x18, ifa=0xf0000040fb8a0010,
> > iip=0xf4000000040638e0, ipsr=0x0000101008226038, isr=0x0000008000000030
> > (XEN) General Exception: IA-64 Reserved Register/Field fault (data access).
> > (XEN) d 0xf000000004118080 domid 6
> > (XEN) vcpu 0xf0000002bd318000 vcpu 1
> > (XEN)
> > (XEN) CPU 0
> > (XEN) psr : 0000101008226038 ifs : 8000000000000710 ip :
> > [<f4000000040638e0>]
> > (XEN) ip is at flush_vtlb_for_context_switch+0x20/0x370
> > (XEN) unat: 0000000000000000 pfs : 0000000000000006 rsc : 0000000000000003
> > (XEN) rnat: 0000000000000000 bsps: 0000000000000000 pr : 0000000000008153
> > (XEN) ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
> > (XEN) csd : 0000000000000000 ssd : 0000000000000000
> > (XEN) b0 : f4000000040a9570 b6 : a0000002005461e0 b7 : 0000000000000000
> > (XEN) f6 : 000000000000000000000 f7 : 000000000000000000000
> > (XEN) f8 : 000000000000000000000 f9 : 000000000000000000000
> > (XEN) f10 : 000000000000000000000 f11 : 000000000000000000000
> > (XEN) r1 : a0000002005607a8 r2 : 0000000000000020 r3 : 0000000000000000
> > (XEN) r8 : 0000000000000000 r9 : 000000007e817c90 r10 : 0000000000000000
> > (XEN) r11 : 2000000000000000 r12 : e00000007e817c40 r13 : e00000007e810000
> > (XEN) r14 : 0000000000000000 r15 : f0000002bd319081 r16 : 0000000000000000
> > (XEN) r17 : 0000000000000000 r18 : 0000000000000000 r19 : 0000000000000000
> > (XEN) r20 : 0000000000000000 r21 : 0000000000000000 r22 : 0000000000000000
> > (XEN) r23 : 0000000000000000 r24 : 0000000000000000 r25 : 0000000000000000
> > (XEN) r26 : 0000000000000000 r27 : 0000000000000000 r28 : 0000000000000000
> > (XEN) r29 : 0000000000000000 r30 : 0000000000000000 r31 : 0000000000000000
> > (XEN)
> > (XEN) Call Trace:
> > (XEN) [<f4000000040cf2e0>] show_stack+0x80/0xa0
> > (XEN) sp=f0000002bd319680
> > bsp=f0000002bd319660
> > (XEN) [<f40000000408d790>] ia64_fault+0x790/0xad0
> > (XEN) sp=f0000002bd319850
> > bsp=f0000002bd319628
> > (XEN) [<f4000000040c7480>] ia64_leave_kernel+0x0/0x300
> > (XEN) sp=f0000002bd319850
> > bsp=f0000002bd319628
> > (XEN)
> > (XEN) ****************************************
> > (XEN) Panic on CPU 0:
> > (XEN) Fault in Xen.
> > (XEN) ****************************************
> > (XEN)
> > (XEN) Reboot in five seconds...
>
> > _______________________________________________
> > Xen-ia64-devel mailing list
> > Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-ia64-devel
>
--
yamahata
percpu-in-xenva.patch
Description: Text Data
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home