Jeremy Fitzhardinge
2008-Jun-25 04:18 UTC
[Xen-devel] [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Hi Ingo,
This series lays the groundwork for 64-bit Xen support. It follows
the usual pattern: a series of general cleanups and improvements,
followed by additions and modifications needed to slide Xen in.
Most of the 64-bit paravirt-ops work has already been done and
integrated for some time, so the changes are relatively minor.
Interesting and potentially hazardous changes in this series are:
"paravirt/x86_64: move __PAGE_OFFSET to leave a space for hypervisor"
This moves __PAGE_OFFSET up by 16 GDT slots, from 0xffff810000000000
to 0xffff880000000000. I have no general justification for this: the
specific reason is that Xen claims the first 16 kernel GDT slots for
itself, and we must move up the mapping to make room. In the process
I parameterised the compile-time construction of the initial
pagetables in head_64.S to cope with it.
"x86_64: adjust mapping of physical pagetables to work with Xen"
"x86_64: create small vmemmap mappings if PSE not available"
This rearranges the construction of the physical mapping so that it
works with Xen. This affects three aspects of the code:
1. It can''t use pse, so it will only use pse if the processor
supports it.
2. It never replaces an existing mapping, so it can just extend the
early boot-provided mappings (either from head_64.S or the Xen domain
builder).
3. It makes sure that any page is iounmapped before attaching it to the
pagetable to avoid having writable aliases of pagetable pages.
The logical structure of the code is more or less unchanged, and still
works fine in the native case.
vmemmap mapping is likewise changed.
"x86_64: PSE no longer a hard requirement."
Because booting under Xen doesn''t set PSE, it''s no longer a
hard
requirement for the kernel. PSE will be used whereever possible.
Overall diffstat:
arch/x86/Kconfig | 7 +
arch/x86/ia32/ia32entry.S | 37 +++--
arch/x86/kernel/aperture_64.c | 4
arch/x86/kernel/asm-offsets_32.c | 2
arch/x86/kernel/asm-offsets_64.c | 5
arch/x86/kernel/cpu/common_64.c | 3
arch/x86/kernel/e820.c | 2
arch/x86/kernel/early-quirks.c | 2
arch/x86/kernel/entry_32.S | 8 -
arch/x86/kernel/entry_64.S | 14 +-
arch/x86/kernel/head64.c | 5
arch/x86/kernel/head_64.S | 17 +-
arch/x86/kernel/machine_kexec_64.c | 2
arch/x86/kernel/paravirt.c | 24 +++
arch/x86/kernel/paravirt_patch_32.c | 4
arch/x86/kernel/paravirt_patch_64.c | 9 -
arch/x86/kernel/pci-calgary_64.c | 4
arch/x86/kernel/pci-dma.c | 4
arch/x86/kernel/pci-gart_64.c | 4
arch/x86/kernel/pci-swiotlb_64.c | 2
arch/x86/kernel/process_64.c | 50 +++++--
arch/x86/kernel/setup_64.c | 24 +--
arch/x86/kernel/vmi_32.c | 4
arch/x86/kernel/vsyscall_64.c | 12 -
arch/x86/mm/fault.c | 73 +++--------
arch/x86/mm/init_64.c | 234 +++++++++++++++++++++---------------
arch/x86/mm/ioremap.c | 7 -
arch/x86/mm/k8topology_64.c | 4
arch/x86/mm/numa_64.c | 4
arch/x86/mm/pgtable.c | 176 ++++++++++++++++-----------
arch/x86/mm/srat_64.c | 2
arch/x86/power/hibernate_64.c | 2
arch/x86/xen/enlighten.c | 9 +
include/asm-x86/cmpxchg_64.h | 37 +++++
include/asm-x86/desc_defs.h | 4
include/asm-x86/elf.h | 2
include/asm-x86/fixmap_64.h | 16 ++
include/asm-x86/io.h | 13 ++
include/asm-x86/io_32.h | 12 -
include/asm-x86/irqflags.h | 19 ++
include/asm-x86/mmu_context.h | 32 ++++
include/asm-x86/mmu_context_32.h | 28 ----
include/asm-x86/mmu_context_64.h | 18 --
include/asm-x86/msr.h | 5
include/asm-x86/page_64.h | 11 +
include/asm-x86/paravirt.h | 141 ++++++++++++++++++---
include/asm-x86/pgalloc.h | 4
include/asm-x86/pgtable.h | 20 +++
include/asm-x86/pgtable_32.h | 20 ---
include/asm-x86/pgtable_64.h | 8 -
include/asm-x86/processor.h | 2
include/asm-x86/required-features.h | 2
include/asm-x86/setup.h | 4
include/asm-x86/system.h | 7 -
54 files changed, 734 insertions(+), 431 deletions(-)
Thanks,
J
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:18 UTC
[Xen-devel] [PATCH 01 of 36] x86: asm-x86/pgtable.h: fix compiler warning
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/pgtable.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h --- a/include/asm-x86/pgtable.h +++ b/include/asm-x86/pgtable.h @@ -425,6 +425,8 @@ * race with other CPU''s that might be updating the dirty * bit at the same time. */ +struct vm_area_struct; + #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS extern int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address, pte_t *ptep, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:18 UTC
[Xen-devel] [PATCH 02 of 36] x86: add memory clobber to save/loadsegment
Add "memory" clobbers to savesegment and loadsegment, since they can
affect memory accesses and we never want the compiler to reorder them
with respect to memory references.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/system.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-x86/system.h b/include/asm-x86/system.h
--- a/include/asm-x86/system.h
+++ b/include/asm-x86/system.h
@@ -157,14 +157,14 @@
"jmp 2b\n" \
".previous\n" \
_ASM_EXTABLE(1b,3b) \
- : :"r" (value), "r" (0))
+ : :"r" (value), "r" (0) : "memory")
/*
* Save a segment register away
*/
#define savesegment(seg, value) \
- asm volatile("mov %%" #seg ",%0":"=rm" (value))
+ asm("mov %%" #seg ",%0":"=rm" (value) : :
"memory")
static inline unsigned long get_limit(unsigned long segment)
{
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:18 UTC
[Xen-devel] [PATCH 03 of 36] x86: add memory barriers to wrmsr
wrmsr is a special instruction which can have arbitrary system-wide
effects. We don''t want the compiler to reorder it with respect to
memory operations, so make it a memory barrier.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/msr.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/asm-x86/msr.h b/include/asm-x86/msr.h
--- a/include/asm-x86/msr.h
+++ b/include/asm-x86/msr.h
@@ -66,7 +66,7 @@
static inline void native_write_msr(unsigned int msr,
unsigned low, unsigned high)
{
- asm volatile("wrmsr" : : "c" (msr), "a"(low),
"d" (high));
+ asm volatile("wrmsr" : : "c" (msr), "a"(low),
"d" (high) : "memory");
}
static inline int native_write_msr_safe(unsigned int msr,
@@ -81,7 +81,8 @@
_ASM_EXTABLE(2b, 3b)
: "=a" (err)
: "c" (msr), "0" (low), "d" (high),
- "i" (-EFAULT));
+ "i" (-EFAULT)
+ : "memory");
return err;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 04 of 36] x86: remove open-coded save/load segment operations
This removes a pile of buggy open-coded implementations of savesegment
and loadsegment.
(They are buggy because they don''t have memory barriers to prevent
them from being reordered with respect to memory accesses.)
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/cpu/common_64.c | 3 ++-
arch/x86/kernel/process_64.c | 28 +++++++++++++++-------------
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/cpu/common_64.c b/arch/x86/kernel/cpu/common_64.c
--- a/arch/x86/kernel/cpu/common_64.c
+++ b/arch/x86/kernel/cpu/common_64.c
@@ -480,7 +480,8 @@
struct x8664_pda *pda = cpu_pda(cpu);
/* Setup up data that may be needed in __get_free_pages early */
- asm volatile("movl %0,%%fs ; movl %0,%%gs" :: "r" (0));
+ loadsegment(fs, 0);
+ loadsegment(gs, 0);
/* Memory clobbers used to order PDA accessed */
mb();
wrmsrl(MSR_GS_BASE, pda);
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -362,10 +362,10 @@
p->thread.fs = me->thread.fs;
p->thread.gs = me->thread.gs;
- asm("mov %%gs,%0" : "=m" (p->thread.gsindex));
- asm("mov %%fs,%0" : "=m" (p->thread.fsindex));
- asm("mov %%es,%0" : "=m" (p->thread.es));
- asm("mov %%ds,%0" : "=m" (p->thread.ds));
+ savesegment(gs, p->thread.gsindex);
+ savesegment(fs, p->thread.fsindex);
+ savesegment(es, p->thread.es);
+ savesegment(ds, p->thread.ds);
if (unlikely(test_tsk_thread_flag(me, TIF_IO_BITMAP))) {
p->thread.io_bitmap_ptr = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
@@ -404,7 +404,9 @@
void
start_thread(struct pt_regs *regs, unsigned long new_ip, unsigned long new_sp)
{
- asm volatile("movl %0, %%fs; movl %0, %%es; movl %0, %%ds" ::
"r"(0));
+ loadsegment(fs, 0);
+ loadsegment(es, 0);
+ loadsegment(ds, 0);
load_gs_index(0);
regs->ip = new_ip;
regs->sp = new_sp;
@@ -591,11 +593,11 @@
* Switch DS and ES.
* This won''t pick up thread selector changes, but I guess that is
ok.
*/
- asm volatile("mov %%es,%0" : "=m" (prev->es));
+ savesegment(es, prev->es);
if (unlikely(next->es | prev->es))
loadsegment(es, next->es);
-
- asm volatile ("mov %%ds,%0" : "=m" (prev->ds));
+
+ savesegment(ds, prev->ds);
if (unlikely(next->ds | prev->ds))
loadsegment(ds, next->ds);
@@ -606,7 +608,7 @@
*/
{
unsigned fsindex;
- asm volatile("movl %%fs,%0" : "=r" (fsindex));
+ savesegment(fs, fsindex);
/* segment register != 0 always requires a reload.
also reload when it has changed.
when prev process used 64bit base always reload
@@ -627,7 +629,7 @@
}
{
unsigned gsindex;
- asm volatile("movl %%gs,%0" : "=r" (gsindex));
+ savesegment(gs, gsindex);
if (unlikely(gsindex | next->gsindex | prev->gs)) {
load_gs_index(next->gsindex);
if (gsindex)
@@ -807,7 +809,7 @@
set_32bit_tls(task, FS_TLS, addr);
if (doit) {
load_TLS(&task->thread, cpu);
- asm volatile("movl %0,%%fs" :: "r"(FS_TLS_SEL));
+ loadsegment(fs, FS_TLS_SEL);
}
task->thread.fsindex = FS_TLS_SEL;
task->thread.fs = 0;
@@ -817,7 +819,7 @@
if (doit) {
/* set the selector to 0 to not confuse
__switch_to */
- asm volatile("movl %0,%%fs" :: "r" (0));
+ loadsegment(fs, 0);
ret = checking_wrmsrl(MSR_FS_BASE, addr);
}
}
@@ -840,7 +842,7 @@
if (task->thread.gsindex == GS_TLS_SEL)
base = read_32bit_tls(task, GS_TLS);
else if (doit) {
- asm("movl %%gs,%0" : "=r" (gsindex));
+ savesegment(gs, gsindex);
if (gsindex)
rdmsrl(MSR_KERNEL_GS_BASE, base);
else
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 05 of 36] x86_64: use write_gdt_entry in vsyscall_set_cpu
Use write_gdt_entry to generate the special vgetcpu descriptor in the
vsyscall page.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/vsyscall_64.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -250,7 +250,7 @@
doesn''t violate that. We''ll find out if it does. */
static void __cpuinit vsyscall_set_cpu(int cpu)
{
- unsigned long *d;
+ unsigned long d;
unsigned long node = 0;
#ifdef CONFIG_NUMA
node = cpu_to_node(cpu);
@@ -261,11 +261,11 @@
/* Store cpu number in limit so that it can be loaded quickly
in user space in vgetcpu.
12 bits for the CPU and 8 bits for the node. */
- d = (unsigned long *)(get_cpu_gdt_table(cpu) + GDT_ENTRY_PER_CPU);
- *d = 0x0f40000000000ULL;
- *d |= cpu;
- *d |= (node & 0xf) << 12;
- *d |= (node >> 4) << 48;
+ d = 0x0f40000000000ULL;
+ d |= cpu;
+ d |= (node & 0xf) << 12;
+ d |= (node >> 4) << 48;
+ write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_PER_CPU, &d,
DESCTYPE_S);
}
static void __cpuinit cpu_vsyscall_init(void *arg)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 06 of 36] x86_64: use p??_populate() to attach pages to pagetable
Use the _populate() functions to attach new pages to a pagetable, to
make sure the right paravirt_ops calls get called.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/mm/init_64.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -167,7 +167,7 @@
pud = pud_offset(pgd, vaddr);
if (pud_none(*pud)) {
pmd = (pmd_t *) spp_getpage();
- set_pud(pud, __pud(__pa(pmd) | _KERNPG_TABLE | _PAGE_USER));
+ pud_populate(&init_mm, pud, pmd);
if (pmd != pmd_offset(pud, 0)) {
printk(KERN_ERR "PAGETABLE BUG #01! %p <-> %p\n",
pmd, pmd_offset(pud, 0));
@@ -177,7 +177,7 @@
pmd = pmd_offset(pud, vaddr);
if (pmd_none(*pmd)) {
pte = (pte_t *) spp_getpage();
- set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE | _PAGE_USER));
+ pmd_populate_kernel(&init_mm, pmd, pte);
if (pte != pte_offset_kernel(pmd, 0)) {
printk(KERN_ERR "PAGETABLE BUG #02!\n");
return;
@@ -389,7 +389,7 @@
pmd = alloc_low_page(&pmd_phys);
spin_lock(&init_mm.page_table_lock);
- set_pud(pud, __pud(pmd_phys | _KERNPG_TABLE));
+ pud_populate(&init_mm, pud, __va(pmd_phys));
last_map_addr = phys_pmd_init(pmd, addr, end);
spin_unlock(&init_mm.page_table_lock);
@@ -591,7 +591,8 @@
next = end;
last_map_addr = phys_pud_init(pud, __pa(start), __pa(next));
if (!after_bootmem)
- set_pgd(pgd_offset_k(start), mk_kernel_pgd(pud_phys));
+ pgd_populate(&init_mm, pgd_offset_k(start),
+ __va(pud_phys));
unmap_low_page(pud);
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 07 of 36] x86_64: unify early_ioremap
The 32-bit early_ioremap will work equally well for 64-bit, so just use it.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/setup_64.c | 2 +
arch/x86/mm/init_64.c | 52 -------------------------------------------
arch/x86/mm/ioremap.c | 5 +++-
include/asm-x86/fixmap_64.h | 13 ++++++++++
include/asm-x86/io.h | 13 ++++++++++
include/asm-x86/io_32.h | 12 ---------
6 files changed, 32 insertions(+), 65 deletions(-)
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -191,6 +191,8 @@
{
printk(KERN_INFO "Command line: %s\n", boot_command_line);
+ early_ioremap_init();
+
ROOT_DEV = old_decode_dev(boot_params.hdr.root_dev);
screen_info = boot_params.screen_info;
edid_info = boot_params.edid_info;
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -255,58 +255,6 @@
return;
early_iounmap(adr, PAGE_SIZE);
-}
-
-/* Must run before zap_low_mappings */
-__meminit void *early_ioremap(unsigned long addr, unsigned long size)
-{
- pmd_t *pmd, *last_pmd;
- unsigned long vaddr;
- int i, pmds;
-
- pmds = ((addr & ~PMD_MASK) + size + ~PMD_MASK) / PMD_SIZE;
- vaddr = __START_KERNEL_map;
- pmd = level2_kernel_pgt;
- last_pmd = level2_kernel_pgt + PTRS_PER_PMD - 1;
-
- for (; pmd <= last_pmd; pmd++, vaddr += PMD_SIZE) {
- for (i = 0; i < pmds; i++) {
- if (pmd_present(pmd[i]))
- goto continue_outer_loop;
- }
- vaddr += addr & ~PMD_MASK;
- addr &= PMD_MASK;
-
- for (i = 0; i < pmds; i++, addr += PMD_SIZE)
- set_pmd(pmd+i, __pmd(addr | __PAGE_KERNEL_LARGE_EXEC));
- __flush_tlb_all();
-
- return (void *)vaddr;
-continue_outer_loop:
- ;
- }
- printk(KERN_ERR "early_ioremap(0x%lx, %lu) failed\n", addr, size);
-
- return NULL;
-}
-
-/*
- * To avoid virtual aliases later:
- */
-__meminit void early_iounmap(void *addr, unsigned long size)
-{
- unsigned long vaddr;
- pmd_t *pmd;
- int i, pmds;
-
- vaddr = (unsigned long)addr;
- pmds = ((vaddr & ~PMD_MASK) + size + ~PMD_MASK) / PMD_SIZE;
- pmd = level2_kernel_pgt + pmd_index(vaddr);
-
- for (i = 0; i < pmds; i++)
- pmd_clear(pmd + i);
-
- __flush_tlb_all();
}
static unsigned long __meminit
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -409,8 +409,6 @@
return;
}
-#ifdef CONFIG_X86_32
-
int __initdata early_ioremap_debug;
static int __init early_ioremap_debug_setup(char *str)
@@ -511,6 +509,7 @@
return;
}
pte = early_ioremap_pte(addr);
+
if (pgprot_val(flags))
set_pte(pte, pfn_pte(phys >> PAGE_SHIFT, flags));
else
@@ -652,5 +651,3 @@
{
WARN_ON(1);
}
-
-#endif /* CONFIG_X86_32 */
diff --git a/include/asm-x86/fixmap_64.h b/include/asm-x86/fixmap_64.h
--- a/include/asm-x86/fixmap_64.h
+++ b/include/asm-x86/fixmap_64.h
@@ -49,6 +49,19 @@
#ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
FIX_OHCI1394_BASE,
#endif
+ __end_of_permanent_fixed_addresses,
+ /*
+ * 256 temporary boot-time mappings, used by early_ioremap(),
+ * before ioremap() is functional.
+ *
+ * We round it up to the next 512 pages boundary so that we
+ * can have a single pgd entry and a single pte table:
+ */
+#define NR_FIX_BTMAPS 64
+#define FIX_BTMAPS_NESTING 4
+ FIX_BTMAP_END = __end_of_permanent_fixed_addresses + 512 -
+ (__end_of_permanent_fixed_addresses & 511),
+ FIX_BTMAP_BEGIN = FIX_BTMAP_END + NR_FIX_BTMAPS*FIX_BTMAPS_NESTING - 1,
__end_of_fixed_addresses
};
diff --git a/include/asm-x86/io.h b/include/asm-x86/io.h
--- a/include/asm-x86/io.h
+++ b/include/asm-x86/io.h
@@ -72,4 +72,17 @@
unsigned long prot_val);
extern void __iomem *ioremap_wc(unsigned long offset, unsigned long size);
+/*
+ * early_ioremap() and early_iounmap() are for temporary early boot-time
+ * mappings, before the real ioremap() is functional.
+ * A boot-time mapping is currently limited to at most 16 pages.
+ */
+extern void early_ioremap_init(void);
+extern void early_ioremap_clear(void);
+extern void early_ioremap_reset(void);
+extern void *early_ioremap(unsigned long offset, unsigned long size);
+extern void early_iounmap(void *addr, unsigned long size);
+extern void __iomem *fix_ioremap(unsigned idx, unsigned long phys);
+
+
#endif /* _ASM_X86_IO_H */
diff --git a/include/asm-x86/io_32.h b/include/asm-x86/io_32.h
--- a/include/asm-x86/io_32.h
+++ b/include/asm-x86/io_32.h
@@ -122,18 +122,6 @@
extern void iounmap(volatile void __iomem *addr);
/*
- * early_ioremap() and early_iounmap() are for temporary early boot-time
- * mappings, before the real ioremap() is functional.
- * A boot-time mapping is currently limited to at most 16 pages.
- */
-extern void early_ioremap_init(void);
-extern void early_ioremap_clear(void);
-extern void early_ioremap_reset(void);
-extern void *early_ioremap(unsigned long offset, unsigned long size);
-extern void early_iounmap(void *addr, unsigned long size);
-extern void __iomem *fix_ioremap(unsigned idx, unsigned long phys);
-
-/*
* ISA I/O bus memory addresses are 1:1 with the physical address.
*/
#define isa_virt_to_bus virt_to_phys
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 08 of 36] x86_64: Add gate_offset() and gate_segment() macros
For calculating the offset from struct gate_struct fields.
[ gate_offset and gate_segment were broken for 32-bit. ]
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/desc_defs.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/asm-x86/desc_defs.h b/include/asm-x86/desc_defs.h
--- a/include/asm-x86/desc_defs.h
+++ b/include/asm-x86/desc_defs.h
@@ -75,10 +75,14 @@
typedef struct gate_struct64 gate_desc;
typedef struct ldttss_desc64 ldt_desc;
typedef struct ldttss_desc64 tss_desc;
+#define gate_offset(g) ((g).offset_low | ((unsigned long)(g).offset_middle
<< 16) | ((unsigned long)(g).offset_high << 32))
+#define gate_segment(g) ((g).segment)
#else
typedef struct desc_struct gate_desc;
typedef struct desc_struct ldt_desc;
typedef struct desc_struct tss_desc;
+#define gate_offset(g) (((g).b & 0xffff0000) | ((g).a & 0x0000ffff))
+#define gate_segment(g) ((g).a >> 16)
#endif
struct desc_ptr {
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 09 of 36] x86_64: Use __pgd() on mk_kernel_pgd()
From: Eduardo Habkost <ehabkost@redhat.com>
Use __pgd() on mk_kernel_pgd()
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
include/asm-x86/pgtable_64.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/asm-x86/pgtable_64.h b/include/asm-x86/pgtable_64.h
--- a/include/asm-x86/pgtable_64.h
+++ b/include/asm-x86/pgtable_64.h
@@ -201,7 +201,7 @@
#define pgd_offset_k(address) (init_level4_pgt + pgd_index((address)))
#define pgd_present(pgd) (pgd_val(pgd) & _PAGE_PRESENT)
static inline int pgd_large(pgd_t pgd) { return 0; }
-#define mk_kernel_pgd(address) ((pgd_t){ (address) | _KERNPG_TABLE })
+#define mk_kernel_pgd(address) __pgd((address) | _KERNPG_TABLE)
/* PUD - Level3 access */
/* to find an entry in a page-table-directory. */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 10 of 36] x86: unify pgd_index
pgd_index is common for 32 and 64-bit, so move it to a common place.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/pgtable.h | 20 ++++++++++++++++++++
include/asm-x86/pgtable_32.h | 20 --------------------
include/asm-x86/pgtable_64.h | 3 ---
3 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h
--- a/include/asm-x86/pgtable.h
+++ b/include/asm-x86/pgtable.h
@@ -357,6 +357,26 @@
# include "pgtable_64.h"
#endif
+/*
+ * the pgd page can be thought of an array like this: pgd_t[PTRS_PER_PGD]
+ *
+ * this macro returns the index of the entry in the pgd page which would
+ * control the given virtual address
+ */
+#define pgd_index(address) (((address) >> PGDIR_SHIFT) &
(PTRS_PER_PGD - 1))
+
+/*
+ * pgd_offset() returns a (pgd_t *)
+ * pgd_index() is used get the offset into the pgd page''s array of
pgd_t''s;
+ */
+#define pgd_offset(mm, address) ((mm)->pgd + pgd_index((address)))
+/*
+ * a shortcut which implies the use of the kernel''s pgd, instead
+ * of a process''s
+ */
+#define pgd_offset_k(address) pgd_offset(&init_mm, (address))
+
+
#define KERNEL_PGD_BOUNDARY pgd_index(PAGE_OFFSET)
#define KERNEL_PGD_PTRS (PTRS_PER_PGD - KERNEL_PGD_BOUNDARY)
diff --git a/include/asm-x86/pgtable_32.h b/include/asm-x86/pgtable_32.h
--- a/include/asm-x86/pgtable_32.h
+++ b/include/asm-x86/pgtable_32.h
@@ -119,26 +119,6 @@
*/
#define mk_pte(page, pgprot) pfn_pte(page_to_pfn(page), (pgprot))
-/*
- * the pgd page can be thought of an array like this: pgd_t[PTRS_PER_PGD]
- *
- * this macro returns the index of the entry in the pgd page which would
- * control the given virtual address
- */
-#define pgd_index(address) (((address) >> PGDIR_SHIFT) &
(PTRS_PER_PGD - 1))
-#define pgd_index_k(addr) pgd_index((addr))
-
-/*
- * pgd_offset() returns a (pgd_t *)
- * pgd_index() is used get the offset into the pgd page''s array of
pgd_t''s;
- */
-#define pgd_offset(mm, address) ((mm)->pgd + pgd_index((address)))
-
-/*
- * a shortcut which implies the use of the kernel''s pgd, instead
- * of a process''s
- */
-#define pgd_offset_k(address) pgd_offset(&init_mm, (address))
static inline int pud_large(pud_t pud) { return 0; }
diff --git a/include/asm-x86/pgtable_64.h b/include/asm-x86/pgtable_64.h
--- a/include/asm-x86/pgtable_64.h
+++ b/include/asm-x86/pgtable_64.h
@@ -196,9 +196,6 @@
#define pgd_page_vaddr(pgd) \
((unsigned long)__va((unsigned long)pgd_val((pgd)) & PTE_MASK))
#define pgd_page(pgd) (pfn_to_page(pgd_val((pgd)) >> PAGE_SHIFT))
-#define pgd_index(address) (((address) >> PGDIR_SHIFT) &
(PTRS_PER_PGD - 1))
-#define pgd_offset(mm, address) ((mm)->pgd + pgd_index((address)))
-#define pgd_offset_k(address) (init_level4_pgt + pgd_index((address)))
#define pgd_present(pgd) (pgd_val(pgd) & _PAGE_PRESENT)
static inline int pgd_large(pgd_t pgd) { return 0; }
#define mk_kernel_pgd(address) __pgd((address) | _KERNPG_TABLE)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 11 of 36] x86: unify mmu_context.h
Some amount of asm-x86/mmu_context.h can be unified, including
activate_mm paravirt hook.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/mmu_context.h | 32 ++++++++++++++++++++++++++++++++
include/asm-x86/mmu_context_32.h | 28 ----------------------------
include/asm-x86/mmu_context_64.h | 18 ------------------
3 files changed, 32 insertions(+), 46 deletions(-)
diff --git a/include/asm-x86/mmu_context.h b/include/asm-x86/mmu_context.h
--- a/include/asm-x86/mmu_context.h
+++ b/include/asm-x86/mmu_context.h
@@ -1,5 +1,37 @@
+#ifndef __ASM_X86_MMU_CONTEXT_H
+#define __ASM_X86_MMU_CONTEXT_H
+
+#include <asm/desc.h>
+#include <asm/atomic.h>
+#include <asm/pgalloc.h>
+#include <asm/tlbflush.h>
+#include <asm/paravirt.h>
+#ifndef CONFIG_PARAVIRT
+#include <asm-generic/mm_hooks.h>
+
+static inline void paravirt_activate_mm(struct mm_struct *prev,
+ struct mm_struct *next)
+{
+}
+#endif /* !CONFIG_PARAVIRT */
+
+/*
+ * Used for LDT copy/destruction.
+ */
+int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
+void destroy_context(struct mm_struct *mm);
+
#ifdef CONFIG_X86_32
# include "mmu_context_32.h"
#else
# include "mmu_context_64.h"
#endif
+
+#define activate_mm(prev, next) \
+do { \
+ paravirt_activate_mm((prev), (next)); \
+ switch_mm((prev), (next), NULL); \
+} while (0);
+
+
+#endif /* __ASM_X86_MMU_CONTEXT_H */
diff --git a/include/asm-x86/mmu_context_32.h b/include/asm-x86/mmu_context_32.h
--- a/include/asm-x86/mmu_context_32.h
+++ b/include/asm-x86/mmu_context_32.h
@@ -1,27 +1,5 @@
#ifndef __I386_SCHED_H
#define __I386_SCHED_H
-
-#include <asm/desc.h>
-#include <asm/atomic.h>
-#include <asm/pgalloc.h>
-#include <asm/tlbflush.h>
-#include <asm/paravirt.h>
-#ifndef CONFIG_PARAVIRT
-#include <asm-generic/mm_hooks.h>
-
-static inline void paravirt_activate_mm(struct mm_struct *prev,
- struct mm_struct *next)
-{
-}
-#endif /* !CONFIG_PARAVIRT */
-
-
-/*
- * Used for LDT copy/destruction.
- */
-int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
-void destroy_context(struct mm_struct *mm);
-
static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct
*tsk)
{
@@ -75,10 +53,4 @@
#define deactivate_mm(tsk, mm) \
asm("movl %0,%%gs": :"r" (0));
-#define activate_mm(prev, next) \
-do { \
- paravirt_activate_mm((prev), (next)); \
- switch_mm((prev), (next), NULL); \
-} while (0);
-
#endif
diff --git a/include/asm-x86/mmu_context_64.h b/include/asm-x86/mmu_context_64.h
--- a/include/asm-x86/mmu_context_64.h
+++ b/include/asm-x86/mmu_context_64.h
@@ -1,21 +1,7 @@
#ifndef __X86_64_MMU_CONTEXT_H
#define __X86_64_MMU_CONTEXT_H
-#include <asm/desc.h>
-#include <asm/atomic.h>
-#include <asm/pgalloc.h>
#include <asm/pda.h>
-#include <asm/pgtable.h>
-#include <asm/tlbflush.h>
-#ifndef CONFIG_PARAVIRT
-#include <asm-generic/mm_hooks.h>
-#endif
-
-/*
- * possibly do the LDT unload here?
- */
-int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
-void destroy_context(struct mm_struct *mm);
static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct
*tsk)
{
@@ -65,8 +51,4 @@
asm volatile("movl %0,%%fs"::"r"(0)); \
} while (0)
-#define activate_mm(prev, next) \
- switch_mm((prev), (next), NULL)
-
-
#endif
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 12 of 36] x86_64: replace end_pfn with num_physpages
Reasons for replacement:
- they''re semantically identical
- end_pfn is a bad name for a global identifier
- small step towards unification
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Vivek Goyal <vgoyal@in.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
---
arch/x86/kernel/aperture_64.c | 4 ++--
arch/x86/kernel/e820.c | 2 +-
arch/x86/kernel/early-quirks.c | 2 +-
arch/x86/kernel/machine_kexec_64.c | 2 +-
arch/x86/kernel/pci-calgary_64.c | 4 ++--
arch/x86/kernel/pci-dma.c | 4 ++--
arch/x86/kernel/pci-gart_64.c | 4 ++--
arch/x86/kernel/pci-swiotlb_64.c | 2 +-
arch/x86/kernel/setup_64.c | 22 ++++++++++------------
arch/x86/mm/init_64.c | 14 +++++++-------
arch/x86/mm/k8topology_64.c | 4 ++--
arch/x86/mm/numa_64.c | 4 ++--
arch/x86/mm/srat_64.c | 2 +-
arch/x86/power/hibernate_64.c | 2 +-
include/asm-x86/page_64.h | 3 +--
15 files changed, 36 insertions(+), 39 deletions(-)
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -407,7 +407,7 @@
agp_aper_base == aper_base &&
agp_aper_order == aper_order) {
/* the same between two setting from NB and agp */
- if (!no_iommu && end_pfn > MAX_DMA32_PFN &&
!printed_gart_size_msg) {
+ if (!no_iommu && num_physpages > MAX_DMA32_PFN &&
!printed_gart_size_msg) {
printk(KERN_ERR "you are using iommu with agp, but GART size is less
than 64M\n");
printk(KERN_ERR "please increase GART size in your BIOS
setup\n");
printk(KERN_ERR "if BIOS doesn''t have that option, contact
your HW vendor!\n");
@@ -448,7 +448,7 @@
/* Got the aperture from the AGP bridge */
} else if (swiotlb && !valid_agp) {
/* Do nothing */
- } else if ((!no_iommu && end_pfn > MAX_DMA32_PFN) ||
+ } else if ((!no_iommu && num_physpages > MAX_DMA32_PFN) ||
force_iommu ||
valid_agp ||
fallback_aper_force) {
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -516,7 +516,7 @@
#ifdef CONFIG_X86_64
if (!found) {
- gapstart = (end_pfn << PAGE_SHIFT) + 1024*1024;
+ gapstart = (num_physpages << PAGE_SHIFT) + 1024*1024;
printk(KERN_ERR "PCI: Warning: Cannot find a gap in the 32bit "
"address range\n"
KERN_ERR "PCI: Unassigned devices with 32bit resource "
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -50,7 +50,7 @@
static void __init via_bugs(int num, int slot, int func)
{
#ifdef CONFIG_GART_IOMMU
- if ((end_pfn > MAX_DMA32_PFN || force_iommu) &&
+ if ((num_physpages > MAX_DMA32_PFN || force_iommu) &&
!gart_iommu_aperture_allowed) {
printk(KERN_INFO
"Looks like a VIA chipset. Disabling IOMMU."
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -112,7 +112,7 @@
{
pgd_t *level4p;
level4p = (pgd_t *)__va(start_pgtable);
- return init_level4_page(image, level4p, 0, end_pfn << PAGE_SHIFT);
+ return init_level4_page(image, level4p, 0, num_physpages <<
PAGE_SHIFT);
}
static void set_idt(void *newidt, u16 limit)
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
--- a/arch/x86/kernel/pci-calgary_64.c
+++ b/arch/x86/kernel/pci-calgary_64.c
@@ -1394,7 +1394,7 @@
return;
}
- specified_table_size = determine_tce_table_size(end_pfn * PAGE_SIZE);
+ specified_table_size = determine_tce_table_size(num_physpages * PAGE_SIZE);
for (bus = 0; bus < MAX_PHB_BUS_NUM; bus++) {
struct calgary_bus_info *info = &bus_info[bus];
@@ -1459,7 +1459,7 @@
if (ret) {
printk(KERN_ERR "PCI-DMA: Calgary init failed %d, "
"falling back to no_iommu\n", ret);
- if (end_pfn > MAX_DMA32_PFN)
+ if (num_physpages > MAX_DMA32_PFN)
printk(KERN_ERR "WARNING more than 4GB of memory, "
"32bit PCI may malfunction.\n");
return ret;
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -74,7 +74,7 @@
void __init dma32_reserve_bootmem(void)
{
unsigned long size, align;
- if (end_pfn <= MAX_DMA32_PFN)
+ if (num_physpages <= MAX_DMA32_PFN)
return;
/*
@@ -93,7 +93,7 @@
static void __init dma32_free_bootmem(void)
{
- if (end_pfn <= MAX_DMA32_PFN)
+ if (num_physpages <= MAX_DMA32_PFN)
return;
if (!dma32_bootmem_ptr)
diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -752,10 +752,10 @@
return;
if (no_iommu ||
- (!force_iommu && end_pfn <= MAX_DMA32_PFN) ||
+ (!force_iommu && num_physpages <= MAX_DMA32_PFN) ||
!gart_iommu_aperture ||
(no_agp && init_k8_gatt(&info) < 0)) {
- if (end_pfn > MAX_DMA32_PFN) {
+ if (num_physpages > MAX_DMA32_PFN) {
printk(KERN_WARNING "More than 4GB of memory "
"but GART IOMMU not available.\n"
KERN_WARNING "falling back to iommu=soft.\n");
diff --git a/arch/x86/kernel/pci-swiotlb_64.c b/arch/x86/kernel/pci-swiotlb_64.c
--- a/arch/x86/kernel/pci-swiotlb_64.c
+++ b/arch/x86/kernel/pci-swiotlb_64.c
@@ -38,7 +38,7 @@
void __init pci_swiotlb_init(void)
{
/* don''t initialize swiotlb if iommu=off (no_iommu=1) */
- if (!iommu_detected && !no_iommu && end_pfn >
MAX_DMA32_PFN)
+ if (!iommu_detected && !no_iommu && num_physpages >
MAX_DMA32_PFN)
swiotlb = 1;
if (swiotlb_force)
swiotlb = 1;
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -161,7 +161,7 @@
unsigned long ramdisk_image = boot_params.hdr.ramdisk_image;
unsigned long ramdisk_size = boot_params.hdr.ramdisk_size;
unsigned long ramdisk_end = ramdisk_image + ramdisk_size;
- unsigned long end_of_mem = end_pfn << PAGE_SHIFT;
+ unsigned long end_of_mem = num_physpages << PAGE_SHIFT;
if (ramdisk_end <= end_of_mem) {
/*
@@ -267,25 +267,23 @@
* partially used pages are not usable - thus
* we are rounding upwards:
*/
- end_pfn = e820_end_of_ram();
+ num_physpages = e820_end_of_ram();
/* pre allocte 4k for mptable mpc */
early_reserve_e820_mpc_new();
/* update e820 for memory not covered by WB MTRRs */
mtrr_bp_init();
- if (mtrr_trim_uncached_memory(end_pfn)) {
+ if (mtrr_trim_uncached_memory(num_physpages)) {
remove_all_active_ranges();
e820_register_active_regions(0, 0, -1UL);
- end_pfn = e820_end_of_ram();
+ num_physpages = e820_end_of_ram();
}
reserve_initrd();
- num_physpages = end_pfn;
-
check_efer();
- max_pfn_mapped = init_memory_mapping(0, (end_pfn << PAGE_SHIFT));
+ max_pfn_mapped = init_memory_mapping(0, (num_physpages << PAGE_SHIFT));
vsmp_init();
@@ -300,9 +298,9 @@
acpi_boot_table_init();
/* How many end-of-memory variables you have, grandma! */
- max_low_pfn = end_pfn;
- max_pfn = end_pfn;
- high_memory = (void *)__va(end_pfn * PAGE_SIZE - 1) + 1;
+ max_low_pfn = num_physpages;
+ max_pfn = num_physpages;
+ high_memory = (void *)__va(num_physpages * PAGE_SIZE - 1) + 1;
/* Remove active ranges so rediscovery with NUMA-awareness happens */
remove_all_active_ranges();
@@ -314,7 +312,7 @@
acpi_numa_init();
#endif
- initmem_init(0, end_pfn);
+ initmem_init(0, num_physpages);
dma32_reserve_bootmem();
@@ -366,7 +364,7 @@
* We trust e820 completely. No explicit ROM probing in memory.
*/
e820_reserve_resources();
- e820_mark_nosave_regions(end_pfn);
+ e820_mark_nosave_regions(num_physpages);
reserve_standard_io_resources();
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -240,7 +240,7 @@
return adr;
}
- if (pfn >= end_pfn)
+ if (pfn >= num_physpages)
panic("alloc_low_page: ran out of memory");
adr = early_ioremap(pfn * PAGE_SIZE, PAGE_SIZE);
@@ -584,9 +584,9 @@
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
- max_zone_pfns[ZONE_NORMAL] = end_pfn;
+ max_zone_pfns[ZONE_NORMAL] = num_physpages;
- memory_present(0, 0, end_pfn);
+ memory_present(0, 0, num_physpages);
sparse_init();
free_area_init_nodes(max_zone_pfns);
}
@@ -668,8 +668,8 @@
#else
totalram_pages = free_all_bootmem();
#endif
- reservedpages = end_pfn - totalram_pages -
- absent_pages_in_range(0, end_pfn);
+ reservedpages = num_physpages - totalram_pages -
+ absent_pages_in_range(0, num_physpages);
after_bootmem = 1;
codesize = (unsigned long) &_etext - (unsigned long) &_text;
@@ -688,7 +688,7 @@
printk(KERN_INFO "Memory: %luk/%luk available (%ldk kernel code, "
"%ldk reserved, %ldk data, %ldk init)\n",
(unsigned long) nr_free_pages() << (PAGE_SHIFT-10),
- end_pfn << (PAGE_SHIFT-10),
+ num_physpages << (PAGE_SHIFT-10),
codesize >> 10,
reservedpages << (PAGE_SHIFT-10),
datasize >> 10,
@@ -788,7 +788,7 @@
#endif
unsigned long pfn = phys >> PAGE_SHIFT;
- if (pfn >= end_pfn) {
+ if (pfn >= num_physpages) {
/*
* This can happen with kdump kernels when accessing
* firmware tables:
diff --git a/arch/x86/mm/k8topology_64.c b/arch/x86/mm/k8topology_64.c
--- a/arch/x86/mm/k8topology_64.c
+++ b/arch/x86/mm/k8topology_64.c
@@ -143,8 +143,8 @@
limit |= (1<<24)-1;
limit++;
- if (limit > end_pfn << PAGE_SHIFT)
- limit = end_pfn << PAGE_SHIFT;
+ if (limit > num_physpages << PAGE_SHIFT)
+ limit = num_physpages << PAGE_SHIFT;
if (limit <= base)
continue;
diff --git a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c
--- a/arch/x86/mm/numa_64.c
+++ b/arch/x86/mm/numa_64.c
@@ -86,7 +86,7 @@
addr = 0x8000;
nodemap_size = round_up(sizeof(s16) * memnodemapsize, L1_CACHE_BYTES);
- nodemap_addr = find_e820_area(addr, end_pfn<<PAGE_SHIFT,
+ nodemap_addr = find_e820_area(addr, num_physpages<<PAGE_SHIFT,
nodemap_size, L1_CACHE_BYTES);
if (nodemap_addr == -1UL) {
printk(KERN_ERR
@@ -579,7 +579,7 @@
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
max_zone_pfns[ZONE_DMA32] = MAX_DMA32_PFN;
- max_zone_pfns[ZONE_NORMAL] = end_pfn;
+ max_zone_pfns[ZONE_NORMAL] = num_physpages;
sparse_memory_present_with_active_regions(MAX_NUMNODES);
sparse_init();
diff --git a/arch/x86/mm/srat_64.c b/arch/x86/mm/srat_64.c
--- a/arch/x86/mm/srat_64.c
+++ b/arch/x86/mm/srat_64.c
@@ -299,7 +299,7 @@
pxmram = 0;
}
- e820ram = end_pfn - absent_pages_in_range(0, end_pfn);
+ e820ram = num_physpages - absent_pages_in_range(0, num_physpages);
/* We seem to lose 3 pages somewhere. Allow a bit of slack. */
if ((long)(e820ram - pxmram) >= 1*1024*1024) {
printk(KERN_ERR
diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
--- a/arch/x86/power/hibernate_64.c
+++ b/arch/x86/power/hibernate_64.c
@@ -83,7 +83,7 @@
/* Set up the direct mapping from scratch */
start = (unsigned long)pfn_to_kaddr(0);
- end = (unsigned long)pfn_to_kaddr(end_pfn);
+ end = (unsigned long)pfn_to_kaddr(num_physpages);
for (; start < end; start = next) {
pud_t *pud = (pud_t *)get_safe_page(GFP_ATOMIC);
diff --git a/include/asm-x86/page_64.h b/include/asm-x86/page_64.h
--- a/include/asm-x86/page_64.h
+++ b/include/asm-x86/page_64.h
@@ -58,7 +58,6 @@
void clear_page(void *page);
void copy_page(void *to, void *from);
-extern unsigned long end_pfn;
extern unsigned long phys_base;
extern unsigned long __phys_addr(unsigned long);
@@ -87,7 +86,7 @@
#endif /* !__ASSEMBLY__ */
#ifdef CONFIG_FLATMEM
-#define pfn_valid(pfn) ((pfn) < end_pfn)
+#define pfn_valid(pfn) ((pfn) < num_physpages)
#endif
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 13 of 36] x86_64: add prototype for x86_64_start_kernel()
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/setup.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/asm-x86/setup.h b/include/asm-x86/setup.h --- a/include/asm-x86/setup.h +++ b/include/asm-x86/setup.h @@ -61,6 +61,8 @@ extern unsigned long init_pg_tables_start; extern unsigned long init_pg_tables_end; +#else +void __init x86_64_start_kernel(char *real_mode); #endif /* __i386__ */ #endif /* _SETUP */ #endif /* __ASSEMBLY__ */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 14 of 36] x86_64: add sync_cmpxchg
Add sync_cmpxchg to match 32-bit''s sync_cmpxchg.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
include/asm-x86/cmpxchg_64.h | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/include/asm-x86/cmpxchg_64.h b/include/asm-x86/cmpxchg_64.h
--- a/include/asm-x86/cmpxchg_64.h
+++ b/include/asm-x86/cmpxchg_64.h
@@ -93,6 +93,39 @@
return old;
}
+/*
+ * Always use locked operations when touching memory shared with a
+ * hypervisor, since the system may be SMP even if the guest kernel
+ * isn''t.
+ */
+static inline unsigned long __sync_cmpxchg(volatile void *ptr,
+ unsigned long old,
+ unsigned long new, int size)
+{
+ unsigned long prev;
+ switch (size) {
+ case 1:
+ asm volatile("lock; cmpxchgb %b1,%2"
+ : "=a"(prev)
+ : "q"(new), "m"(*__xg(ptr)), "0"(old)
+ : "memory");
+ return prev;
+ case 2:
+ asm volatile("lock; cmpxchgw %w1,%2"
+ : "=a"(prev)
+ : "r"(new), "m"(*__xg(ptr)), "0"(old)
+ : "memory");
+ return prev;
+ case 4:
+ asm volatile("lock; cmpxchgl %1,%2"
+ : "=a"(prev)
+ : "r"(new), "m"(*__xg(ptr)), "0"(old)
+ : "memory");
+ return prev;
+ }
+ return old;
+}
+
static inline unsigned long __cmpxchg_local(volatile void *ptr,
unsigned long old,
unsigned long new, int size)
@@ -139,6 +172,10 @@
((__typeof__(*(ptr)))__cmpxchg_local((ptr), (unsigned long)(o), \
(unsigned long)(n), \
sizeof(*(ptr))))
+#define sync_cmpxchg(ptr, o, n) \
+ ((__typeof__(*(ptr)))__sync_cmpxchg((ptr), (unsigned long)(o), \
+ (unsigned long)(n), \
+ sizeof(*(ptr))))
#define cmpxchg64_local(ptr, o, n) \
({ \
BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 15 of 36] x86: simplify vmalloc_sync_all
vmalloc_sync_all() is only called from register_die_notifier and
alloc_vm_area. Neither is on any performance-critical paths, so
vmalloc_sync_all() itself is not on any hot paths.
Given that the optimisations in vmalloc_sync_all add a fair amount of
code and complexity, and are fairly hard to evaluate for correctness,
it''s better to just remove them to simplify the code rather than worry
about its absolute performance.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/mm/fault.c | 73 ++++++++++++++++-----------------------------------
1 file changed, 24 insertions(+), 49 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -949,14 +949,7 @@
void vmalloc_sync_all(void)
{
#ifdef CONFIG_X86_32
- /*
- * Note that races in the updates of insync and start aren''t
- * problematic: insync can only get set bits added, and updates to
- * start are only improving performance (without affecting correctness
- * if undone).
- */
- static DECLARE_BITMAP(insync, PTRS_PER_PGD);
- static unsigned long start = TASK_SIZE;
+ unsigned long start = VMALLOC_START & PGDIR_MASK;
unsigned long address;
if (SHARED_KERNEL_PMD)
@@ -964,56 +957,38 @@
BUILD_BUG_ON(TASK_SIZE & ~PGDIR_MASK);
for (address = start; address >= TASK_SIZE; address += PGDIR_SIZE) {
- if (!test_bit(pgd_index(address), insync)) {
- unsigned long flags;
- struct page *page;
+ unsigned long flags;
+ struct page *page;
- spin_lock_irqsave(&pgd_lock, flags);
- list_for_each_entry(page, &pgd_list, lru) {
- if (!vmalloc_sync_one(page_address(page),
- address))
- break;
- }
- spin_unlock_irqrestore(&pgd_lock, flags);
- if (!page)
- set_bit(pgd_index(address), insync);
+ spin_lock_irqsave(&pgd_lock, flags);
+ list_for_each_entry(page, &pgd_list, lru) {
+ if (!vmalloc_sync_one(page_address(page),
+ address))
+ break;
}
- if (address == start && test_bit(pgd_index(address), insync))
- start = address + PGDIR_SIZE;
+ spin_unlock_irqrestore(&pgd_lock, flags);
}
#else /* CONFIG_X86_64 */
- /*
- * Note that races in the updates of insync and start aren''t
- * problematic: insync can only get set bits added, and updates to
- * start are only improving performance (without affecting correctness
- * if undone).
- */
- static DECLARE_BITMAP(insync, PTRS_PER_PGD);
- static unsigned long start = VMALLOC_START & PGDIR_MASK;
+ unsigned long start = VMALLOC_START & PGDIR_MASK;
unsigned long address;
for (address = start; address <= VMALLOC_END; address += PGDIR_SIZE) {
- if (!test_bit(pgd_index(address), insync)) {
- const pgd_t *pgd_ref = pgd_offset_k(address);
- unsigned long flags;
- struct page *page;
+ const pgd_t *pgd_ref = pgd_offset_k(address);
+ unsigned long flags;
+ struct page *page;
- if (pgd_none(*pgd_ref))
- continue;
- spin_lock_irqsave(&pgd_lock, flags);
- list_for_each_entry(page, &pgd_list, lru) {
- pgd_t *pgd;
- pgd = (pgd_t *)page_address(page) + pgd_index(address);
- if (pgd_none(*pgd))
- set_pgd(pgd, *pgd_ref);
- else
- BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
- }
- spin_unlock_irqrestore(&pgd_lock, flags);
- set_bit(pgd_index(address), insync);
+ if (pgd_none(*pgd_ref))
+ continue;
+ spin_lock_irqsave(&pgd_lock, flags);
+ list_for_each_entry(page, &pgd_list, lru) {
+ pgd_t *pgd;
+ pgd = (pgd_t *)page_address(page) + pgd_index(address);
+ if (pgd_none(*pgd))
+ set_pgd(pgd, *pgd_ref);
+ else
+ BUG_ON(pgd_page_vaddr(*pgd) != pgd_page_vaddr(*pgd_ref));
}
- if (address == start)
- start = address + PGDIR_SIZE;
+ spin_unlock_irqrestore(&pgd_lock, flags);
}
#endif
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 16 of 36] x86/paravirt: add a pgd_alloc/free hooks
Add hooks which are called at pgd_alloc/free time. The pgd_alloc hook
may return an error code, which if non-zero, causes the pgd allocation
to be failed. The hooks may be used to allocate/free auxillary
per-pgd information.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/paravirt.c | 4 ++++
arch/x86/mm/pgtable.c | 13 ++++++++-----
arch/x86/xen/enlighten.c | 4 ++++
include/asm-x86/paravirt.h | 19 ++++++++++++++++++-
include/asm-x86/pgalloc.h | 4 ++++
5 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -30,6 +30,7 @@
#include <asm/setup.h>
#include <asm/arch_hooks.h>
#include <asm/time.h>
+#include <asm/pgalloc.h>
#include <asm/irq.h>
#include <asm/delay.h>
#include <asm/fixmap.h>
@@ -369,6 +370,9 @@
.flush_tlb_single = native_flush_tlb_single,
.flush_tlb_others = native_flush_tlb_others,
+ .pgd_alloc = __paravirt_pgd_alloc,
+ .pgd_free = paravirt_nop,
+
.alloc_pte = paravirt_nop,
.alloc_pmd = paravirt_nop,
.alloc_pmd_clone = paravirt_nop,
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -215,13 +215,15 @@
/* so that alloc_pmd can use it */
mm->pgd = pgd;
- if (pgd)
+ if (pgd) {
pgd_ctor(pgd);
- if (pgd && !pgd_prepopulate_pmd(mm, pgd)) {
- pgd_dtor(pgd);
- free_page((unsigned long)pgd);
- pgd = NULL;
+ if (paravirt_pgd_alloc(mm) != 0 ||
+ !pgd_prepopulate_pmd(mm, pgd)) {
+ pgd_dtor(pgd);
+ free_page((unsigned long)pgd);
+ pgd = NULL;
+ }
}
return pgd;
@@ -231,6 +233,7 @@
{
pgd_mop_up_pmds(mm, pgd);
pgd_dtor(pgd);
+ paravirt_pgd_free(mm, pgd);
free_page((unsigned long)pgd);
}
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -45,6 +45,7 @@
#include <asm/pgtable.h>
#include <asm/tlbflush.h>
#include <asm/reboot.h>
+#include <asm/pgalloc.h>
#include "xen-ops.h"
#include "mmu.h"
@@ -1151,6 +1152,9 @@
.pte_update = paravirt_nop,
.pte_update_defer = paravirt_nop,
+ .pgd_alloc = __paravirt_pgd_alloc,
+ .pgd_free = paravirt_nop,
+
.alloc_pte = xen_alloc_pte_init,
.release_pte = xen_release_pte_init,
.alloc_pmd = xen_alloc_pte_init,
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
--- a/include/asm-x86/paravirt.h
+++ b/include/asm-x86/paravirt.h
@@ -220,7 +220,14 @@
void (*flush_tlb_others)(const cpumask_t *cpus, struct mm_struct *mm,
unsigned long va);
- /* Hooks for allocating/releasing pagetable pages */
+ /* Hooks for allocating and freeing a pagetable top-level */
+ int (*pgd_alloc)(struct mm_struct *mm);
+ void (*pgd_free)(struct mm_struct *mm, pgd_t *pgd);
+
+ /*
+ * Hooks for allocating/releasing pagetable pages when they''re
+ * attached to a pagetable
+ */
void (*alloc_pte)(struct mm_struct *mm, u32 pfn);
void (*alloc_pmd)(struct mm_struct *mm, u32 pfn);
void (*alloc_pmd_clone)(u32 pfn, u32 clonepfn, u32 start, u32 count);
@@ -926,6 +933,16 @@
PVOP_VCALL3(pv_mmu_ops.flush_tlb_others, &cpumask, mm, va);
}
+static inline int paravirt_pgd_alloc(struct mm_struct *mm)
+{
+ return PVOP_CALL1(int, pv_mmu_ops.pgd_alloc, mm);
+}
+
+static inline void paravirt_pgd_free(struct mm_struct *mm, pgd_t *pgd)
+{
+ PVOP_VCALL2(pv_mmu_ops.pgd_free, mm, pgd);
+}
+
static inline void paravirt_alloc_pte(struct mm_struct *mm, unsigned pfn)
{
PVOP_VCALL2(pv_mmu_ops.alloc_pte, mm, pfn);
diff --git a/include/asm-x86/pgalloc.h b/include/asm-x86/pgalloc.h
--- a/include/asm-x86/pgalloc.h
+++ b/include/asm-x86/pgalloc.h
@@ -5,9 +5,13 @@
#include <linux/mm.h> /* for struct page */
#include <linux/pagemap.h>
+static inline int __paravirt_pgd_alloc(struct mm_struct *mm) { return 0; }
+
#ifdef CONFIG_PARAVIRT
#include <asm/paravirt.h>
#else
+#define paravirt_pgd_alloc(mm) __paravirt_pgd_alloc(mm)
+static inline void paravirt_pgd_free(struct mm_struct *mm, pgd_t *) {}
static inline void paravirt_alloc_pte(struct mm_struct *mm, unsigned long pfn)
{}
static inline void paravirt_alloc_pmd(struct mm_struct *mm, unsigned long pfn)
{}
static inline void paravirt_alloc_pmd_clone(unsigned long pfn, unsigned long
clonepfn,
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 17 of 36] x86: preallocate and prepopulate separately
Jan Beulich points out that vmalloc_sync_all() assumes that the
kernel''s pmd is always expected to be present in the pgd. The current
pgd construction code will add the pgd to the pgd_list before its pmds
have been pre-populated, thereby making it visible to
vmalloc_sync_all().
However, because pgd_prepopulate_pmd also does the allocation, it may
block and cannot be done under spinlock.
The solution is to preallocate the pmds out of the spinlock, then
populate them while holding the pgd_list lock.
This patch also pulls the pmd preallocation and mop-up functions out
to be common, assuming that the compiler will generate no code for
them when PREALLOCTED_PMDS is 0. Also, there''s no need for pgd_ctor
to clear the pgd again, since it''s allocated as a zeroed page.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Jan Beulich <jbeulich@novell.com>
---
arch/x86/mm/pgtable.c | 177 +++++++++++++++++++++++++++++--------------------
1 file changed, 105 insertions(+), 72 deletions(-)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -66,12 +66,6 @@
static void pgd_ctor(void *p)
{
pgd_t *pgd = p;
- unsigned long flags;
-
- /* Clear usermode parts of PGD */
- memset(pgd, 0, KERNEL_PGD_BOUNDARY*sizeof(pgd_t));
-
- spin_lock_irqsave(&pgd_lock, flags);
/* If the pgd points to a shared pagetable level (either the
ptes in non-PAE, or shared PMD in PAE), then just copy the
@@ -91,8 +85,6 @@
/* list required to sync kernel mapping updates */
if (!SHARED_KERNEL_PMD)
pgd_list_add(pgd);
-
- spin_unlock_irqrestore(&pgd_lock, flags);
}
static void pgd_dtor(void *pgd)
@@ -120,30 +112,6 @@
#ifdef CONFIG_X86_PAE
/*
- * Mop up any pmd pages which may still be attached to the pgd.
- * Normally they will be freed by munmap/exit_mmap, but any pmd we
- * preallocate which never got a corresponding vma will need to be
- * freed manually.
- */
-static void pgd_mop_up_pmds(struct mm_struct *mm, pgd_t *pgdp)
-{
- int i;
-
- for(i = 0; i < UNSHARED_PTRS_PER_PGD; i++) {
- pgd_t pgd = pgdp[i];
-
- if (pgd_val(pgd) != 0) {
- pmd_t *pmd = (pmd_t *)pgd_page_vaddr(pgd);
-
- pgdp[i] = native_make_pgd(0);
-
- paravirt_release_pmd(pgd_val(pgd) >> PAGE_SHIFT);
- pmd_free(mm, pmd);
- }
- }
-}
-
-/*
* In PAE mode, we need to do a cr3 reload (=tlb flush) when
* updating the top-level pagetable entries to guarantee the
* processor notices the update. Since this is expensive, and
@@ -154,31 +122,7 @@
* not shared between pagetables (!SHARED_KERNEL_PMDS), we allocate
* and initialize the kernel pmds here.
*/
-static int pgd_prepopulate_pmd(struct mm_struct *mm, pgd_t *pgd)
-{
- pud_t *pud;
- unsigned long addr;
- int i;
-
- pud = pud_offset(pgd, 0);
- for (addr = i = 0; i < UNSHARED_PTRS_PER_PGD;
- i++, pud++, addr += PUD_SIZE) {
- pmd_t *pmd = pmd_alloc_one(mm, addr);
-
- if (!pmd) {
- pgd_mop_up_pmds(mm, pgd);
- return 0;
- }
-
- if (i >= KERNEL_PGD_BOUNDARY)
- memcpy(pmd, (pmd_t *)pgd_page_vaddr(swapper_pg_dir[i]),
- sizeof(pmd_t) * PTRS_PER_PMD);
-
- pud_populate(mm, pud, pmd);
- }
-
- return 1;
-}
+#define PREALLOCATED_PMDS UNSHARED_PTRS_PER_PGD
void pud_populate(struct mm_struct *mm, pud_t *pudp, pmd_t *pmd)
{
@@ -198,35 +142,124 @@
write_cr3(read_cr3());
}
#else /* !CONFIG_X86_PAE */
+
/* No need to prepopulate any pagetable entries in non-PAE modes. */
-static int pgd_prepopulate_pmd(struct mm_struct *mm, pgd_t *pgd)
+#define PREALLOCATED_PMDS 0
+
+#endif /* CONFIG_X86_PAE */
+
+static void free_pmds(pmd_t *pmds[])
{
- return 1;
+ int i;
+
+ for(i = 0; i < PREALLOCATED_PMDS; i++)
+ if (pmds[i])
+ free_page((unsigned long)pmds[i]);
}
-static void pgd_mop_up_pmds(struct mm_struct *mm, pgd_t *pgd)
+static int preallocate_pmds(pmd_t *pmds[])
{
+ int i;
+ bool failed = false;
+
+ for(i = 0; i < PREALLOCATED_PMDS; i++) {
+ pmd_t *pmd = (pmd_t *)get_zeroed_page(GFP_KERNEL|__GFP_REPEAT);
+ if (pmd == NULL)
+ failed = true;
+ pmds[i] = pmd;
+ }
+
+ if (failed) {
+ free_pmds(pmds);
+ return -ENOMEM;
+ }
+
+ return 0;
}
-#endif /* CONFIG_X86_PAE */
+
+/*
+ * Mop up any pmd pages which may still be attached to the pgd.
+ * Normally they will be freed by munmap/exit_mmap, but any pmd we
+ * preallocate which never got a corresponding vma will need to be
+ * freed manually.
+ */
+static void pgd_mop_up_pmds(struct mm_struct *mm, pgd_t *pgdp)
+{
+ int i;
+
+ for(i = 0; i < PREALLOCATED_PMDS; i++) {
+ pgd_t pgd = pgdp[i];
+
+ if (pgd_val(pgd) != 0) {
+ pmd_t *pmd = (pmd_t *)pgd_page_vaddr(pgd);
+
+ pgdp[i] = native_make_pgd(0);
+
+ paravirt_release_pmd(pgd_val(pgd) >> PAGE_SHIFT);
+ pmd_free(mm, pmd);
+ }
+ }
+}
+
+static void pgd_prepopulate_pmd(struct mm_struct *mm, pgd_t *pgd, pmd_t
*pmds[])
+{
+ pud_t *pud;
+ unsigned long addr;
+ int i;
+
+ pud = pud_offset(pgd, 0);
+
+ for (addr = i = 0; i < PREALLOCATED_PMDS;
+ i++, pud++, addr += PUD_SIZE) {
+ pmd_t *pmd = pmds[i];
+
+ if (i >= KERNEL_PGD_BOUNDARY)
+ memcpy(pmd, (pmd_t *)pgd_page_vaddr(swapper_pg_dir[i]),
+ sizeof(pmd_t) * PTRS_PER_PMD);
+
+ pud_populate(mm, pud, pmd);
+ }
+}
pgd_t *pgd_alloc(struct mm_struct *mm)
{
- pgd_t *pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+ pgd_t *pgd;
+ pmd_t *pmds[PREALLOCATED_PMDS];
+ unsigned long flags;
- /* so that alloc_pmd can use it */
+ pgd = (pgd_t *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+
+ if (pgd == NULL)
+ goto out;
+
mm->pgd = pgd;
- if (pgd) {
- pgd_ctor(pgd);
- if (paravirt_pgd_alloc(mm) != 0 ||
- !pgd_prepopulate_pmd(mm, pgd)) {
- pgd_dtor(pgd);
- free_page((unsigned long)pgd);
- pgd = NULL;
- }
- }
+ if (preallocate_pmds(pmds) != 0)
+ goto out_free_pgd;
+
+ if (paravirt_pgd_alloc(mm) != 0)
+ goto out_free_pmds;
+
+ /*
+ * Make sure that pre-populating the pmds is atomic with
+ * respect to anything walking the pgd_list, so that they
+ * never see a partially populated pgd.
+ */
+ spin_lock_irqsave(&pgd_lock, flags);
+
+ pgd_ctor(pgd);
+ pgd_prepopulate_pmd(mm, pgd, pmds);
+
+ spin_unlock_irqrestore(&pgd_lock, flags);
return pgd;
+
+out_free_pmds:
+ free_pmds(pmds);
+out_free_pgd:
+ free_page((unsigned long)pgd);
+out:
+ return NULL;
}
void pgd_free(struct mm_struct *mm, pgd_t *pgd)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 18 of 36] x86/paravirt: add debugging for missing operations
Rather than just jumping to 0 when there''s a missing operation, raise a
BUG.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/Kconfig | 7 +++++++
include/asm-x86/paravirt.h | 8 ++++++++
2 files changed, 15 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -433,6 +433,13 @@
the kernel is theoretically slower and slightly larger.
endif
+
+config PARAVIRT_DEBUG
+ bool "paravirt-ops debugging"
+ depends on PARAVIRT && DEBUG_KERNEL
+ help
+ Enable to debug paravirt_ops internals. Specifically, BUG if
+ a paravirt_op is missing when it is called.
config MEMTEST
bool "Memtest"
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
--- a/include/asm-x86/paravirt.h
+++ b/include/asm-x86/paravirt.h
@@ -460,10 +460,17 @@
#define VEXTRA_CLOBBERS , "rax", "r8", "r9",
"r10", "r11"
#endif
+#ifdef CONFIG_PARAVIRT_DEBUG
+#define PVOP_TEST_NULL(op) BUG_ON(op == NULL)
+#else
+#define PVOP_TEST_NULL(op) ((void)op)
+#endif
+
#define __PVOP_CALL(rettype, op, pre, post, ...) \
({ \
rettype __ret; \
PVOP_CALL_ARGS; \
+ PVOP_TEST_NULL(op); \
/* This is 32-bit specific, but is okay in 64-bit */ \
/* since this condition will never hold */ \
if (sizeof(rettype) > sizeof(unsigned long)) { \
@@ -492,6 +499,7 @@
#define __PVOP_VCALL(op, pre, post, ...) \
({ \
PVOP_VCALL_ARGS; \
+ PVOP_TEST_NULL(op); \
asm volatile(pre \
paravirt_alt(PARAVIRT_CALL) \
post \
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 19 of 36] paravirt_ops: define PARA_INDIRECT for indirect asm calls
On 32-bit it''s best to use a %cs: prefix to access memory where the other segments may not bet set up properly yet. On 64-bit it''s best to use a rip-relative addressing mode. Define PARA_INDIRECT() to abstract this and generate the proper addressing mode in each case. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/paravirt.h | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h --- a/include/asm-x86/paravirt.h +++ b/include/asm-x86/paravirt.h @@ -1456,55 +1456,57 @@ #define PV_RESTORE_REGS popq %rdx; popq %rcx; popq %rdi; popq %rax #define PARA_PATCH(struct, off) ((PARAVIRT_PATCH_##struct + (off)) / 8) #define PARA_SITE(ptype, clobbers, ops) _PVSITE(ptype, clobbers, ops, .quad, 8) +#define PARA_INDIRECT(addr) *addr(%rip) #else #define PV_SAVE_REGS pushl %eax; pushl %edi; pushl %ecx; pushl %edx #define PV_RESTORE_REGS popl %edx; popl %ecx; popl %edi; popl %eax #define PARA_PATCH(struct, off) ((PARAVIRT_PATCH_##struct + (off)) / 4) #define PARA_SITE(ptype, clobbers, ops) _PVSITE(ptype, clobbers, ops, .long, 4) +#define PARA_INDIRECT(addr) *%cs:addr #endif #define INTERRUPT_RETURN \ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_iret), CLBR_NONE, \ - jmp *%cs:pv_cpu_ops+PV_CPU_iret) + jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_iret)) #define INTERRUPT_RETURN_NMI_SAFE \ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_nmi_return), CLBR_NONE, \ - jmp *%cs:pv_cpu_ops+PV_CPU_nmi_return) + jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_nmi_return)) #define DISABLE_INTERRUPTS(clobbers) \ PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_irq_disable), clobbers, \ - PV_SAVE_REGS; \ - call *%cs:pv_irq_ops+PV_IRQ_irq_disable; \ + PV_SAVE_REGS; \ + call PARA_INDIRECT(pv_irq_ops+PV_IRQ_irq_disable); \ PV_RESTORE_REGS;) \ #define ENABLE_INTERRUPTS(clobbers) \ PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_irq_enable), clobbers, \ - PV_SAVE_REGS; \ - call *%cs:pv_irq_ops+PV_IRQ_irq_enable; \ + PV_SAVE_REGS; \ + call PARA_INDIRECT(pv_irq_ops+PV_IRQ_irq_enable); \ PV_RESTORE_REGS;) #define ENABLE_INTERRUPTS_SYSCALL_RET \ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_irq_enable_syscall_ret),\ CLBR_NONE, \ - jmp *%cs:pv_cpu_ops+PV_CPU_irq_enable_syscall_ret) + jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_irq_enable_syscall_ret)) #ifdef CONFIG_X86_32 -#define GET_CR0_INTO_EAX \ - push %ecx; push %edx; \ - call *pv_cpu_ops+PV_CPU_read_cr0; \ +#define GET_CR0_INTO_EAX \ + push %ecx; push %edx; \ + call PARA_INDIRECT(pv_cpu_ops+PV_CPU_read_cr0); \ pop %edx; pop %ecx #else #define SWAPGS \ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_swapgs), CLBR_NONE, \ PV_SAVE_REGS; \ - call *pv_cpu_ops+PV_CPU_swapgs; \ + call PARA_INDIRECT(pv_cpu_ops+PV_CPU_swapgs); \ PV_RESTORE_REGS \ ) -#define GET_CR2_INTO_RCX \ - call *pv_mmu_ops+PV_MMU_read_cr2; \ - movq %rax, %rcx; \ +#define GET_CR2_INTO_RCX \ + call PARA_INDIRECT(pv_mmu_ops+PV_MMU_read_cr2); \ + movq %rax, %rcx; \ xorq %rax, %rax; #endif _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 20 of 36] paravirt/x86_64: move __PAGE_OFFSET to leave a space for hypervisor
From: Eduardo Habkost <ehabkost@redhat.com> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Set __PAGE_OFFSET to the most negative possible address + 16*PGDIR_SIZE. The gap is to allow a space for a hypervisor to fit. The gap is more or less arbitrary, but it''s what Xen needs. When booting native, kernel/head_64.S has a set of compile-time generated pagetables used at boot time. This patch removes their absolutely hard-coded layout, and makes it parameterised on __PAGE_OFFSET (and __START_KERNEL_map). Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/head_64.S | 19 +++++++++++++------ include/asm-x86/page_64.h | 8 +++++++- 2 files changed, 20 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -31,6 +31,13 @@ * because we need identity-mapped pages. * */ + +#define pud_index(x) (((x) >> PUD_SHIFT) & (PTRS_PER_PUD-1)) + +L4_PAGE_OFFSET = pgd_index(__PAGE_OFFSET) +L3_PAGE_OFFSET = pud_index(__PAGE_OFFSET) +L4_START_KERNEL = pgd_index(__START_KERNEL_map) +L3_START_KERNEL = pud_index(__START_KERNEL_map) .text .section .text.head @@ -77,8 +84,8 @@ /* Fixup the physical addresses in the page table */ addq %rbp, init_level4_pgt + 0(%rip) - addq %rbp, init_level4_pgt + (258*8)(%rip) - addq %rbp, init_level4_pgt + (511*8)(%rip) + addq %rbp, init_level4_pgt + (L4_PAGE_OFFSET*8)(%rip) + addq %rbp, init_level4_pgt + (L4_START_KERNEL*8)(%rip) addq %rbp, level3_ident_pgt + 0(%rip) @@ -338,9 +345,9 @@ */ NEXT_PAGE(init_level4_pgt) .quad level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE - .fill 257,8,0 + .org init_level4_pgt + L4_PAGE_OFFSET*8, 0 .quad level3_ident_pgt - __START_KERNEL_map + _KERNPG_TABLE - .fill 252,8,0 + .org init_level4_pgt + L4_START_KERNEL*8, 0 /* (2^48-(2*1024*1024*1024))/(2^39) = 511 */ .quad level3_kernel_pgt - __START_KERNEL_map + _PAGE_TABLE @@ -349,7 +356,7 @@ .fill 511,8,0 NEXT_PAGE(level3_kernel_pgt) - .fill 510,8,0 + .fill L3_START_KERNEL,8,0 /* (2^48-(2*1024*1024*1024)-((2^39)*511))/(2^30) = 510 */ .quad level2_kernel_pgt - __START_KERNEL_map + _KERNPG_TABLE .quad level2_fixmap_pgt - __START_KERNEL_map + _PAGE_TABLE diff --git a/include/asm-x86/page_64.h b/include/asm-x86/page_64.h --- a/include/asm-x86/page_64.h +++ b/include/asm-x86/page_64.h @@ -26,7 +26,13 @@ #define PUD_PAGE_SIZE (_AC(1, UL) << PUD_SHIFT) #define PUD_PAGE_MASK (~(PUD_PAGE_SIZE-1)) -#define __PAGE_OFFSET _AC(0xffff810000000000, UL) +/* + * Set __PAGE_OFFSET to the most negative possible address + + * PGDIR_SIZE*16 (pgd slot 272). The gap is to allow a space for a + * hypervisor to fit. Choosing 16 slots here is arbitrary, but it''s + * what Xen requires. + */ +#define __PAGE_OFFSET _AC(0xffff880000000000, UL) #define __PHYSICAL_START CONFIG_PHYSICAL_START #define __KERNEL_ALIGN 0x200000 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 21 of 36] x86-64: add FIX_PARAVIRT_BOOTMAP fixmap slot
This matches 32 bit. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/fixmap_64.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/asm-x86/fixmap_64.h b/include/asm-x86/fixmap_64.h --- a/include/asm-x86/fixmap_64.h +++ b/include/asm-x86/fixmap_64.h @@ -46,6 +46,9 @@ FIX_EFI_IO_MAP_LAST_PAGE, FIX_EFI_IO_MAP_FIRST_PAGE = FIX_EFI_IO_MAP_LAST_PAGE + MAX_EFI_IO_PAGES - 1, +#ifdef CONFIG_PARAVIRT + FIX_PARAVIRT_BOOTMAP, +#endif #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT FIX_OHCI1394_BASE, #endif _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 22 of 36] x86_64: split x86_64_start_kernel
Split x86_64_start_kernel() into two pieces:
The first essentially cleans up after head_64.S. It clears the
bss, zaps low identity mappings, sets up some early exception
handlers.
The second part preserves the boot data, reserves the kernel''s
text/data/bss, pagetables and ramdisk, and then starts the kernel
proper.
This split is so that Xen can call the second part to do the set up it
needs done. It doesn''t need any of the first part setups, because it
doesn''t boot via head_64.S, and its redundant or actively damaging.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/head64.c | 5 +++++
include/asm-x86/setup.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -108,6 +108,11 @@
early_printk("Kernel really alive\n");
+ x86_64_start_reservations(real_mode_data);
+}
+
+void __init x86_64_start_reservations(char *real_mode_data)
+{
copy_bootdata(__va(real_mode_data));
reserve_early(__pa_symbol(&_text), __pa_symbol(&_end), "TEXT DATA
BSS");
diff --git a/include/asm-x86/setup.h b/include/asm-x86/setup.h
--- a/include/asm-x86/setup.h
+++ b/include/asm-x86/setup.h
@@ -63,6 +63,8 @@
#else
void __init x86_64_start_kernel(char *real_mode);
+void __init x86_64_start_reservations(char *real_mode_data);
+
#endif /* __i386__ */
#endif /* _SETUP */
#endif /* __ASSEMBLY__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 23 of 36] x86_64: adjust mapping of physical pagetables to work with Xen
This makes a few of changes to the construction of the initial
pagetables to work better with paravirt_ops/Xen. The main areas
are:
1. Support non-PSE mapping of memory, since Xen doesn''t currently
allow 2M pages to be mapped in guests.
2. Make sure that the ioremap alias of all pages are dropped before
attaching the new page to the pagetable. This avoids having
writable aliases of pagetable pages.
3. Preserve existing pagetable entries, rather than overwriting. Its
possible that a fair amount of pagetable has already been constructed,
so reuse what''s already in place rather than ignoring and
overwriting it.
The algorithm relies on the invariant that any page which is part of
the kernel pagetable is itself mapped in the linear memory area. This
way, it can avoid using ioremap on a pagetable page.
The invariant holds because it maps memory from low to high addresses,
and also allocates memory from low to high. Each allocated page can
map at least 2M of address space, so the mapped area will always
progress much faster than the allocated area. It relies on the early
boot code mapping enough pages to get started.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/mm/init_64.c | 94 ++++++++++++++++++++++++++++++++++++++++++-------
arch/x86/mm/ioremap.c | 2 -
2 files changed, 83 insertions(+), 13 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -257,6 +257,43 @@
early_iounmap(adr, PAGE_SIZE);
}
+static void __meminit
+phys_pte_init(pte_t *pte_page, unsigned long addr, unsigned long end)
+{
+ unsigned pages = 0;
+ int i;
+ pte_t *pte = pte_page + pte_index(addr);
+
+ for(i = pte_index(addr); i < PTRS_PER_PTE; i++, addr += PAGE_SIZE, pte++) {
+
+ if (addr >= end) {
+ if (!after_bootmem) {
+ for(; i < PTRS_PER_PTE; i++, pte++)
+ set_pte(pte, __pte(0));
+ }
+ break;
+ }
+
+ if (pte_val(*pte))
+ continue;
+
+ if (0)
+ printk(" pte=%p addr=%lx pte=%016lx\n",
+ pte, addr, pfn_pte(addr >> PAGE_SHIFT, PAGE_KERNEL).pte);
+ set_pte(pte, pfn_pte(addr >> PAGE_SHIFT, PAGE_KERNEL));
+ pages++;
+ }
+ update_page_count(PG_LEVEL_4K, pages);
+}
+
+static void __meminit
+phys_pte_update(pmd_t *pmd, unsigned long address, unsigned long end)
+{
+ pte_t *pte = (pte_t *)pmd_page_vaddr(*pmd);
+
+ phys_pte_init(pte, address, end);
+}
+
static unsigned long __meminit
phys_pmd_init(pmd_t *pmd_page, unsigned long address, unsigned long end)
{
@@ -265,7 +302,9 @@
int i = pmd_index(address);
for (; i < PTRS_PER_PMD; i++, address += PMD_SIZE) {
+ unsigned long pte_phys;
pmd_t *pmd = pmd_page + pmd_index(address);
+ pte_t *pte;
if (address >= end) {
if (!after_bootmem) {
@@ -275,12 +314,23 @@
break;
}
- if (pmd_val(*pmd))
+ if (pmd_val(*pmd)) {
+ phys_pte_update(pmd, address, end);
continue;
+ }
- pages++;
- set_pte((pte_t *)pmd,
- pfn_pte(address >> PAGE_SHIFT, PAGE_KERNEL_LARGE));
+ if (cpu_has_pse) {
+ pages++;
+ set_pte((pte_t *)pmd,
+ pfn_pte(address >> PAGE_SHIFT, PAGE_KERNEL_LARGE));
+ continue;
+ }
+
+ pte = alloc_low_page(&pte_phys);
+ phys_pte_init(pte, address, end);
+ unmap_low_page(pte);
+
+ pmd_populate_kernel(&init_mm, pmd, __va(pte_phys));
}
update_page_count(PG_LEVEL_2M, pages);
return address;
@@ -337,11 +387,11 @@
pmd = alloc_low_page(&pmd_phys);
spin_lock(&init_mm.page_table_lock);
+ last_map_addr = phys_pmd_init(pmd, addr, end);
+ unmap_low_page(pmd);
pud_populate(&init_mm, pud, __va(pmd_phys));
- last_map_addr = phys_pmd_init(pmd, addr, end);
spin_unlock(&init_mm.page_table_lock);
- unmap_low_page(pmd);
}
__flush_tlb_all();
update_page_count(PG_LEVEL_1G, pages);
@@ -349,15 +399,29 @@
return last_map_addr >> PAGE_SHIFT;
}
+static unsigned long __meminit
+phys_pud_update(pgd_t *pgd, unsigned long addr, unsigned long end)
+{
+ pud_t *pud;
+
+ pud = (pud_t *)pgd_page_vaddr(*pgd);
+
+ return phys_pud_init(pud, addr, end);
+}
+
static void __init find_early_table_space(unsigned long end)
{
- unsigned long puds, pmds, tables, start;
+ unsigned long puds, tables, start;
puds = (end + PUD_SIZE - 1) >> PUD_SHIFT;
tables = round_up(puds * sizeof(pud_t), PAGE_SIZE);
if (!direct_gbpages) {
- pmds = (end + PMD_SIZE - 1) >> PMD_SHIFT;
+ unsigned long pmds = (end + PMD_SIZE - 1) >> PMD_SHIFT;
tables += round_up(pmds * sizeof(pmd_t), PAGE_SIZE);
+ }
+ if (!cpu_has_pse) {
+ unsigned long ptes = (end + PAGE_SIZE - 1) >> PAGE_SHIFT;
+ tables += round_up(ptes * sizeof(pte_t), PAGE_SIZE);
}
/*
@@ -529,19 +593,25 @@
unsigned long pud_phys;
pud_t *pud;
+ next = start + PGDIR_SIZE;
+ if (next > end)
+ next = end;
+
+ if (pgd_val(*pgd)) {
+ last_map_addr = phys_pud_update(pgd, __pa(start), __pa(end));
+ continue;
+ }
+
if (after_bootmem)
pud = pud_offset(pgd, start & PGDIR_MASK);
else
pud = alloc_low_page(&pud_phys);
- next = start + PGDIR_SIZE;
- if (next > end)
- next = end;
last_map_addr = phys_pud_init(pud, __pa(start), __pa(next));
+ unmap_low_page(pud);
if (!after_bootmem)
pgd_populate(&init_mm, pgd_offset_k(start),
__va(pud_phys));
- unmap_low_page(pud);
}
if (!after_bootmem)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -513,7 +513,7 @@
if (pgprot_val(flags))
set_pte(pte, pfn_pte(phys >> PAGE_SHIFT, flags));
else
- pte_clear(NULL, addr, pte);
+ pte_clear(&init_mm, addr, pte);
__flush_tlb_one(addr);
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 24 of 36] x86_64: create small vmemmap mappings if PSE not available
If PSE is not available, then fall back to 4k page mappings for the
vmemmap area.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/mm/init_64.c | 62 +++++++++++++++++++++++++++++++------------------
1 file changed, 40 insertions(+), 22 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -997,7 +997,7 @@
pmd_t *pmd;
for (; addr < end; addr = next) {
- next = pmd_addr_end(addr, end);
+ void *p = NULL;
pgd = vmemmap_pgd_populate(addr, node);
if (!pgd)
@@ -1007,33 +1007,51 @@
if (!pud)
return -ENOMEM;
- pmd = pmd_offset(pud, addr);
- if (pmd_none(*pmd)) {
- pte_t entry;
- void *p;
+ if (!cpu_has_pse) {
+ next = (addr + PAGE_SIZE) & PAGE_MASK;
+ pmd = vmemmap_pmd_populate(pud, addr, node);
- p = vmemmap_alloc_block(PMD_SIZE, node);
+ if (!pmd)
+ return -ENOMEM;
+
+ p = vmemmap_pte_populate(pmd, addr, node);
+
if (!p)
return -ENOMEM;
- entry = pfn_pte(__pa(p) >> PAGE_SHIFT,
- PAGE_KERNEL_LARGE);
- set_pmd(pmd, __pmd(pte_val(entry)));
+ addr_end = addr + PAGE_SIZE;
+ p_end = p + PAGE_SIZE;
+ } else {
+ next = pmd_addr_end(addr, end);
- /* check to see if we have contiguous blocks */
- if (p_end != p || node_start != node) {
- if (p_start)
- printk(KERN_DEBUG " [%lx-%lx] PMD -> [%p-%p] on node %d\n",
- addr_start, addr_end-1, p_start, p_end-1, node_start);
- addr_start = addr;
- node_start = node;
- p_start = p;
- }
- addr_end = addr + PMD_SIZE;
- p_end = p + PMD_SIZE;
- } else {
- vmemmap_verify((pte_t *)pmd, node, addr, next);
+ pmd = pmd_offset(pud, addr);
+ if (pmd_none(*pmd)) {
+ pte_t entry;
+
+ p = vmemmap_alloc_block(PMD_SIZE, node);
+ if (!p)
+ return -ENOMEM;
+
+ entry = pfn_pte(__pa(p) >> PAGE_SHIFT,
+ PAGE_KERNEL_LARGE);
+ set_pmd(pmd, __pmd(pte_val(entry)));
+
+ addr_end = addr + PMD_SIZE;
+ p_end = p + PMD_SIZE;
+
+ /* check to see if we have contiguous blocks */
+ if (p_end != p || node_start != node) {
+ if (p_start)
+ printk(KERN_DEBUG " [%lx-%lx] PMD -> [%p-%p] on node %d\n",
+ addr_start, addr_end-1, p_start, p_end-1, node_start);
+ addr_start = addr;
+ node_start = node;
+ p_start = p;
+ }
+ } else
+ vmemmap_verify((pte_t *)pmd, node, addr, next);
}
+
}
return 0;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 25 of 36] x86_64: PSE no longer a hard requirement
Because Xen doesn''t support PSE mappings in guests, all code which assumed the presence of PSE has been changed to fall back to smaller mappings if necessary. As a result, PSE is optional rather than required (though still used whereever possible). Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/required-features.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/asm-x86/required-features.h b/include/asm-x86/required-features.h --- a/include/asm-x86/required-features.h +++ b/include/asm-x86/required-features.h @@ -42,7 +42,7 @@ #endif #ifdef CONFIG_X86_64 -#define NEED_PSE (1<<(X86_FEATURE_PSE & 31)) +#define NEED_PSE 0 #define NEED_MSR (1<<(X86_FEATURE_MSR & 31)) #define NEED_PGE (1<<(X86_FEATURE_PGE & 31)) #define NEED_FXSR (1<<(X86_FEATURE_FXSR & 31)) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 26 of 36] x86_64: Split set_pte_vaddr()
From: Eduardo Habkost <ehabkost@redhat.com>
We will need to set a pte on l3_user_pgt. Extract set_pte_vaddr_pud()
from set_pte_vaddr(), that will accept the l3 page table as parameter.
This change should be a no-op for existing code.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/mm/init_64.c | 31 ++++++++++++++++++++-----------
include/asm-x86/pgtable_64.h | 3 +++
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -149,22 +149,13 @@
}
void
-set_pte_vaddr(unsigned long vaddr, pte_t new_pte)
+set_pte_vaddr_pud(pud_t *pud_page, unsigned long vaddr, pte_t new_pte)
{
- pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
pte_t *pte;
- pr_debug("set_pte_vaddr %lx to %lx\n", vaddr,
native_pte_val(new_pte));
-
- pgd = pgd_offset_k(vaddr);
- if (pgd_none(*pgd)) {
- printk(KERN_ERR
- "PGD FIXMAP MISSING, it should be setup in head.S!\n");
- return;
- }
- pud = pud_offset(pgd, vaddr);
+ pud = pud_page + pud_index(vaddr);
if (pud_none(*pud)) {
pmd = (pmd_t *) spp_getpage();
pud_populate(&init_mm, pud, pmd);
@@ -195,6 +186,24 @@
* (PGE mappings get flushed as well)
*/
__flush_tlb_one(vaddr);
+}
+
+void
+set_pte_vaddr(unsigned long vaddr, pte_t pteval)
+{
+ pgd_t *pgd;
+ pud_t *pud_page;
+
+ pr_debug("set_pte_vaddr %lx to %lx\n", vaddr,
native_pte_val(pteval));
+
+ pgd = pgd_offset_k(vaddr);
+ if (pgd_none(*pgd)) {
+ printk(KERN_ERR
+ "PGD FIXMAP MISSING, it should be setup in head.S!\n");
+ return;
+ }
+ pud_page = (pud_t*)pgd_page_vaddr(*pgd);
+ set_pte_vaddr_pud(pud_page, vaddr, pteval);
}
/*
diff --git a/include/asm-x86/pgtable_64.h b/include/asm-x86/pgtable_64.h
--- a/include/asm-x86/pgtable_64.h
+++ b/include/asm-x86/pgtable_64.h
@@ -69,6 +69,9 @@
#define pud_none(x) (!pud_val(x))
struct mm_struct;
+
+void set_pte_vaddr_pud(pud_t *pud_page, unsigned long vaddr, pte_t new_pte);
+
static inline void native_pte_clear(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 27 of 36] x86_64: __switch_to(): Move arch_leave_lazy_cpu_mode() to the right place
We must leave lazy mode before switching the %fs and %gs selectors.
(patch should be merged with previous
__switch_to()/arch_leave_lazy_cpu_mode() patch)
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/process_64.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -603,6 +603,15 @@
load_TLS(next, cpu);
+ /*
+ * Leave lazy mode, flushing any hypercalls made here.
+ * This must be done before restoring TLS segments so
+ * the GDT and LDT are properly updated, and must be
+ * done before math_state_restore, so the TS bit is up
+ * to date.
+ */
+ arch_leave_lazy_cpu_mode();
+
/*
* Switch FS and GS.
*/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 28 of 36] Save %fs and %gs before load_TLS() and arch_leave_lazy_cpu_mode()
We must do this because load_TLS() may need to clear %fs and %gs,
such (e.g. under Xen).
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/process_64.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -579,6 +579,7 @@
*next = &next_p->thread;
int cpu = smp_processor_id();
struct tss_struct *tss = &per_cpu(init_tss, cpu);
+ unsigned fsindex, gsindex;
/* we''re going to use this soon, after a few expensive things */
if (next_p->fpu_counter>5)
@@ -601,6 +602,15 @@
if (unlikely(next->ds | prev->ds))
loadsegment(ds, next->ds);
+
+ /* We must save %fs and %gs before load_TLS() because
+ * %fs and %gs may be cleared by load_TLS().
+ *
+ * (e.g. xen_load_tls())
+ */
+ savesegment(fs, fsindex);
+ savesegment(gs, gsindex);
+
load_TLS(next, cpu);
/*
@@ -616,8 +626,6 @@
* Switch FS and GS.
*/
{
- unsigned fsindex;
- savesegment(fs, fsindex);
/* segment register != 0 always requires a reload.
also reload when it has changed.
when prev process used 64bit base always reload
@@ -635,10 +643,7 @@
if (next->fs)
wrmsrl(MSR_FS_BASE, next->fs);
prev->fsindex = fsindex;
- }
- {
- unsigned gsindex;
- savesegment(gs, gsindex);
+
if (unlikely(gsindex | next->gsindex | prev->gs)) {
load_gs_index(next->gsindex);
if (gsindex)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 29 of 36] Use __KERNEL_DS as SS when returning to a kernel thread (VERIFY)
This is needed when the kernel is running on RING3, such as under Xen.
x86_64 has a weird feature that makes it #GP on iret when SS is a null
descriptor.
This need to be tested on bare metal to make sure it doesn''t cause
any
problems. AMD specs say SS is always ignored (except on iret?).
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/entry_64.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -212,7 +212,7 @@
.macro FAKE_STACK_FRAME child_rip
/* push in order ss, rsp, eflags, cs, rip */
xorl %eax, %eax
- pushq %rax /* ss */
+ pushq $__KERNEL_DS /* ss */
CFI_ADJUST_CFA_OFFSET 8
/*CFI_REL_OFFSET ss,0*/
pushq %rax /* rsp */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 30 of 36] x86/paravirt_ops: split sysret and sysexit
Don''t conflate sysret and sysexit; they''re different
instructions with
different semantics, and may be in use at the same time (at least
within the same kernel, depending on whether its an Intel or AMD
system).
sysexit - just return to userspace, does no register restoration of
any kind; must explicitly atomically enable interrupts.
sysret - reloads flags from r11, so no need to explicitly enable
interrupts on 64-bit, responsible for restoring usermode %gs
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citirx.com>
---
arch/x86/kernel/asm-offsets_32.c | 2 +-
arch/x86/kernel/asm-offsets_64.c | 2 +-
arch/x86/kernel/entry_32.S | 8 ++++----
arch/x86/kernel/entry_64.S | 4 ++--
arch/x86/kernel/paravirt.c | 12 +++++++++---
arch/x86/kernel/paravirt_patch_32.c | 4 ++--
arch/x86/kernel/paravirt_patch_64.c | 4 ++--
arch/x86/kernel/vmi_32.c | 4 ++--
arch/x86/xen/enlighten.c | 2 +-
include/asm-x86/irqflags.h | 4 ++--
include/asm-x86/paravirt.h | 15 ++++++++++-----
11 files changed, 36 insertions(+), 25 deletions(-)
diff --git a/arch/x86/kernel/asm-offsets_32.c b/arch/x86/kernel/asm-offsets_32.c
--- a/arch/x86/kernel/asm-offsets_32.c
+++ b/arch/x86/kernel/asm-offsets_32.c
@@ -112,7 +112,7 @@
OFFSET(PV_IRQ_irq_enable, pv_irq_ops, irq_enable);
OFFSET(PV_CPU_iret, pv_cpu_ops, iret);
OFFSET(PV_CPU_nmi_return, pv_cpu_ops, nmi_return);
- OFFSET(PV_CPU_irq_enable_syscall_ret, pv_cpu_ops, irq_enable_syscall_ret);
+ OFFSET(PV_CPU_irq_enable_sysexit, pv_cpu_ops, irq_enable_sysexit);
OFFSET(PV_CPU_read_cr0, pv_cpu_ops, read_cr0);
#endif
diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c
--- a/arch/x86/kernel/asm-offsets_64.c
+++ b/arch/x86/kernel/asm-offsets_64.c
@@ -63,7 +63,7 @@
OFFSET(PV_IRQ_irq_enable, pv_irq_ops, irq_enable);
OFFSET(PV_CPU_iret, pv_cpu_ops, iret);
OFFSET(PV_CPU_nmi_return, pv_cpu_ops, nmi_return);
- OFFSET(PV_CPU_irq_enable_syscall_ret, pv_cpu_ops, irq_enable_syscall_ret);
+ OFFSET(PV_CPU_usersp_sysret, pv_cpu_ops, usersp_sysret);
OFFSET(PV_CPU_swapgs, pv_cpu_ops, swapgs);
OFFSET(PV_MMU_read_cr2, pv_mmu_ops, read_cr2);
#endif
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -59,7 +59,7 @@
* for paravirtualization. The following will never clobber any registers:
* INTERRUPT_RETURN (aka. "iret")
* GET_CR0_INTO_EAX (aka. "movl %cr0, %eax")
- * ENABLE_INTERRUPTS_SYSCALL_RET (aka "sti; sysexit").
+ * ENABLE_INTERRUPTS_SYSEXIT (aka "sti; sysexit").
*
* For DISABLE_INTERRUPTS/ENABLE_INTERRUPTS (aka
"cli"/"sti"), you must
* specify what registers can be overwritten (CLBR_NONE, CLBR_EAX/EDX/ECX/ANY).
@@ -376,7 +376,7 @@
xorl %ebp,%ebp
TRACE_IRQS_ON
1: mov PT_FS(%esp), %fs
- ENABLE_INTERRUPTS_SYSCALL_RET
+ ENABLE_INTERRUPTS_SYSEXIT
CFI_ENDPROC
.pushsection .fixup,"ax"
2: movl $0,PT_FS(%esp)
@@ -905,10 +905,10 @@
NATIVE_INTERRUPT_RETURN_NMI_SAFE # Should we deal with popf exception ?
END(native_nmi_return)
-ENTRY(native_irq_enable_syscall_ret)
+ENTRY(native_irq_enable_sysexit)
sti
sysexit
-END(native_irq_enable_syscall_ret)
+END(native_irq_enable_sysexit)
#endif
KPROBE_ENTRY(int3)
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -167,7 +167,7 @@
#endif
#ifdef CONFIG_PARAVIRT
-ENTRY(native_irq_enable_syscall_ret)
+ENTRY(native_usersp_sysret)
movq %gs:pda_oldrsp,%rsp
swapgs
sysretq
@@ -383,7 +383,7 @@
CFI_REGISTER rip,rcx
RESTORE_ARGS 0,-ARG_SKIP,1
/*CFI_REGISTER rflags,r11*/
- ENABLE_INTERRUPTS_SYSCALL_RET
+ USERSP_SYSRET
CFI_RESTORE_STATE
/* Handle reschedules */
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -141,7 +141,8 @@
ret = paravirt_patch_nop();
else if (type == PARAVIRT_PATCH(pv_cpu_ops.iret) ||
type == PARAVIRT_PATCH(pv_cpu_ops.nmi_return) ||
- type == PARAVIRT_PATCH(pv_cpu_ops.irq_enable_syscall_ret))
+ type == PARAVIRT_PATCH(pv_cpu_ops.irq_enable_sysexit) ||
+ type == PARAVIRT_PATCH(pv_cpu_ops.usersp_sysret))
/* If operation requires a jmp, then jmp */
ret = paravirt_patch_jmp(insnbuf, opfunc, addr, len);
else
@@ -193,7 +194,8 @@
/* These are in entry.S */
extern void native_iret(void);
extern void native_nmi_return(void);
-extern void native_irq_enable_syscall_ret(void);
+extern void native_irq_enable_sysexit(void);
+extern void native_usersp_sysret(void);
static int __init print_banner(void)
{
@@ -329,7 +331,11 @@
.write_idt_entry = native_write_idt_entry,
.load_sp0 = native_load_sp0,
- .irq_enable_syscall_ret = native_irq_enable_syscall_ret,
+#ifdef CONFIG_X86_32
+ .irq_enable_sysexit = native_irq_enable_sysexit,
+#else
+ .usersp_sysret = native_usersp_sysret,
+#endif
.iret = native_iret,
.nmi_return = native_nmi_return,
.swapgs = native_swapgs,
diff --git a/arch/x86/kernel/paravirt_patch_32.c
b/arch/x86/kernel/paravirt_patch_32.c
--- a/arch/x86/kernel/paravirt_patch_32.c
+++ b/arch/x86/kernel/paravirt_patch_32.c
@@ -8,7 +8,7 @@
DEF_NATIVE(pv_cpu_ops, iret, "iret");
DEF_NATIVE(pv_cpu_ops, nmi_return,
__stringify(NATIVE_INTERRUPT_RETURN_NMI_SAFE));
-DEF_NATIVE(pv_cpu_ops, irq_enable_syscall_ret, "sti; sysexit");
+DEF_NATIVE(pv_cpu_ops, irq_enable_sysexit, "sti; sysexit");
DEF_NATIVE(pv_mmu_ops, read_cr2, "mov %cr2, %eax");
DEF_NATIVE(pv_mmu_ops, write_cr3, "mov %eax, %cr3");
DEF_NATIVE(pv_mmu_ops, read_cr3, "mov %cr3, %eax");
@@ -33,7 +33,7 @@
PATCH_SITE(pv_irq_ops, save_fl);
PATCH_SITE(pv_cpu_ops, iret);
PATCH_SITE(pv_cpu_ops, nmi_return);
- PATCH_SITE(pv_cpu_ops, irq_enable_syscall_ret);
+ PATCH_SITE(pv_cpu_ops, irq_enable_sysexit);
PATCH_SITE(pv_mmu_ops, read_cr2);
PATCH_SITE(pv_mmu_ops, read_cr3);
PATCH_SITE(pv_mmu_ops, write_cr3);
diff --git a/arch/x86/kernel/paravirt_patch_64.c
b/arch/x86/kernel/paravirt_patch_64.c
--- a/arch/x86/kernel/paravirt_patch_64.c
+++ b/arch/x86/kernel/paravirt_patch_64.c
@@ -18,7 +18,7 @@
DEF_NATIVE(pv_cpu_ops, wbinvd, "wbinvd");
/* the three commands give us more control to how to return from a syscall */
-DEF_NATIVE(pv_cpu_ops, irq_enable_syscall_ret, "movq %gs:"
__stringify(pda_oldrsp) ", %rsp; swapgs; sysretq;");
+DEF_NATIVE(pv_cpu_ops, usersp_sysret, "movq %gs:"
__stringify(pda_oldrsp) ", %rsp; swapgs; sysretq;");
DEF_NATIVE(pv_cpu_ops, swapgs, "swapgs");
unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
@@ -39,7 +39,7 @@
PATCH_SITE(pv_irq_ops, irq_disable);
PATCH_SITE(pv_cpu_ops, iret);
PATCH_SITE(pv_cpu_ops, nmi_return);
- PATCH_SITE(pv_cpu_ops, irq_enable_syscall_ret);
+ PATCH_SITE(pv_cpu_ops, usersp_sysret);
PATCH_SITE(pv_cpu_ops, swapgs);
PATCH_SITE(pv_mmu_ops, read_cr2);
PATCH_SITE(pv_mmu_ops, read_cr3);
diff --git a/arch/x86/kernel/vmi_32.c b/arch/x86/kernel/vmi_32.c
--- a/arch/x86/kernel/vmi_32.c
+++ b/arch/x86/kernel/vmi_32.c
@@ -153,7 +153,7 @@
return patch_internal(VMI_CALL_IRET, len, insns, ip);
case PARAVIRT_PATCH(pv_cpu_ops.nmi_return):
return patch_internal(VMI_CALL_IRET, len, insns, ip);
- case PARAVIRT_PATCH(pv_cpu_ops.irq_enable_syscall_ret):
+ case PARAVIRT_PATCH(pv_cpu_ops.irq_enable_sysexit):
return patch_internal(VMI_CALL_SYSEXIT, len, insns, ip);
default:
break;
@@ -898,7 +898,7 @@
* the backend. They are performance critical anyway, so requiring
* a patch is not a big problem.
*/
- pv_cpu_ops.irq_enable_syscall_ret = (void *)0xfeedbab0;
+ pv_cpu_ops.irq_enable_sysexit = (void *)0xfeedbab0;
pv_cpu_ops.iret = (void *)0xbadbab0;
#ifdef CONFIG_SMP
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1087,7 +1087,7 @@
.iret = xen_iret,
.nmi_return = xen_iret,
- .irq_enable_syscall_ret = xen_sysexit,
+ .irq_enable_sysexit = xen_sysexit,
.load_tr_desc = paravirt_nop,
.set_ldt = xen_set_ldt,
diff --git a/include/asm-x86/irqflags.h b/include/asm-x86/irqflags.h
--- a/include/asm-x86/irqflags.h
+++ b/include/asm-x86/irqflags.h
@@ -168,13 +168,13 @@
#ifdef CONFIG_X86_64
#define INTERRUPT_RETURN iretq
-#define ENABLE_INTERRUPTS_SYSCALL_RET \
+#define USERSP_SYSRET \
movq %gs:pda_oldrsp, %rsp; \
swapgs; \
sysretq;
#else
#define INTERRUPT_RETURN iret
-#define ENABLE_INTERRUPTS_SYSCALL_RET sti; sysexit
+#define ENABLE_INTERRUPTS_SYSEXIT sti; sysexit
#define GET_CR0_INTO_EAX movl %cr0, %eax
#endif
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
--- a/include/asm-x86/paravirt.h
+++ b/include/asm-x86/paravirt.h
@@ -141,8 +141,9 @@
u64 (*read_pmc)(int counter);
unsigned long long (*read_tscp)(unsigned int *aux);
- /* These three are jmp to, not actually called. */
- void (*irq_enable_syscall_ret)(void);
+ /* These ones are jmp''ed to, not actually called. */
+ void (*irq_enable_sysexit)(void);
+ void (*usersp_sysret)(void);
void (*iret)(void);
void (*nmi_return)(void);
@@ -1485,10 +1486,10 @@
call PARA_INDIRECT(pv_irq_ops+PV_IRQ_irq_enable); \
PV_RESTORE_REGS;)
-#define ENABLE_INTERRUPTS_SYSCALL_RET \
- PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_irq_enable_syscall_ret),\
+#define ENABLE_INTERRUPTS_SYSEXIT \
+ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_irq_enable_sysexit), \
CLBR_NONE, \
- jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_irq_enable_syscall_ret))
+ jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_irq_enable_sysexit))
#ifdef CONFIG_X86_32
@@ -1509,6 +1510,10 @@
movq %rax, %rcx; \
xorq %rax, %rax;
+#define USERSP_SYSRET \
+ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usersp_sysret), \
+ CLBR_NONE, \
+ jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_usersp_sysret))
#endif
#endif /* __ASSEMBLY__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 31 of 36] x86_64 pvops: don''t restore user rsp within sysret
There''s no need to combine restoring the user rsp within the sysret
pvop, so split it out. This makes the pvop''s semantics closer to the
machine instruction.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citirx.com>
---
arch/x86/kernel/asm-offsets_64.c | 2 +-
arch/x86/kernel/entry_64.S | 6 +++---
arch/x86/kernel/paravirt.c | 6 +++---
arch/x86/kernel/paravirt_patch_64.c | 4 ++--
include/asm-x86/irqflags.h | 3 +--
include/asm-x86/paravirt.h | 8 ++++----
6 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c
--- a/arch/x86/kernel/asm-offsets_64.c
+++ b/arch/x86/kernel/asm-offsets_64.c
@@ -63,7 +63,7 @@
OFFSET(PV_IRQ_irq_enable, pv_irq_ops, irq_enable);
OFFSET(PV_CPU_iret, pv_cpu_ops, iret);
OFFSET(PV_CPU_nmi_return, pv_cpu_ops, nmi_return);
- OFFSET(PV_CPU_usersp_sysret, pv_cpu_ops, usersp_sysret);
+ OFFSET(PV_CPU_usergs_sysret, pv_cpu_ops, usergs_sysret);
OFFSET(PV_CPU_swapgs, pv_cpu_ops, swapgs);
OFFSET(PV_MMU_read_cr2, pv_mmu_ops, read_cr2);
#endif
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -167,8 +167,7 @@
#endif
#ifdef CONFIG_PARAVIRT
-ENTRY(native_usersp_sysret)
- movq %gs:pda_oldrsp,%rsp
+ENTRY(native_usergs_sysret)
swapgs
sysretq
#endif /* CONFIG_PARAVIRT */
@@ -383,7 +382,8 @@
CFI_REGISTER rip,rcx
RESTORE_ARGS 0,-ARG_SKIP,1
/*CFI_REGISTER rflags,r11*/
- USERSP_SYSRET
+ movq %gs:pda_oldrsp, %rsp
+ USERGS_SYSRET
CFI_RESTORE_STATE
/* Handle reschedules */
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -142,7 +142,7 @@
else if (type == PARAVIRT_PATCH(pv_cpu_ops.iret) ||
type == PARAVIRT_PATCH(pv_cpu_ops.nmi_return) ||
type == PARAVIRT_PATCH(pv_cpu_ops.irq_enable_sysexit) ||
- type == PARAVIRT_PATCH(pv_cpu_ops.usersp_sysret))
+ type == PARAVIRT_PATCH(pv_cpu_ops.usergs_sysret))
/* If operation requires a jmp, then jmp */
ret = paravirt_patch_jmp(insnbuf, opfunc, addr, len);
else
@@ -195,7 +195,7 @@
extern void native_iret(void);
extern void native_nmi_return(void);
extern void native_irq_enable_sysexit(void);
-extern void native_usersp_sysret(void);
+extern void native_usergs_sysret(void);
static int __init print_banner(void)
{
@@ -334,7 +334,7 @@
#ifdef CONFIG_X86_32
.irq_enable_sysexit = native_irq_enable_sysexit,
#else
- .usersp_sysret = native_usersp_sysret,
+ .usergs_sysret = native_usergs_sysret,
#endif
.iret = native_iret,
.nmi_return = native_nmi_return,
diff --git a/arch/x86/kernel/paravirt_patch_64.c
b/arch/x86/kernel/paravirt_patch_64.c
--- a/arch/x86/kernel/paravirt_patch_64.c
+++ b/arch/x86/kernel/paravirt_patch_64.c
@@ -18,7 +18,7 @@
DEF_NATIVE(pv_cpu_ops, wbinvd, "wbinvd");
/* the three commands give us more control to how to return from a syscall */
-DEF_NATIVE(pv_cpu_ops, usersp_sysret, "movq %gs:"
__stringify(pda_oldrsp) ", %rsp; swapgs; sysretq;");
+DEF_NATIVE(pv_cpu_ops, usergs_sysret, "swapgs; sysretq;");
DEF_NATIVE(pv_cpu_ops, swapgs, "swapgs");
unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
@@ -39,7 +39,7 @@
PATCH_SITE(pv_irq_ops, irq_disable);
PATCH_SITE(pv_cpu_ops, iret);
PATCH_SITE(pv_cpu_ops, nmi_return);
- PATCH_SITE(pv_cpu_ops, usersp_sysret);
+ PATCH_SITE(pv_cpu_ops, usergs_sysret);
PATCH_SITE(pv_cpu_ops, swapgs);
PATCH_SITE(pv_mmu_ops, read_cr2);
PATCH_SITE(pv_mmu_ops, read_cr3);
diff --git a/include/asm-x86/irqflags.h b/include/asm-x86/irqflags.h
--- a/include/asm-x86/irqflags.h
+++ b/include/asm-x86/irqflags.h
@@ -168,8 +168,7 @@
#ifdef CONFIG_X86_64
#define INTERRUPT_RETURN iretq
-#define USERSP_SYSRET \
- movq %gs:pda_oldrsp, %rsp; \
+#define USERGS_SYSRET \
swapgs; \
sysretq;
#else
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
--- a/include/asm-x86/paravirt.h
+++ b/include/asm-x86/paravirt.h
@@ -143,7 +143,7 @@
/* These ones are jmp''ed to, not actually called. */
void (*irq_enable_sysexit)(void);
- void (*usersp_sysret)(void);
+ void (*usergs_sysret)(void);
void (*iret)(void);
void (*nmi_return)(void);
@@ -1510,10 +1510,10 @@
movq %rax, %rcx; \
xorq %rax, %rax;
-#define USERSP_SYSRET \
- PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usersp_sysret), \
+#define USERGS_SYSRET \
+ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret), \
CLBR_NONE, \
- jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_usersp_sysret))
+ jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_usergs_sysret))
#endif
#endif /* __ASSEMBLY__ */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 32 of 36] Add sysret/sysexit pvops for returning to 32-bit compatibility userspace
In a 64-bit system, we need separate sysret/sysexit operations to
return to a 32-bit userspace.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citirx.com>
---
arch/x86/ia32/ia32entry.S | 21 +++++++++---
arch/x86/kernel/asm-offsets_64.c | 4 +-
arch/x86/kernel/entry_64.S | 4 +-
arch/x86/kernel/paravirt.c | 12 ++++---
arch/x86/kernel/paravirt_patch_64.c | 9 +++--
include/asm-x86/irqflags.h | 14 ++++++--
include/asm-x86/paravirt.h | 58 ++++++++++++++++++++++++++++-------
7 files changed, 91 insertions(+), 31 deletions(-)
diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -60,6 +60,19 @@
CFI_UNDEFINED r14
CFI_UNDEFINED r15
.endm
+
+#ifdef CONFIG_PARAVIRT
+ENTRY(native_usergs_sysret32)
+ swapgs
+ sysretl
+ENDPROC(native_usergs_sysret32)
+
+ENTRY(native_irq_enable_sysexit)
+ swapgs
+ sti
+ sysexit
+ENDPROC(native_irq_enable_sysexit)
+#endif
/*
* 32bit SYSENTER instruction entry.
@@ -151,10 +164,7 @@
CFI_ADJUST_CFA_OFFSET -8
CFI_REGISTER rsp,rcx
TRACE_IRQS_ON
- swapgs
- sti /* sti only takes effect after the next instruction */
- /* sysexit */
- .byte 0xf, 0x35
+ ENABLE_INTERRUPTS_SYSEXIT32
sysenter_tracesys:
CFI_RESTORE_STATE
@@ -254,8 +264,7 @@
TRACE_IRQS_ON
movl RSP-ARGOFFSET(%rsp),%esp
CFI_RESTORE rsp
- swapgs
- sysretl
+ USERGS_SYSRET32
cstar_tracesys:
CFI_RESTORE_STATE
diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c
--- a/arch/x86/kernel/asm-offsets_64.c
+++ b/arch/x86/kernel/asm-offsets_64.c
@@ -63,7 +63,9 @@
OFFSET(PV_IRQ_irq_enable, pv_irq_ops, irq_enable);
OFFSET(PV_CPU_iret, pv_cpu_ops, iret);
OFFSET(PV_CPU_nmi_return, pv_cpu_ops, nmi_return);
- OFFSET(PV_CPU_usergs_sysret, pv_cpu_ops, usergs_sysret);
+ OFFSET(PV_CPU_usergs_sysret32, pv_cpu_ops, usergs_sysret32);
+ OFFSET(PV_CPU_usergs_sysret64, pv_cpu_ops, usergs_sysret64);
+ OFFSET(PV_CPU_irq_enable_sysexit, pv_cpu_ops, irq_enable_sysexit);
OFFSET(PV_CPU_swapgs, pv_cpu_ops, swapgs);
OFFSET(PV_MMU_read_cr2, pv_mmu_ops, read_cr2);
#endif
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -167,7 +167,7 @@
#endif
#ifdef CONFIG_PARAVIRT
-ENTRY(native_usergs_sysret)
+ENTRY(native_usergs_sysret64)
swapgs
sysretq
#endif /* CONFIG_PARAVIRT */
@@ -383,7 +383,7 @@
RESTORE_ARGS 0,-ARG_SKIP,1
/*CFI_REGISTER rflags,r11*/
movq %gs:pda_oldrsp, %rsp
- USERGS_SYSRET
+ USERGS_SYSRET64
CFI_RESTORE_STATE
/* Handle reschedules */
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -142,7 +142,8 @@
else if (type == PARAVIRT_PATCH(pv_cpu_ops.iret) ||
type == PARAVIRT_PATCH(pv_cpu_ops.nmi_return) ||
type == PARAVIRT_PATCH(pv_cpu_ops.irq_enable_sysexit) ||
- type == PARAVIRT_PATCH(pv_cpu_ops.usergs_sysret))
+ type == PARAVIRT_PATCH(pv_cpu_ops.usergs_sysret32) ||
+ type == PARAVIRT_PATCH(pv_cpu_ops.usergs_sysret64))
/* If operation requires a jmp, then jmp */
ret = paravirt_patch_jmp(insnbuf, opfunc, addr, len);
else
@@ -195,7 +196,8 @@
extern void native_iret(void);
extern void native_nmi_return(void);
extern void native_irq_enable_sysexit(void);
-extern void native_usergs_sysret(void);
+extern void native_usergs_sysret32(void);
+extern void native_usergs_sysret64(void);
static int __init print_banner(void)
{
@@ -331,10 +333,10 @@
.write_idt_entry = native_write_idt_entry,
.load_sp0 = native_load_sp0,
-#ifdef CONFIG_X86_32
.irq_enable_sysexit = native_irq_enable_sysexit,
-#else
- .usergs_sysret = native_usergs_sysret,
+#ifdef CONFIG_X86_64
+ .usergs_sysret32 = native_usergs_sysret32,
+ .usergs_sysret64 = native_usergs_sysret64,
#endif
.iret = native_iret,
.nmi_return = native_nmi_return,
diff --git a/arch/x86/kernel/paravirt_patch_64.c
b/arch/x86/kernel/paravirt_patch_64.c
--- a/arch/x86/kernel/paravirt_patch_64.c
+++ b/arch/x86/kernel/paravirt_patch_64.c
@@ -17,8 +17,9 @@
DEF_NATIVE(pv_cpu_ops, clts, "clts");
DEF_NATIVE(pv_cpu_ops, wbinvd, "wbinvd");
-/* the three commands give us more control to how to return from a syscall */
-DEF_NATIVE(pv_cpu_ops, usergs_sysret, "swapgs; sysretq;");
+DEF_NATIVE(pv_cpu_ops, irq_enable_sysexit, "swapgs; sti; sysexit");
+DEF_NATIVE(pv_cpu_ops, usergs_sysret64, "swapgs; sysretq");
+DEF_NATIVE(pv_cpu_ops, usergs_sysret32, "swapgs; sysretl");
DEF_NATIVE(pv_cpu_ops, swapgs, "swapgs");
unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
@@ -39,7 +40,9 @@
PATCH_SITE(pv_irq_ops, irq_disable);
PATCH_SITE(pv_cpu_ops, iret);
PATCH_SITE(pv_cpu_ops, nmi_return);
- PATCH_SITE(pv_cpu_ops, usergs_sysret);
+ PATCH_SITE(pv_cpu_ops, irq_enable_sysexit);
+ PATCH_SITE(pv_cpu_ops, usergs_sysret32);
+ PATCH_SITE(pv_cpu_ops, usergs_sysret64);
PATCH_SITE(pv_cpu_ops, swapgs);
PATCH_SITE(pv_mmu_ops, read_cr2);
PATCH_SITE(pv_mmu_ops, read_cr3);
diff --git a/include/asm-x86/irqflags.h b/include/asm-x86/irqflags.h
--- a/include/asm-x86/irqflags.h
+++ b/include/asm-x86/irqflags.h
@@ -168,9 +168,17 @@
#ifdef CONFIG_X86_64
#define INTERRUPT_RETURN iretq
-#define USERGS_SYSRET \
- swapgs; \
- sysretq;
+#define USERGS_SYSRET64 \
+ swapgs; \
+ sysretq;
+#define USERGS_SYSRET32 \
+ swapgs; \
+ sysretl
+#define ENABLE_INTERRUPTS_SYSEXIT32 \
+ swapgs; \
+ sti; \
+ sysexit
+
#else
#define INTERRUPT_RETURN iret
#define ENABLE_INTERRUPTS_SYSEXIT sti; sysexit
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
--- a/include/asm-x86/paravirt.h
+++ b/include/asm-x86/paravirt.h
@@ -141,10 +141,35 @@
u64 (*read_pmc)(int counter);
unsigned long long (*read_tscp)(unsigned int *aux);
- /* These ones are jmp''ed to, not actually called. */
+ /*
+ * Atomically enable interrupts and return to userspace. This
+ * is only ever used to return to 32-bit processes; in a
+ * 64-bit kernel, it''s used for 32-on-64 compat processes, but
+ * never native 64-bit processes. (Jump, not call.)
+ */
void (*irq_enable_sysexit)(void);
- void (*usergs_sysret)(void);
+
+ /*
+ * Switch to usermode gs and return to 64-bit usermode using
+ * sysret. Only used in 64-bit kernels to return to 64-bit
+ * processes. Usermode register state, including %rsp, must
+ * already be restored.
+ */
+ void (*usergs_sysret64)(void);
+
+ /*
+ * Switch to usermode gs and return to 32-bit usermode using
+ * sysret. Used to return to 32-on-64 compat processes.
+ * Other usermode register state, including %esp, must already
+ * be restored.
+ */
+ void (*usergs_sysret32)(void);
+
+ /* Normal iret. Jump to this with the standard iret stack
+ frame set up. */
void (*iret)(void);
+
+ /* Return from NMI. (?) */
void (*nmi_return)(void);
void (*swapgs)(void);
@@ -1486,18 +1511,24 @@
call PARA_INDIRECT(pv_irq_ops+PV_IRQ_irq_enable); \
PV_RESTORE_REGS;)
-#define ENABLE_INTERRUPTS_SYSEXIT \
- PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_irq_enable_sysexit), \
+#define USERGS_SYSRET32 \
+ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret32), \
CLBR_NONE, \
- jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_irq_enable_sysexit))
-
+ jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_usergs_sysret32))
#ifdef CONFIG_X86_32
#define GET_CR0_INTO_EAX \
push %ecx; push %edx; \
call PARA_INDIRECT(pv_cpu_ops+PV_CPU_read_cr0); \
pop %edx; pop %ecx
-#else
+
+#define ENABLE_INTERRUPTS_SYSEXIT \
+ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_irq_enable_sysexit), \
+ CLBR_NONE, \
+ jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_irq_enable_sysexit))
+
+
+#else /* !CONFIG_X86_32 */
#define SWAPGS \
PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_swapgs), CLBR_NONE, \
PV_SAVE_REGS; \
@@ -1510,11 +1541,16 @@
movq %rax, %rcx; \
xorq %rax, %rax;
-#define USERGS_SYSRET \
- PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret), \
+#define USERGS_SYSRET64 \
+ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret64), \
CLBR_NONE, \
- jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_usergs_sysret))
-#endif
+ jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_usergs_sysret64))
+
+#define ENABLE_INTERRUPTS_SYSEXIT32 \
+ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_irq_enable_sysexit), \
+ CLBR_NONE, \
+ jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_irq_enable_sysexit))
+#endif /* CONFIG_X86_32 */
#endif /* __ASSEMBLY__ */
#endif /* CONFIG_PARAVIRT */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 33 of 36] x86_64: ia32entry: replace privileged instructions with pvops
Replace privileged instructions with the corresponding pvops in ia32entry.S. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/ia32/ia32entry.S | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S --- a/arch/x86/ia32/ia32entry.S +++ b/arch/x86/ia32/ia32entry.S @@ -98,14 +98,14 @@ CFI_SIGNAL_FRAME CFI_DEF_CFA rsp,0 CFI_REGISTER rsp,rbp - swapgs + SWAPGS movq %gs:pda_kernelstack, %rsp addq $(PDA_STACKOFFSET),%rsp /* * No need to follow this irqs on/off section: the syscall * disabled irqs, here we enable it straight after entry: */ - sti + ENABLE_INTERRUPTS(CLBR_NONE) movl %ebp,%ebp /* zero extension */ pushq $__USER32_DS CFI_ADJUST_CFA_OFFSET 8 @@ -147,7 +147,7 @@ call *ia32_sys_call_table(,%rax,8) movq %rax,RAX-ARGOFFSET(%rsp) GET_THREAD_INFO(%r10) - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF testl $_TIF_ALLWORK_MASK,threadinfo_flags(%r10) jnz int_ret_from_sys_call @@ -210,7 +210,7 @@ CFI_DEF_CFA rsp,PDA_STACKOFFSET CFI_REGISTER rip,rcx /*CFI_REGISTER rflags,r11*/ - swapgs + SWAPGS movl %esp,%r8d CFI_REGISTER rsp,r8 movq %gs:pda_kernelstack,%rsp @@ -218,7 +218,7 @@ * No need to follow this irqs on/off section: the syscall * disabled irqs and here we enable it straight after entry: */ - sti + ENABLE_INTERRUPTS(CLBR_NONE) SAVE_ARGS 8,1,1 movl %eax,%eax /* zero extension */ movq %rax,ORIG_RAX-ARGOFFSET(%rsp) @@ -251,7 +251,7 @@ call *ia32_sys_call_table(,%rax,8) movq %rax,RAX-ARGOFFSET(%rsp) GET_THREAD_INFO(%r10) - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF testl $_TIF_ALLWORK_MASK,threadinfo_flags(%r10) jnz int_ret_from_sys_call @@ -319,12 +319,12 @@ /*CFI_REL_OFFSET rflags,EFLAGS-RIP*/ /*CFI_REL_OFFSET cs,CS-RIP*/ CFI_REL_OFFSET rip,RIP-RIP - swapgs + SWAPGS /* * No need to follow this irqs on/off section: the syscall * disabled irqs and here we enable it straight after entry: */ - sti + ENABLE_INTERRUPTS(CLBR_NONE) movl %eax,%eax pushq %rax CFI_ADJUST_CFA_OFFSET 8 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 34 of 36] x86_64: swapgs pvop with a user-stack can never be called
It''s never safe to call a swapgs pvop when the user stack is current - it must be inline replaced. Rather than making a call, the SWAPGS_UNSAFE_STACK pvop always just puts "swapgs" as a placeholder, which must either be replaced inline or trap''n''emulated (somehow). Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/irqflags.h | 2 +- include/asm-x86/paravirt.h | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/include/asm-x86/irqflags.h b/include/asm-x86/irqflags.h --- a/include/asm-x86/irqflags.h +++ b/include/asm-x86/irqflags.h @@ -167,6 +167,7 @@ #define INTERRUPT_RETURN_NMI_SAFE NATIVE_INTERRUPT_RETURN_NMI_SAFE #ifdef CONFIG_X86_64 +#define SWAPGS_UNSAFE_STACK swapgs #define INTERRUPT_RETURN iretq #define USERGS_SYSRET64 \ swapgs; \ @@ -241,7 +242,6 @@ * Either way, this is a good way to document that we don''t * have a reliable stack. x86_64 only. */ -#define SWAPGS_UNSAFE_STACK swapgs #define ARCH_LOCKDEP_SYS_EXIT call lockdep_sys_exit_thunk #define ARCH_LOCKDEP_SYS_EXIT_IRQ \ TRACE_IRQS_ON; \ diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h --- a/include/asm-x86/paravirt.h +++ b/include/asm-x86/paravirt.h @@ -1529,6 +1529,16 @@ #else /* !CONFIG_X86_32 */ + +/* + * If swapgs is used while the userspace stack is still current, + * there''s no way to call a pvop. The PV replacement *must* be + * inlined, or the swapgs instruction must be trapped and emulated. + */ +#define SWAPGS_UNSAFE_STACK \ + PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_swapgs), CLBR_NONE, \ + swapgs) + #define SWAPGS \ PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_swapgs), CLBR_NONE, \ PV_SAVE_REGS; \ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 35 of 36] x86_64/paravirt: add adjust_exception_frame
64-bit Xen pushes a couple of extra words onto an exception frame.
Add a hook to deal with them.
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/asm-offsets_64.c | 1 +
arch/x86/kernel/entry_64.S | 2 ++
arch/x86/kernel/paravirt.c | 3 +++
arch/x86/xen/enlighten.c | 3 +++
include/asm-x86/paravirt.h | 9 +++++++++
include/asm-x86/processor.h | 2 ++
6 files changed, 20 insertions(+)
diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c
--- a/arch/x86/kernel/asm-offsets_64.c
+++ b/arch/x86/kernel/asm-offsets_64.c
@@ -61,6 +61,7 @@
OFFSET(PARAVIRT_PATCH_pv_irq_ops, paravirt_patch_template, pv_irq_ops);
OFFSET(PV_IRQ_irq_disable, pv_irq_ops, irq_disable);
OFFSET(PV_IRQ_irq_enable, pv_irq_ops, irq_enable);
+ OFFSET(PV_IRQ_adjust_exception_frame, pv_irq_ops, adjust_exception_frame);
OFFSET(PV_CPU_iret, pv_cpu_ops, iret);
OFFSET(PV_CPU_nmi_return, pv_cpu_ops, nmi_return);
OFFSET(PV_CPU_usergs_sysret32, pv_cpu_ops, usergs_sysret32);
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -864,6 +864,7 @@
*/
.macro zeroentry sym
INTR_FRAME
+ PARAVIRT_ADJUST_EXCEPTION_FRAME
pushq $0 /* push error code/oldrax */
CFI_ADJUST_CFA_OFFSET 8
pushq %rax /* push real oldrax to the rdi slot */
@@ -876,6 +877,7 @@
.macro errorentry sym
XCPT_FRAME
+ PARAVIRT_ADJUST_EXCEPTION_FRAME
pushq %rax
CFI_ADJUST_CFA_OFFSET 8
CFI_REL_OFFSET rax,0
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -298,6 +298,9 @@
.irq_enable = native_irq_enable,
.safe_halt = native_safe_halt,
.halt = native_halt,
+#ifdef CONFIG_X86_64
+ .adjust_exception_frame = paravirt_nop,
+#endif
};
struct pv_cpu_ops pv_cpu_ops = {
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1121,6 +1121,9 @@
.irq_enable = xen_irq_enable,
.safe_halt = xen_safe_halt,
.halt = xen_halt,
+#ifdef CONFIG_X86_64
+ .adjust_exception_frame = paravirt_nop,
+#endif
};
static const struct pv_apic_ops xen_apic_ops __initdata = {
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
--- a/include/asm-x86/paravirt.h
+++ b/include/asm-x86/paravirt.h
@@ -192,6 +192,10 @@
void (*irq_enable)(void);
void (*safe_halt)(void);
void (*halt)(void);
+
+#ifdef CONFIG_X86_64
+ void (*adjust_exception_frame)(void);
+#endif
};
struct pv_apic_ops {
@@ -1551,6 +1555,11 @@
movq %rax, %rcx; \
xorq %rax, %rax;
+#define PARAVIRT_ADJUST_EXCEPTION_FRAME \
+ PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_adjust_exception_frame), \
+ CLBR_NONE, \
+ call PARA_INDIRECT(pv_irq_ops+PV_IRQ_adjust_exception_frame))
+
#define USERGS_SYSRET64 \
PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret64), \
CLBR_NONE, \
diff --git a/include/asm-x86/processor.h b/include/asm-x86/processor.h
--- a/include/asm-x86/processor.h
+++ b/include/asm-x86/processor.h
@@ -542,6 +542,8 @@
#define set_iopl_mask native_set_iopl_mask
#define SWAPGS swapgs
+
+#define PARAVIRT_ADJUST_EXCEPTION_FRAME /* */
#endif /* CONFIG_PARAVIRT */
/*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 04:19 UTC
[Xen-devel] [PATCH 36 of 36] x86_64/paravirt: Make load_gs_index() a paravirt operation
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
---
arch/x86/kernel/entry_64.S | 4 ++--
arch/x86/kernel/paravirt.c | 3 +++
include/asm-x86/elf.h | 2 +-
include/asm-x86/paravirt.h | 10 ++++++++++
include/asm-x86/system.h | 3 ++-
5 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -1080,7 +1080,7 @@
/* Reload gs selector with exception handling */
/* edi: new selector */
-ENTRY(load_gs_index)
+ENTRY(native_load_gs_index)
CFI_STARTPROC
pushf
CFI_ADJUST_CFA_OFFSET 8
@@ -1094,7 +1094,7 @@
CFI_ADJUST_CFA_OFFSET -8
ret
CFI_ENDPROC
-ENDPROC(load_gs_index)
+ENDPROC(native_load_gs_index)
.section __ex_table,"a"
.align 8
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -331,6 +331,9 @@
.store_idt = native_store_idt,
.store_tr = native_store_tr,
.load_tls = native_load_tls,
+#ifdef CONFIG_X86_64
+ .load_gs_index = native_load_gs_index,
+#endif
.write_ldt_entry = native_write_ldt_entry,
.write_gdt_entry = native_write_gdt_entry,
.write_idt_entry = native_write_idt_entry,
diff --git a/include/asm-x86/elf.h b/include/asm-x86/elf.h
--- a/include/asm-x86/elf.h
+++ b/include/asm-x86/elf.h
@@ -83,9 +83,9 @@
(((x)->e_machine == EM_386) || ((x)->e_machine == EM_486))
#include <asm/processor.h>
+#include <asm/system.h>
#ifdef CONFIG_X86_32
-#include <asm/system.h> /* for savesegment */
#include <asm/desc.h>
#define elf_check_arch(x) elf_check_arch_ia32(x)
diff --git a/include/asm-x86/paravirt.h b/include/asm-x86/paravirt.h
--- a/include/asm-x86/paravirt.h
+++ b/include/asm-x86/paravirt.h
@@ -115,6 +115,9 @@
void (*set_ldt)(const void *desc, unsigned entries);
unsigned long (*store_tr)(void);
void (*load_tls)(struct thread_struct *t, unsigned int cpu);
+#ifdef CONFIG_X86_64
+ void (*load_gs_index)(unsigned int idx);
+#endif
void (*write_ldt_entry)(struct desc_struct *ldt, int entrynum,
const void *desc);
void (*write_gdt_entry)(struct desc_struct *,
@@ -848,6 +851,13 @@
PVOP_VCALL2(pv_cpu_ops.load_tls, t, cpu);
}
+#ifdef CONFIG_X86_64
+static inline void load_gs_index(unsigned int gs)
+{
+ PVOP_VCALL1(pv_cpu_ops.load_gs_index, gs);
+}
+#endif
+
static inline void write_ldt_entry(struct desc_struct *dt, int entry,
const void *desc)
{
diff --git a/include/asm-x86/system.h b/include/asm-x86/system.h
--- a/include/asm-x86/system.h
+++ b/include/asm-x86/system.h
@@ -140,7 +140,7 @@
#define set_base(ldt, base) _set_base(((char *)&(ldt)) , (base))
#define set_limit(ldt, limit) _set_limit(((char *)&(ldt)) , ((limit)-1))
-extern void load_gs_index(unsigned);
+extern void native_load_gs_index(unsigned);
/*
* Load a segment. Fall back on loading the zero
@@ -286,6 +286,7 @@
#ifdef CONFIG_X86_64
#define read_cr8() (native_read_cr8())
#define write_cr8(x) (native_write_cr8(x))
+#define load_gs_index native_load_gs_index
#endif
/* Clear the ''TS'' bit */
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Arjan van de Ven
2008-Jun-25 04:44 UTC
[Xen-devel] Re: [PATCH 03 of 36] x86: add memory barriers to wrmsr
On Wed, 25 Jun 2008 00:18:59 -0400 Jeremy Fitzhardinge <jeremy@goop.org> wrote:> wrmsr is a special instruction which can have arbitrary system-wide > effects. We don''t want the compiler to reorder it with respect to > memory operations, so make it a memory barrier.it''s more readable for several of these cases to stick a barrier(); in front and after it to be honest; that makes it more explicit that these are deliberate compiler barriers rather than "actual" memory access... -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-25 08:42 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Hi Ingo, > > This series lays the groundwork for 64-bit Xen support. It follows > the usual pattern: a series of general cleanups and improvements, > followed by additions and modifications needed to slide Xen in.cool stuff :-)> Most of the 64-bit paravirt-ops work has already been done and > integrated for some time, so the changes are relatively minor. > > Interesting and potentially hazardous changes in this series are: > > "paravirt/x86_64: move __PAGE_OFFSET to leave a space for hypervisor" > > This moves __PAGE_OFFSET up by 16 GDT slots, from 0xffff810000000000 > to 0xffff880000000000. I have no general justification for this: the > specific reason is that Xen claims the first 16 kernel GDT slots for > itself, and we must move up the mapping to make room. In the process > I parameterised the compile-time construction of the initial > pagetables in head_64.S to cope with it.This reduces native kernel max memory support from around 127 TB to around 120 TB. We also limit the Xen hypervisor to ~7 TB of physical memory - is that wise in the long run? Sure, current CPUs support 40 physical bits [1 TB] for now so it''s all theoretical at this moment. my guess is that CPU makers will first extend the physical lines all the way up to 46-47 bits before they are willing to touch the logical model and extend the virtual space beyond 48 bits (47 bits of that available to kernel-space in practice - i.e. 128 TB). So eventually, in a few years, we''ll feel some sort of crunch when the # of physical lines approaches the # of logical bits - just like when 32-bit felt a crunch when physical lines went to 31 and beyond.> "x86_64: adjust mapping of physical pagetables to work with Xen" > "x86_64: create small vmemmap mappings if PSE not available" > > This rearranges the construction of the physical mapping so that it > works with Xen. This affects three aspects of the code: > 1. It can''t use pse, so it will only use pse if the processor > supports it. > 2. It never replaces an existing mapping, so it can just extend the > early boot-provided mappings (either from head_64.S or the Xen domain > builder). > 3. It makes sure that any page is iounmapped before attaching it to the > pagetable to avoid having writable aliases of pagetable pages. > > The logical structure of the code is more or less unchanged, and still > works fine in the native case. > > vmemmap mapping is likewise changed. > > "x86_64: PSE no longer a hard requirement." > > Because booting under Xen doesn''t set PSE, it''s no longer a hard > requirement for the kernel. PSE will be used whereever possible.That should be fine too - and probably useful for 64-bit kmemcheck support as well. To further increase the symmetry between 64-bit and 32-bit, could you please also activate the mem=nopentium switch on 64-bit to allow the forcing of a non-PSE native 64-bit bootup? (Obviously not a good idea normally, as it wastes 0.1% of RAM and increases PTE related CPU cache footprint and TLB overhead, but it is useful for debugging.) a few other risk areas: - the vmalloc-sync changes. Are you absolutely sure that it does not matter for performance? - "The 32-bit early_ioremap will work equally well for 64-bit, so just use it." Famous last words ;-) Anyway, that''s all theory - i''ll try out your patchset in -tip to see what breaks in practice ;-) Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-25 08:47 UTC
[Xen-devel] Re: [PATCH 36 of 36] x86_64/paravirt: Make load_gs_index() a paravirt operation
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>patch logistics detail: the signoff order suggests it''s been authored by Eduardo - but there''s no From line to that effect - should i change it accordingly? Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 11:46 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:>> "paravirt/x86_64: move __PAGE_OFFSET to leave a space for hypervisor" >> >> This moves __PAGE_OFFSET up by 16 GDT slots, from 0xffff810000000000 >> to 0xffff880000000000. I have no general justification for this: the >> specific reason is that Xen claims the first 16 kernel GDT slots for >> itself, and we must move up the mapping to make room. In the process >> I parameterised the compile-time construction of the initial >> pagetables in head_64.S to cope with it. >> > > This reduces native kernel max memory support from around 127 TB to > around 120 TB. We also limit the Xen hypervisor to ~7 TB of physical > memory - is that wise in the long run? Sure, current CPUs support 40 > physical bits [1 TB] for now so it''s all theoretical at this moment. > > my guess is that CPU makers will first extend the physical lines all the > way up to 46-47 bits before they are willing to touch the logical model > and extend the virtual space beyond 48 bits (47 bits of that available > to kernel-space in practice - i.e. 128 TB). > > So eventually, in a few years, we''ll feel some sort of crunch when the # > of physical lines approaches the # of logical bits - just like when > 32-bit felt a crunch when physical lines went to 31 and beyond. >There''s no inherent reason why Xen itself needs to be able to have all memory mapped at once. 32-bit Xen doesn''t and can survive quite happily. It''s certainly nice to be able to access anything directly, but it''s just a performance optimisation. In practice, the guest generally has almost everything interesting mapped anyway, and Xen maintains a recursive mapping of the pagetable to make its access to the pagetable very efficient, so it''s only when a hypercall is doing something to an unmapped page that there''s an issue. The main limitation the hole-size imposes is the max size of the machine to physical map. That uses 8bytes/page, and reserves 256GB of space for it, meaning that the current limit is 2^47 bytes - but there''s another 256GB of reserved and unused space next to it, so that could be easily extended to 2^48 if that really becomes an issue.> That should be fine too - and probably useful for 64-bit kmemcheck > support as well. > > To further increase the symmetry between 64-bit and 32-bit, could you > please also activate the mem=nopentium switch on 64-bit to allow the > forcing of a non-PSE native 64-bit bootup? (Obviously not a good idea > normally, as it wastes 0.1% of RAM and increases PTE related CPU cache > footprint and TLB overhead, but it is useful for debugging.) >OK. Though it might be an idea to add "nopse" and start deprecating nopentium.> a few other risk areas: > > - the vmalloc-sync changes. Are you absolutely sure that it does not > matter for performance? >Oh, I didn''t mean to include that one. I think it''s probably safe (from both the performance and correctness stands), but it''s not necessary for 64-bit Xen.> - "The 32-bit early_ioremap will work equally well for 64-bit, so just > use it." Famous last words ;-) > > Anyway, that''s all theory - i''ll try out your patchset in -tip to see > what breaks in practice ;-) >Yep, thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 11:48 UTC
[Xen-devel] Re: [PATCH 36 of 36] x86_64/paravirt: Make load_gs_index() a paravirt operation
Ingo Molnar wrote:> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > >> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> >> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >> > > patch logistics detail: the signoff order suggests it''s been authored by > Eduardo - but there''s no From line to that effect - should i change it > accordingly?Yes, it''s Eduardo''s. Huh, I have the From line here; must have got stripped off by my script... J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Andi Kleen
2008-Jun-25 12:40 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Jeremy Fitzhardinge <jeremy@goop.org> writes:> > This moves __PAGE_OFFSET up by 16 GDT slots, from 0xffff810000000000GDT? PDP?> to 0xffff880000000000. I have no general justification for this: thThis will significantly decrease the maximum amount of physical memory supported by Linux longer term.> "x86_64: PSE no longer a hard requirement." > > Because booting under Xen doesn''t set PSE, it''s no longer a hard > requirement for the kernel. PSE will be used whereever possible.Both sound like cases of "let''s hack Linux to work around Xen problems" -Andi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-25 15:22 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Ingo Molnar <mingo@elte.hu> wrote:> Anyway, that''s all theory - i''ll try out your patchset in -tip to see > what breaks in practice ;-)i''ve put the commits (and a good number of dependent commits) into the new tip/x86/xen-64bit topic branch. It quickly broke the build in testing: include/asm/pgalloc.h: In function ‘paravirt_pgd_free'': include/asm/pgalloc.h:14: error: parameter name omitted arch/x86/kernel/entry_64.S: In file included from arch/x86/kernel/traps_64.c:51:include/asm/pgalloc.h: In function ‘paravirt_pgd_free'': include/asm/pgalloc.h:14: error: parameter name omitted [...] with this config: http://redhat.com/~mingo/misc/config-Wed_Jun_25_16_37_51_CEST_2008.bad this could easily be some integration mistake on my part, so please double-check the end result. Merging it into tip/master is a bit tricky, due to various interactions. This should work fine if you check out the latest tip/master: git-merge tip/x86/xen-64bit [ ... fix up the trivial merge conflict ... ] i''ve already merged tip/x86/xen-64bit-base topic into master, to make it easier. (there were a few preconditions for the 64-bit Xen patches which arent carried in linux-next - such as the nmi-safe changes.) Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jun-25 18:45 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
On 25/6/08 13:40, "Andi Kleen" <andi@firstfloor.org> wrote:>> to 0xffff880000000000. I have no general justification for this: th > > This will significantly decrease the maximum amount of physical > memory supported by Linux longer term.What does Linux expect to scale up to? Reserving 16 PML4 entries leaves the kernel with 120TB of available ''negative'' address space. Should be plenty, I would think. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2008-Jun-25 19:22 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
On 25/6/08 20:13, "Andi Kleen" <andi@firstfloor.org> wrote:>> What does Linux expect to scale up to? Reserving 16 PML4 entries leaves the >> kernel with 120TB of available ''negative'' address space. Should be plenty, I >> would think. > > There are already (ok non x86-64) systems shipping today with 10+TB of > addressable memory. 100+TB is not that far away with typical > growth rates. Besides there has to be much more in the negative address > space than just direct mapping.There are obviously no x64 boxes around at the moment with >1TB of regular shared memory, since no CPUs have more than 40 address lines. 100+TB RAM is surely years away. If this is a blocker issue, we could just keep PAGE_OFFSET as it is when Xen support is not configured into the kernel. Then those who are concerned about 5% extra headroom at 100TB RAM sizes can configure their kernel appropriately.> So far we always that 64bit Linux can support upto 1/4*max VA memory. > With your change that formula would be not true anymore.Does the formula have any practical significance? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 20:03 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Andi Kleen wrote:> Jeremy Fitzhardinge <jeremy@goop.org> writes: > >> This moves __PAGE_OFFSET up by 16 GDT slots, from 0xffff810000000000 >> > > GDT? PDP? >I meant PGD slots. Or PML4 in x86 terms.>> to 0xffff880000000000. I have no general justification for this: th >> > > This will significantly decrease the maximum amount of physical > memory supported by Linux longer term. >A bit, but not "significantly". We''d already discussed that if the amount of physical starts approaching 2^48 then we''d hope that the chips will grow some more virtual bits. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 20:12 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> * Ingo Molnar <mingo@elte.hu> wrote: > > >> Anyway, that''s all theory - i''ll try out your patchset in -tip to see >> what breaks in practice ;-) >> > > i''ve put the commits (and a good number of dependent commits) into the > new tip/x86/xen-64bit topic branch. > > It quickly broke the build in testing: > > include/asm/pgalloc.h: In function ‘paravirt_pgd_free'': > include/asm/pgalloc.h:14: error: parameter name omitted > arch/x86/kernel/entry_64.S: In file included from > arch/x86/kernel/traps_64.c:51:include/asm/pgalloc.h: In function ‘paravirt_pgd_free'': > include/asm/pgalloc.h:14: error: parameter name omitted >No, looks like my fault. The non-PARAVIRT version of paravirt_pgd_free() is: static inline void paravirt_pgd_free(struct mm_struct *mm, pgd_t *) {} but C doesn''t like missing parameter names, even if unused. This should fix it: diff -r 19b73cc5fdf4 include/asm-x86/pgalloc.h --- a/include/asm-x86/pgalloc.h Wed Jun 25 11:24:41 2008 -0400 +++ b/include/asm-x86/pgalloc.h Wed Jun 25 13:11:56 2008 -0700 @@ -11,7 +11,7 @@ #include <asm/paravirt.h> #else #define paravirt_pgd_alloc(mm) __paravirt_pgd_alloc(mm) -static inline void paravirt_pgd_free(struct mm_struct *mm, pgd_t *) {} +static inline void paravirt_pgd_free(struct mm_struct *mm, pgd_t *pgd) {} static inline void paravirt_alloc_pte(struct mm_struct *mm, unsigned long pfn) {} static inline void paravirt_alloc_pmd(struct mm_struct *mm, unsigned long pfn) {} static inline void paravirt_alloc_pmd_clone(unsigned long pfn, unsigned long clonepfn, _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 21:08 UTC
[Xen-devel] Re: [PATCH 03 of 36] x86: add memory barriers to wrmsr
Arjan van de Ven wrote:> it''s more readable for several of these cases to stick a barrier(); in > front and after it to be honest; that makes it more explicit that > these are deliberate compiler barriers rather than "actual" memory > access... > >I suppose, though I would be inclined to put the barriers in the wrmsr macro itself to act as documentation. Either way, I don''t think there''s any legitimate reason to let the compiler reorder things around a wrmsr, and it should be an inherent property of the macro, rather than relying on ad-hoc barriers where it gets used. After all, that''s a fairly accurate reflection of how the micro-architecture treats wrmsr... J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 23:05 UTC
[Xen-devel] Re: [PATCH 03 of 36] x86: add memory barriers to wrmsr
Arjan van de Ven wrote:> On Wed, 25 Jun 2008 14:08:57 -0700 > Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > >> Arjan van de Ven wrote: >> >>> it''s more readable for several of these cases to stick a barrier(); >>> in front and after it to be honest; that makes it more explicit that >>> these are deliberate compiler barriers rather than "actual" memory >>> access... >>> >>> >>> >> I suppose, though I would be inclined to put the barriers in the >> wrmsr macro itself to act as documentation. >> > > > yeah I meant like this: > > static inline void native_write_msr(unsigned int msr, > unsigned low, unsigned high) > { > barrier(); > asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high)); > barrier(); > } > > or in the same in the thing that calls this. > >OK, we''re in vehement agreement then. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-25 23:37 UTC
[Xen-devel] Re: [PATCH 03 of 36] x86: add memory barriers to wrmsr
H. Peter Anvin wrote:> Arjan van de Ven wrote: >>>> >>> I suppose, though I would be inclined to put the barriers in the >>> wrmsr macro itself to act as documentation. >> >> >> yeah I meant like this: >> >> static inline void native_write_msr(unsigned int msr, >> unsigned low, unsigned high) >> { >> barrier(); >> asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high)); >> barrier(); >> } >> >> or in the same in the thing that calls this. >> > > Actually, I believe the barrier(); before is actually incorrect, since > it would affect the wrmsr() register arguments rather than the wrmsr > instruction itself.How so? What kind of failure do think might occur? Some effect on how the wrmsr arguments are evaluated? barrier() is specifically a compiler optimisation barrier, so the barrier before would prevent the compiler from moving anything logically before the wrmsr to afterwards. That said, making the wrmsr itself a memory clobber may be simpler understand with a comment, rather than separate barriers... J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-26 10:57 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:>> It quickly broke the build in testing: >> >> include/asm/pgalloc.h: In function ‘paravirt_pgd_free'': >> include/asm/pgalloc.h:14: error: parameter name omitted >> arch/x86/kernel/entry_64.S: In file included from >> arch/x86/kernel/traps_64.c:51:include/asm/pgalloc.h: In function >> ‘paravirt_pgd_free'': >> include/asm/pgalloc.h:14: error: parameter name omitted >> > > No, looks like my fault. The non-PARAVIRT version of > paravirt_pgd_free() is: > > static inline void paravirt_pgd_free(struct mm_struct *mm, pgd_t *) {} > > but C doesn''t like missing parameter names, even if unused. > > This should fix it:that fixed the build but now we''ve got a boot crash with this config: time.c: Detected 2010.304 MHz processor. spurious 8259A interrupt: IRQ7. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [<0000000000000000>] PGD 0 Thread overran stack, or stack corrupted Oops: 0010 [1] SMP CPU 0 with: http://redhat.com/~mingo/misc/config-Thu_Jun_26_12_46_46_CEST_2008.bad i''ve pushed out the current tip/xen-64bit branch, so that you can see how things look like at the moment, but i cannot put it into tip/master yet. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-26 10:58 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Ingo Molnar <mingo@elte.hu> wrote:> that fixed the build but now we''ve got a boot crash with this config:plus -tip auto-testing found another build failure with: http://redhat.com/~mingo/misc/config-Thu_Jun_26_12_46_46_CEST_2008.bad arch/x86/kernel/entry_64.S: Assembler messages: arch/x86/kernel/entry_64.S:1201: Error: invalid character ''_'' in mnemonic arch/x86/kernel/entry_64.S:1205: Error: invalid character ''_'' in mnemonic arch/x86/kernel/entry_64.S:1209: Error: invalid character ''_'' in mnemonic arch/x86/kernel/entry_64.S:1213: Error: invalid character ''_'' in mnemonic Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-26 14:28 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > >>> It quickly broke the build in testing: >>> >>> include/asm/pgalloc.h: In function ‘paravirt_pgd_free'': >>> include/asm/pgalloc.h:14: error: parameter name omitted >>> arch/x86/kernel/entry_64.S: In file included from >>> arch/x86/kernel/traps_64.c:51:include/asm/pgalloc.h: In function >>> ‘paravirt_pgd_free'': >>> include/asm/pgalloc.h:14: error: parameter name omitted >>> >>> >> No, looks like my fault. The non-PARAVIRT version of >> paravirt_pgd_free() is: >> >> static inline void paravirt_pgd_free(struct mm_struct *mm, pgd_t *) {} >> >> but C doesn''t like missing parameter names, even if unused. >> >> This should fix it: >> > > that fixed the build but now we''ve got a boot crash with this config: > > time.c: Detected 2010.304 MHz processor. > spurious 8259A interrupt: IRQ7. > BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 > IP: [<0000000000000000>] > PGD 0 > Thread overran stack, or stack corrupted > Oops: 0010 [1] SMP > CPU 0 > > with: > > http://redhat.com/~mingo/misc/config-Thu_Jun_26_12_46_46_CEST_2008.bad >Blerg, a contextless NULL rip. Have you done any bisection on it? Could you try again with the same config, but with "CONFIG_PARAVIRT_DEBUG" enabled as well? That will BUG if it turns out to be trying to call a NULL paravirt-op I''ll try to repro here anyway.> i''ve pushed out the current tip/xen-64bit branch, so that you can see > how things look like at the moment, but i cannot put it into tip/master > yet.Yeah, I was expecting things to break somewhere with this lot :/ Could you add this patch? I don''t think it will help this case, but it''s a bugfix. J Subject: x86_64: use SWAPGS_UNSAFE_STACK in ia32entry.S Use SWAPGS_UNSAFE_STACK in ia32entry.S in the places where the active stack is the usermode stack. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/ia32/ia32entry.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) ==================================================================--- a/arch/x86/ia32/ia32entry.S +++ b/arch/x86/ia32/ia32entry.S @@ -98,7 +98,7 @@ CFI_SIGNAL_FRAME CFI_DEF_CFA rsp,0 CFI_REGISTER rsp,rbp - SWAPGS + SWAPGS_UNSAFE_STACK movq %gs:pda_kernelstack, %rsp addq $(PDA_STACKOFFSET),%rsp /* @@ -210,7 +210,7 @@ CFI_DEF_CFA rsp,PDA_STACKOFFSET CFI_REGISTER rip,rcx /*CFI_REGISTER rflags,r11*/ - SWAPGS + SWAPGS_UNSAFE_STACK movl %esp,%r8d CFI_REGISTER rsp,r8 movq %gs:pda_kernelstack,%rsp _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-26 14:34 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> * Ingo Molnar <mingo@elte.hu> wrote: > > >> that fixed the build but now we''ve got a boot crash with this config: >> > > plus -tip auto-testing found another build failure with: > > http://redhat.com/~mingo/misc/config-Thu_Jun_26_12_46_46_CEST_2008.bad > > arch/x86/kernel/entry_64.S: Assembler messages: > arch/x86/kernel/entry_64.S:1201: Error: invalid character ''_'' in mnemonic > arch/x86/kernel/entry_64.S:1205: Error: invalid character ''_'' in mnemonic > arch/x86/kernel/entry_64.S:1209: Error: invalid character ''_'' in mnemonic > arch/x86/kernel/entry_64.S:1213: Error: invalid character ''_'' in mnemonic > >I''m confused. How did this config both crash and not build? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-26 18:25 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > >>> It quickly broke the build in testing: >>> >>> include/asm/pgalloc.h: In function ‘paravirt_pgd_free'': >>> include/asm/pgalloc.h:14: error: parameter name omitted >>> arch/x86/kernel/entry_64.S: In file included from >>> arch/x86/kernel/traps_64.c:51:include/asm/pgalloc.h: In function >>> ‘paravirt_pgd_free'': >>> include/asm/pgalloc.h:14: error: parameter name omitted >>> >>> >> No, looks like my fault. The non-PARAVIRT version of >> paravirt_pgd_free() is: >> >> static inline void paravirt_pgd_free(struct mm_struct *mm, pgd_t *) {} >> >> but C doesn''t like missing parameter names, even if unused. >> >> This should fix it: >> > > that fixed the build but now we''ve got a boot crash with this config: > > time.c: Detected 2010.304 MHz processor. > spurious 8259A interrupt: IRQ7. > BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 > IP: [<0000000000000000>] > PGD 0 > Thread overran stack, or stack corrupted > Oops: 0010 [1] SMP > CPU 0 >What stage during boot? I''m seeing an initrd problem, but that''s relatively late. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-26 19:02 UTC
[Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> that fixed the build but now we''ve got a boot crash with this config: > > time.c: Detected 2010.304 MHz processor. > spurious 8259A interrupt: IRQ7. > BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 > IP: [<0000000000000000>] > PGD 0 > Thread overran stack, or stack corrupted > Oops: 0010 [1] SMP > CPU 0 >I don''t know if this will fix this bug, but it''s definitely a bugfix. It was trashing random pages by overwriting them with pagetables... Subject: x86_64: memory mapping: don''t trash large pmd mapping Don''t trash a large pmd''s data when mapping physical memory. This is a bugfix for "x86_64: adjust mapping of physical pagetables to work with Xen". Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/mm/init_64.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) ==================================================================--- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -311,7 +311,8 @@ } if (pmd_val(*pmd)) { - phys_pte_update(pmd, address, end); + if (!pmd_large(*pmd)) + phys_pte_update(pmd, address, end); continue; } _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-27 15:56 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Ingo Molnar wrote: >> * Ingo Molnar <mingo@elte.hu> wrote: >> >> >>> that fixed the build but now we''ve got a boot crash with this config: >>> >> >> plus -tip auto-testing found another build failure with: >> >> http://redhat.com/~mingo/misc/config-Thu_Jun_26_12_46_46_CEST_2008.bad >> >> arch/x86/kernel/entry_64.S: Assembler messages: >> arch/x86/kernel/entry_64.S:1201: Error: invalid character ''_'' in mnemonic >> arch/x86/kernel/entry_64.S:1205: Error: invalid character ''_'' in mnemonic >> arch/x86/kernel/entry_64.S:1209: Error: invalid character ''_'' in mnemonic >> arch/x86/kernel/entry_64.S:1213: Error: invalid character ''_'' in mnemonic >> >> > > I''m confused. How did this config both crash and not build?i''m testing on multiple systems in parallel, each is running randconfig kernels. One 64-bit system found a build bug, the other one found a boot crash. This can happen if certain configs build fine (but crash), certain configs dont even build. Each system does a random walk of the config space. I''ve applied your two fixes and i''m re-testing. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-27 16:02 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> i''m testing on multiple systems in parallel, each is running randconfig > kernels. One 64-bit system found a build bug, the other one found a boot > crash. > > This can happen if certain configs build fine (but crash), certain > configs dont even build. Each system does a random walk of the config > space. >Yes, but the URL for both the crash and the build failure pointed to the same config. Is one of them a mistake?> I''ve applied your two fixes and i''m re-testing. >Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-27 16:03 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:>> plus -tip auto-testing found another build failure with: >> >> http://redhat.com/~mingo/misc/config-Thu_Jun_26_12_46_46_CEST_2008.bad >> >> arch/x86/kernel/entry_64.S: Assembler messages: >> arch/x86/kernel/entry_64.S:1201: Error: invalid character ''_'' in mnemonic >> arch/x86/kernel/entry_64.S:1205: Error: invalid character ''_'' in mnemonic >> arch/x86/kernel/entry_64.S:1209: Error: invalid character ''_'' in mnemonic >> arch/x86/kernel/entry_64.S:1213: Error: invalid character ''_'' in mnemonic > > I''m confused. How did this config both crash and not build?this problem still reproduces. i''ve pushed out all fixes into tip/x86/xen-64bit. That branch combined with the config above still reproduces the build failure above. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-27 16:06 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Ingo Molnar wrote: >> i''m testing on multiple systems in parallel, each is running randconfig >> kernels. One 64-bit system found a build bug, the other one found a >> boot crash. >> >> This can happen if certain configs build fine (but crash), certain >> configs dont even build. Each system does a random walk of the config >> space. > > Yes, but the URL for both the crash and the build failure pointed to > the same config. Is one of them a mistake?yeah, i guess so. Right now i only ran into the build failure so there''s hope :) Here''s a config that fails to build for sure: http://redhat.com/~mingo/misc/config-Fri_Jun_27_17_54_32_CEST_2008.bad note, on 32-bit there''s a yet unfixed initrd corruption bug i''ve bisected back to: | 510be56adc4bb9fb229637a8e89268d987263614 is first bad commit | commit 510be56adc4bb9fb229637a8e89268d987263614 | Author: Yinghai Lu <yhlu.kernel@gmail.com> | Date: Tue Jun 24 04:10:47 2008 -0700 | | x86: introduce init_memory_mapping for 32bit so if you see something like that it''s probably not a bug introduced by your changes. (and maybe you''ll see why the above commit is buggy, i havent figured it out yet) Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-27 16:25 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> yeah, i guess so. Right now i only ran into the build failure so there''s > hope :) Here''s a config that fails to build for sure: > > http://redhat.com/~mingo/misc/config-Fri_Jun_27_17_54_32_CEST_2008.bad >Will look at it shortly.> note, on 32-bit there''s a yet unfixed initrd corruption bug i''ve > bisected back to: > > | 510be56adc4bb9fb229637a8e89268d987263614 is first bad commit > | commit 510be56adc4bb9fb229637a8e89268d987263614 > | Author: Yinghai Lu <yhlu.kernel@gmail.com> > | Date: Tue Jun 24 04:10:47 2008 -0700 > | > | x86: introduce init_memory_mapping for 32bit > > so if you see something like that it''s probably not a bug introduced by > your changes. (and maybe you''ll see why the above commit is buggy, i > havent figured it out yet)Well, on a non-PSE system find_early_table_space() will not allocate enough memory for ptes. But I posted the fix for that, and it''s likely you''re using PSE anyway. Nothing pops out from a quick re-read, but it could easily be mis-reserving the ramdisk memory or something. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-27 19:04 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> this problem still reproduces. > > i''ve pushed out all fixes into tip/x86/xen-64bit. That branch combined > with the config above still reproduces the build failure above. >Subject: x86_64: fix non-paravirt compilation Make sure SWAPGS and PARAVIRT_ADJUST_EXCEPTION_FRAME are properly defined when CONFIG_PARAVIRT is off. Fixes Ingo''s build failure: arch/x86/kernel/entry_64.S: Assembler messages: arch/x86/kernel/entry_64.S:1201: Error: invalid character ''_'' in mnemonic arch/x86/kernel/entry_64.S:1205: Error: invalid character ''_'' in mnemonic arch/x86/kernel/entry_64.S:1209: Error: invalid character ''_'' in mnemonic arch/x86/kernel/entry_64.S:1213: Error: invalid character ''_'' in mnemonic Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/irqflags.h | 22 +++++++++++++--------- include/asm-x86/processor.h | 3 --- 2 files changed, 13 insertions(+), 12 deletions(-) ==================================================================--- a/include/asm-x86/irqflags.h +++ b/include/asm-x86/irqflags.h @@ -167,7 +167,20 @@ #define INTERRUPT_RETURN_NMI_SAFE NATIVE_INTERRUPT_RETURN_NMI_SAFE #ifdef CONFIG_X86_64 +#define SWAPGS swapgs +/* + * Currently paravirt can''t handle swapgs nicely when we + * don''t have a stack we can rely on (such as a user space + * stack). So we either find a way around these or just fault + * and emulate if a guest tries to call swapgs directly. + * + * Either way, this is a good way to document that we don''t + * have a reliable stack. x86_64 only. + */ #define SWAPGS_UNSAFE_STACK swapgs + +#define PARAVIRT_ADJUST_EXCEPTION_FRAME /* */ + #define INTERRUPT_RETURN iretq #define USERGS_SYSRET64 \ swapgs; \ @@ -233,15 +246,6 @@ #else #ifdef CONFIG_X86_64 -/* - * Currently paravirt can''t handle swapgs nicely when we - * don''t have a stack we can rely on (such as a user space - * stack). So we either find a way around these or just fault - * and emulate if a guest tries to call swapgs directly. - * - * Either way, this is a good way to document that we don''t - * have a reliable stack. x86_64 only. - */ #define ARCH_LOCKDEP_SYS_EXIT call lockdep_sys_exit_thunk #define ARCH_LOCKDEP_SYS_EXIT_IRQ \ TRACE_IRQS_ON; \ ==================================================================--- a/include/asm-x86/processor.h +++ b/include/asm-x86/processor.h @@ -541,9 +541,6 @@ } #define set_iopl_mask native_set_iopl_mask -#define SWAPGS swapgs - -#define PARAVIRT_ADJUST_EXCEPTION_FRAME /* */ #endif /* CONFIG_PARAVIRT */ /* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-29 08:43 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Subject: x86_64: fix non-paravirt compilationi''ve put tip/x86/xen-64bit into tip/master briefly and it quickly triggered this crash on 64-bit x86: Linux version 2.6.26-rc8-tip-00241-gc6c8cb2-dirty (mingo@dione) (gcc version 4.2.3) #12303 SMP Sun Jun 29 10:30:01 CEST 2008 Command line: root=/dev/sda6 console=ttyS0,115200 earlyprintk=serial,ttyS0,115200 debug initcall_debug apic=verbose sysrq_always_enabled ignore_loglevel selinux=0 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003fff0000 (usable) BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS) BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Centaur CentaurHauls console [earlyser0] enabled debug: ignoring loglevel setting. Entering add_active_range(0, 0x0, 0x9f) 0 entries of 25600 used Entering add_active_range(0, 0x100, 0x3fff0) 1 entries of 25600 used last_pfn = 0x3fff0 max_arch_pfn = 0x3ffffffff init_memory_mapping kernel direct mapping tables up to 3fff0000 @ 8000-a000 PANIC: early exception 0e rip 10:ffffffff804b24e2 error 0 cr2 ffffffffff300000 Pid: 0, comm: swapper Not tainted 2.6.26-rc8-tip-00241-gc6c8cb2-dirty #12303 Call Trace: [<ffffffff80efe196>] early_idt_handler+0x56/0x6a [<ffffffff804b24e2>] ? __memcpy_fromio+0x12/0x30 [<ffffffff804b24d9>] ? __memcpy_fromio+0x9/0x30 [<ffffffff80f32f27>] dmi_scan_machine+0x57/0x1b0 [<ffffffff80f02c15>] setup_arch+0x3f5/0x5e0 [<ffffffff80efedd5>] start_kernel+0x75/0x350 [<ffffffff80efe289>] x86_64_start_reservations+0x89/0xa0 [<ffffffff80efe397>] x86_64_start_kernel+0xf7/0x100 RIP 0x10 with this config: http://redhat.com/~mingo/misc/config-Sun_Jun_29_10_29_11_CEST_2008.bad i''ve saved the merged 2.6.26-rc8-tip-00241-gc6c8cb2-dirty tree into tip/tmp.x86.xen-64bit.Sun_Jun_29_10 and pushed it out, so you can test that exact version. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-30 03:02 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> with this config: > > http://redhat.com/~mingo/misc/config-Sun_Jun_29_10_29_11_CEST_2008.bad > > i''ve saved the merged 2.6.26-rc8-tip-00241-gc6c8cb2-dirty tree into > tip/tmp.x86.xen-64bit.Sun_Jun_29_10 and pushed it out, so you can test > that exact version.Looks like the setup.c unification missed the early_ioremap init from the early_ioremap unification. Unconditionally call early_ioremap_init(). Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> diff -r 5c26177fdf8c arch/x86/kernel/setup.c --- a/arch/x86/kernel/setup.c Sun Jun 29 16:57:52 2008 -0700 +++ b/arch/x86/kernel/setup.c Sun Jun 29 19:57:00 2008 -0700 @@ -523,11 +523,12 @@ memcpy(&boot_cpu_data, &new_cpu_data, sizeof(new_cpu_data)); pre_setup_arch_hook(); early_cpu_init(); - early_ioremap_init(); reserve_setup_data(); #else printk(KERN_INFO "Command line: %s\n", boot_command_line); #endif + + early_ioremap_init(); ROOT_DEV = old_decode_dev(boot_params.hdr.root_dev); screen_info = boot_params.screen_info; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yinghai Lu
2008-Jun-30 04:35 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
On Sun, Jun 29, 2008 at 8:02 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Ingo Molnar wrote: >> >> with this config: >> >> http://redhat.com/~mingo/misc/config-Sun_Jun_29_10_29_11_CEST_2008.bad >> >> i''ve saved the merged 2.6.26-rc8-tip-00241-gc6c8cb2-dirty tree into >> tip/tmp.x86.xen-64bit.Sun_Jun_29_10 and pushed it out, so you can test that >> exact version. > > Looks like the setup.c unification missed the early_ioremap init from the > early_ioremap unification. Unconditionally call early_ioremap_init(). > > Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > > diff -r 5c26177fdf8c arch/x86/kernel/setup.c > --- a/arch/x86/kernel/setup.c Sun Jun 29 16:57:52 2008 -0700 > +++ b/arch/x86/kernel/setup.c Sun Jun 29 19:57:00 2008 -0700 > @@ -523,11 +523,12 @@ > memcpy(&boot_cpu_data, &new_cpu_data, sizeof(new_cpu_data)); > pre_setup_arch_hook(); > early_cpu_init(); > - early_ioremap_init(); > reserve_setup_data(); > #else > printk(KERN_INFO "Command line: %s\n", boot_command_line); > #endif > + > + early_ioremap_init(); > > ROOT_DEV = old_decode_dev(boot_params.hdr.root_dev); > screen_info = boot_params.screen_info;it could be wrong? do we need that for 64 bit? YH _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-30 05:32 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Yinghai Lu wrote:> On Sun, Jun 29, 2008 at 8:02 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > >> Ingo Molnar wrote: >> >>> with this config: >>> >>> http://redhat.com/~mingo/misc/config-Sun_Jun_29_10_29_11_CEST_2008.bad >>> >>> i''ve saved the merged 2.6.26-rc8-tip-00241-gc6c8cb2-dirty tree into >>> tip/tmp.x86.xen-64bit.Sun_Jun_29_10 and pushed it out, so you can test that >>> exact version. >>> >> Looks like the setup.c unification missed the early_ioremap init from the >> early_ioremap unification. Unconditionally call early_ioremap_init(). >> >> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> >> >> diff -r 5c26177fdf8c arch/x86/kernel/setup.c >> --- a/arch/x86/kernel/setup.c Sun Jun 29 16:57:52 2008 -0700 >> +++ b/arch/x86/kernel/setup.c Sun Jun 29 19:57:00 2008 -0700 >> @@ -523,11 +523,12 @@ >> memcpy(&boot_cpu_data, &new_cpu_data, sizeof(new_cpu_data)); >> pre_setup_arch_hook(); >> early_cpu_init(); >> - early_ioremap_init(); >> reserve_setup_data(); >> #else >> printk(KERN_INFO "Command line: %s\n", boot_command_line); >> #endif >> + >> + early_ioremap_init(); >> >> ROOT_DEV = old_decode_dev(boot_params.hdr.root_dev); >> screen_info = boot_params.screen_info; >> > > it could be wrong? do we need that for 64 bit?Yes. I unified the early_ioremap implementations by making 64-bit use the 32-bit one. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-30 08:21 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Ingo Molnar wrote: >> with this config: >> >> http://redhat.com/~mingo/misc/config-Sun_Jun_29_10_29_11_CEST_2008.bad >> >> i''ve saved the merged 2.6.26-rc8-tip-00241-gc6c8cb2-dirty tree into >> tip/tmp.x86.xen-64bit.Sun_Jun_29_10 and pushed it out, so you can test >> that exact version. > > Looks like the setup.c unification missed the early_ioremap init from > the early_ioremap unification. Unconditionally call > early_ioremap_init().applied to tip/x86/unify-setup - thanks Jeremy. I''ve reactived the x86/xen-64bit branch and i''m testing it currently. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-30 09:22 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Ingo Molnar <mingo@elte.hu> wrote:> > * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > > Ingo Molnar wrote: > >> with this config: > >> > >> http://redhat.com/~mingo/misc/config-Sun_Jun_29_10_29_11_CEST_2008.bad > >> > >> i''ve saved the merged 2.6.26-rc8-tip-00241-gc6c8cb2-dirty tree into > >> tip/tmp.x86.xen-64bit.Sun_Jun_29_10 and pushed it out, so you can test > >> that exact version. > > > > Looks like the setup.c unification missed the early_ioremap init from > > the early_ioremap unification. Unconditionally call > > early_ioremap_init(). > > applied to tip/x86/unify-setup - thanks Jeremy. > > I''ve reactived the x86/xen-64bit branch and i''m testing it currently.-tip auto-testing found pagetable corruption (CPA self-test failure): [ 32.956015] CPA self-test: [ 32.958822] 4k 2048 large 508 gb 0 x 2556[ffff880000000000-ffff88003fe00000] miss 0 [ 32.964000] CPA ffff88001d54e000: bad pte 1d4000e3 [ 32.968000] CPA ffff88001d54e000: unexpected level 2 [ 32.972000] CPA ffff880022c5d000: bad pte 22c000e3 [ 32.976000] CPA ffff880022c5d000: unexpected level 2 [ 32.980000] CPA ffff8800200ce000: bad pte 200000e3 [ 32.984000] CPA ffff8800200ce000: unexpected level 2 [ 32.988000] CPA ffff8800210f0000: bad pte 210000e3 config and full log can be found at: http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_11_51_CEST_2008.bad http://redhat.com/~mingo/misc/log-Mon_Jun_30_11_11_51_CEST_2008.bad i''ve pushed that tree out into tip/tmp.xen-64bit.Mon_Jun_30_11_11. The only new item in that tree over a well-tested base is x86/xen-64bit, so i''ve taken it out again. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-30 17:17 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> * Ingo Molnar <mingo@elte.hu> wrote: > > >> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> >> >>> Ingo Molnar wrote: >>> >>>> with this config: >>>> >>>> http://redhat.com/~mingo/misc/config-Sun_Jun_29_10_29_11_CEST_2008.bad >>>> >>>> i''ve saved the merged 2.6.26-rc8-tip-00241-gc6c8cb2-dirty tree into >>>> tip/tmp.x86.xen-64bit.Sun_Jun_29_10 and pushed it out, so you can test >>>> that exact version. >>>> >>> Looks like the setup.c unification missed the early_ioremap init from >>> the early_ioremap unification. Unconditionally call >>> early_ioremap_init(). >>> >> applied to tip/x86/unify-setup - thanks Jeremy. >> >> I''ve reactived the x86/xen-64bit branch and i''m testing it currently. >> > > -tip auto-testing found pagetable corruption (CPA self-test failure): > > [ 32.956015] CPA self-test: > [ 32.958822] 4k 2048 large 508 gb 0 x 2556[ffff880000000000-ffff88003fe00000] miss 0 > [ 32.964000] CPA ffff88001d54e000: bad pte 1d4000e3 > [ 32.968000] CPA ffff88001d54e000: unexpected level 2 > [ 32.972000] CPA ffff880022c5d000: bad pte 22c000e3 > [ 32.976000] CPA ffff880022c5d000: unexpected level 2 > [ 32.980000] CPA ffff8800200ce000: bad pte 200000e3 > [ 32.984000] CPA ffff8800200ce000: unexpected level 2 > [ 32.988000] CPA ffff8800210f0000: bad pte 210000e3 > > config and full log can be found at: > > http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_11_51_CEST_2008.bad >That config doesn''t build for me. When I put it in place and do "make oldconfig" it still asks for lots of config options (which I just set to default). But when I build it fails with: CC arch/x86/kernel/asm-offsets.s In file included from include2/asm/page.h:40, from include2/asm/pda.h:8, from include2/asm/current.h:19, from include2/asm/processor.h:15, from /home/jeremy/hg/xen/paravirt/linux/include/linux/prefetch.h:14, from /home/jeremy/hg/xen/paravirt/linux/include/linux/list.h:6, from /home/jeremy/hg/xen/paravirt/linux/include/linux/module.h:9, from /home/jeremy/hg/xen/paravirt/linux/include/linux/crypto.h:21, from /home/jeremy/hg/xen/paravirt/linux/arch/x86/kernel/asm-offsets_64.c:7, from /home/jeremy/hg/xen/paravirt/linux/arch/x86/kernel/asm-offsets.c:4: include2/asm/page_64.h:46:2: error: #error "CONFIG_PHYSICAL_START must be a multiple of 2MB" make[3]: *** [arch/x86/kernel/asm-offsets.s] Error 1 I can fix that, of course, but it doesn''t give me confidence I''m testing what you are... J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-30 17:57 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> * Ingo Molnar <mingo@elte.hu> wrote: > > >> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> >> >>> Ingo Molnar wrote: >>> >>>> with this config: >>>> >>>> http://redhat.com/~mingo/misc/config-Sun_Jun_29_10_29_11_CEST_2008.bad >>>> >>>> i''ve saved the merged 2.6.26-rc8-tip-00241-gc6c8cb2-dirty tree into >>>> tip/tmp.x86.xen-64bit.Sun_Jun_29_10 and pushed it out, so you can test >>>> that exact version. >>>> >>> Looks like the setup.c unification missed the early_ioremap init from >>> the early_ioremap unification. Unconditionally call >>> early_ioremap_init(). >>> >> applied to tip/x86/unify-setup - thanks Jeremy. >> >> I''ve reactived the x86/xen-64bit branch and i''m testing it currently. >> > > -tip auto-testing found pagetable corruption (CPA self-test failure): > > [ 32.956015] CPA self-test: > [ 32.958822] 4k 2048 large 508 gb 0 x 2556[ffff880000000000-ffff88003fe00000] miss 0 > [ 32.964000] CPA ffff88001d54e000: bad pte 1d4000e3 > [ 32.968000] CPA ffff88001d54e000: unexpected level 2 > [ 32.972000] CPA ffff880022c5d000: bad pte 22c000e3 > [ 32.976000] CPA ffff880022c5d000: unexpected level 2 > [ 32.980000] CPA ffff8800200ce000: bad pte 200000e3 > [ 32.984000] CPA ffff8800200ce000: unexpected level 2 > [ 32.988000] CPA ffff8800210f0000: bad pte 210000e3 > > config and full log can be found at: > > http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_11_51_CEST_2008.bad >This config doesn''t have CONFIG_DEBUG_KERNEL enabled, let alone CONFIG_CPA_DEBUG. I''ve noticed this seems to happen quite a lot: there''s a disconnect between the log file and the config which is supposed to have built the kernel. Is there a bug in your test infrastructure? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-30 18:03 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:>> -tip auto-testing found pagetable corruption (CPA self-test failure): >> >> [ 32.956015] CPA self-test: >> [ 32.958822] 4k 2048 large 508 gb 0 x 2556[ffff880000000000-ffff88003fe00000] miss 0 >> [ 32.964000] CPA ffff88001d54e000: bad pte 1d4000e3 >> [ 32.968000] CPA ffff88001d54e000: unexpected level 2 >> [ 32.972000] CPA ffff880022c5d000: bad pte 22c000e3 >> [ 32.976000] CPA ffff880022c5d000: unexpected level 2 >> [ 32.980000] CPA ffff8800200ce000: bad pte 200000e3 >> [ 32.984000] CPA ffff8800200ce000: unexpected level 2 >> [ 32.988000] CPA ffff8800210f0000: bad pte 210000e3 >> >> config and full log can be found at: >> >> http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_11_51_CEST_2008.bad >> > > This config doesn''t have CONFIG_DEBUG_KERNEL enabled, let alone > CONFIG_CPA_DEBUG. I''ve noticed this seems to happen quite a lot: > there''s a disconnect between the log file and the config which is > supposed to have built the kernel. Is there a bug in your test > infrastructure?sometimes the kernel preceding the currently built one is the buggy one. As i have them saved away, so the right one should be: http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_03_04_CEST_2008.bad Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-30 18:12 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:>> config and full log can be found at: >> >> http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_11_51_CEST_2008.bad >> > > That config doesn''t build for me. When I put it in place and do "make > oldconfig" it still asks for lots of config options (which I just set > to default). But when I build it fails with:try ''make ARCH=i386 oldconfig'' - does it work better that way?> include2/asm/page_64.h:46:2: error: #error "CONFIG_PHYSICAL_START must be a multiple of 2MB" > make[3]: *** [arch/x86/kernel/asm-offsets.s] Error 1 > > I can fix that, of course, but it doesn''t give me confidence I''m > testing what you are...the problem there is that the 32-bit config has: CONFIG_PHYSICAL_START=0x100000 which the 64-bit make oldconfig picked up, but that start address is not valid on 64-bit. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-30 18:36 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > >>> config and full log can be found at: >>> >>> http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_11_51_CEST_2008.bad >>> >>> >> That config doesn''t build for me. When I put it in place and do "make >> oldconfig" it still asks for lots of config options (which I just set >> to default). But when I build it fails with: >> > > try ''make ARCH=i386 oldconfig'' - does it work better that way? >Er, we''re talking about 64-bit here, aren''t we? The log messages are from a 64-bit kernel. Well, it was the wrong config anyway, which I guess is the source of this confusion. (I thought ARCH= to select 32/64 was going away now that the config has the bitsize config?) J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jun-30 18:44 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:>> try ''make ARCH=i386 oldconfig'' - does it work better that way? > > Er, we''re talking about 64-bit here, aren''t we? The log messages are > from a 64-bit kernel. > > Well, it was the wrong config anyway, which I guess is the source of > this confusion.yeah.> (I thought ARCH= to select 32/64 was going away now that the config > has the bitsize config?)yep, correct - but it has to be done carefully - until now people (and tools) could assume that ''make oldconfig'' just creates stuff for their native host architecture. But i agree in principle. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jun-30 23:04 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> -tip auto-testing found pagetable corruption (CPA self-test failure): > > [ 32.956015] CPA self-test: > [ 32.958822] 4k 2048 large 508 gb 0 x 2556[ffff880000000000-ffff88003fe00000] miss 0 > [ 32.964000] CPA ffff88001d54e000: bad pte 1d4000e3 > [ 32.968000] CPA ffff88001d54e000: unexpected level 2 > [ 32.972000] CPA ffff880022c5d000: bad pte 22c000e3 > [ 32.976000] CPA ffff880022c5d000: unexpected level 2 > [ 32.980000] CPA ffff8800200ce000: bad pte 200000e3 > [ 32.984000] CPA ffff8800200ce000: unexpected level 2 > [ 32.988000] CPA ffff8800210f0000: bad pte 210000e3 > > config and full log can be found at: > > http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_11_51_CEST_2008.bad > http://redhat.com/~mingo/misc/log-Mon_Jun_30_11_11_51_CEST_2008.bad > > i''ve pushed that tree out into tip/tmp.xen-64bit.Mon_Jun_30_11_11. The > only new item in that tree over a well-tested base is x86/xen-64bit, so > i''ve taken it out again. >Phew. OK, I''ve worked this out. Short version is that''s it''s a false alarm, and there was no real failure here. Long version: * I changed the code to create the physical mapping pagetables to reuse any existing mapping rather than replace it. Specifically, reusing an pud pointed to by the pgd caused this symptom to appear. * The specific PUD being reused is the one created statically in head_64.S, which creates an initial 1GB mapping. * That mapping doesn''t have _PAGE_GLOBAL set on it, due to the inconsistency between __PAGE_* and PAGE_*. * The CPA test attempts to clear _PAGE_GLOBAL, and then checks to see that the resulting range is 1) shattered into 4k pages, and 2) has no _PAGE_GLOBAL. * However, since it didn''t have _PAGE_GLOBAL on that range to start with, change_page_attr_clear() had nothing to do, and didn''t bother shattering the range, * resulting in the reported messages The simple fix is to set _PAGE_GLOBAL in level2_ident_pgt. An additional fix to make CPA testing more robust by using some other pagetable bit (one of the unused available-to-software ones). This would solve spurious CPA test warnings under Xen which uses _PAGE_GLOBAL for its own purposes (ie, not under guest control). Also, we should revisit the use of _PAGE_GLOBAL in asm-x86/pgtable.h, and use it consistently, and drop MAKE_GLOBAL. The first time I proposed it it caused breakages in the very early CPA code; with luck that''s all fixed now. Anyway, the simple fix below. I''ll put together RFC patches for the other suggestions. I also split the originating patch into tiny, tiny bisectable pieces. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/kernel/head_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ==================================================================--- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -374,7 +374,7 @@ /* Since I easily can, map the first 1G. * Don''t set NX because code runs from these pages. */ - PMDS(0, __PAGE_KERNEL_LARGE_EXEC, PTRS_PER_PMD) + PMDS(0, __PAGE_KERNEL_LARGE_EXEC | _PAGE_GLOBAL, PTRS_PER_PMD) NEXT_PAGE(level2_kernel_pgt) /* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jul-01 08:52 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Ingo Molnar wrote: >> -tip auto-testing found pagetable corruption (CPA self-test failure): >> >> [ 32.956015] CPA self-test: >> [ 32.958822] 4k 2048 large 508 gb 0 x 2556[ffff880000000000-ffff88003fe00000] miss 0 >> [ 32.964000] CPA ffff88001d54e000: bad pte 1d4000e3 >> [ 32.968000] CPA ffff88001d54e000: unexpected level 2 >> [ 32.972000] CPA ffff880022c5d000: bad pte 22c000e3 >> [ 32.976000] CPA ffff880022c5d000: unexpected level 2 >> [ 32.980000] CPA ffff8800200ce000: bad pte 200000e3 >> [ 32.984000] CPA ffff8800200ce000: unexpected level 2 >> [ 32.988000] CPA ffff8800210f0000: bad pte 210000e3 >> >> config and full log can be found at: >> >> http://redhat.com/~mingo/misc/config-Mon_Jun_30_11_11_51_CEST_2008.bad >> http://redhat.com/~mingo/misc/log-Mon_Jun_30_11_11_51_CEST_2008.bad >> >> i''ve pushed that tree out into tip/tmp.xen-64bit.Mon_Jun_30_11_11. The >> only new item in that tree over a well-tested base is x86/xen-64bit, so >> i''ve taken it out again. >> > > Phew. OK, I''ve worked this out. Short version is that''s it''s a false > alarm, and there was no real failure here. Long version: > > * I changed the code to create the physical mapping pagetables to > reuse any existing mapping rather than replace it. Specifically, > reusing an pud pointed to by the pgd caused this symptom to appear. > * The specific PUD being reused is the one created statically in > head_64.S, which creates an initial 1GB mapping. > * That mapping doesn''t have _PAGE_GLOBAL set on it, due to the > inconsistency between __PAGE_* and PAGE_*. > * The CPA test attempts to clear _PAGE_GLOBAL, and then checks to > see that the resulting range is 1) shattered into 4k pages, and 2) > has no _PAGE_GLOBAL. > * However, since it didn''t have _PAGE_GLOBAL on that range to start > with, change_page_attr_clear() had nothing to do, and didn''t > bother shattering the range, > * resulting in the reported messages > > The simple fix is to set _PAGE_GLOBAL in level2_ident_pgt. > > An additional fix to make CPA testing more robust by using some other > pagetable bit (one of the unused available-to-software ones). This > would solve spurious CPA test warnings under Xen which uses _PAGE_GLOBAL > for its own purposes (ie, not under guest control). > > Also, we should revisit the use of _PAGE_GLOBAL in asm-x86/pgtable.h, > and use it consistently, and drop MAKE_GLOBAL. The first time I > proposed it it caused breakages in the very early CPA code; with luck > that''s all fixed now. > > Anyway, the simple fix below. [...]great - i''ve applied your fix and re-integrated x86/xen-64bit, it''s under testing now. (no problems so far)> [...] I''ll put together RFC patches for the other suggestions. I also > split the originating patch into tiny, tiny bisectable pieces.cool! :) Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jul-01 09:21 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Ingo Molnar <mingo@elte.hu> wrote:> great - i''ve applied your fix and re-integrated x86/xen-64bit, it''s > under testing now. (no problems so far)hm, -tip testing still triggers a 64-bit bootup crash: [ 0.000000] init_memory_mapping [ 0.000000] kernel direct mapping tables up to 3fff0000 @ 8000-a000 PANIC: early exception 0e rip 10:ffffffff80418f81 error 0 cr2 ffffffffff300000 [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.26-rc8-tip #13363 [ 0.000000] [ 0.000000] Call Trace: [ 0.000000] [<ffffffff807f088b>] ? init_memory_mapping+0x341/0x56b [ 0.000000] [<ffffffff80dba19f>] early_idt_handler+0x5f/0x73 [ 0.000000] [<ffffffff80418f81>] ? __memcpy_fromio+0xd/0x1e [ 0.000000] [<ffffffff80de238a>] dmi_scan_machine+0x41/0x19b [ 0.000000] [<ffffffff80dbeba8>] setup_arch+0x46d/0x5d8 [ 0.000000] [<ffffffff802896a0>] ? kernel_text_unlock+0x10/0x12 [ 0.000000] [<ffffffff80263b86>] ? raw_notifier_chain_register+0x9/0xb [ 0.000000] [<ffffffff80dba140>] ? early_idt_handler+0x0/0x73 [ 0.000000] [<ffffffff80dbac5a>] start_kernel+0xf4/0x3b3 [ 0.000000] [<ffffffff80dba140>] ? early_idt_handler+0x0/0x73 [ 0.000000] [<ffffffff80dba2a4>] x86_64_start_reservations+0xa9/0xad [ 0.000000] [<ffffffff80dba3b8>] x86_64_start_kernel+0x110/0x11f [ 0.000000] http://redhat.com/~mingo/misc/crash.log-Tue_Jul__1_10_55_47_CEST_2008.bad http://redhat.com/~mingo/misc/config-Tue_Jul__1_10_55_47_CEST_2008.bad Excluding the x86/xen-64bit topic solves the problem. It triggered on two 64-bit machines so it seems readily reproducible with that config. i''ve pushed the failing tree out to tip/tmp.xen-64bit.Tue_Jul__1_10_55 Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jul-01 16:10 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> http://redhat.com/~mingo/misc/crash.log-Tue_Jul__1_10_55_47_CEST_2008.bad > http://redhat.com/~mingo/misc/config-Tue_Jul__1_10_55_47_CEST_2008.bad > > Excluding the x86/xen-64bit topic solves the problem. > > It triggered on two 64-bit machines so it seems readily reproducible > with that config. > > i''ve pushed the failing tree out to tip/tmp.xen-64bit.Tue_Jul__1_10_55 >Looks like you lost the other patch to put the early_ioremap_init in the right place... J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jul-01 16:14 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> Excluding the x86/xen-64bit topic solves the problem. > > It triggered on two 64-bit machines so it seems readily reproducible > with that config. > > i''ve pushed the failing tree out to tip/tmp.xen-64bit.Tue_Jul__1_10_55 >The patch to fix this is on tip/x86/unify-setup: "x86: setup_arch() && early_ioremap_init()". Logically that patch should probably be in the xen64 branch, since it''s only meaningful with the early_ioremap unification. J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jul-01 20:31 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Ingo Molnar wrote: >> Excluding the x86/xen-64bit topic solves the problem. >> >> It triggered on two 64-bit machines so it seems readily reproducible >> with that config. >> >> i''ve pushed the failing tree out to tip/tmp.xen-64bit.Tue_Jul__1_10_55 >> > > The patch to fix this is on tip/x86/unify-setup: "x86: setup_arch() && > early_ioremap_init()". Logically that patch should probably be in the > xen64 branch, since it''s only meaningful with the early_ioremap > unification.ah, indeed - it was missing from tip/master due to: | commit ac998c259605741efcfbd215533b379970ba1d9f | Author: Ingo Molnar <mingo@elte.hu> | Date: Mon Jun 30 12:01:31 2008 +0200 | | Revert "x86: setup_arch() && early_ioremap_init()" | | This reverts commit 181b3601a1a7d2ac3ace6b23cb3204450a4f9a27. because that change needed the other changes from xen-64bit. will retry tomorrow. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jul-03 09:10 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Ingo Molnar <mingo@elte.hu> wrote:> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > > Ingo Molnar wrote: > >> Excluding the x86/xen-64bit topic solves the problem. > >> > >> It triggered on two 64-bit machines so it seems readily reproducible > >> with that config. > >> > >> i''ve pushed the failing tree out to tip/tmp.xen-64bit.Tue_Jul__1_10_55 > >> > > > > The patch to fix this is on tip/x86/unify-setup: "x86: setup_arch() && > > early_ioremap_init()". Logically that patch should probably be in the > > xen64 branch, since it''s only meaningful with the early_ioremap > > unification. > > ah, indeed - it was missing from tip/master due to: > > | commit ac998c259605741efcfbd215533b379970ba1d9f > | Author: Ingo Molnar <mingo@elte.hu> > | Date: Mon Jun 30 12:01:31 2008 +0200 > | > | Revert "x86: setup_arch() && early_ioremap_init()" > | > | This reverts commit 181b3601a1a7d2ac3ace6b23cb3204450a4f9a27. > > because that change needed the other changes from xen-64bit. > > will retry tomorrow.ok, i''ve re-added x86/xen-64bit and it''s looking good in testing so far. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jul-03 15:47 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Ingo Molnar wrote:> * Ingo Molnar <mingo@elte.hu> wrote: > > >> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> >> >>> Ingo Molnar wrote: >>> >>>> Excluding the x86/xen-64bit topic solves the problem. >>>> >>>> It triggered on two 64-bit machines so it seems readily reproducible >>>> with that config. >>>> >>>> i''ve pushed the failing tree out to tip/tmp.xen-64bit.Tue_Jul__1_10_55 >>>> >>>> >>> The patch to fix this is on tip/x86/unify-setup: "x86: setup_arch() && >>> early_ioremap_init()". Logically that patch should probably be in the >>> xen64 branch, since it''s only meaningful with the early_ioremap >>> unification. >>> >> ah, indeed - it was missing from tip/master due to: >> >> | commit ac998c259605741efcfbd215533b379970ba1d9f >> | Author: Ingo Molnar <mingo@elte.hu> >> | Date: Mon Jun 30 12:01:31 2008 +0200 >> | >> | Revert "x86: setup_arch() && early_ioremap_init()" >> | >> | This reverts commit 181b3601a1a7d2ac3ace6b23cb3204450a4f9a27. >> >> because that change needed the other changes from xen-64bit. >> >> will retry tomorrow. >> > > ok, i''ve re-added x86/xen-64bit and it''s looking good in testing so far. >Great. I''m hoping this stuff will be OK for the next merge, so I''m primed for fast turnaround bugfixes ;) Also, I have the series of followup patches to actually implement 64-bit Xen which have much less impact on the non-Xen parts of the tree. I''ll probably mail them out later today. Thanks, J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yinghai Lu
2008-Jul-03 18:20 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
On Thu, Jul 3, 2008 at 2:10 AM, Ingo Molnar <mingo@elte.hu> wrote:> > * Ingo Molnar <mingo@elte.hu> wrote: > >> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> >> > Ingo Molnar wrote: >> >> Excluding the x86/xen-64bit topic solves the problem. >> >> >> >> It triggered on two 64-bit machines so it seems readily reproducible >> >> with that config. >> >> >> >> i''ve pushed the failing tree out to tip/tmp.xen-64bit.Tue_Jul__1_10_55 >> >> >> > >> > The patch to fix this is on tip/x86/unify-setup: "x86: setup_arch() && >> > early_ioremap_init()". Logically that patch should probably be in the >> > xen64 branch, since it''s only meaningful with the early_ioremap >> > unification. >> >> ah, indeed - it was missing from tip/master due to: >> >> | commit ac998c259605741efcfbd215533b379970ba1d9f >> | Author: Ingo Molnar <mingo@elte.hu> >> | Date: Mon Jun 30 12:01:31 2008 +0200 >> | >> | Revert "x86: setup_arch() && early_ioremap_init()" >> | >> | This reverts commit 181b3601a1a7d2ac3ace6b23cb3204450a4f9a27. >> >> because that change needed the other changes from xen-64bit. >> >> will retry tomorrow. > > ok, i''ve re-added x86/xen-64bit and it''s looking good in testing so far. >got [ffffe20000000000-ffffe27fffffffff] PGD ->ffff88000128a000 on node 0 [ffffe20000000000-ffffe2003fffffff] PUD ->ffff88000128b000 on node 0 [ffffe20000000000-ffffe200003fffff] PMD -> [ffff880001400000-ffff8800017fffff] on node 0 [ffffe20000200000-ffffe200005fffff] PMD -> [ffff880001600000-ffff8800019fffff] on node 0 [ffffe20000400000-ffffe200007fffff] PMD -> [ffff880001800000-ffff880001bfffff] on node 0 [ffffe20000600000-ffffe200009fffff] PMD -> [ffff880001a00000-ffff880001dfffff] on node 0 [ffffe20000800000-ffffe20000bfffff] PMD -> [ffff880001c00000-ffff880001ffffff] on node 0 [ffffe20000a00000-ffffe20000dfffff] PMD -> [ffff880001e00000-ffff8800021fffff] on node 0 [ffffe20000c00000-ffffe20000ffffff] PMD -> [ffff880002000000-ffff8800023fffff] on node 0 [ffffe20000e00000-ffffe200011fffff] PMD -> [ffff880002200000-ffff8800025fffff] on node 0 [ffffe20001000000-ffffe200013fffff] PMD -> [ffff880002400000-ffff8800027fffff] on node 0 [ffffe20001200000-ffffe200015fffff] PMD -> [ffff880002600000-ffff8800029fffff] on node 0 [ffffe20001400000-ffffe200017fffff] PMD -> [ffff880002800000-ffff880002bfffff] on node 0 [ffffe20001600000-ffffe200019fffff] PMD -> [ffff880002a00000-ffff880002dfffff] on node 0 [ffffe20001800000-ffffe20001bfffff] PMD -> [ffff880002c00000-ffff880002ffffff] on node 0 [ffffe20001a00000-ffffe20001dfffff] PMD -> [ffff880002e00000-ffff8800031fffff] on node 0 [ffffe20001c00000-ffffe20001ffffff] PMD -> [ffff880003000000-ffff8800033fffff] on node 0 [ffffe20001e00000-ffffe200021fffff] PMD -> [ffff880003200000-ffff8800035fffff] on node 0 [ffffe20002000000-ffffe200023fffff] PMD -> [ffff880003400000-ffff8800037fffff] on node 0 [ffffe20002200000-ffffe200025fffff] PMD -> [ffff880003600000-ffff8800039fffff] on node 0 [ffffe20002400000-ffffe200027fffff] PMD -> [ffff880003800000-ffff880003bfffff] on node 0 [ffffe20002600000-ffffe200029fffff] PMD -> [ffff880003a00000-ffff880003dfffff] on node 0 [ffffe20002800000-ffffe20002bfffff] PMD -> [ffff880003c00000-ffff880003ffffff] on node 0 [ffffe20002a00000-ffffe20002dfffff] PMD -> [ffff880003e00000-ffff8800041fffff] on node 0 [ffffe20002c00000-ffffe20002ffffff] PMD -> [ffff880004000000-ffff8800043fffff] on node 0 [ffffe20002e00000-ffffe200039fffff] PMD -> [ffff880004200000-ffff8800045fffff] on node 0 [ffffe20003800000-ffffe20003bfffff] PMD -> [ffff880004400000-ffff8800047fffff] on node 0 [ffffe20003a00000-ffffe20003dfffff] PMD -> [ffff880004600000-ffff8800049fffff] on node 0 [ffffe20003c00000-ffffe20003ffffff] PMD -> [ffff880004800000-ffff880004bfffff] on node 0 [ffffe20003e00000-ffffe200041fffff] PMD -> [ffff880004a00000-ffff880004dfffff] on node 0 [ffffe20004000000-ffffe200043fffff] PMD -> [ffff880004c00000-ffff880004ffffff] on node 0 [ffffe20004200000-ffffe200045fffff] PMD -> [ffff880004e00000-ffff8800051fffff] on node 0 [ffffe20004400000-ffffe200047fffff] PMD -> [ffff880005000000-ffff8800053fffff] on node 0 [ffffe20004600000-ffffe200049fffff] PMD -> [ffff880005200000-ffff8800055fffff] on node 0 [ffffe20004800000-ffffe20004bfffff] PMD -> [ffff880005400000-ffff8800057fffff] on node 0 [ffffe20004a00000-ffffe20004dfffff] PMD -> [ffff880005600000-ffff8800059fffff] on node 0 [ffffe20004c00000-ffffe20004ffffff] PMD -> [ffff880005800000-ffff880005bfffff] on node 0 [ffffe20004e00000-ffffe200051fffff] PMD -> [ffff880005a00000-ffff880005dfffff] on node 0 [ffffe20005000000-ffffe200053fffff] PMD -> [ffff880005c00000-ffff880005ffffff] on node 0 [ffffe20005200000-ffffe200055fffff] PMD -> [ffff880005e00000-ffff8800061fffff] on node 0 [ffffe20005400000-ffffe200057fffff] PMD -> [ffff880006000000-ffff8800063fffff] on node 0 [ffffe20005600000-ffffe200059fffff] PMD -> [ffff880006200000-ffff8800065fffff] on node 0 [ffffe20005800000-ffffe20005bfffff] PMD -> [ffff880006400000-ffff8800067fffff] on node 0 [ffffe20005a00000-ffffe20005dfffff] PMD -> [ffff880006600000-ffff8800069fffff] on node 0 [ffffe20005c00000-ffffe20005ffffff] PMD -> [ffff880006800000-ffff880006bfffff] on node 0 [ffffe20005e00000-ffffe200061fffff] PMD -> [ffff880006a00000-ffff880006dfffff] on node 0 [ffffe20006000000-ffffe200063fffff] PMD -> [ffff880006c00000-ffff880006ffffff] on node 0 [ffffe20006200000-ffffe200065fffff] PMD -> [ffff880006e00000-ffff8800071fffff] on node 0 [ffffe20006400000-ffffe200067fffff] PMD -> [ffff880007000000-ffff8800073fffff] on node 0 [ffffe20006600000-ffffe200069fffff] PMD -> [ffff880007200000-ffff8800075fffff] on node 0 [ffffe20006800000-ffffe20006bfffff] PMD -> [ffff880007400000-ffff8800077fffff] on node 0 [ffffe20006a00000-ffffe20006dfffff] PMD -> [ffff880007600000-ffff8800079fffff] on node 0 [ffffe20006c00000-ffffe20006ffffff] PMD -> [ffff880007800000-ffff880007bfffff] on node 0 [ffffe20006e00000-ffffe200071fffff] PMD -> [ffff880007a00000-ffff880007dfffff] on node 0 [ffffe20007000000-ffffe200073fffff] PMD -> [ffff880007c00000-ffff880007ffffff] on node 0 [ffffe20007200000-ffffe200075fffff] PMD -> [ffff880007e00000-ffff8800081fffff] on node 0 [ffffe20007400000-ffffe200077fffff] PMD -> [ffff880008000000-ffff8800083fffff] on node 0 [ffffe20007600000-ffffe200079fffff] PMD -> [ffff880008200000-ffff8800085fffff] on node 0 [ffffe200078c0000-ffffe200079fffff] potential offnode page_structs [ffffe20007800000-ffffe20007bfffff] PMD -> [ffff880008400000-ffff8802283fffff] on node 0 [ffffe20007a00000-ffffe20007dfffff] PMD -> [ffff880228200000-ffff8802285fffff] on node 1 [ffffe20007c00000-ffffe20007ffffff] PMD -> [ffff880228400000-ffff8802287fffff] on node 1 [ffffe20007e00000-ffffe200081fffff] PMD -> [ffff880228600000-ffff8802289fffff] on node 1 [ffffe20008000000-ffffe200083fffff] PMD -> [ffff880228800000-ffff880228bfffff] on node 1 [ffffe20008200000-ffffe200085fffff] PMD -> [ffff880228a00000-ffff880228dfffff] on node 1 [ffffe20008400000-ffffe200087fffff] PMD -> [ffff880228c00000-ffff880228ffffff] on node 1 [ffffe20008600000-ffffe200089fffff] PMD -> [ffff880228e00000-ffff8802291fffff] on node 1 [ffffe20008800000-ffffe20008bfffff] PMD -> [ffff880229000000-ffff8802293fffff] on node 1 [ffffe20008a00000-ffffe20008dfffff] PMD -> [ffff880229200000-ffff8802295fffff] on node 1 [ffffe20008c00000-ffffe20008ffffff] PMD -> [ffff880229400000-ffff8802297fffff] on node 1 [ffffe20008e00000-ffffe200091fffff] PMD -> [ffff880229600000-ffff8802299fffff] on node 1 [ffffe20009000000-ffffe200093fffff] PMD -> [ffff880229800000-ffff880229bfffff] on node 1 [ffffe20009200000-ffffe200095fffff] PMD -> [ffff880229a00000-ffff880229dfffff] on node 1 [ffffe20009400000-ffffe200097fffff] PMD -> [ffff880229c00000-ffff880229ffffff] on node 1 [ffffe20009600000-ffffe200099fffff] PMD -> [ffff880229e00000-ffff88022a1fffff] on node 1 [ffffe20009800000-ffffe20009bfffff] PMD -> [ffff88022a000000-ffff88022a3fffff] on node 1 [ffffe20009a00000-ffffe20009dfffff] PMD -> [ffff88022a200000-ffff88022a5fffff] on node 1 [ffffe20009c00000-ffffe20009ffffff] PMD -> [ffff88022a400000-ffff88022a7fffff] on node 1 [ffffe20009e00000-ffffe2000a1fffff] PMD -> [ffff88022a600000-ffff88022a9fffff] on node 1 [ffffe2000a000000-ffffe2000a3fffff] PMD -> [ffff88022a800000-ffff88022abfffff] on node 1 [ffffe2000a200000-ffffe2000a5fffff] PMD -> [ffff88022aa00000-ffff88022adfffff] on node 1 [ffffe2000a400000-ffffe2000a7fffff] PMD -> [ffff88022ac00000-ffff88022affffff] on node 1 [ffffe2000a600000-ffffe2000a9fffff] PMD -> [ffff88022ae00000-ffff88022b1fffff] on node 1 [ffffe2000a800000-ffffe2000abfffff] PMD -> [ffff88022b000000-ffff88022b3fffff] on node 1 [ffffe2000aa00000-ffffe2000adfffff] PMD -> [ffff88022b200000-ffff88022b5fffff] on node 1 [ffffe2000ac00000-ffffe2000affffff] PMD -> [ffff88022b400000-ffff88022b7fffff] on node 1 [ffffe2000ae00000-ffffe2000b1fffff] PMD -> [ffff88022b600000-ffff88022b9fffff] on node 1 [ffffe2000b000000-ffffe2000b3fffff] PMD -> [ffff88022b800000-ffff88022bbfffff] on node 1 [ffffe2000b200000-ffffe2000b5fffff] PMD -> [ffff88022ba00000-ffff88022bdfffff] on node 1 [ffffe2000b400000-ffffe2000b7fffff] PMD -> [ffff88022bc00000-ffff88022bffffff] on node 1 [ffffe2000b600000-ffffe2000b9fffff] PMD -> [ffff88022be00000-ffff88022c1fffff] on node 1 [ffffe2000b800000-ffffe2000bbfffff] PMD -> [ffff88022c000000-ffff88022c3fffff] on node 1 [ffffe2000ba00000-ffffe2000bdfffff] PMD -> [ffff88022c200000-ffff88022c5fffff] on node 1 [ffffe2000bc00000-ffffe2000bffffff] PMD -> [ffff88022c400000-ffff88022c7fffff] on node 1 [ffffe2000be00000-ffffe2000c1fffff] PMD -> [ffff88022c600000-ffff88022c9fffff] on node 1 [ffffe2000c000000-ffffe2000c3fffff] PMD -> [ffff88022c800000-ffff88022cbfffff] on node 1 [ffffe2000c200000-ffffe2000c5fffff] PMD -> [ffff88022ca00000-ffff88022cdfffff] on node 1 [ffffe2000c400000-ffffe2000c7fffff] PMD -> [ffff88022cc00000-ffff88022cffffff] on node 1 [ffffe2000c600000-ffffe2000c9fffff] PMD -> [ffff88022ce00000-ffff88022d1fffff] on node 1 [ffffe2000c800000-ffffe2000cbfffff] PMD -> [ffff88022d000000-ffff88022d3fffff] on node 1 [ffffe2000ca00000-ffffe2000cdfffff] PMD -> [ffff88022d200000-ffff88022d5fffff] on node 1 [ffffe2000cc00000-ffffe2000cffffff] PMD -> [ffff88022d400000-ffff88022d7fffff] on node 1 [ffffe2000ce00000-ffffe2000d1fffff] PMD -> [ffff88022d600000-ffff88022d9fffff] on node 1 [ffffe2000d000000-ffffe2000d3fffff] PMD -> [ffff88022d800000-ffff88022dbfffff] on node 1 [ffffe2000d200000-ffffe2000d5fffff] PMD -> [ffff88022da00000-ffff88022ddfffff] on node 1 [ffffe2000d400000-ffffe2000d7fffff] PMD -> [ffff88022dc00000-ffff88022dffffff] on node 1 [ffffe2000d600000-ffffe2000d9fffff] PMD -> [ffff88022de00000-ffff88022e1fffff] on node 1 [ffffe2000d800000-ffffe2000dbfffff] PMD -> [ffff88022e000000-ffff88022e3fffff] on node 1 [ffffe2000da00000-ffffe2000ddfffff] PMD -> [ffff88022e200000-ffff88022e5fffff] on node 1 [ffffe2000dc00000-ffffe2000dffffff] PMD -> [ffff88022e400000-ffff88022e7fffff] on node 1 [ffffe2000de00000-ffffe2000e1fffff] PMD -> [ffff88022e600000-ffff88022e9fffff] on node 1 [ffffe2000e000000-ffffe2000e3fffff] PMD -> [ffff88022e800000-ffff88022ebfffff] on node 1 [ffffe2000e200000-ffffe2000e5fffff] PMD -> [ffff88022ea00000-ffff88022edfffff] on node 1 [ffffe2000e400000-ffffe2000e7fffff] PMD -> [ffff88022ec00000-ffff88022effffff] on node 1 [ffffe2000e600000-ffffe2000e9fffff] PMD -> [ffff88022ee00000-ffff88022f1fffff] on node 1 [ffffe2000e800000-ffffe2000e9fffff] PMD -> [ffff88022f000000-ffff88022f1fffff] on node 1 should have [ffffe20000000000-ffffe27fffffffff] PGD ->ffff8100011ce000 on node 0 [ffffe20000000000-ffffe2003fffffff] PUD ->ffff8100011cf000 on node 0 [ffffe200078c0000-ffffe200079fffff] potential offnode page_structs [ffffe20000000000-ffffe200079fffff] PMD -> [ffff810001200000-ffff8100083fffff] on node 0 [ffffe20007a00000-ffffe2000e9fffff] PMD -> [ffff810228200000-ffff81022f1fffff] on node 1 YH _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jul-03 18:25 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Yinghai Lu wrote:> On Thu, Jul 3, 2008 at 2:10 AM, Ingo Molnar <mingo@elte.hu> wrote: > >> * Ingo Molnar <mingo@elte.hu> wrote: >> >> >>> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: >>> >>> >>>> Ingo Molnar wrote: >>>> >>>>> Excluding the x86/xen-64bit topic solves the problem. >>>>> >>>>> It triggered on two 64-bit machines so it seems readily reproducible >>>>> with that config. >>>>> >>>>> i''ve pushed the failing tree out to tip/tmp.xen-64bit.Tue_Jul__1_10_55 >>>>> >>>>> >>>> The patch to fix this is on tip/x86/unify-setup: "x86: setup_arch() && >>>> early_ioremap_init()". Logically that patch should probably be in the >>>> xen64 branch, since it''s only meaningful with the early_ioremap >>>> unification. >>>> >>> ah, indeed - it was missing from tip/master due to: >>> >>> | commit ac998c259605741efcfbd215533b379970ba1d9f >>> | Author: Ingo Molnar <mingo@elte.hu> >>> | Date: Mon Jun 30 12:01:31 2008 +0200 >>> | >>> | Revert "x86: setup_arch() && early_ioremap_init()" >>> | >>> | This reverts commit 181b3601a1a7d2ac3ace6b23cb3204450a4f9a27. >>> >>> because that change needed the other changes from xen-64bit. >>> >>> will retry tomorrow. >>> >> ok, i''ve re-added x86/xen-64bit and it''s looking good in testing so far. >> >> > > got > [ffffe20000000000-ffffe27fffffffff] PGD ->ffff88000128a000 on node 0 > [ffffe20000000000-ffffe2003fffffff] PUD ->ffff88000128b000 on node 0 > [ffffe20000000000-ffffe200003fffff] PMD -> > [ffff880001400000-ffff8800017fffff] on node 0 > [ffffe20000200000-ffffe200005fffff] PMD -> > [ffff880001600000-ffff8800019fffff] on node 0 > [ffffe20000400000-ffffe200007fffff] PMD -> > [ffff880001800000-ffff880001bfffff] on node 0 > [ffffe20000600000-ffffe200009fffff] PMD -> > [ffff880001a00000-ffff880001dfffff] on node 0 > [ffffe20000800000-ffffe20000bfffff] PMD -> > [ffff880001c00000-ffff880001ffffff] on node 0 > [ffffe20000a00000-ffffe20000dfffff] PMD -> > [ffff880001e00000-ffff8800021fffff] on node 0 > [ffffe20000c00000-ffffe20000ffffff] PMD -> > [ffff880002000000-ffff8800023fffff] on node 0 > [ffffe20000e00000-ffffe200011fffff] PMD -> > [ffff880002200000-ffff8800025fffff] on node 0 > [ffffe20001000000-ffffe200013fffff] PMD -> > [ffff880002400000-ffff8800027fffff] on node 0 > [ffffe20001200000-ffffe200015fffff] PMD -> > [ffff880002600000-ffff8800029fffff] on node 0 > [ffffe20001400000-ffffe200017fffff] PMD -> > [ffff880002800000-ffff880002bfffff] on node 0 > [ffffe20001600000-ffffe200019fffff] PMD -> > [ffff880002a00000-ffff880002dfffff] on node 0 > [ffffe20001800000-ffffe20001bfffff] PMD -> > [ffff880002c00000-ffff880002ffffff] on node 0 > [ffffe20001a00000-ffffe20001dfffff] PMD -> > [ffff880002e00000-ffff8800031fffff] on node 0 > [ffffe20001c00000-ffffe20001ffffff] PMD -> > [ffff880003000000-ffff8800033fffff] on node 0 > [ffffe20001e00000-ffffe200021fffff] PMD -> > [ffff880003200000-ffff8800035fffff] on node 0 > [ffffe20002000000-ffffe200023fffff] PMD -> > [ffff880003400000-ffff8800037fffff] on node 0 > [ffffe20002200000-ffffe200025fffff] PMD -> > [ffff880003600000-ffff8800039fffff] on node 0 > [ffffe20002400000-ffffe200027fffff] PMD -> > [ffff880003800000-ffff880003bfffff] on node 0 > [ffffe20002600000-ffffe200029fffff] PMD -> > [ffff880003a00000-ffff880003dfffff] on node 0 > [ffffe20002800000-ffffe20002bfffff] PMD -> > [ffff880003c00000-ffff880003ffffff] on node 0 > [ffffe20002a00000-ffffe20002dfffff] PMD -> > [ffff880003e00000-ffff8800041fffff] on node 0 > [ffffe20002c00000-ffffe20002ffffff] PMD -> > [ffff880004000000-ffff8800043fffff] on node 0 > [ffffe20002e00000-ffffe200039fffff] PMD -> > [ffff880004200000-ffff8800045fffff] on node 0 > [ffffe20003800000-ffffe20003bfffff] PMD -> > [ffff880004400000-ffff8800047fffff] on node 0 > [ffffe20003a00000-ffffe20003dfffff] PMD -> > [ffff880004600000-ffff8800049fffff] on node 0 > [ffffe20003c00000-ffffe20003ffffff] PMD -> > [ffff880004800000-ffff880004bfffff] on node 0 > [ffffe20003e00000-ffffe200041fffff] PMD -> > [ffff880004a00000-ffff880004dfffff] on node 0 > [ffffe20004000000-ffffe200043fffff] PMD -> > [ffff880004c00000-ffff880004ffffff] on node 0 > [ffffe20004200000-ffffe200045fffff] PMD -> > [ffff880004e00000-ffff8800051fffff] on node 0 > [ffffe20004400000-ffffe200047fffff] PMD -> > [ffff880005000000-ffff8800053fffff] on node 0 > [ffffe20004600000-ffffe200049fffff] PMD -> > [ffff880005200000-ffff8800055fffff] on node 0 > [ffffe20004800000-ffffe20004bfffff] PMD -> > [ffff880005400000-ffff8800057fffff] on node 0 > [ffffe20004a00000-ffffe20004dfffff] PMD -> > [ffff880005600000-ffff8800059fffff] on node 0 > [ffffe20004c00000-ffffe20004ffffff] PMD -> > [ffff880005800000-ffff880005bfffff] on node 0 > [ffffe20004e00000-ffffe200051fffff] PMD -> > [ffff880005a00000-ffff880005dfffff] on node 0 > [ffffe20005000000-ffffe200053fffff] PMD -> > [ffff880005c00000-ffff880005ffffff] on node 0 > [ffffe20005200000-ffffe200055fffff] PMD -> > [ffff880005e00000-ffff8800061fffff] on node 0 > [ffffe20005400000-ffffe200057fffff] PMD -> > [ffff880006000000-ffff8800063fffff] on node 0 > [ffffe20005600000-ffffe200059fffff] PMD -> > [ffff880006200000-ffff8800065fffff] on node 0 > [ffffe20005800000-ffffe20005bfffff] PMD -> > [ffff880006400000-ffff8800067fffff] on node 0 > [ffffe20005a00000-ffffe20005dfffff] PMD -> > [ffff880006600000-ffff8800069fffff] on node 0 > [ffffe20005c00000-ffffe20005ffffff] PMD -> > [ffff880006800000-ffff880006bfffff] on node 0 > [ffffe20005e00000-ffffe200061fffff] PMD -> > [ffff880006a00000-ffff880006dfffff] on node 0 > [ffffe20006000000-ffffe200063fffff] PMD -> > [ffff880006c00000-ffff880006ffffff] on node 0 > [ffffe20006200000-ffffe200065fffff] PMD -> > [ffff880006e00000-ffff8800071fffff] on node 0 > [ffffe20006400000-ffffe200067fffff] PMD -> > [ffff880007000000-ffff8800073fffff] on node 0 > [ffffe20006600000-ffffe200069fffff] PMD -> > [ffff880007200000-ffff8800075fffff] on node 0 > [ffffe20006800000-ffffe20006bfffff] PMD -> > [ffff880007400000-ffff8800077fffff] on node 0 > [ffffe20006a00000-ffffe20006dfffff] PMD -> > [ffff880007600000-ffff8800079fffff] on node 0 > [ffffe20006c00000-ffffe20006ffffff] PMD -> > [ffff880007800000-ffff880007bfffff] on node 0 > [ffffe20006e00000-ffffe200071fffff] PMD -> > [ffff880007a00000-ffff880007dfffff] on node 0 > [ffffe20007000000-ffffe200073fffff] PMD -> > [ffff880007c00000-ffff880007ffffff] on node 0 > [ffffe20007200000-ffffe200075fffff] PMD -> > [ffff880007e00000-ffff8800081fffff] on node 0 > [ffffe20007400000-ffffe200077fffff] PMD -> > [ffff880008000000-ffff8800083fffff] on node 0 > [ffffe20007600000-ffffe200079fffff] PMD -> > [ffff880008200000-ffff8800085fffff] on node 0 > [ffffe200078c0000-ffffe200079fffff] potential offnode page_structs > [ffffe20007800000-ffffe20007bfffff] PMD -> > [ffff880008400000-ffff8802283fffff] on node 0 > [ffffe20007a00000-ffffe20007dfffff] PMD -> > [ffff880228200000-ffff8802285fffff] on node 1 > [ffffe20007c00000-ffffe20007ffffff] PMD -> > [ffff880228400000-ffff8802287fffff] on node 1 > [ffffe20007e00000-ffffe200081fffff] PMD -> > [ffff880228600000-ffff8802289fffff] on node 1 > [ffffe20008000000-ffffe200083fffff] PMD -> > [ffff880228800000-ffff880228bfffff] on node 1 > [ffffe20008200000-ffffe200085fffff] PMD -> > [ffff880228a00000-ffff880228dfffff] on node 1 > [ffffe20008400000-ffffe200087fffff] PMD -> > [ffff880228c00000-ffff880228ffffff] on node 1 > [ffffe20008600000-ffffe200089fffff] PMD -> > [ffff880228e00000-ffff8802291fffff] on node 1 > [ffffe20008800000-ffffe20008bfffff] PMD -> > [ffff880229000000-ffff8802293fffff] on node 1 > [ffffe20008a00000-ffffe20008dfffff] PMD -> > [ffff880229200000-ffff8802295fffff] on node 1 > [ffffe20008c00000-ffffe20008ffffff] PMD -> > [ffff880229400000-ffff8802297fffff] on node 1 > [ffffe20008e00000-ffffe200091fffff] PMD -> > [ffff880229600000-ffff8802299fffff] on node 1 > [ffffe20009000000-ffffe200093fffff] PMD -> > [ffff880229800000-ffff880229bfffff] on node 1 > [ffffe20009200000-ffffe200095fffff] PMD -> > [ffff880229a00000-ffff880229dfffff] on node 1 > [ffffe20009400000-ffffe200097fffff] PMD -> > [ffff880229c00000-ffff880229ffffff] on node 1 > [ffffe20009600000-ffffe200099fffff] PMD -> > [ffff880229e00000-ffff88022a1fffff] on node 1 > [ffffe20009800000-ffffe20009bfffff] PMD -> > [ffff88022a000000-ffff88022a3fffff] on node 1 > [ffffe20009a00000-ffffe20009dfffff] PMD -> > [ffff88022a200000-ffff88022a5fffff] on node 1 > [ffffe20009c00000-ffffe20009ffffff] PMD -> > [ffff88022a400000-ffff88022a7fffff] on node 1 > [ffffe20009e00000-ffffe2000a1fffff] PMD -> > [ffff88022a600000-ffff88022a9fffff] on node 1 > [ffffe2000a000000-ffffe2000a3fffff] PMD -> > [ffff88022a800000-ffff88022abfffff] on node 1 > [ffffe2000a200000-ffffe2000a5fffff] PMD -> > [ffff88022aa00000-ffff88022adfffff] on node 1 > [ffffe2000a400000-ffffe2000a7fffff] PMD -> > [ffff88022ac00000-ffff88022affffff] on node 1 > [ffffe2000a600000-ffffe2000a9fffff] PMD -> > [ffff88022ae00000-ffff88022b1fffff] on node 1 > [ffffe2000a800000-ffffe2000abfffff] PMD -> > [ffff88022b000000-ffff88022b3fffff] on node 1 > [ffffe2000aa00000-ffffe2000adfffff] PMD -> > [ffff88022b200000-ffff88022b5fffff] on node 1 > [ffffe2000ac00000-ffffe2000affffff] PMD -> > [ffff88022b400000-ffff88022b7fffff] on node 1 > [ffffe2000ae00000-ffffe2000b1fffff] PMD -> > [ffff88022b600000-ffff88022b9fffff] on node 1 > [ffffe2000b000000-ffffe2000b3fffff] PMD -> > [ffff88022b800000-ffff88022bbfffff] on node 1 > [ffffe2000b200000-ffffe2000b5fffff] PMD -> > [ffff88022ba00000-ffff88022bdfffff] on node 1 > [ffffe2000b400000-ffffe2000b7fffff] PMD -> > [ffff88022bc00000-ffff88022bffffff] on node 1 > [ffffe2000b600000-ffffe2000b9fffff] PMD -> > [ffff88022be00000-ffff88022c1fffff] on node 1 > [ffffe2000b800000-ffffe2000bbfffff] PMD -> > [ffff88022c000000-ffff88022c3fffff] on node 1 > [ffffe2000ba00000-ffffe2000bdfffff] PMD -> > [ffff88022c200000-ffff88022c5fffff] on node 1 > [ffffe2000bc00000-ffffe2000bffffff] PMD -> > [ffff88022c400000-ffff88022c7fffff] on node 1 > [ffffe2000be00000-ffffe2000c1fffff] PMD -> > [ffff88022c600000-ffff88022c9fffff] on node 1 > [ffffe2000c000000-ffffe2000c3fffff] PMD -> > [ffff88022c800000-ffff88022cbfffff] on node 1 > [ffffe2000c200000-ffffe2000c5fffff] PMD -> > [ffff88022ca00000-ffff88022cdfffff] on node 1 > [ffffe2000c400000-ffffe2000c7fffff] PMD -> > [ffff88022cc00000-ffff88022cffffff] on node 1 > [ffffe2000c600000-ffffe2000c9fffff] PMD -> > [ffff88022ce00000-ffff88022d1fffff] on node 1 > [ffffe2000c800000-ffffe2000cbfffff] PMD -> > [ffff88022d000000-ffff88022d3fffff] on node 1 > [ffffe2000ca00000-ffffe2000cdfffff] PMD -> > [ffff88022d200000-ffff88022d5fffff] on node 1 > [ffffe2000cc00000-ffffe2000cffffff] PMD -> > [ffff88022d400000-ffff88022d7fffff] on node 1 > [ffffe2000ce00000-ffffe2000d1fffff] PMD -> > [ffff88022d600000-ffff88022d9fffff] on node 1 > [ffffe2000d000000-ffffe2000d3fffff] PMD -> > [ffff88022d800000-ffff88022dbfffff] on node 1 > [ffffe2000d200000-ffffe2000d5fffff] PMD -> > [ffff88022da00000-ffff88022ddfffff] on node 1 > [ffffe2000d400000-ffffe2000d7fffff] PMD -> > [ffff88022dc00000-ffff88022dffffff] on node 1 > [ffffe2000d600000-ffffe2000d9fffff] PMD -> > [ffff88022de00000-ffff88022e1fffff] on node 1 > [ffffe2000d800000-ffffe2000dbfffff] PMD -> > [ffff88022e000000-ffff88022e3fffff] on node 1 > [ffffe2000da00000-ffffe2000ddfffff] PMD -> > [ffff88022e200000-ffff88022e5fffff] on node 1 > [ffffe2000dc00000-ffffe2000dffffff] PMD -> > [ffff88022e400000-ffff88022e7fffff] on node 1 > [ffffe2000de00000-ffffe2000e1fffff] PMD -> > [ffff88022e600000-ffff88022e9fffff] on node 1 > [ffffe2000e000000-ffffe2000e3fffff] PMD -> > [ffff88022e800000-ffff88022ebfffff] on node 1 > [ffffe2000e200000-ffffe2000e5fffff] PMD -> > [ffff88022ea00000-ffff88022edfffff] on node 1 > [ffffe2000e400000-ffffe2000e7fffff] PMD -> > [ffff88022ec00000-ffff88022effffff] on node 1 > [ffffe2000e600000-ffffe2000e9fffff] PMD -> > [ffff88022ee00000-ffff88022f1fffff] on node 1 > [ffffe2000e800000-ffffe2000e9fffff] PMD -> > [ffff88022f000000-ffff88022f1fffff] on node 1 > > should have > > [ffffe20000000000-ffffe27fffffffff] PGD ->ffff8100011ce000 on node 0 > [ffffe20000000000-ffffe2003fffffff] PUD ->ffff8100011cf000 on node 0 > [ffffe200078c0000-ffffe200079fffff] potential offnode page_structs > [ffffe20000000000-ffffe200079fffff] PMD -> > [ffff810001200000-ffff8100083fffff] on node 0 > [ffffe20007a00000-ffffe2000e9fffff] PMD -> > [ffff810228200000-ffff81022f1fffff] on node 1I haven''t seen those messages before. Can you explain what they mean? J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yinghai Lu
2008-Jul-03 18:30 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
On Thu, Jul 3, 2008 at 11:25 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Yinghai Lu wrote: >> >> On Thu, Jul 3, 2008 at 2:10 AM, Ingo Molnar <mingo@elte.hu> wrote: >> >>> >>> * Ingo Molnar <mingo@elte.hu> wrote: >>> >>> >>>> >>>> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: >>>> >>>> >>>>> >>>>> Ingo Molnar wrote: >>>>> >>>>>> >>>>>> Excluding the x86/xen-64bit topic solves the problem. >>>>>> >>>>>> It triggered on two 64-bit machines so it seems readily reproducible >>>>>> with that config. >>>>>> >>>>>> i''ve pushed the failing tree out to tip/tmp.xen-64bit.Tue_Jul__1_10_55 >>>>>> >>>>>> >>>>> >>>>> The patch to fix this is on tip/x86/unify-setup: "x86: setup_arch() && >>>>> early_ioremap_init()". Logically that patch should probably be in the >>>>> xen64 branch, since it''s only meaningful with the early_ioremap >>>>> unification. >>>>> >>>> >>>> ah, indeed - it was missing from tip/master due to: >>>> >>>> | commit ac998c259605741efcfbd215533b379970ba1d9f >>>> | Author: Ingo Molnar <mingo@elte.hu> >>>> | Date: Mon Jun 30 12:01:31 2008 +0200 >>>> | >>>> | Revert "x86: setup_arch() && early_ioremap_init()" >>>> | >>>> | This reverts commit 181b3601a1a7d2ac3ace6b23cb3204450a4f9a27. >>>> >>>> because that change needed the other changes from xen-64bit. >>>> >>>> will retry tomorrow. >>>> >>> >>> ok, i''ve re-added x86/xen-64bit and it''s looking good in testing so far. >>> >>> >> >> got >> [ffffe20000000000-ffffe27fffffffff] PGD ->ffff88000128a000 on node 0 >> [ffffe20000000000-ffffe2003fffffff] PUD ->ffff88000128b000 on node 0 >> [ffffe20000000000-ffffe200003fffff] PMD -> >> [ffff880001400000-ffff8800017fffff] on node 0 >> [ffffe20000200000-ffffe200005fffff] PMD -> >> [ffff880001600000-ffff8800019fffff] on node 0 >> [ffffe20000400000-ffffe200007fffff] PMD -> >> [ffff880001800000-ffff880001bfffff] on node 0 >> [ffffe20000600000-ffffe200009fffff] PMD -> >> [ffff880001a00000-ffff880001dfffff] on node 0 >> [ffffe20000800000-ffffe20000bfffff] PMD -> >> [ffff880001c00000-ffff880001ffffff] on node 0 >> [ffffe20000a00000-ffffe20000dfffff] PMD -> >> [ffff880001e00000-ffff8800021fffff] on node 0 >> [ffffe20000c00000-ffffe20000ffffff] PMD -> >> [ffff880002000000-ffff8800023fffff] on node 0 >> [ffffe20000e00000-ffffe200011fffff] PMD -> >> [ffff880002200000-ffff8800025fffff] on node 0 >> [ffffe20001000000-ffffe200013fffff] PMD -> >> [ffff880002400000-ffff8800027fffff] on node 0 >> [ffffe20001200000-ffffe200015fffff] PMD -> >> [ffff880002600000-ffff8800029fffff] on node 0 >> [ffffe20001400000-ffffe200017fffff] PMD -> >> [ffff880002800000-ffff880002bfffff] on node 0 >> [ffffe20001600000-ffffe200019fffff] PMD -> >> [ffff880002a00000-ffff880002dfffff] on node 0 >> [ffffe20001800000-ffffe20001bfffff] PMD -> >> [ffff880002c00000-ffff880002ffffff] on node 0 >> [ffffe20001a00000-ffffe20001dfffff] PMD -> >> [ffff880002e00000-ffff8800031fffff] on node 0 >> [ffffe20001c00000-ffffe20001ffffff] PMD -> >> [ffff880003000000-ffff8800033fffff] on node 0 >> [ffffe20001e00000-ffffe200021fffff] PMD -> >> [ffff880003200000-ffff8800035fffff] on node 0 >> [ffffe20002000000-ffffe200023fffff] PMD -> >> [ffff880003400000-ffff8800037fffff] on node 0 >> [ffffe20002200000-ffffe200025fffff] PMD -> >> [ffff880003600000-ffff8800039fffff] on node 0 >> [ffffe20002400000-ffffe200027fffff] PMD -> >> [ffff880003800000-ffff880003bfffff] on node 0 >> [ffffe20002600000-ffffe200029fffff] PMD -> >> [ffff880003a00000-ffff880003dfffff] on node 0 >> [ffffe20002800000-ffffe20002bfffff] PMD -> >> [ffff880003c00000-ffff880003ffffff] on node 0 >> [ffffe20002a00000-ffffe20002dfffff] PMD -> >> [ffff880003e00000-ffff8800041fffff] on node 0 >> [ffffe20002c00000-ffffe20002ffffff] PMD -> >> [ffff880004000000-ffff8800043fffff] on node 0 >> [ffffe20002e00000-ffffe200039fffff] PMD -> >> [ffff880004200000-ffff8800045fffff] on node 0 >> [ffffe20003800000-ffffe20003bfffff] PMD -> >> [ffff880004400000-ffff8800047fffff] on node 0 >> [ffffe20003a00000-ffffe20003dfffff] PMD -> >> [ffff880004600000-ffff8800049fffff] on node 0 >> [ffffe20003c00000-ffffe20003ffffff] PMD -> >> [ffff880004800000-ffff880004bfffff] on node 0 >> [ffffe20003e00000-ffffe200041fffff] PMD -> >> [ffff880004a00000-ffff880004dfffff] on node 0 >> [ffffe20004000000-ffffe200043fffff] PMD -> >> [ffff880004c00000-ffff880004ffffff] on node 0 >> [ffffe20004200000-ffffe200045fffff] PMD -> >> [ffff880004e00000-ffff8800051fffff] on node 0 >> [ffffe20004400000-ffffe200047fffff] PMD -> >> [ffff880005000000-ffff8800053fffff] on node 0 >> [ffffe20004600000-ffffe200049fffff] PMD -> >> [ffff880005200000-ffff8800055fffff] on node 0 >> [ffffe20004800000-ffffe20004bfffff] PMD -> >> [ffff880005400000-ffff8800057fffff] on node 0 >> [ffffe20004a00000-ffffe20004dfffff] PMD -> >> [ffff880005600000-ffff8800059fffff] on node 0 >> [ffffe20004c00000-ffffe20004ffffff] PMD -> >> [ffff880005800000-ffff880005bfffff] on node 0 >> [ffffe20004e00000-ffffe200051fffff] PMD -> >> [ffff880005a00000-ffff880005dfffff] on node 0 >> [ffffe20005000000-ffffe200053fffff] PMD -> >> [ffff880005c00000-ffff880005ffffff] on node 0 >> [ffffe20005200000-ffffe200055fffff] PMD -> >> [ffff880005e00000-ffff8800061fffff] on node 0 >> [ffffe20005400000-ffffe200057fffff] PMD -> >> [ffff880006000000-ffff8800063fffff] on node 0 >> [ffffe20005600000-ffffe200059fffff] PMD -> >> [ffff880006200000-ffff8800065fffff] on node 0 >> [ffffe20005800000-ffffe20005bfffff] PMD -> >> [ffff880006400000-ffff8800067fffff] on node 0 >> [ffffe20005a00000-ffffe20005dfffff] PMD -> >> [ffff880006600000-ffff8800069fffff] on node 0 >> [ffffe20005c00000-ffffe20005ffffff] PMD -> >> [ffff880006800000-ffff880006bfffff] on node 0 >> [ffffe20005e00000-ffffe200061fffff] PMD -> >> [ffff880006a00000-ffff880006dfffff] on node 0 >> [ffffe20006000000-ffffe200063fffff] PMD -> >> [ffff880006c00000-ffff880006ffffff] on node 0 >> [ffffe20006200000-ffffe200065fffff] PMD -> >> [ffff880006e00000-ffff8800071fffff] on node 0 >> [ffffe20006400000-ffffe200067fffff] PMD -> >> [ffff880007000000-ffff8800073fffff] on node 0 >> [ffffe20006600000-ffffe200069fffff] PMD -> >> [ffff880007200000-ffff8800075fffff] on node 0 >> [ffffe20006800000-ffffe20006bfffff] PMD -> >> [ffff880007400000-ffff8800077fffff] on node 0 >> [ffffe20006a00000-ffffe20006dfffff] PMD -> >> [ffff880007600000-ffff8800079fffff] on node 0 >> [ffffe20006c00000-ffffe20006ffffff] PMD -> >> [ffff880007800000-ffff880007bfffff] on node 0 >> [ffffe20006e00000-ffffe200071fffff] PMD -> >> [ffff880007a00000-ffff880007dfffff] on node 0 >> [ffffe20007000000-ffffe200073fffff] PMD -> >> [ffff880007c00000-ffff880007ffffff] on node 0 >> [ffffe20007200000-ffffe200075fffff] PMD -> >> [ffff880007e00000-ffff8800081fffff] on node 0 >> [ffffe20007400000-ffffe200077fffff] PMD -> >> [ffff880008000000-ffff8800083fffff] on node 0 >> [ffffe20007600000-ffffe200079fffff] PMD -> >> [ffff880008200000-ffff8800085fffff] on node 0 >> [ffffe200078c0000-ffffe200079fffff] potential offnode page_structs >> [ffffe20007800000-ffffe20007bfffff] PMD -> >> [ffff880008400000-ffff8802283fffff] on node 0 >> [ffffe20007a00000-ffffe20007dfffff] PMD -> >> [ffff880228200000-ffff8802285fffff] on node 1 >> [ffffe20007c00000-ffffe20007ffffff] PMD -> >> [ffff880228400000-ffff8802287fffff] on node 1 >> [ffffe20007e00000-ffffe200081fffff] PMD -> >> [ffff880228600000-ffff8802289fffff] on node 1 >> [ffffe20008000000-ffffe200083fffff] PMD -> >> [ffff880228800000-ffff880228bfffff] on node 1 >> [ffffe20008200000-ffffe200085fffff] PMD -> >> [ffff880228a00000-ffff880228dfffff] on node 1 >> [ffffe20008400000-ffffe200087fffff] PMD -> >> [ffff880228c00000-ffff880228ffffff] on node 1 >> [ffffe20008600000-ffffe200089fffff] PMD -> >> [ffff880228e00000-ffff8802291fffff] on node 1 >> [ffffe20008800000-ffffe20008bfffff] PMD -> >> [ffff880229000000-ffff8802293fffff] on node 1 >> [ffffe20008a00000-ffffe20008dfffff] PMD -> >> [ffff880229200000-ffff8802295fffff] on node 1 >> [ffffe20008c00000-ffffe20008ffffff] PMD -> >> [ffff880229400000-ffff8802297fffff] on node 1 >> [ffffe20008e00000-ffffe200091fffff] PMD -> >> [ffff880229600000-ffff8802299fffff] on node 1 >> [ffffe20009000000-ffffe200093fffff] PMD -> >> [ffff880229800000-ffff880229bfffff] on node 1 >> [ffffe20009200000-ffffe200095fffff] PMD -> >> [ffff880229a00000-ffff880229dfffff] on node 1 >> [ffffe20009400000-ffffe200097fffff] PMD -> >> [ffff880229c00000-ffff880229ffffff] on node 1 >> [ffffe20009600000-ffffe200099fffff] PMD -> >> [ffff880229e00000-ffff88022a1fffff] on node 1 >> [ffffe20009800000-ffffe20009bfffff] PMD -> >> [ffff88022a000000-ffff88022a3fffff] on node 1 >> [ffffe20009a00000-ffffe20009dfffff] PMD -> >> [ffff88022a200000-ffff88022a5fffff] on node 1 >> [ffffe20009c00000-ffffe20009ffffff] PMD -> >> [ffff88022a400000-ffff88022a7fffff] on node 1 >> [ffffe20009e00000-ffffe2000a1fffff] PMD -> >> [ffff88022a600000-ffff88022a9fffff] on node 1 >> [ffffe2000a000000-ffffe2000a3fffff] PMD -> >> [ffff88022a800000-ffff88022abfffff] on node 1 >> [ffffe2000a200000-ffffe2000a5fffff] PMD -> >> [ffff88022aa00000-ffff88022adfffff] on node 1 >> [ffffe2000a400000-ffffe2000a7fffff] PMD -> >> [ffff88022ac00000-ffff88022affffff] on node 1 >> [ffffe2000a600000-ffffe2000a9fffff] PMD -> >> [ffff88022ae00000-ffff88022b1fffff] on node 1 >> [ffffe2000a800000-ffffe2000abfffff] PMD -> >> [ffff88022b000000-ffff88022b3fffff] on node 1 >> [ffffe2000aa00000-ffffe2000adfffff] PMD -> >> [ffff88022b200000-ffff88022b5fffff] on node 1 >> [ffffe2000ac00000-ffffe2000affffff] PMD -> >> [ffff88022b400000-ffff88022b7fffff] on node 1 >> [ffffe2000ae00000-ffffe2000b1fffff] PMD -> >> [ffff88022b600000-ffff88022b9fffff] on node 1 >> [ffffe2000b000000-ffffe2000b3fffff] PMD -> >> [ffff88022b800000-ffff88022bbfffff] on node 1 >> [ffffe2000b200000-ffffe2000b5fffff] PMD -> >> [ffff88022ba00000-ffff88022bdfffff] on node 1 >> [ffffe2000b400000-ffffe2000b7fffff] PMD -> >> [ffff88022bc00000-ffff88022bffffff] on node 1 >> [ffffe2000b600000-ffffe2000b9fffff] PMD -> >> [ffff88022be00000-ffff88022c1fffff] on node 1 >> [ffffe2000b800000-ffffe2000bbfffff] PMD -> >> [ffff88022c000000-ffff88022c3fffff] on node 1 >> [ffffe2000ba00000-ffffe2000bdfffff] PMD -> >> [ffff88022c200000-ffff88022c5fffff] on node 1 >> [ffffe2000bc00000-ffffe2000bffffff] PMD -> >> [ffff88022c400000-ffff88022c7fffff] on node 1 >> [ffffe2000be00000-ffffe2000c1fffff] PMD -> >> [ffff88022c600000-ffff88022c9fffff] on node 1 >> [ffffe2000c000000-ffffe2000c3fffff] PMD -> >> [ffff88022c800000-ffff88022cbfffff] on node 1 >> [ffffe2000c200000-ffffe2000c5fffff] PMD -> >> [ffff88022ca00000-ffff88022cdfffff] on node 1 >> [ffffe2000c400000-ffffe2000c7fffff] PMD -> >> [ffff88022cc00000-ffff88022cffffff] on node 1 >> [ffffe2000c600000-ffffe2000c9fffff] PMD -> >> [ffff88022ce00000-ffff88022d1fffff] on node 1 >> [ffffe2000c800000-ffffe2000cbfffff] PMD -> >> [ffff88022d000000-ffff88022d3fffff] on node 1 >> [ffffe2000ca00000-ffffe2000cdfffff] PMD -> >> [ffff88022d200000-ffff88022d5fffff] on node 1 >> [ffffe2000cc00000-ffffe2000cffffff] PMD -> >> [ffff88022d400000-ffff88022d7fffff] on node 1 >> [ffffe2000ce00000-ffffe2000d1fffff] PMD -> >> [ffff88022d600000-ffff88022d9fffff] on node 1 >> [ffffe2000d000000-ffffe2000d3fffff] PMD -> >> [ffff88022d800000-ffff88022dbfffff] on node 1 >> [ffffe2000d200000-ffffe2000d5fffff] PMD -> >> [ffff88022da00000-ffff88022ddfffff] on node 1 >> [ffffe2000d400000-ffffe2000d7fffff] PMD -> >> [ffff88022dc00000-ffff88022dffffff] on node 1 >> [ffffe2000d600000-ffffe2000d9fffff] PMD -> >> [ffff88022de00000-ffff88022e1fffff] on node 1 >> [ffffe2000d800000-ffffe2000dbfffff] PMD -> >> [ffff88022e000000-ffff88022e3fffff] on node 1 >> [ffffe2000da00000-ffffe2000ddfffff] PMD -> >> [ffff88022e200000-ffff88022e5fffff] on node 1 >> [ffffe2000dc00000-ffffe2000dffffff] PMD -> >> [ffff88022e400000-ffff88022e7fffff] on node 1 >> [ffffe2000de00000-ffffe2000e1fffff] PMD -> >> [ffff88022e600000-ffff88022e9fffff] on node 1 >> [ffffe2000e000000-ffffe2000e3fffff] PMD -> >> [ffff88022e800000-ffff88022ebfffff] on node 1 >> [ffffe2000e200000-ffffe2000e5fffff] PMD -> >> [ffff88022ea00000-ffff88022edfffff] on node 1 >> [ffffe2000e400000-ffffe2000e7fffff] PMD -> >> [ffff88022ec00000-ffff88022effffff] on node 1 >> [ffffe2000e600000-ffffe2000e9fffff] PMD -> >> [ffff88022ee00000-ffff88022f1fffff] on node 1 >> [ffffe2000e800000-ffffe2000e9fffff] PMD -> >> [ffff88022f000000-ffff88022f1fffff] on node 1 >> >> should have >> >> [ffffe20000000000-ffffe27fffffffff] PGD ->ffff8100011ce000 on node 0 >> [ffffe20000000000-ffffe2003fffffff] PUD ->ffff8100011cf000 on node 0 >> [ffffe200078c0000-ffffe200079fffff] potential offnode page_structs >> [ffffe20000000000-ffffe200079fffff] PMD -> >> [ffff810001200000-ffff8100083fffff] on node 0 >> [ffffe20007a00000-ffffe2000e9fffff] PMD -> >> [ffff810228200000-ffff81022f1fffff] on node 1 > > > I haven''t seen those messages before. Can you explain what they mean?that is for SPARSEMEM virtual memmap... CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y YH _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jeremy Fitzhardinge
2008-Jul-03 18:41 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
Yinghai Lu wrote:> On Thu, Jul 3, 2008 at 11:25 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > >> Yinghai Lu wrote: >> >>> On Thu, Jul 3, 2008 at 2:10 AM, Ingo Molnar <mingo@elte.hu> wrote: >>> >>> >>>> * Ingo Molnar <mingo@elte.hu> wrote: >>>> >>>> >>>> >>>>> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: >>>>> >>>>> >>>>> >>>>>> Ingo Molnar wrote: >>>>>> >>>>>> >>>>>>> Excluding the x86/xen-64bit topic solves the problem. >>>>>>> >>>>>>> It triggered on two 64-bit machines so it seems readily reproducible >>>>>>> with that config. >>>>>>> >>>>>>> i''ve pushed the failing tree out to tip/tmp.xen-64bit.Tue_Jul__1_10_55 >>>>>>> >>>>>>> >>>>>>> >>>>>> The patch to fix this is on tip/x86/unify-setup: "x86: setup_arch() && >>>>>> early_ioremap_init()". Logically that patch should probably be in the >>>>>> xen64 branch, since it''s only meaningful with the early_ioremap >>>>>> unification. >>>>>> >>>>>> >>>>> ah, indeed - it was missing from tip/master due to: >>>>> >>>>> | commit ac998c259605741efcfbd215533b379970ba1d9f >>>>> | Author: Ingo Molnar <mingo@elte.hu> >>>>> | Date: Mon Jun 30 12:01:31 2008 +0200 >>>>> | >>>>> | Revert "x86: setup_arch() && early_ioremap_init()" >>>>> | >>>>> | This reverts commit 181b3601a1a7d2ac3ace6b23cb3204450a4f9a27. >>>>> >>>>> because that change needed the other changes from xen-64bit. >>>>> >>>>> will retry tomorrow. >>>>> >>>>> >>>> ok, i''ve re-added x86/xen-64bit and it''s looking good in testing so far. >>>> >>>> >>>> >>> got >>> [ffffe20000000000-ffffe27fffffffff] PGD ->ffff88000128a000 on node 0 >>> [ffffe20000000000-ffffe2003fffffff] PUD ->ffff88000128b000 on node 0 >>> [ffffe20000000000-ffffe200003fffff] PMD -> >>> [ffff880001400000-ffff8800017fffff] on node 0 >>> [ffffe20000200000-ffffe200005fffff] PMD -> >>> [ffff880001600000-ffff8800019fffff] on node 0 >>> [ffffe20000400000-ffffe200007fffff] PMD -> >>> [ffff880001800000-ffff880001bfffff] on node 0 >>> [ffffe20000600000-ffffe200009fffff] PMD -> >>> [ffff880001a00000-ffff880001dfffff] on node 0 >>> [ffffe20000800000-ffffe20000bfffff] PMD -> >>> [ffff880001c00000-ffff880001ffffff] on node 0 >>> [ffffe20000a00000-ffffe20000dfffff] PMD -> >>> [ffff880001e00000-ffff8800021fffff] on node 0 >>> [ffffe20000c00000-ffffe20000ffffff] PMD -> >>> [ffff880002000000-ffff8800023fffff] on node 0 >>> [ffffe20000e00000-ffffe200011fffff] PMD -> >>> [ffff880002200000-ffff8800025fffff] on node 0 >>> [ffffe20001000000-ffffe200013fffff] PMD -> >>> [ffff880002400000-ffff8800027fffff] on node 0 >>> [ffffe20001200000-ffffe200015fffff] PMD -> >>> [ffff880002600000-ffff8800029fffff] on node 0 >>> [ffffe20001400000-ffffe200017fffff] PMD -> >>> [ffff880002800000-ffff880002bfffff] on node 0 >>> [ffffe20001600000-ffffe200019fffff] PMD -> >>> [ffff880002a00000-ffff880002dfffff] on node 0 >>> [ffffe20001800000-ffffe20001bfffff] PMD -> >>> [ffff880002c00000-ffff880002ffffff] on node 0 >>> [ffffe20001a00000-ffffe20001dfffff] PMD -> >>> [ffff880002e00000-ffff8800031fffff] on node 0 >>> [ffffe20001c00000-ffffe20001ffffff] PMD -> >>> [ffff880003000000-ffff8800033fffff] on node 0 >>> [ffffe20001e00000-ffffe200021fffff] PMD -> >>> [ffff880003200000-ffff8800035fffff] on node 0 >>> [ffffe20002000000-ffffe200023fffff] PMD -> >>> [ffff880003400000-ffff8800037fffff] on node 0 >>> [ffffe20002200000-ffffe200025fffff] PMD -> >>> [ffff880003600000-ffff8800039fffff] on node 0 >>> [ffffe20002400000-ffffe200027fffff] PMD -> >>> [ffff880003800000-ffff880003bfffff] on node 0 >>> [ffffe20002600000-ffffe200029fffff] PMD -> >>> [ffff880003a00000-ffff880003dfffff] on node 0 >>> [ffffe20002800000-ffffe20002bfffff] PMD -> >>> [ffff880003c00000-ffff880003ffffff] on node 0 >>> [ffffe20002a00000-ffffe20002dfffff] PMD -> >>> [ffff880003e00000-ffff8800041fffff] on node 0 >>> [ffffe20002c00000-ffffe20002ffffff] PMD -> >>> [ffff880004000000-ffff8800043fffff] on node 0 >>> [ffffe20002e00000-ffffe200039fffff] PMD -> >>> [ffff880004200000-ffff8800045fffff] on node 0 >>> [ffffe20003800000-ffffe20003bfffff] PMD -> >>> [ffff880004400000-ffff8800047fffff] on node 0 >>> [ffffe20003a00000-ffffe20003dfffff] PMD -> >>> [ffff880004600000-ffff8800049fffff] on node 0 >>> [ffffe20003c00000-ffffe20003ffffff] PMD -> >>> [ffff880004800000-ffff880004bfffff] on node 0 >>> [ffffe20003e00000-ffffe200041fffff] PMD -> >>> [ffff880004a00000-ffff880004dfffff] on node 0 >>> [ffffe20004000000-ffffe200043fffff] PMD -> >>> [ffff880004c00000-ffff880004ffffff] on node 0 >>> [ffffe20004200000-ffffe200045fffff] PMD -> >>> [ffff880004e00000-ffff8800051fffff] on node 0 >>> [ffffe20004400000-ffffe200047fffff] PMD -> >>> [ffff880005000000-ffff8800053fffff] on node 0 >>> [ffffe20004600000-ffffe200049fffff] PMD -> >>> [ffff880005200000-ffff8800055fffff] on node 0 >>> [ffffe20004800000-ffffe20004bfffff] PMD -> >>> [ffff880005400000-ffff8800057fffff] on node 0 >>> [ffffe20004a00000-ffffe20004dfffff] PMD -> >>> [ffff880005600000-ffff8800059fffff] on node 0 >>> [ffffe20004c00000-ffffe20004ffffff] PMD -> >>> [ffff880005800000-ffff880005bfffff] on node 0 >>> [ffffe20004e00000-ffffe200051fffff] PMD -> >>> [ffff880005a00000-ffff880005dfffff] on node 0 >>> [ffffe20005000000-ffffe200053fffff] PMD -> >>> [ffff880005c00000-ffff880005ffffff] on node 0 >>> [ffffe20005200000-ffffe200055fffff] PMD -> >>> [ffff880005e00000-ffff8800061fffff] on node 0 >>> [ffffe20005400000-ffffe200057fffff] PMD -> >>> [ffff880006000000-ffff8800063fffff] on node 0 >>> [ffffe20005600000-ffffe200059fffff] PMD -> >>> [ffff880006200000-ffff8800065fffff] on node 0 >>> [ffffe20005800000-ffffe20005bfffff] PMD -> >>> [ffff880006400000-ffff8800067fffff] on node 0 >>> [ffffe20005a00000-ffffe20005dfffff] PMD -> >>> [ffff880006600000-ffff8800069fffff] on node 0 >>> [ffffe20005c00000-ffffe20005ffffff] PMD -> >>> [ffff880006800000-ffff880006bfffff] on node 0 >>> [ffffe20005e00000-ffffe200061fffff] PMD -> >>> [ffff880006a00000-ffff880006dfffff] on node 0 >>> [ffffe20006000000-ffffe200063fffff] PMD -> >>> [ffff880006c00000-ffff880006ffffff] on node 0 >>> [ffffe20006200000-ffffe200065fffff] PMD -> >>> [ffff880006e00000-ffff8800071fffff] on node 0 >>> [ffffe20006400000-ffffe200067fffff] PMD -> >>> [ffff880007000000-ffff8800073fffff] on node 0 >>> [ffffe20006600000-ffffe200069fffff] PMD -> >>> [ffff880007200000-ffff8800075fffff] on node 0 >>> [ffffe20006800000-ffffe20006bfffff] PMD -> >>> [ffff880007400000-ffff8800077fffff] on node 0 >>> [ffffe20006a00000-ffffe20006dfffff] PMD -> >>> [ffff880007600000-ffff8800079fffff] on node 0 >>> [ffffe20006c00000-ffffe20006ffffff] PMD -> >>> [ffff880007800000-ffff880007bfffff] on node 0 >>> [ffffe20006e00000-ffffe200071fffff] PMD -> >>> [ffff880007a00000-ffff880007dfffff] on node 0 >>> [ffffe20007000000-ffffe200073fffff] PMD -> >>> [ffff880007c00000-ffff880007ffffff] on node 0 >>> [ffffe20007200000-ffffe200075fffff] PMD -> >>> [ffff880007e00000-ffff8800081fffff] on node 0 >>> [ffffe20007400000-ffffe200077fffff] PMD -> >>> [ffff880008000000-ffff8800083fffff] on node 0 >>> [ffffe20007600000-ffffe200079fffff] PMD -> >>> [ffff880008200000-ffff8800085fffff] on node 0 >>> [ffffe200078c0000-ffffe200079fffff] potential offnode page_structs >>> [ffffe20007800000-ffffe20007bfffff] PMD -> >>> [ffff880008400000-ffff8802283fffff] on node 0 >>> [ffffe20007a00000-ffffe20007dfffff] PMD -> >>> [ffff880228200000-ffff8802285fffff] on node 1 >>> [ffffe20007c00000-ffffe20007ffffff] PMD -> >>> [ffff880228400000-ffff8802287fffff] on node 1 >>> [ffffe20007e00000-ffffe200081fffff] PMD -> >>> [ffff880228600000-ffff8802289fffff] on node 1 >>> [ffffe20008000000-ffffe200083fffff] PMD -> >>> [ffff880228800000-ffff880228bfffff] on node 1 >>> [ffffe20008200000-ffffe200085fffff] PMD -> >>> [ffff880228a00000-ffff880228dfffff] on node 1 >>> [ffffe20008400000-ffffe200087fffff] PMD -> >>> [ffff880228c00000-ffff880228ffffff] on node 1 >>> [ffffe20008600000-ffffe200089fffff] PMD -> >>> [ffff880228e00000-ffff8802291fffff] on node 1 >>> [ffffe20008800000-ffffe20008bfffff] PMD -> >>> [ffff880229000000-ffff8802293fffff] on node 1 >>> [ffffe20008a00000-ffffe20008dfffff] PMD -> >>> [ffff880229200000-ffff8802295fffff] on node 1 >>> [ffffe20008c00000-ffffe20008ffffff] PMD -> >>> [ffff880229400000-ffff8802297fffff] on node 1 >>> [ffffe20008e00000-ffffe200091fffff] PMD -> >>> [ffff880229600000-ffff8802299fffff] on node 1 >>> [ffffe20009000000-ffffe200093fffff] PMD -> >>> [ffff880229800000-ffff880229bfffff] on node 1 >>> [ffffe20009200000-ffffe200095fffff] PMD -> >>> [ffff880229a00000-ffff880229dfffff] on node 1 >>> [ffffe20009400000-ffffe200097fffff] PMD -> >>> [ffff880229c00000-ffff880229ffffff] on node 1 >>> [ffffe20009600000-ffffe200099fffff] PMD -> >>> [ffff880229e00000-ffff88022a1fffff] on node 1 >>> [ffffe20009800000-ffffe20009bfffff] PMD -> >>> [ffff88022a000000-ffff88022a3fffff] on node 1 >>> [ffffe20009a00000-ffffe20009dfffff] PMD -> >>> [ffff88022a200000-ffff88022a5fffff] on node 1 >>> [ffffe20009c00000-ffffe20009ffffff] PMD -> >>> [ffff88022a400000-ffff88022a7fffff] on node 1 >>> [ffffe20009e00000-ffffe2000a1fffff] PMD -> >>> [ffff88022a600000-ffff88022a9fffff] on node 1 >>> [ffffe2000a000000-ffffe2000a3fffff] PMD -> >>> [ffff88022a800000-ffff88022abfffff] on node 1 >>> [ffffe2000a200000-ffffe2000a5fffff] PMD -> >>> [ffff88022aa00000-ffff88022adfffff] on node 1 >>> [ffffe2000a400000-ffffe2000a7fffff] PMD -> >>> [ffff88022ac00000-ffff88022affffff] on node 1 >>> [ffffe2000a600000-ffffe2000a9fffff] PMD -> >>> [ffff88022ae00000-ffff88022b1fffff] on node 1 >>> [ffffe2000a800000-ffffe2000abfffff] PMD -> >>> [ffff88022b000000-ffff88022b3fffff] on node 1 >>> [ffffe2000aa00000-ffffe2000adfffff] PMD -> >>> [ffff88022b200000-ffff88022b5fffff] on node 1 >>> [ffffe2000ac00000-ffffe2000affffff] PMD -> >>> [ffff88022b400000-ffff88022b7fffff] on node 1 >>> [ffffe2000ae00000-ffffe2000b1fffff] PMD -> >>> [ffff88022b600000-ffff88022b9fffff] on node 1 >>> [ffffe2000b000000-ffffe2000b3fffff] PMD -> >>> [ffff88022b800000-ffff88022bbfffff] on node 1 >>> [ffffe2000b200000-ffffe2000b5fffff] PMD -> >>> [ffff88022ba00000-ffff88022bdfffff] on node 1 >>> [ffffe2000b400000-ffffe2000b7fffff] PMD -> >>> [ffff88022bc00000-ffff88022bffffff] on node 1 >>> [ffffe2000b600000-ffffe2000b9fffff] PMD -> >>> [ffff88022be00000-ffff88022c1fffff] on node 1 >>> [ffffe2000b800000-ffffe2000bbfffff] PMD -> >>> [ffff88022c000000-ffff88022c3fffff] on node 1 >>> [ffffe2000ba00000-ffffe2000bdfffff] PMD -> >>> [ffff88022c200000-ffff88022c5fffff] on node 1 >>> [ffffe2000bc00000-ffffe2000bffffff] PMD -> >>> [ffff88022c400000-ffff88022c7fffff] on node 1 >>> [ffffe2000be00000-ffffe2000c1fffff] PMD -> >>> [ffff88022c600000-ffff88022c9fffff] on node 1 >>> [ffffe2000c000000-ffffe2000c3fffff] PMD -> >>> [ffff88022c800000-ffff88022cbfffff] on node 1 >>> [ffffe2000c200000-ffffe2000c5fffff] PMD -> >>> [ffff88022ca00000-ffff88022cdfffff] on node 1 >>> [ffffe2000c400000-ffffe2000c7fffff] PMD -> >>> [ffff88022cc00000-ffff88022cffffff] on node 1 >>> [ffffe2000c600000-ffffe2000c9fffff] PMD -> >>> [ffff88022ce00000-ffff88022d1fffff] on node 1 >>> [ffffe2000c800000-ffffe2000cbfffff] PMD -> >>> [ffff88022d000000-ffff88022d3fffff] on node 1 >>> [ffffe2000ca00000-ffffe2000cdfffff] PMD -> >>> [ffff88022d200000-ffff88022d5fffff] on node 1 >>> [ffffe2000cc00000-ffffe2000cffffff] PMD -> >>> [ffff88022d400000-ffff88022d7fffff] on node 1 >>> [ffffe2000ce00000-ffffe2000d1fffff] PMD -> >>> [ffff88022d600000-ffff88022d9fffff] on node 1 >>> [ffffe2000d000000-ffffe2000d3fffff] PMD -> >>> [ffff88022d800000-ffff88022dbfffff] on node 1 >>> [ffffe2000d200000-ffffe2000d5fffff] PMD -> >>> [ffff88022da00000-ffff88022ddfffff] on node 1 >>> [ffffe2000d400000-ffffe2000d7fffff] PMD -> >>> [ffff88022dc00000-ffff88022dffffff] on node 1 >>> [ffffe2000d600000-ffffe2000d9fffff] PMD -> >>> [ffff88022de00000-ffff88022e1fffff] on node 1 >>> [ffffe2000d800000-ffffe2000dbfffff] PMD -> >>> [ffff88022e000000-ffff88022e3fffff] on node 1 >>> [ffffe2000da00000-ffffe2000ddfffff] PMD -> >>> [ffff88022e200000-ffff88022e5fffff] on node 1 >>> [ffffe2000dc00000-ffffe2000dffffff] PMD -> >>> [ffff88022e400000-ffff88022e7fffff] on node 1 >>> [ffffe2000de00000-ffffe2000e1fffff] PMD -> >>> [ffff88022e600000-ffff88022e9fffff] on node 1 >>> [ffffe2000e000000-ffffe2000e3fffff] PMD -> >>> [ffff88022e800000-ffff88022ebfffff] on node 1 >>> [ffffe2000e200000-ffffe2000e5fffff] PMD -> >>> [ffff88022ea00000-ffff88022edfffff] on node 1 >>> [ffffe2000e400000-ffffe2000e7fffff] PMD -> >>> [ffff88022ec00000-ffff88022effffff] on node 1 >>> [ffffe2000e600000-ffffe2000e9fffff] PMD -> >>> [ffff88022ee00000-ffff88022f1fffff] on node 1 >>> [ffffe2000e800000-ffffe2000e9fffff] PMD -> >>> [ffff88022f000000-ffff88022f1fffff] on node 1 >>> >>> should have >>> >>> [ffffe20000000000-ffffe27fffffffff] PGD ->ffff8100011ce000 on node 0 >>> [ffffe20000000000-ffffe2003fffffff] PUD ->ffff8100011cf000 on node 0 >>> [ffffe200078c0000-ffffe200079fffff] potential offnode page_structs >>> [ffffe20000000000-ffffe200079fffff] PMD -> >>> [ffff810001200000-ffff8100083fffff] on node 0 >>> [ffffe20007a00000-ffffe2000e9fffff] PMD -> >>> [ffff810228200000-ffff81022f1fffff] on node 1 >>> >> I haven''t seen those messages before. Can you explain what they mean? >> > > that is for SPARSEMEM virtual memmap... > > CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y > CONFIG_SPARSEMEM_VMEMMAP=y >I modified the vmemmap code so it would create 4k mappings if PSE isn''t supported. Did I get it wrong? It should have no effect when PSE is available (which is any time you''re not running under Xen). J _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yinghai Lu
2008-Jul-03 18:51 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
On Thu, Jul 3, 2008 at 11:41 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:> Yinghai Lu wrote: >> >> On Thu, Jul 3, 2008 at 11:25 AM, Jeremy Fitzhardinge <jeremy@goop.org> >> wrote: >> >>> >>> Yinghai Lu wrote: >>> >>>> >>>> On Thu, Jul 3, 2008 at 2:10 AM, Ingo Molnar <mingo@elte.hu> wrote: >>>> >>>> >>>>> >>>>> * Ingo Molnar <mingo@elte.hu> wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> * Jeremy Fitzhardinge <jeremy@goop.org> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Ingo Molnar wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Excluding the x86/xen-64bit topic solves the problem. >>>>>>>> >>>>>>>> It triggered on two 64-bit machines so it seems readily reproducible >>>>>>>> with that config. >>>>>>>> >>>>>>>> i''ve pushed the failing tree out to >>>>>>>> tip/tmp.xen-64bit.Tue_Jul__1_10_55 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> The patch to fix this is on tip/x86/unify-setup: "x86: setup_arch() >>>>>>> && >>>>>>> early_ioremap_init()". Logically that patch should probably be in >>>>>>> the >>>>>>> xen64 branch, since it''s only meaningful with the early_ioremap >>>>>>> unification. >>>>>>> >>>>>>> >>>>>> >>>>>> ah, indeed - it was missing from tip/master due to: >>>>>> >>>>>> | commit ac998c259605741efcfbd215533b379970ba1d9f >>>>>> | Author: Ingo Molnar <mingo@elte.hu> >>>>>> | Date: Mon Jun 30 12:01:31 2008 +0200 >>>>>> | >>>>>> | Revert "x86: setup_arch() && early_ioremap_init()" >>>>>> | >>>>>> | This reverts commit 181b3601a1a7d2ac3ace6b23cb3204450a4f9a27. >>>>>> >>>>>> because that change needed the other changes from xen-64bit. >>>>>> >>>>>> will retry tomorrow. >>>>>> >>>>>> >>>>> >>>>> ok, i''ve re-added x86/xen-64bit and it''s looking good in testing so >>>>> far. >>>>> >>>>> >>>>> >>>> >>>> got >>>> [ffffe20000000000-ffffe27fffffffff] PGD ->ffff88000128a000 on node 0 >>>> [ffffe20000000000-ffffe2003fffffff] PUD ->ffff88000128b000 on node 0 >>>> [ffffe20000000000-ffffe200003fffff] PMD -> >>>> [ffff880001400000-ffff8800017fffff] on node 0 >>>> [ffffe20000200000-ffffe200005fffff] PMD -> >>>> [ffff880001600000-ffff8800019fffff] on node 0 >>>> [ffffe20000400000-ffffe200007fffff] PMD -> >>>> [ffff880001800000-ffff880001bfffff] on node 0 >>>> [ffffe20000600000-ffffe200009fffff] PMD -> >>>> [ffff880001a00000-ffff880001dfffff] on node 0 >>>> [ffffe20000800000-ffffe20000bfffff] PMD -> >>>> [ffff880001c00000-ffff880001ffffff] on node 0 >>>> [ffffe20000a00000-ffffe20000dfffff] PMD -> >>>> [ffff880001e00000-ffff8800021fffff] on node 0 >>>> [ffffe20000c00000-ffffe20000ffffff] PMD -> >>>> [ffff880002000000-ffff8800023fffff] on node 0 >>>> [ffffe20000e00000-ffffe200011fffff] PMD -> >>>> [ffff880002200000-ffff8800025fffff] on node 0 >>>> [ffffe20001000000-ffffe200013fffff] PMD -> >>>> [ffff880002400000-ffff8800027fffff] on node 0 >>>> [ffffe20001200000-ffffe200015fffff] PMD -> >>>> [ffff880002600000-ffff8800029fffff] on node 0 >>>> [ffffe20001400000-ffffe200017fffff] PMD -> >>>> [ffff880002800000-ffff880002bfffff] on node 0 >>>> [ffffe20001600000-ffffe200019fffff] PMD -> >>>> [ffff880002a00000-ffff880002dfffff] on node 0 >>>> [ffffe20001800000-ffffe20001bfffff] PMD -> >>>> [ffff880002c00000-ffff880002ffffff] on node 0 >>>> [ffffe20001a00000-ffffe20001dfffff] PMD -> >>>> [ffff880002e00000-ffff8800031fffff] on node 0 >>>> [ffffe20001c00000-ffffe20001ffffff] PMD -> >>>> [ffff880003000000-ffff8800033fffff] on node 0 >>>> [ffffe20001e00000-ffffe200021fffff] PMD -> >>>> [ffff880003200000-ffff8800035fffff] on node 0 >>>> [ffffe20002000000-ffffe200023fffff] PMD -> >>>> [ffff880003400000-ffff8800037fffff] on node 0 >>>> [ffffe20002200000-ffffe200025fffff] PMD -> >>>> [ffff880003600000-ffff8800039fffff] on node 0 >>>> [ffffe20002400000-ffffe200027fffff] PMD -> >>>> [ffff880003800000-ffff880003bfffff] on node 0 >>>> [ffffe20002600000-ffffe200029fffff] PMD -> >>>> [ffff880003a00000-ffff880003dfffff] on node 0 >>>> [ffffe20002800000-ffffe20002bfffff] PMD -> >>>> [ffff880003c00000-ffff880003ffffff] on node 0 >>>> [ffffe20002a00000-ffffe20002dfffff] PMD -> >>>> [ffff880003e00000-ffff8800041fffff] on node 0 >>>> [ffffe20002c00000-ffffe20002ffffff] PMD -> >>>> [ffff880004000000-ffff8800043fffff] on node 0 >>>> [ffffe20002e00000-ffffe200039fffff] PMD -> >>>> [ffff880004200000-ffff8800045fffff] on node 0 >>>> [ffffe20003800000-ffffe20003bfffff] PMD -> >>>> [ffff880004400000-ffff8800047fffff] on node 0 >>>> [ffffe20003a00000-ffffe20003dfffff] PMD -> >>>> [ffff880004600000-ffff8800049fffff] on node 0 >>>> [ffffe20003c00000-ffffe20003ffffff] PMD -> >>>> [ffff880004800000-ffff880004bfffff] on node 0 >>>> [ffffe20003e00000-ffffe200041fffff] PMD -> >>>> [ffff880004a00000-ffff880004dfffff] on node 0 >>>> [ffffe20004000000-ffffe200043fffff] PMD -> >>>> [ffff880004c00000-ffff880004ffffff] on node 0 >>>> [ffffe20004200000-ffffe200045fffff] PMD -> >>>> [ffff880004e00000-ffff8800051fffff] on node 0 >>>> [ffffe20004400000-ffffe200047fffff] PMD -> >>>> [ffff880005000000-ffff8800053fffff] on node 0 >>>> [ffffe20004600000-ffffe200049fffff] PMD -> >>>> [ffff880005200000-ffff8800055fffff] on node 0 >>>> [ffffe20004800000-ffffe20004bfffff] PMD -> >>>> [ffff880005400000-ffff8800057fffff] on node 0 >>>> [ffffe20004a00000-ffffe20004dfffff] PMD -> >>>> [ffff880005600000-ffff8800059fffff] on node 0 >>>> [ffffe20004c00000-ffffe20004ffffff] PMD -> >>>> [ffff880005800000-ffff880005bfffff] on node 0 >>>> [ffffe20004e00000-ffffe200051fffff] PMD -> >>>> [ffff880005a00000-ffff880005dfffff] on node 0 >>>> [ffffe20005000000-ffffe200053fffff] PMD -> >>>> [ffff880005c00000-ffff880005ffffff] on node 0 >>>> [ffffe20005200000-ffffe200055fffff] PMD -> >>>> [ffff880005e00000-ffff8800061fffff] on node 0 >>>> [ffffe20005400000-ffffe200057fffff] PMD -> >>>> [ffff880006000000-ffff8800063fffff] on node 0 >>>> [ffffe20005600000-ffffe200059fffff] PMD -> >>>> [ffff880006200000-ffff8800065fffff] on node 0 >>>> [ffffe20005800000-ffffe20005bfffff] PMD -> >>>> [ffff880006400000-ffff8800067fffff] on node 0 >>>> [ffffe20005a00000-ffffe20005dfffff] PMD -> >>>> [ffff880006600000-ffff8800069fffff] on node 0 >>>> [ffffe20005c00000-ffffe20005ffffff] PMD -> >>>> [ffff880006800000-ffff880006bfffff] on node 0 >>>> [ffffe20005e00000-ffffe200061fffff] PMD -> >>>> [ffff880006a00000-ffff880006dfffff] on node 0 >>>> [ffffe20006000000-ffffe200063fffff] PMD -> >>>> [ffff880006c00000-ffff880006ffffff] on node 0 >>>> [ffffe20006200000-ffffe200065fffff] PMD -> >>>> [ffff880006e00000-ffff8800071fffff] on node 0 >>>> [ffffe20006400000-ffffe200067fffff] PMD -> >>>> [ffff880007000000-ffff8800073fffff] on node 0 >>>> [ffffe20006600000-ffffe200069fffff] PMD -> >>>> [ffff880007200000-ffff8800075fffff] on node 0 >>>> [ffffe20006800000-ffffe20006bfffff] PMD -> >>>> [ffff880007400000-ffff8800077fffff] on node 0 >>>> [ffffe20006a00000-ffffe20006dfffff] PMD -> >>>> [ffff880007600000-ffff8800079fffff] on node 0 >>>> [ffffe20006c00000-ffffe20006ffffff] PMD -> >>>> [ffff880007800000-ffff880007bfffff] on node 0 >>>> [ffffe20006e00000-ffffe200071fffff] PMD -> >>>> [ffff880007a00000-ffff880007dfffff] on node 0 >>>> [ffffe20007000000-ffffe200073fffff] PMD -> >>>> [ffff880007c00000-ffff880007ffffff] on node 0 >>>> [ffffe20007200000-ffffe200075fffff] PMD -> >>>> [ffff880007e00000-ffff8800081fffff] on node 0 >>>> [ffffe20007400000-ffffe200077fffff] PMD -> >>>> [ffff880008000000-ffff8800083fffff] on node 0 >>>> [ffffe20007600000-ffffe200079fffff] PMD -> >>>> [ffff880008200000-ffff8800085fffff] on node 0 >>>> [ffffe200078c0000-ffffe200079fffff] potential offnode page_structs >>>> [ffffe20007800000-ffffe20007bfffff] PMD -> >>>> [ffff880008400000-ffff8802283fffff] on node 0 >>>> [ffffe20007a00000-ffffe20007dfffff] PMD -> >>>> [ffff880228200000-ffff8802285fffff] on node 1 >>>> [ffffe20007c00000-ffffe20007ffffff] PMD -> >>>> [ffff880228400000-ffff8802287fffff] on node 1 >>>> [ffffe20007e00000-ffffe200081fffff] PMD -> >>>> [ffff880228600000-ffff8802289fffff] on node 1 >>>> [ffffe20008000000-ffffe200083fffff] PMD -> >>>> [ffff880228800000-ffff880228bfffff] on node 1 >>>> [ffffe20008200000-ffffe200085fffff] PMD -> >>>> [ffff880228a00000-ffff880228dfffff] on node 1 >>>> [ffffe20008400000-ffffe200087fffff] PMD -> >>>> [ffff880228c00000-ffff880228ffffff] on node 1 >>>> [ffffe20008600000-ffffe200089fffff] PMD -> >>>> [ffff880228e00000-ffff8802291fffff] on node 1 >>>> [ffffe20008800000-ffffe20008bfffff] PMD -> >>>> [ffff880229000000-ffff8802293fffff] on node 1 >>>> [ffffe20008a00000-ffffe20008dfffff] PMD -> >>>> [ffff880229200000-ffff8802295fffff] on node 1 >>>> [ffffe20008c00000-ffffe20008ffffff] PMD -> >>>> [ffff880229400000-ffff8802297fffff] on node 1 >>>> [ffffe20008e00000-ffffe200091fffff] PMD -> >>>> [ffff880229600000-ffff8802299fffff] on node 1 >>>> [ffffe20009000000-ffffe200093fffff] PMD -> >>>> [ffff880229800000-ffff880229bfffff] on node 1 >>>> [ffffe20009200000-ffffe200095fffff] PMD -> >>>> [ffff880229a00000-ffff880229dfffff] on node 1 >>>> [ffffe20009400000-ffffe200097fffff] PMD -> >>>> [ffff880229c00000-ffff880229ffffff] on node 1 >>>> [ffffe20009600000-ffffe200099fffff] PMD -> >>>> [ffff880229e00000-ffff88022a1fffff] on node 1 >>>> [ffffe20009800000-ffffe20009bfffff] PMD -> >>>> [ffff88022a000000-ffff88022a3fffff] on node 1 >>>> [ffffe20009a00000-ffffe20009dfffff] PMD -> >>>> [ffff88022a200000-ffff88022a5fffff] on node 1 >>>> [ffffe20009c00000-ffffe20009ffffff] PMD -> >>>> [ffff88022a400000-ffff88022a7fffff] on node 1 >>>> [ffffe20009e00000-ffffe2000a1fffff] PMD -> >>>> [ffff88022a600000-ffff88022a9fffff] on node 1 >>>> [ffffe2000a000000-ffffe2000a3fffff] PMD -> >>>> [ffff88022a800000-ffff88022abfffff] on node 1 >>>> [ffffe2000a200000-ffffe2000a5fffff] PMD -> >>>> [ffff88022aa00000-ffff88022adfffff] on node 1 >>>> [ffffe2000a400000-ffffe2000a7fffff] PMD -> >>>> [ffff88022ac00000-ffff88022affffff] on node 1 >>>> [ffffe2000a600000-ffffe2000a9fffff] PMD -> >>>> [ffff88022ae00000-ffff88022b1fffff] on node 1 >>>> [ffffe2000a800000-ffffe2000abfffff] PMD -> >>>> [ffff88022b000000-ffff88022b3fffff] on node 1 >>>> [ffffe2000aa00000-ffffe2000adfffff] PMD -> >>>> [ffff88022b200000-ffff88022b5fffff] on node 1 >>>> [ffffe2000ac00000-ffffe2000affffff] PMD -> >>>> [ffff88022b400000-ffff88022b7fffff] on node 1 >>>> [ffffe2000ae00000-ffffe2000b1fffff] PMD -> >>>> [ffff88022b600000-ffff88022b9fffff] on node 1 >>>> [ffffe2000b000000-ffffe2000b3fffff] PMD -> >>>> [ffff88022b800000-ffff88022bbfffff] on node 1 >>>> [ffffe2000b200000-ffffe2000b5fffff] PMD -> >>>> [ffff88022ba00000-ffff88022bdfffff] on node 1 >>>> [ffffe2000b400000-ffffe2000b7fffff] PMD -> >>>> [ffff88022bc00000-ffff88022bffffff] on node 1 >>>> [ffffe2000b600000-ffffe2000b9fffff] PMD -> >>>> [ffff88022be00000-ffff88022c1fffff] on node 1 >>>> [ffffe2000b800000-ffffe2000bbfffff] PMD -> >>>> [ffff88022c000000-ffff88022c3fffff] on node 1 >>>> [ffffe2000ba00000-ffffe2000bdfffff] PMD -> >>>> [ffff88022c200000-ffff88022c5fffff] on node 1 >>>> [ffffe2000bc00000-ffffe2000bffffff] PMD -> >>>> [ffff88022c400000-ffff88022c7fffff] on node 1 >>>> [ffffe2000be00000-ffffe2000c1fffff] PMD -> >>>> [ffff88022c600000-ffff88022c9fffff] on node 1 >>>> [ffffe2000c000000-ffffe2000c3fffff] PMD -> >>>> [ffff88022c800000-ffff88022cbfffff] on node 1 >>>> [ffffe2000c200000-ffffe2000c5fffff] PMD -> >>>> [ffff88022ca00000-ffff88022cdfffff] on node 1 >>>> [ffffe2000c400000-ffffe2000c7fffff] PMD -> >>>> [ffff88022cc00000-ffff88022cffffff] on node 1 >>>> [ffffe2000c600000-ffffe2000c9fffff] PMD -> >>>> [ffff88022ce00000-ffff88022d1fffff] on node 1 >>>> [ffffe2000c800000-ffffe2000cbfffff] PMD -> >>>> [ffff88022d000000-ffff88022d3fffff] on node 1 >>>> [ffffe2000ca00000-ffffe2000cdfffff] PMD -> >>>> [ffff88022d200000-ffff88022d5fffff] on node 1 >>>> [ffffe2000cc00000-ffffe2000cffffff] PMD -> >>>> [ffff88022d400000-ffff88022d7fffff] on node 1 >>>> [ffffe2000ce00000-ffffe2000d1fffff] PMD -> >>>> [ffff88022d600000-ffff88022d9fffff] on node 1 >>>> [ffffe2000d000000-ffffe2000d3fffff] PMD -> >>>> [ffff88022d800000-ffff88022dbfffff] on node 1 >>>> [ffffe2000d200000-ffffe2000d5fffff] PMD -> >>>> [ffff88022da00000-ffff88022ddfffff] on node 1 >>>> [ffffe2000d400000-ffffe2000d7fffff] PMD -> >>>> [ffff88022dc00000-ffff88022dffffff] on node 1 >>>> [ffffe2000d600000-ffffe2000d9fffff] PMD -> >>>> [ffff88022de00000-ffff88022e1fffff] on node 1 >>>> [ffffe2000d800000-ffffe2000dbfffff] PMD -> >>>> [ffff88022e000000-ffff88022e3fffff] on node 1 >>>> [ffffe2000da00000-ffffe2000ddfffff] PMD -> >>>> [ffff88022e200000-ffff88022e5fffff] on node 1 >>>> [ffffe2000dc00000-ffffe2000dffffff] PMD -> >>>> [ffff88022e400000-ffff88022e7fffff] on node 1 >>>> [ffffe2000de00000-ffffe2000e1fffff] PMD -> >>>> [ffff88022e600000-ffff88022e9fffff] on node 1 >>>> [ffffe2000e000000-ffffe2000e3fffff] PMD -> >>>> [ffff88022e800000-ffff88022ebfffff] on node 1 >>>> [ffffe2000e200000-ffffe2000e5fffff] PMD -> >>>> [ffff88022ea00000-ffff88022edfffff] on node 1 >>>> [ffffe2000e400000-ffffe2000e7fffff] PMD -> >>>> [ffff88022ec00000-ffff88022effffff] on node 1 >>>> [ffffe2000e600000-ffffe2000e9fffff] PMD -> >>>> [ffff88022ee00000-ffff88022f1fffff] on node 1 >>>> [ffffe2000e800000-ffffe2000e9fffff] PMD -> >>>> [ffff88022f000000-ffff88022f1fffff] on node 1 >>>> >>>> should have >>>> >>>> [ffffe20000000000-ffffe27fffffffff] PGD ->ffff8100011ce000 on node 0 >>>> [ffffe20000000000-ffffe2003fffffff] PUD ->ffff8100011cf000 on node 0 >>>> [ffffe200078c0000-ffffe200079fffff] potential offnode page_structs >>>> [ffffe20000000000-ffffe200079fffff] PMD -> >>>> [ffff810001200000-ffff8100083fffff] on node 0 >>>> [ffffe20007a00000-ffffe2000e9fffff] PMD -> >>>> [ffff810228200000-ffff81022f1fffff] on node 1 >>>> >>> >>> I haven''t seen those messages before. Can you explain what they mean? >>> >> >> that is for SPARSEMEM virtual memmap... >> >> CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y >> CONFIG_SPARSEMEM_VMEMMAP=y >> > > I modified the vmemmap code so it would create 4k mappings if PSE isn''t > supported. Did I get it wrong? It should have no effect when PSE is > available (which is any time you''re not running under Xen). >it could be address continuous checkup for printout in vmemmap_populated has some problem... YH _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yinghai Lu
2008-Jul-03 19:19 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
On Thu, Jul 3, 2008 at 11:51 AM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:> On Thu, Jul 3, 2008 at 11:41 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:..>> I modified the vmemmap code so it would create 4k mappings if PSE isn''t >> supported. Did I get it wrong? It should have no effect when PSE is >> available (which is any time you''re not running under Xen). >> > > it could be address continuous checkup for printout in > vmemmap_populated has some problem...you moved p_end = p + PMD_SIZE before... if (p_end != p || node_start != node) { YH _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Yinghai Lu
2008-Jul-03 19:29 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
On Thu, Jul 3, 2008 at 12:19 PM, Yinghai Lu <yhlu.kernel@gmail.com> wrote:> On Thu, Jul 3, 2008 at 11:51 AM, Yinghai Lu <yhlu.kernel@gmail.com> wrote: >> On Thu, Jul 3, 2008 at 11:41 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > .. >>> I modified the vmemmap code so it would create 4k mappings if PSE isn''t >>> supported. Did I get it wrong? It should have no effect when PSE is >>> available (which is any time you''re not running under Xen). >>> >> >> it could be address continuous checkup for printout in >> vmemmap_populated has some problem... > > you moved p_end = p + PMD_SIZE before... > > if (p_end != p || node_start != node) {Ingo, please put attached patch after jeremy''s xen pv64 patches. YH _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ingo Molnar
2008-Jul-09 07:42 UTC
Re: [Xen-devel] Re: [PATCH 00 of 36] x86/paravirt: groundwork for 64-bit Xen support
* Yinghai Lu <yhlu.kernel@gmail.com> wrote:> >> it could be address continuous checkup for printout in > >> vmemmap_populated has some problem... > > > > you moved p_end = p + PMD_SIZE before... > > > > if (p_end != p || node_start != node) { > > Ingo, > > please put attached patch after jeremy''s xen pv64 patches. > > YH> [PATCH] x86: fix vmemmap printout checkapplied, thanks. Ingo _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel