HYP panic with 3.16-rc5, arm64 + 64k pages

[Joel Schopp]

On 07/17/2014 10:28 AM, Will Deacon wrote:
> Hi all,
>
> If I try to spawn a kvm guest with kvmtool (not tried qemu) with a vanilla
> 3.16-rc5 kernel (same for host and guest) using 64k pages, I'm greeted by:
>
>   Kernel panic - not syncing: HYP panic:
>   PS:800002c5 PC:fffffe000042bd10 ESR:00000000bf000000
>   FAR:          (null) HPFAR:          (null) PAR:          (null)
>   VCPU:0000020979e20000
>
>   CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-rc5 #4
>   Call trace:
>   [<fffffe000009642c>] dump_backtrace+0x0/0x130
>
> on the host. The problem happens every time on Juno and the fastmodel.
>
> Any ideas? Is anybody else seeing this problem? The limited guest output
> is below.

I'm running a small patch series (nothing that should affect what you
are seeing) on top of 3.16-rc5 (both host and guest) with 64K pages on
an arm64 SOC.  I'm not seeing any problems.
>
> Will
>
> --->8
>
> Initializing cgroup subsys cpu
> Linux version 3.16.0-rc5 (will at edgewater-inn) (gcc version 4.9.0 20140214 (experimental) (aarch64-trunk.530) ) #1 SMP PREEMPT Thu Jul 17 16:19:36 BST 2014
> CPU: AArch64 Processor [410fd070] revision 0
> Early serial console at I/O port 0x0 (options '')
> bootconsole [uart0] enabled
> efi: Getting parameters from FDT:
> efi: Can't find System Table in device tree!
> cma: CMA: failed to reserve 512 MiB
> psci: probing for conduit method from DT.
> psci: Using PSCI v0.1 Function IDs from DT
> PERCPU: Embedded 1 pages/cpu @fffffe0023e80000 s13120 r8192 d44224 u65536
> Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 9208
> Kernel command line: console=hvc0,38400 earlycon=uart8250,0x3f8 root=/dev/root rw rootflags=rw,trans=virtio,version=9p2000.L rootfstype=9p init=/virt/init  ip=dhcp
> PID hash table entries: 4096 (order: -1, 32768 bytes)
> Dentry cache hash table entries: 131072 (order: 4, 1048576 bytes)
> Inode-cache hash table entries: 65536 (order: 3, 524288 bytes)
> Memory: 579264K/589824K available (4359K kernel code, 455K rwdata, 1536K rodata, 332K init, 280K bss, 10560K reserved)
> Virtual kernel memory layout:
>     vmalloc : 0xfffffc0000000000 - 0xfffffdfbffff0000   (2080767 MB)
>     vmemmap : 0xfffffdfc001c0000 - 0xfffffdfc0023e000   (     0 MB)
>     modules : 0xfffffdfffc000000 - 0xfffffe0000000000   (    64 MB)
>     memory  : 0xfffffe0000000000 - 0xfffffe0024000000   (   576 MB)
>       .init : 0xfffffe0000660000 - 0xfffffe00006b3340   (   333 kB)
>       .text : 0xfffffe0000080000 - 0xfffffe0000651f94   (  5960 kB)
>       .data : 0xfffffe00006c0000 - 0xfffffe0000731ca8   (   456 kB)
> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> Preemptible hierarchical RCU implementation.
> 	RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
> RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
> NR_IRQS:64 nr_irqs:64 0

Not a lot to go on there.  If you get desperate you can configure FTRACE
and pass "ftrace=function ftrace_dump_on_oops" as additional additional
kernel command line arguments.  If you get really desperate you can do
the same on the host.  Just beware the output is really long.