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