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

[Vaibhav Bedia <vaibhav.bedia@xxxxxxxxx>]

On Mon, Dec 2, 2013 at 8:13 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 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 ;-)

Heh i was wondering whether i should just give that a shot. This has
apparently been fixed in 13.10 release. I'll go with the quick hack for now ;)

>> >> 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);
>  }
>

Ok i'll add in this diff.

>
>> [...]
>
>> (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.
>

I'll check once my dom0 rebuild completes.
I really should keep the system map around a bit longer.

Regards,
Vaibhav

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