Re: [kvm-ppc-devel] Guests oops when trying to mount initramfs

[Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>]

Hi,
I already chatted with Hollis a bit about that, but wanted to ask you about it. I also put kvm-ppc-devel on cc because it seem to be a common issue.
I as well as Hollis saw that kind of bug in the past occasionally but never in a reproducible way to be able to debug it.
So the first question is - is your scenario running into that bug to ~>95% ?

And if it reproducible in your case we can use it to find the reason for it, here a short summary from my past discussions about that issue:
- effectively what you see is that the guest has an itlb miss for it's kernel mapping.
- we only deliver that to the guest if we can't find that mapping in the guest tlb
- this should never happen because the guest should never remove it's own kernel mapping and therefor we should be able to cover all itlb misses in the host by using the guest tlb
- but it happens so the question is when&why is the guest kernel mapping removed from the guest tlb
- afaik we have only one place that might remove that mapping which is the function kvmppc_emul_tlbwe
- we also know the kernel mapping which is usually a single 16mb mapping we initialize for the guest in kvm_arch_vcpu_setup (I might be wrong here - Hollis?)
=> we could track that tlbwe that should never happen by inserting a warn_on into kvmppc_emul_tlbwe if it overwrites a guest tlb kernel mapping and starting from there debug whats going on

Any comments or other suggestions are welcome

Jerone Young wrote:
> I'm looking into this. But got a guest to load without the device tree
> mainpulation code. I have an cuImage with a prefilled device tree built
> in & initramfs integrated. 
> 
> It oopses at Decrementor() 
> 
> Does not mount the initramfs 
> 
> Here is the trace:
> 
[...]
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> Freeing unused kernel memory: 1500k init
> Unable to handle kernel paging request for instruction fetch
> Faulting instruction address: 0xc0000ac0
> Oops: Kernel access of bad area, sig: 1 [#1]
> Bamboo
> Modules linked in:
> NIP: c0000ac0 LR: 48003fdc CTR: 00000000
> REGS: bfcfe910 TRAP: 0400   Not tainted  (2.6.25-rc3-dirty)
> MSR: 00021000 <ME>  CR: 42000028  XER: 00000000
> TASK = c8810400[1] 'init' THREAD: c881e000
> GPR00: 00000001 bfcfe9c0 00000000 480177b0 4801795c 00000001 00000000
> 48011f34 
> GPR08: 0002d002 48026e64 00000000 bfcfe9c0 c881e000 00000000 00000000
> 00000000 
> GPR16: 00000000 48018700 00000001 c0240000 c0240000 bfcfea48 00000007
> 10000034 
> GPR24: 00000000 6fffff40 48017000 48027f4c 00000000 480177b0 480272e4
> bfcfe9c0 
> NIP [c0000ac0] Decrementer+0x0/0xc0
> LR [48003fdc] 0x48003fdc
> Call Trace:
> Instruction dump:
> 914b00b0 3d400002 614a1002 512a0420 4800c6b5 c000b378 c000d924 60000000 
> 60000000 60000000 60000000 60000000 <7d5043a6> 7d7143a6 7c3443a6
> 7d400026 
> ---[ end trace 59dad6c3a6e54fa0 ]---


-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel