Re: [Xen-devel] [Xen-users] Changing netback tx interrupts affinity on Dom0
Thanks Julien. On Thu, Sep 3, 2015 at 2:21 PM, Julien Grall wrote: > On 03/09/15 17:06, Jintack Lim wrote: > > Hi, > > Hi Jintack, > > > On Thu, Sep 3, 2015 at 11:34 AM, Ian Campbell > <mailto:ian.campb...@citrix.com>> wrote: > > > > On Thu, 2015-09-03 at 10:59 -0400, Jintack Lim wrote: > > > Hi, > > > > > > While I was running Apache server, > > > I found that one of Dom0 vcpu is running 100% to handle irqs, > > > and those irqs are set to be processed only on that specific vcpu. > > > > > > Referring to this document, > > > http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide > > > I tried to change smp_affinity by writing a value to /proc/irq/ > > -no>/smp_affinity, > > > however the smp_affinity value was not changed. > > > > > > I'm working on Xen 4.5 on ARMv8, > > > and the irq is netback tx interrupt. > > > > > > # cat /proc/irq/106/smp_affinity > > > 1 > > > > > > # cat /proc/interrupts > > > ... > > > 106: 53849 0 0 0 xen-dyn-event > > > vif1.1-q0-tx > > > 107: 1 0 0 0 xen-dyn-event > > > vif1.1-q0-rx > > > 108: 61460 0 0 0 xen-dyn-event > > > vif1.1-q1-tx > > > 109: 1 0 0 0 xen-dyn-event > > > vif1.1-q1-rx > > > 110: 67118 0 0 0 xen-dyn-event > > > vif1.1-q2-tx > > > 111: 1 0 0 0 xen-dyn-event > > > vif1.1-q2-rx > > > 112: 58273 0 0 0 xen-dyn-event > > > vif1.1-q3-tx > > > 113: 1 0 0 0 xen-dyn-event > > > vif1.1-q3-rx > > > ... > > > > > > What would be the way to change smp_affinity? > > All those interrupts are in-fine event channels. This is a bug in Linux > which I sent a fix a month ago and it's queued in xentip for Linux 4.3 [1] > > The event channel rebinding was not working because we don't have vector > callback on ARM and therefore the driver was only allowing event channel > to be routed on VCPU0. > > After applying this patch, I was able to set smp_affinity. In addition, the default value of smp_affinity for netback tx interrupts on Dom0 becomes "f" (I have four vcpus on Dom0). What I meant by 'netback tx interrupts' is vif1.1-q-tx This is slightly different from x86, because netback tx interrupts are pinned to separate vcpus on x86. I'm not sure this question is appropriate for devel-list, but why the policy to set smp_affinity for netback tx interrupts are different on ARM and x86? > commit 4a5b69464e51f4a8dd432e8c2a1468630df1a53c > Author: Julien Grall > Date: Tue Jul 28 10:10:42 2015 +0100 > > xen/events: Support event channel rebind on ARM > Currently, the event channel rebind code is gated with the presence of > the vector callback. > > The virtual interrupt controller on ARM has the concept of per-CPU > interrupt (PPI) which allow us to support per-VCPU event > channel.Therefore there is no need of vector callback for ARM. > > Xen is already using a free PPI to notify the guest VCPU of an event. > Furthermore, the xen code initialization in Linux (see > arch/arm/xen/enlighten.c) is requesting correctly a per-CPU IRQ. > > Introduce new helper xen_support_evtchn_rebind to allow architecture > decide whether rebind an event is support or not. It will always return > true on ARM and keep the same behavior on x86. > > This is also allow us to drop the usage of xen_have_vector_callback > entirely in the ARM code. > > Signed-off-by: Julien Grall > Signed-off-by: David Vrabel > > Regards, > > [1] https://lkml.org/lkml/2015/7/28/205 > > -- > Julien Grall > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] Changing netback tx interrupts affinity on Dom0
On Thu, Sep 3, 2015 at 12:06 PM, Jintack Lim wrote: > Hi, > > I was trying to set irq affinity by writing a value > to /proc/irq//smp_affinity, > but smp_affinity value was not changed at all. > Ian suggested to take this to the devel list. > I'm working on Xen4.5, ARMv8. > I checked that setting smp_affinity works on Xen4.5, x86. So, probably this is an ARM specific issue. > > Thanks, > Jintack > > On Thu, Sep 3, 2015 at 11:34 AM, Ian Campbell > wrote: > >> On Thu, 2015-09-03 at 10:59 -0400, Jintack Lim wrote: >> > Hi, >> > >> > While I was running Apache server, >> > I found that one of Dom0 vcpu is running 100% to handle irqs, >> > and those irqs are set to be processed only on that specific vcpu. >> > >> > Referring to this document, >> > http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide >> > I tried to change smp_affinity by writing a value to /proc/irq/> > -no>/smp_affinity, >> > however the smp_affinity value was not changed. >> > >> > I'm working on Xen 4.5 on ARMv8, >> > and the irq is netback tx interrupt. >> > >> > # cat /proc/irq/106/smp_affinity >> > 1 >> > >> > # cat /proc/interrupts >> > ... >> > 106: 53849 0 0 0 xen-dyn-event >> > vif1.1-q0-tx >> > 107: 1 0 0 0 xen-dyn-event >> > vif1.1-q0-rx >> > 108: 61460 0 0 0 xen-dyn-event >> > vif1.1-q1-tx >> > 109: 1 0 0 0 xen-dyn-event >> > vif1.1-q1-rx >> > 110: 67118 0 0 0 xen-dyn-event >> > vif1.1-q2-tx >> > 111: 1 0 0 0 xen-dyn-event >> > vif1.1-q2-rx >> > 112: 58273 0 0 0 xen-dyn-event >> > vif1.1-q3-tx >> > 113: 1 0 0 0 xen-dyn-event >> > vif1.1-q3-rx >> > ... >> > >> > What would be the way to change smp_affinity? >> >> It should be via /proc/irq//smp_affinity as you've tried, I asked >> Stefano and he things this was already implemented in 4.5 even. That it is >> not happening would be a bug, I think. >> >> I'd suggest you take this to the devel list as a bug. >> >> > and where is the affinity set initially for netback tx interrupts? >> >> Not, sure, I think it might just be generic IRQ code. >> >> Ian. >> >> > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] Changing netback tx interrupts affinity on Dom0
Hi, I was trying to set irq affinity by writing a value to /proc/irq//smp_affinity, but smp_affinity value was not changed at all. Ian suggested to take this to the devel list. I'm working on Xen4.5, ARMv8. Thanks, Jintack On Thu, Sep 3, 2015 at 11:34 AM, Ian Campbell wrote: > On Thu, 2015-09-03 at 10:59 -0400, Jintack Lim wrote: > > Hi, > > > > While I was running Apache server, > > I found that one of Dom0 vcpu is running 100% to handle irqs, > > and those irqs are set to be processed only on that specific vcpu. > > > > Referring to this document, > > http://wiki.xen.org/wiki/Network_Throughput_and_Performance_Guide > > I tried to change smp_affinity by writing a value to /proc/irq/ > -no>/smp_affinity, > > however the smp_affinity value was not changed. > > > > I'm working on Xen 4.5 on ARMv8, > > and the irq is netback tx interrupt. > > > > # cat /proc/irq/106/smp_affinity > > 1 > > > > # cat /proc/interrupts > > ... > > 106: 53849 0 0 0 xen-dyn-event > > vif1.1-q0-tx > > 107: 1 0 0 0 xen-dyn-event > > vif1.1-q0-rx > > 108: 61460 0 0 0 xen-dyn-event > > vif1.1-q1-tx > > 109: 1 0 0 0 xen-dyn-event > > vif1.1-q1-rx > > 110: 67118 0 0 0 xen-dyn-event > > vif1.1-q2-tx > > 111: 1 0 0 0 xen-dyn-event > > vif1.1-q2-rx > > 112: 58273 0 0 0 xen-dyn-event > > vif1.1-q3-tx > > 113: 1 0 0 0 xen-dyn-event > > vif1.1-q3-rx > > ... > > > > What would be the way to change smp_affinity? > > It should be via /proc/irq//smp_affinity as you've tried, I asked > Stefano and he things this was already implemented in 4.5 even. That it is > not happening would be a bug, I think. > > I'd suggest you take this to the devel list as a bug. > > > and where is the affinity set initially for netback tx interrupts? > > Not, sure, I think it might just be generic IRQ code. > > Ian. > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: arm64: more useful logging on bad trap.
On Wed, Feb 18, 2015 at 11:01 AM, Ian Campbell wrote: > On Wed, 2015-02-18 at 10:47 -0500, Jintack Lim wrote: >> On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell >> wrote: >> > Dump the register state before panicing so we have some clue where the >> > issue occurred. Also decode the ESR register a bit to save having to >> > grab a pen and paper. >> > >> > ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as >> > we already do correctly in the main trap handler. >> > >> > While here notice that do_trap_serror is never called and remove it. >> > >> > Signed-off-by: Ian Campbell >> > Cc: jint...@cs.columbia.edu >> > --- >> > Jintack, since you have a system which is exhibiting SError issues I >> > wonder if I could prevail on you to give this patch a try on your >> > system and report on the output. I've only compile tested this myself. >> > --- >> >> Hi Ian, >> this is the output I got from the machine. > > Thanks, may I add a "Tested-by: Jintack Lim " > please? Yes!, Thanks. > > >> (XEN) Bad mode in Error handler detected, code 0xbf00, EC=2f, IL=1 >> ISS=100 > > I notice I missed a "," here after "IL=1", which I'll fix for v2. > > The line is also a bit long so I've split into two lines. > > Ian. > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: arm64: more useful logging on bad trap.
On Wed, Feb 18, 2015 at 11:00 AM, Julien Grall wrote: > > On 18/02/2015 15:47, Jintack Lim wrote: >> >> On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell >> wrote: >>> >>> Dump the register state before panicing so we have some clue where the >>> issue occurred. Also decode the ESR register a bit to save having to >>> grab a pen and paper. >>> >>> ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as >>> we already do correctly in the main trap handler. >>> >>> While here notice that do_trap_serror is never called and remove it. >>> >>> Signed-off-by: Ian Campbell >>> Cc: jint...@cs.columbia.edu >>> --- >>> Jintack, since you have a system which is exhibiting SError issues I >>> wonder if I could prevail on you to give this patch a try on your >>> system and report on the output. I've only compile tested this myself. >>> --- >> >> >> Hi Ian, > > > Hi Jintack, > Hi Julien, >> this is the output I got from the machine. > > > OOI, what is the machine? It is a Seattle machine. > >> >> Xen 4.5.0 (c/s Mon Jan 12 11:30:05 2015 -0500 git:a8ac229-dirty) EFI >> loader >> Using configuration file 'xen.cfg' >> vmlinuz-3.18.0+: 0x0083fbd8f000-0x0083fc5195c0 >> Xen 4.5.0 >> (XEN) Xen version 4.5.0 (jintack@) (gcc (Ubuntu/Linaro >> 4.8.2-19ubuntu1) 4.8.2) debug=n Wed Feb 18 5 >> (XEN) Latest ChangeSet: Mon Jan 12 11:30:05 2015 -0500 >> git:a8ac229-dirty > > > You tree is marked dirty, did you made other changes than this patch? No. This patch is the only change. Basically, I checked out to RELEASE-4.5.0, and applied the patch there. > > >> (XEN) Processor: 410fd070: "ARM Limited", variant: 0x0, part 0xd07, >> rev 0x0 >> (XEN) 64-bit Execution: >> (XEN) Processor Features: >> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 >> (XEN) Extensions: FloatingPoint AdvancedSIMD >> (XEN) Debug Features: 10305106 >> (XEN) Auxiliary Features: >> (XEN) Memory Model Features: 1124 >> (XEN) ISA Features: 00011120 >> (XEN) 32-bit Execution: >> (XEN) Processor Features: 0131:00011011 >> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle >> (XEN) Extensions: GenericTimer Security >> (XEN) Debug Features: 03010066 >> (XEN) Auxiliary Features: >> (XEN) Memory Model Features: 10101105 4000 0126 02102211 >> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 >> 00011121 >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 >> (XEN) Using generic timer at 187500 KHz >> (XEN) GICv2 initialization: >> (XEN) gic_dist_addr=e111 >> (XEN) gic_cpu_addr=e112f000 >> (XEN) gic_hyp_addr=e114 >> (XEN) gic_vcpu_addr=e116 >> (XEN) gic_maintenance_irq=24 >> (XEN) GICv2: 448 lines, 8 cpus, secure (IID 0200143b). >> (XEN) Using scheduler: SMP Credit Scheduler (credit) >> (XEN) Bad mode in Error handler detected, code 0xbf00, EC=2f, IL=1 >> ISS=100 >> (XEN) [ Xen-4.5.0 arm64 debug=n Not tainted ] >> (XEN) CPU:0 >> (XEN) PC: 002770f0 start_xen+0x920/0xc98 > > > Can you try to get the line of code related to this PC? You could do it with > addr2line. Please see below comments. > > [..] > >> (XEN) Xen call trace: >> (XEN)[<002770f0>] start_xen+0x920/0xc98 (PC) >> (XEN)[<002770e8>] start_xen+0x918/0xc98 (LR) > > > It might be good to get those 2 too. [jintack@seattle_2 ~/xen_4.5]$addr2line -C -f -e xen/xen-syms 0x002770f0 start_xen /home/jintack/xen_4.5/xen/arch/arm/setup.c:786 --> PC is iommu_setup() [jintack@seattle_2 ~/xen_4.5]$addr2line -C -f -e xen/xen-syms 0x002770e8 start_xen /home/jintack/xen_4.5/xen/arch/arm/setup.c:783 --> LR is local_irq_enable() It's a bit weird that PC is ahead of LR. Thanks, Jintack > > Regards, > > -- > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: arm64: more useful logging on bad trap.
On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell wrote: > Dump the register state before panicing so we have some clue where the > issue occurred. Also decode the ESR register a bit to save having to > grab a pen and paper. > > ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as > we already do correctly in the main trap handler. > > While here notice that do_trap_serror is never called and remove it. > > Signed-off-by: Ian Campbell > Cc: jint...@cs.columbia.edu > --- > Jintack, since you have a system which is exhibiting SError issues I > wonder if I could prevail on you to give this patch a try on your > system and report on the output. I've only compile tested this myself. > --- Hi Ian, this is the output I got from the machine. Thanks! Xen 4.5.0 (c/s Mon Jan 12 11:30:05 2015 -0500 git:a8ac229-dirty) EFI loader Using configuration file 'xen.cfg' vmlinuz-3.18.0+: 0x0083fbd8f000-0x0083fc5195c0 Xen 4.5.0 (XEN) Xen version 4.5.0 (jintack@) (gcc (Ubuntu/Linaro 4.8.2-19ubuntu1) 4.8.2) debug=n Wed Feb 18 5 (XEN) Latest ChangeSet: Mon Jan 12 11:30:05 2015 -0500 git:a8ac229-dirty (XEN) Processor: 410fd070: "ARM Limited", variant: 0x0, part 0xd07, rev 0x0 (XEN) 64-bit Execution: (XEN) Processor Features: (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 10305106 (XEN) Auxiliary Features: (XEN) Memory Model Features: 1124 (XEN) ISA Features: 00011120 (XEN) 32-bit Execution: (XEN) Processor Features: 0131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10101105 4000 0126 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 (XEN) Using generic timer at 187500 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=e111 (XEN) gic_cpu_addr=e112f000 (XEN) gic_hyp_addr=e114 (XEN) gic_vcpu_addr=e116 (XEN) gic_maintenance_irq=24 (XEN) GICv2: 448 lines, 8 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Bad mode in Error handler detected, code 0xbf00, EC=2f, IL=1 ISS=100 (XEN) [ Xen-4.5.0 arm64 debug=n Not tainted ] (XEN) CPU:0 (XEN) PC: 002770f0 start_xen+0x920/0xc98 (XEN) LR: 002770e8 (XEN) SP: 002a7e10 (XEN) CPSR: 0249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 8003fff87000 X1: X2: 800030001570 (XEN) X3: X4: 09a1 X5: (XEN) X6: 80003000161e X7: 6f74717164736d48 X8: 7f7f7f7f7f7f7f7f (XEN) X9: fefefefefeff7273 X10: 7f7f7f7f7f7f7f7f X11: 0101010101010101 (XEN) X12: 0010 X13: 0026b000 X14: 002183b0 (XEN) X15: X16: X17: (XEN) X18: X19: 0026b710 X20: 002b (XEN) X21: 0026b000 X22: 0026b000 X23: 00290860 (XEN) X24: 0004 X25: 0084 X26: 00800100 (XEN) X27: 0084 X28: 003fd977 FP: (XEN) (XEN) VTCR_EL2: 8000 (XEN) VTTBR_EL2: (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN)HCR_EL2: 0038643f (XEN) TTBR0_EL2: 008027ee4000 (XEN) (XEN)ESR_EL2: bf00 (XEN) HPFAR_EL2: (XEN)FAR_EL2: (XEN) (XEN) Xen stack trace from sp=002a7e10: (XEN)0083fc52 0083fc32 0083fc51a000 (XEN)0083fff70668 0001 0083fc58b000 (XEN) 0083fc5b0030 0083fc5201d8 (XEN) 0083ffe7 000d 0003fd977000 (XEN)0026b000 002f2000 0083fc51a000 4000 (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) 00
Re: [Xen-devel] [Xen-users] Xen memory allocation for dom0 and domU
On Wed, Feb 4, 2015 at 9:55 PM, Jintack Lim wrote: > On Wed, Feb 4, 2015 at 11:41 AM, Ian Campbell wrote: >> >> Patch for all this below. Jan, I don't think there is any (possibly >> historical on x86_32) x86 option we should be trying to be consistent >> with. > > Thanks, Ian. > Your patch works well! > Will this patch be pushed to the upstream? I was not able to find this patch in here. http://xenbits.xen.org/gitweb/?p=xen.git;a=summary Could you tell me where is the patch now? > Jintack ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] Xen memory allocation for dom0 and domU
On Wed, Feb 4, 2015 at 11:41 AM, Ian Campbell wrote: > > Patch for all this below. Jan, I don't think there is any (possibly > historical on x86_32) x86 option we should be trying to be consistent > with. Thanks, Ian. Your patch works well! Jintack ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Hypercall overhead measurement on Xen/ARM
Hi, I'm trying to measure number of cycles for hypercalls. I'm working on ARM v7 and v8. Xentrace seems to be a right tool to use according to this discussion. http://lists.xen.org/archives/html/xen-devel/2008-10/msg00480.html However when I ran it on ARM, it gave an error. The error is the same as in this discussion in 2014 below. Xentrace on ARM is not supported? http://lists.xen.org/archives/html/xen-devel/2014-02/msg00154.html http://lists.xen.org/archives/html/xen-devel/2014-02/msg00206.html Are there other tools for this purpose? Thanks, Jintack ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen compile error with CONFIG_EARLY_PRINTK=seattle option
I'm sorry, it's my bad. It was because I didn't do "make clean" before building with "CONFIG_EARLY_PRINTK=seattle". Jintack On Tue, Jan 6, 2015 at 8:49 PM, Jintack Lim wrote: > Hi, > > When I compiled with CONFIG_EARLY_PRINTK=seattle option, > I got an compile error. > > /home/soccertack/dev/xen/xen/arch/arm/built_in.o: In function `early_puts': > /home/soccertack/dev/xen/xen/arch/arm/early_printk.c:22: multiple > definition of `early_puts' > arm64/head.o:/home/soccertack/dev/xen/xen/arch/arm/arm64/head.S:727: first > defined here > > After I commented "early_puts" function out in early_printk.c, > I successfully compiled and I was able to see earlyprint messages. > > I'm using the latest commit (36174af3fbeb1b662c0eadbfa193e77f68cc955b) > and I compiled with this command. > > make dist-xen XEN_TARGET_ARCH=arm64 debug=y CONFIG_EARLY_PRINTK=seattle > CROSS_COMPILE=aarch64-linux-gnu- > > Jintack > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] xen compile error with CONFIG_EARLY_PRINTK=seattle option
Hi, When I compiled with CONFIG_EARLY_PRINTK=seattle option, I got an compile error. /home/soccertack/dev/xen/xen/arch/arm/built_in.o: In function `early_puts': /home/soccertack/dev/xen/xen/arch/arm/early_printk.c:22: multiple definition of `early_puts' arm64/head.o:/home/soccertack/dev/xen/xen/arch/arm/arm64/head.S:727: first defined here After I commented "early_puts" function out in early_printk.c, I successfully compiled and I was able to see earlyprint messages. I'm using the latest commit (36174af3fbeb1b662c0eadbfa193e77f68cc955b) and I compiled with this command. make dist-xen XEN_TARGET_ARCH=arm64 debug=y CONFIG_EARLY_PRINTK=seattle CROSS_COMPILE=aarch64-linux-gnu- Jintack ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] smmu/ccp warnings on Seattle
While Xen was booting on Seattle, I got warnings/errors related to smmu and ccp. Eventually Seattle was rebooted. These are the relevant logs (and more warnings in a full log at the bottom). (XEN) smmu: /smb/motherboard/smmu@00C0: Try to add master ccp (XEN) smmu: /smb/motherboard/smmu@00C0: duplicate stream ID (11) (XEN) smmu: /smb/motherboard/smmu@00C0: failed to add master ccp ... ... (XEN) arm-smmu: attach /smb/motherboard/ccp@0010 to domain 0 (XEN) /smb/motherboard/ccp@0010: cannot attach to SMMU, is it on the same bus? (XEN) Failed to setup the IOMMU for /smb/motherboard/ccp@0010 (XEN) Device tree generation failed (-19). Even after removing smmu/ccp nodes from the DT, I got an unexpected hypervisor trap on cpu0, and Seattle was rebooted again. Here's the full log WITH smmu/ccp. Shell> FS0:\xen\xenImg.gz Xen 4.5.0-rc (c/s Mon Dec 15 09:30:05 2014 +0100 git:2676bc9) EFI loader Using configuration file 'xenImg.cfg' v318: 0x0083fbd93000-0x0083fc4eada0 Xen 4.5.0-rc (XEN) Xen version 4.5.0-rc (soccertack@) (aarch64-linux-gnu-gcc (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GC C 4.9-2014.09) 4.9.2 20140904 (prerelease)) debug=y Wed Dec 17 11:50:57 EST 2014 (XEN) Latest ChangeSet: Mon Dec 15 09:30:05 2014 +0100 git:2676bc9 (XEN) Processor: 410fd070: "ARM Limited", variant: 0x0, part 0xd07, rev 0x0 (XEN) 64-bit Execution: (XEN) Processor Features: (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 10305106 (XEN) Auxiliary Features: (XEN) Memory Model Features: 1124 (XEN) ISA Features: 00011120 (XEN) 32-bit Execution: (XEN) Processor Features: 0131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: (XEN) Memory Model Features: 10101105 4000 0126 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Platform: SEATTLE (XEN) Using PSCI-0.1 for SMP bringup (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 (XEN) Using generic timer at 187500 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=e111 (XEN) gic_cpu_addr=e112f000 (XEN) gic_hyp_addr=e114 (XEN) gic_vcpu_addr=e116 (XEN) gic_maintenance_irq=24 (XEN) GICv2: 448 lines, 8 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Xen WARN at device_tree.c:1191 (XEN) [ Xen-4.5.0-rc arm64 debug=y Not tainted ] (XEN) CPU:0 (XEN) PC: 002038dc __dt_parse_phandle_with_args+0x160/0x220 (XEN) LR: 00203858 (XEN) SP: 002b7c40 (XEN) CPSR: 2249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0020 X1: 0001 X2: 0004 (XEN) X3: X4: 0080 X5: 6c61626f6c672300 (XEN) X6: 8023676c6f62616c X7: 6b60616e6b6621ff X8: 7f7f7f7f7f7f7f7f (XEN) X9: fffb X10: 0101010101010101 X11: (XEN) X12: 0018 X13: X14: 00219438 (XEN) X15: X16: 00289298 X17: (XEN) X18: X19: 0004 X20: (XEN) X21: 8003d384 X22: 8003d404 X23: 8003fff82ba0 (XEN) X24: X25: 0001 X26: (XEN) X27: 00270940 X28: 002b7d40 FP: 002b7c40 (XEN) (XEN) VTCR_EL2: 8000 (XEN) VTTBR_EL2: (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN)HCR_EL2: 0038643f (XEN) TTBR0_EL2: 008027ef4000 (XEN) (XEN)ESR_EL2: f201 (XEN) HPFAR_EL2: (XEN)FAR_EL2: (XEN) (XEN) Xen stack trace from sp=002b7c40: (XEN)002b7cc0 00204c88 8003fbd90660 0002 (XEN)0002 0001 00270440 0004 (XEN) 00270940 00270440 0027 (XEN)8003fff82d78 0100 002b7cd0 00840020 (XEN)002b7cd0 00280f84 002b7da0 00286204 (XEN)00278a30 0001 00278a90 8003fff82d78 (XEN) 0004 002a0108 00800100 (XEN)0084 000d 00278a90 00270958 (XEN)002b7d50 00203aa8 002b7d80 00286154 (XEN)00290050 8003fff82d78 002b7da0 000c002861b4 (XEN)002b7da0 002861e4 0001 e040 (XEN)002b7de0 0028093c 8003fff82d78 000
Re: [Xen-devel] smmu/ccp warnings on Seattle
Hello, On Tue, Jan 6, 2015 at 8:27 AM, Julien Grall wrote: > Hello, > > On 06/01/15 12:50, Jintack Lim wrote: > > While Xen was booting on Seattle, I got warnings/errors related to smmu > > and ccp. > > Eventually Seattle was rebooted. > > These are the relevant logs (and more warnings in a full log at the > bottom). > > The support of Seattle in the SMMU drivers is missing. > > I would advise you to disable the IOMMU for now (iommu=disable on Xen > command line). > This works! Thanks for your advice. > > Regards, > > -- > Julien Grall > > Jintack ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
