Re: two questions about xen on arm

Re: two questions about xen on arm

[Bamvor Jian Zhang]

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? and i could only get the dom0 kernel trace, how could 
> i get the domU kernel trace?  
>  
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c 
> index 4c0fc32..287dd7b 100644 
> --- a/xen/arch/arm/traps.c 
> +++ b/xen/arch/arm/traps.c 
> @@ -629,12 +629,20 @@ static void show_guest_stack(struct vcpu *v, struct  
> cpu_user_regs *regs) 
>          return; 
>   
>      case PSR_MODE_FIQ: 
> +        sp = regs->sp_fiq; 
> +        break; 
>      case PSR_MODE_IRQ: 
> +        sp = regs->sp_irq; 
> +        break; 
>      case PSR_MODE_SVC: 
> +        sp = regs->sp_svc; 
> +        break; 
>      case PSR_MODE_ABT: 
> +        sp = regs->sp_abt; 
> +        break; 
>      case PSR_MODE_UND: 
> -        printk("No stack trace for 32-bit guest kernel-mode\n"); 
> -        return; 
> +        sp = regs->sp_und; 
> +        break; 
>   
>  #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?  
>  
> --- .config	2013-11-01 14:57:28.489573665 +0800 
> +++ xen_config	2013-11-01 14:57:00.781238549 +0800 
> @@ -579,6 +579,7 @@ 
>  # CONFIG_PHYS_ADDR_T_64BIT is not set 
>  CONFIG_ZONE_DMA_FLAG=1 
>  CONFIG_BOUNCE=y 
> +CONFIG_MMU_NOTIFIER=y 
>  # CONFIG_KSM is not set 
>  CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 
>  CONFIG_CROSS_MEMORY_ATTACH=y 
> @@ -591,7 +592,8 @@ 
>  # CONFIG_UACCESS_WITH_MEMCPY is not set 
>  # CONFIG_SECCOMP is not set 
>  # CONFIG_CC_STACKPROTECTOR is not set 
> -# CONFIG_XEN is not set 
> +CONFIG_XEN_DOM0=y 
> +CONFIG_XEN=y 
>   
>  # 
>  # Boot options 
> @@ -810,7 +812,7 @@ 
>  CONFIG_FW_LOADER_USER_HELPER=y 
>  # CONFIG_DEBUG_DRIVER is not set 
>  # CONFIG_DEBUG_DEVRES is not set 
> -# CONFIG_SYS_HYPERVISOR is not set 
> +CONFIG_SYS_HYPERVISOR=y 
>  # CONFIG_GENERIC_CPU_DEVICES is not set 
>  CONFIG_SOC_BUS=y 
>  CONFIG_REGMAP=y 
> @@ -853,6 +855,8 @@ 
>  # CONFIG_CDROM_PKTCDVD is not set 
>  # CONFIG_ATA_OVER_ETH is not set 
>  # CONFIG_MG_DISK is not set 
> +CONFIG_XEN_BLKDEV_FRONTEND=y 
> +# CONFIG_XEN_BLKDEV_BACKEND is not set 
>  # CONFIG_BLK_DEV_RBD is not set 
>   
>  # 
> @@ -1127,6 +1131,8 @@ 
>  # Enable WiMAX (Networking options) to see the WiMAX drivers 
>  # 
>  # CONFIG_WAN is not set 
> +CONFIG_XEN_NETDEV_FRONTEND=y 
> +# CONFIG_XEN_NETDEV_BACKEND is not set 
>  # CONFIG_ISDN is not set 
>   
>  # 
> @@ -1281,6 +1287,10 @@ 
>  CONFIG_SERIAL_FSL_LPUART=y 
>  CONFIG_SERIAL_FSL_LPUART_CONSOLE=y 
>  # CONFIG_SERIAL_ST_ASC is not set 
> +CONFIG_HVC_DRIVER=y 
> +CONFIG_HVC_IRQ=y 
> +CONFIG_HVC_XEN=y 
> +CONFIG_HVC_XEN_FRONTEND=y 
>  # CONFIG_HVC_DCC is not set 
>  # CONFIG_IPMI_HANDLER is not set 
>  CONFIG_HW_RANDOM=y 
> @@ -1807,7 +1817,8 @@ 
>  CONFIG_FB_SYS_COPYAREA=y 
>  CONFIG_FB_SYS_IMAGEBLIT=y 
>  # CONFIG_FB_FOREIGN_ENDIAN is not set 
> -# CONFIG_FB_SYS_FOPS is not set 
> +CONFIG_FB_SYS_FOPS=y 
> +CONFIG_FB_DEFERRED_IO=y 
>  # CONFIG_FB_SVGALIB is not set 
>  # CONFIG_FB_MACMODES is not set 
>  # CONFIG_FB_BACKLIGHT is not set 
> @@ -1829,6 +1840,7 @@ 
>  # CONFIG_FB_GOLDFISH is not set 
>  # CONFIG_FB_DA8XX is not set 
>  # CONFIG_FB_VIRTUAL is not set 
> +CONFIG_XEN_FBDEV_FRONTEND=y 
>  # CONFIG_FB_METRONOME is not set 
>  CONFIG_FB_MX3=y 
>  # CONFIG_FB_BROADSHEET is not set 
> @@ -2255,6 +2267,19 @@ 
>  # 
>  # Microsoft Hyper-V guest support 
>  # 
> + 
> +# 
> +# Xen driver support 
> +# 
> +CONFIG_XEN_DEV_EVTCHN=y 
> +CONFIG_XEN_BACKEND=y 
> +CONFIG_XENFS=y 
> +CONFIG_XEN_COMPAT_XENFS=y 
> +CONFIG_XEN_SYS_HYPERVISOR=y 
> +CONFIG_XEN_XENBUS_FRONTEND=y 
> +CONFIG_XEN_GNTDEV=y 
> +CONFIG_XEN_GRANT_DEV_ALLOC=y 
> +CONFIG_XEN_PRIVCMD=y 
>  # CONFIG_STAGING is not set 
>  CONFIG_CLKDEV_LOOKUP=y 
>  CONFIG_HAVE_CLK_PREPARE=y 
>  
> [1]  
> http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions/Allwinn 
> er 
>  
> best regards 
>  
> bamvor 
>  
>  

