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

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



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.

> >  
> > > >    
> > > >  #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.

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.

Is this causing you problems?

Ian.


_______________________________________________
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®.