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

Re: [Xen-devel] ARMv8: New board bring up hangs in kernel start?

Hi Julien,

On 06.04.2016 12:48, Julien Grall wrote:

On 04/04/2016 16:44, Dirk Behme wrote:
Hi Julien,

Hello Dirk,

On 01.04.2016 18:34, Julien Grall wrote:

On 31/03/16 18:41, Dirk Behme wrote:
Also have you tried a newer version of Xen?

I've switched to the recent master

a6f2cdb63 x86/hvm/viridian: keep APIC assist page mapped

now. No difference.

I'll have a deeper look into the interrupt configuration.

Is there anywhere some basic description which interrupts are
to be handled by XEN and which by the Linux kernel? I.e. how the ARM
should be configured regarding the distributor/CPU/virtual parts?

All the interrupts are taken by Xen. The function do_IRQ in Xen will
dispatch the IRQ either to a guest or call a Xen specific handler.

Xen handles only a limited number of interrupt:
     * timers
     * UART
     * SMMU

The rest is either routed to guests or blacklisted by Xen.

Ok, thanks, that helps :) Once I have it working, maybe I post a patch
to add this info to the documentation.

That would be good. Thank you!

Just an other question:

On ARMv8 64-bit Xen is supposed to be started at EL2 *nonsecure*,

That's right.

It looks to me that the GICv2 on my board is already partly configured
by the firmware at secure EL3. That does mean, whatever
gicv2_dist_init() and gicv2_cpu_init() are supposed to do, they
can't do
it (completely) because they don't have access to the secure part of
GIC (?)

Which is normal, the secure part of the GIC should have already been
initialized by the firmware running at secure EL3.

I'm using


The special thing here is that it has the offsets 0x10000, 0x20000, 0x40000 and 0x60000. Instead of the standard ones 0x1000, 0x2000, 0x4000 and 0x6000.

Now, just by try & error, using [1] makes things working.

I'm not sure why this changes anything, though:

* To my understanding, the GIC register ranges are max 0x1000. So I'd think that the 0x2000 should be sufficient to map all necessary registers.

* I haven't observed any MMU fault. So it didn't look like any non-mapped register was accessed without this change.

Hmm ...

Best regards



--- r8a7795.dtsi_orig   2016-04-16 19:33:09.698030462 +0200
+++ r8a7795.dtsi        2016-04-16 19:33:38.202029057 +0200
@@ -137,9 +137,9 @@
                        #address-cells = <0>;
                        reg = <0x0 0xf1010000 0 0x1000>,
-                             <0x0 0xf1020000 0 0x2000>,
+                             <0x0 0xf1020000 0 0x20000>,
                              <0x0 0xf1040000 0 0x20000>,
-                             <0x0 0xf1060000 0 0x2000>;
+                             <0x0 0xf1060000 0 0x20000>;
                        interrupts = <GIC_PPI 9
                                        (GIC_CPU_MASK_SIMPLE(4) | 

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.