Re: two questions about xen on arm

[Ian Campbell]

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?

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

Ian.

Re: two questions about xen on arm

[Bamvor Jian Zhang]

 >>>Ian Campbell <Ian.Campbell@citrix.com> 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? 
>  
> > >    
> > >  #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? 
>  
> Ian. 
>  
>  
> _______________________________________________ 
> Xen-devel mailing list 
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  

Re: two questions about xen on arm

[Ian Campbell]

On Fri, 2013-11-01 at 04:34 -0600, Bamvor Jian Zhang wrote:
> 
>  >>>Ian Campbell <Ian.Campbell@citrix.com> 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.

Re: two questions about xen on arm

[Bamvor Jian Zhang]

 >>>Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> On Fri, 2013-11-01 at 04:34 -0600, Bamvor Jian Zhang wrote: 
> >  
> >  >>>Ian Campbell <Ian.Campbell@citrix.com> 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:
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?
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@lists.xen.org 
> http://lists.xen.org/xen-devel 
>  
>  

Re: two questions about xen on arm

[Ian Campbell]

On Fri, 2013-11-01 at 05:38 -0600, Bamvor Jian Zhang wrote:
>  >>>Ian Campbell <Ian.Campbell@citrix.com> wrote: 
> > On Fri, 2013-11-01 at 04:34 -0600, Bamvor Jian Zhang wrote: 
> > >  
> > >  >>>Ian Campbell <Ian.Campbell@citrix.com> 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@lists.xen.org 
> > http://lists.xen.org/xen-devel 
> >  
> >  
> 

Re: two questions about xen on arm

[Stefano Stabellini]

On Fri, 1 Nov 2013, Ian Campbell wrote:
> > > > > > > 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?

Right, having both the backends and the frontends compiled in should
cause no troubles.
If you are really concerned about the size of the kernel it might make
sense to disable the backends or the frontends depending on whether you
are running linux in dom0 or another domU.


> > 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? 

It is unused until xenbus_backend_init and later xenbus_probe_backend
are called.


> > and xenbus_backend_init(xenbus_dev_backend.c) will fail if it
> > is not the initial domain.

Yep, but the failure in that case is normal and expected.


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

Re: two questions about xen on arm

[Ian Campbell]

On Wed, 2013-11-06 at 18:52 +0000, Stefano Stabellini wrote:
> If you are really concerned about the size of the kernel it might make
> sense to disable the backends or the frontends depending on whether you
> are running linux in dom0 or another domU.

Or make them modular, which is what I would expect most distros to do.
Both front and backends should be autoloaded when necessary these days.

Re: two questions about xen on arm

[Stefano Stabellini]

On Thu, 7 Nov 2013, Ian Campbell wrote:
> On Wed, 2013-11-06 at 18:52 +0000, Stefano Stabellini wrote:
> > If you are really concerned about the size of the kernel it might make
> > sense to disable the backends or the frontends depending on whether you
> > are running linux in dom0 or another domU.
> 
> Or make them modular, which is what I would expect most distros to do.
> Both front and backends should be autoloaded when necessary these days.
 
The drivers themselves are modular, only xenbus frontends/backends
support is not. I wouldn't bother for a distro kernel, I was more
thinking of an embedded use case.

Re: two questions about xen on arm

[Ian Campbell]

On Thu, 2013-11-07 at 10:48 +0000, Stefano Stabellini wrote:
> On Thu, 7 Nov 2013, Ian Campbell wrote:
> > On Wed, 2013-11-06 at 18:52 +0000, Stefano Stabellini wrote:
> > > If you are really concerned about the size of the kernel it might make
> > > sense to disable the backends or the frontends depending on whether you
> > > are running linux in dom0 or another domU.
> > 
> > Or make them modular, which is what I would expect most distros to do.
> > Both front and backends should be autoloaded when necessary these days.
>  
> The drivers themselves are modular, only xenbus frontends/backends
> support is not. I wouldn't bother for a distro kernel, I was more
> thinking of an embedded use case.

Bamvor is @suse.com, so I assumed the former ;-)

Ian.