[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen on ARM basic questions



On Mon, 2013-12-02 at 08:02 -0500, Vaibhav Bedia wrote:

> I currently get
> /usr/include/libfdt.h:54:24: fatal error: libfdt_env.h: No such file
> or directory
> 
> Google tells me this was bug in the library build [1]... trying to figure
> out how to get this sorted out.

I keep hitting this, I just grabbed the source and copied libfdt_env.h
to /usr/include. Works for me ;-)
> >> vcpus = 1
> >> vif = [ 'bridge=xenbr0','mac=00:16:3e:23:24:32']
> >
> > This is actually creating two vifs. One one xenbr0 with a random mac and
> > one with the given mac address on the default bridge (probably xenbr0!)
> >
> > You probably wanted:
> >         vif = [ 'bridge=xenbr0,mac=00:16:3e:23:24:32']
> > Or just:
> >         vif = [ 'mac=00:16:3e:23:24:32']
> > which works because xenbr0 is the default bridge.
> >
> 
> Ok. I wanted only one vif. Didn't realize this was creating two of those.
> 
> Now that i get the console in the ubuntu filesystem for domU i was
> hoping to dig deeper into the "unable to ping" domU problem.
> 
> My fresh builds of the kernels for dom0 and domU seems to have
> uncovered some other issue since i just can't get a reliable domU
> boot now. Right now most of the domU creation hangs and it also
> kills off dom0. I have a heartbeat led in dom0 and that just stops -
> i can switch to xen using ctrl-a keystrokes and back but the dom0
> seems to have crashed.
> 
> Any suggestions on how to debug this? There are few "failed to unmap"
> messages when creating domUs but i don't know how to debug this :(

Yes, these are annoying. In the absence of a proper fix I've been:
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 8e74590..7b383bf 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -533,11 +533,16 @@ static void privcmd_close(struct vm_area_struct *vma)
 {
        struct page **pages = vma->vm_private_data;
        int numpgs = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+       int rc;
 
        if (!xen_feature(XENFEAT_auto_translated_physmap) || !numpgs || !pages)
                return;
 
-       xen_unmap_domain_mfn_range(vma, numpgs, pages);
+       rc = xen_unmap_domain_mfn_range(vma, numpgs, pages);
+       if (rc < 0) {
+               pr_crit("PRIVCMD: leaking %d pages\n", numpgs);
+               return;
+       }
        free_xenballooned_pages(numpgs, pages);
        kfree(pages);
 }


> [...]

> (XEN) *** Dumping CPU0 guest state (d0:v0): ***
> (XEN) ----[ Xen-4.4-unstable  arm32  debug=y  Not tainted ]----
> (XEN) CPU:    0
> (XEN) PC:     c0097518

Does this address correspond to anything interesting in the dom0 kernel?
That might give some hint where it has gotten stuck.

> (XEN) CPSR:   60000193 MODE:32-bit Guest SVC
> (XEN)      R0: 00000018 R1: 00000478 R2: 00000000 R3: c09008e8
> (XEN)      R4: c09008e8 R5: c08f2000 R6: c1322a04 R7: c04f784c
> (XEN)      R8: 60000193 R9: c099c4c4 R10:00000001 R11:c08f3e64 R12:60000193
> (XEN) USR: SP: be9724f8 LR: b6f01234
> (XEN) SVC: SP: c08f3de8 LR: c05e7120 SPSR:60000113
> (XEN) ABT: SP: c0997a0c LR: c05e7a80 SPSR:80000193
> (XEN) UND: SP: c0997a18 LR: c05e78e0 SPSR:80070093
> (XEN) IRQ: SP: c0997a00 LR: c05e76c0 SPSR:60000193
> (XEN) FIQ: SP: 00000000 LR: 00000000 SPSR:00000000
> (XEN) FIQ: R8: 00000000 R9: 00000000 R10:00000000 R11:00000000 R12:00000000
> (XEN)
> (XEN)      SCTLR: 10c5387d
> (XEN)        TCR: 00000000
> (XEN)      TTBR0: 000000009d27406a
> (XEN)      TTBR1: 000000008000406a
> (XEN)       IFAR: b6eb1aa0, IFSR: 00000007
> (XEN)       DFAR: b6c00008, DFSR: 00000817
> (XEN)
> (XEN)   VTCR_EL2: 80002558
> (XEN)  VTTBR_EL2: 00010000a200e000
> (XEN)
> (XEN)  SCTLR_EL2: 30cd187f
> (XEN)    HCR_EL2: 0000000000282835
> (XEN)  TTBR0_EL2: 00000000feedf000
> (XEN)
> (XEN)    ESR_EL2: 07e00000
> (XEN)  HPFAR_EL2: 0000000000482110
> (XEN)      HDFAR: d0800100
> (XEN)      HIFAR: 00000000
> (XEN)
> (XEN) No stack trace for 32-bit guest kernel-mode
> (XEN)



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.