On Fri, Apr 29, 2011 at 07:08:29PM -0400, Scott Garron wrote:
> On 04/29/2011 03:38 PM, Dan Magenheimer wrote:
> >Since you are using dom0_mem, there really should be no reason why
> >the balloon driver needs to get initialized. For the balloon driver
> >to work properly, it needs a correct E820 map and there have been
> >recent upstream changes in the balloon driver involving E820. If we
> >assume that your E820 map is indeed broken, the easiest fix for your
> >machine might be just to modify balloon_init in dom0 to immediately
> >fail (and return -ENODEV).
>
> Returning -ENODEV at the beginning of balloon_init() did allow the
> machine to boot, but something is definitely still amiss:
>
> Trying to start any domUs yields:
>
> simba@hailstorm:~$ sudo xm create test.cfg
> Using config file "/etc/xen/test.cfg".
> Error: Failed to query current memory allocation of dom0.
>
> Oddly enough, xencommons and xend started and xm list and xm info
> show everything correctly.
That is probably b/c 'xm' tries to touch /sys/.../target_kb and since
the balloon code never got to run that sysfs does not exist. So 'xm'
bails out.
>
> And this is just bizarre...
>
> simba@hailstorm:~$ free
> total used free shared buffers cached
> Mem: 552 18014398509158460 324076 0 11428
> 34656
> -/+ buffers/cache: 18014398509112376 370160
> Swap: 0 0 0
>
>
> I just tried grabbing the most recent BIOS revision from Tyan for
> this motherboard (was running 2882_306, flashed it to 2882_309). Same
> results.
This is quite baffling. The failure you get:
[ 0.490020] BUG: unable to handle kernel paging request at 0000000003800028
[ 0.493331] IP: [<ffffffff812d89fa>] __balloon_append+0x3f/0x52
[ 0.493331] PGD 0
Tells us that the entry in the PGD, so in init_level4_pgt[3] is zero instead
of having a PFN/MFN in it.
But earlier on:
[ 0.000000] init_memory_mapping: 0000000100000000-00000001d9ff0000
[ 0.000000] 0100000000 - 01d9ff0000 page 4k
[ 0.000000] kernel direct mapping tables up to 1d9ff0000 @ dafa000-e9d3000
It tells us that the pages have been indeed filled up with the right values.
But perhaps the values for the entries past the 4G are filled with zero, which
might be the case as in (pte_pfn_to_mfn):
* If there's no mfn for the pfn, then just create an
802 * empty non-present pte. Unfortunately this loses
803 * information about the original pfn, so
804 * pte_mfn_to_pfn is asymmetric.
805 */
806 if (unlikely(mfn == INVALID_P2M_ENTRY)) {
807 mfn = 0;
808 flags = 0;
809 }
810
Which is correct... we should fill those entries with zero as they don't exist.
Hmm..
But in the meantime, try the attached patch (not compile tested). It should
give us an idea what is happening with the allocation. The theory is that
'kernel_physical_mapping_init' in init_64.c when it calls:
563 pgd_populate(&init_mm, pgd, __va(pud_phys));
and then:
#if PAGETABLE_LEVELS > 3
111 static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t
*pud)
112 {
113 paravirt_alloc_pud(mm, __pa(pud) >> PAGE_SHIFT);
--> 114 set_pgd(pgd, __pgd(_PAGE_TABLE | __pa(pud))); <<---
115 }
ends with an set_pgd(pgd, 0) instead of the proper pointer value being
programmed.. which would imply that the location (so __pa(pud)) is zero
instead of a physical location.
Anyhow, try this patch below. Should give us some ideas. Not compile tested.
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 204e3ba..7a8177c 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -806,6 +806,8 @@ static pteval_t pte_pfn_to_mfn(pteval_t val)
if (unlikely(mfn == INVALID_P2M_ENTRY)) {
mfn = 0;
flags = 0;
+ printk(KERN_INFO "%s: 0x%lx is INVALID for %llx\n",
+ ___func__, pfn, (unsigned long)val);
}
val = ((pteval_t)mfn << PAGE_SHIFT) | flags;
@@ -935,6 +937,7 @@ void xen_set_pud_hyper(pud_t *ptr, pud_t val)
/* ptr may be ioremapped for 64-bit pagetable setup */
u.ptr = arbitrary_virt_to_machine(ptr).maddr;
u.val = pud_val_ma(val);
+ printk(KERN_INFO "%s: %lx, %lx\n", __func__, u.ptr, u.val);
xen_extend_mmu_update(&u);
ADD_STATS(pud_update_batched, paravirt_get_lazy_mode() ==
PARAVIRT_LAZY_MMU);
@@ -1889,6 +1892,7 @@ static __init void xen_alloc_pmd_init(struct mm_struct
*mm, unsigned long pfn)
#ifdef CONFIG_FLATMEM
BUG_ON(mem_map); /* should only be used early */
#endif
+ printk(KERN_INFO "%s: %lx set for PGD/PMD\n", __func__, pfn);
make_lowmem_page_readonly(__va(PFN_PHYS(pfn)));
}
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home