Re: [Xen-devel] two questions about xen on arm

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-11-01 at 05:38 -0600, Bamvor Jian Zhang wrote:
>  >>>Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote: 
> > On Fri, 2013-11-01 at 04:34 -0600, Bamvor Jian Zhang wrote: 
> > >  
> > >  >>>Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:  
> > > > On Fri, 2013-11-01 at 01:54 -0600, Bamvor Jian Zhang wrote:  
> > > > > fix destination.   
> > > > > sorry, i sent it to the wrong address.   
> > > > >   
> > > > >  >>>Bamvor Jian Zhang wrote:   
> > > > > > hi,   
> > > > > >     
> > > > > > recently, i got xen running on allwinner A20 successful[1], and i   
> > > > > > have two questions:   
> > > > > >    
> > > > > > 1, how to get guest stack trace?   
> > > > > > i could get the guest stack trace with the following patch, is it   
> > > > > > make sense?  
> > > >   
> > > > The only issue would be that it prints 8-byte words for a 32-on-64  
> > > > guest. That as it is much better than nothing, we can live with it for  
> > > > sure.  
> > > >   
> > > > >  and i could only get the dom0 kernel trace, how could   
> > > > > > i get the domU kernel trace?    
> > > >   
> > > > This code should work equally well for any guest AFAICT, what issue are 
> > > >  
> > > > you seeing?  
> > > i mean if i have booted a domU, could i get such specific domain stack  
> > trace?  
> > > i only get the dom0 stack trace throught "xl debug-keys d" every time, 
> > > even  
> > if 
> > > domU crash(user maybe want  
> > > the domU stack at that time). or should i use other tools for it?  
> >  
> > "xl debug-keys d" makes a hypercall which necessarily ensures that the 
> > domain making the call (dom0) is scheduled at the time and 'd' only 
> > prints the currently running vcpus. If you use the 'd' key from the 
> > debug console (Ctrl-A three times) while the guest is running you should 
> > occasionally see the guest too. 
> >  
> > But I don't think the d key will ever show a crashed domain, since it 
> > isn't ever going to be scheduled. You probably want to use the xenctx 
> > tool for this case. 
> thanks for explanation. i will try it.
> i just read the code: xenctx support arm and aarch64, but set the
> wrong default value of kernel_start in 32bit arm, do we need this:

yes, I suppose so.

I expect we need to handle the __aarch64__ case too, the ...fffff8000...
is the x86_64 number.

> diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
> index 1214185..a749e93 100644
> --- a/tools/xentrace/xenctx.c
> +++ b/tools/xentrace/xenctx.c
> @@ -69,7 +69,7 @@ struct symbol {
>  
>  guest_word_t kernel_stext, kernel_etext, kernel_sinittext, kernel_einittext, 
> kernel_hypercallpage;
>  
> -#if defined (__i386__)
> +#if defined (__i386__) || defined (__arm__) 
>  unsigned long long kernel_start = 0xc0000000;
>  #else
>  unsigned long long kernel_start = 0xffffffff80000000UL;
> 
> > > >   
> > > > > >     
> > > > > >  #ifdef CONFIG_ARM_64   
> > > > > >      case PSR_MODE_EL1t:   
> > > > > >    
> > > > > > 2, xen kernel config   
> > > > > > i am confuse about what does "CONFIG XEN" mean. it  will check the  
> > kernel    
> > > >   
> > > > > > features for dom0 and domU kernel(mix XEN_BANDEND and XXX_FRONTEND) 
> > > > > >   
> > > > > > should we define XEN_DOM0 and XEN_DOMU configs respectively?    
> > > >   
> > > > I'm not sure what you mean, but yes, if you want to run Xen you should  
> > > > enable the relevant CONFIG options, including CONFIG_XEN and I think  
> > > > CONFIG_XEN_DOM0.  
> > > i mean when i select the CONFIG_XEN in kernel config, both XEN_BACKEND 
> > > and 
> > > XEN_xxx_FRONTEND will be selected.  
> > > i think backend and frontend should not select at the same time, isn't 
> > > it?  
> >  
> > I think (but I'm not sure) that these are just umbrella options which 
> > don't add any code themselves but just make the other more specific e.g. 
> > netback) options. 
> it is compiled into kernel, but it might be no harm?

If you don't boot under Xen then none of the code will be (should be!)
active. If you are booting under Xen then I think it is expected?

> CONFIG_XEN_BACKEND will select xenbus_probe_backend.c and
> xenbus_dev_backend.c, xenbus_probe_backend.c will register the
> "xen-backend" bus. is it unused until the xen backend device
> registered? 
> and xenbus_backend_init(xenbus_dev_backend.c) will fail if it
> is not the initial domain.
> > In any case, I think anyone enabling CONFIG_XEN would expect to get the 
> > rest of the Xen stuff by default. Or at least a basic working subset. 
> yes, i think so.
> >  
> > Is this causing you problems? 
> >  
> > Ian. 
> >  
> >  
> > _______________________________________________ 
> > Xen-devel mailing list 
> > Xen-devel@xxxxxxxxxxxxx 
> > http://lists.xen.org/xen-devel 
> >  
> >  
> 



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