On 18/04/13 15:16, Giridhar Maruthy wrote: Hi Giridhar, > Thanks a lot for pointing me at the series. > I did apply the series and got cpu hotplug to work successfully. Ah, good to know. Thanks for testing. > However, I have the following doubts. > > 1. Though the guest does not crash, when exiting the qemu, I get the > following crash dump. I have not yet looked into the details. > > > [ 547.870000] [<c00145b0>] (unmap_range+0x9c/0x2f4) from [<c0014c2c>] > (kvm_free_stage2_pgd+0x30/0x4c) > [ 547.880000] [<c0014c2c>] (kvm_free_stage2_pgd+0x30/0x4c) from > [<c00129c8>] (kvm_arch_destroy_vm+0xc/0x38) > [ 547.890000] [<c00129c8>] (kvm_arch_destroy_vm+0xc/0x38) from > [<c000eb6c>] (kvm_put_kvm+0xec/0x150) > [ 547.900000] [<c000eb6c>] (kvm_put_kvm+0xec/0x150) from [<c000f068>] > (kvm_vcpu_release+0x10/0x18) > [ 547.910000] [<c000f068>] (kvm_vcpu_release+0x10/0x18) from > [<c00bebcc>] (__fput+0x88/0x1dc) > [ 547.920000] [<c00bebcc>] (__fput+0x88/0x1dc) from [<c0044810>] > (task_work_run+0xac/0xe8) > [ 547.920000] [<c0044810>] (task_work_run+0xac/0xe8) from [<c0030cb8>] > (do_exit+0x22c/0x82c) > [ 547.930000] [<c0030cb8>] (do_exit+0x22c/0x82c) from [<c003132c>] > (do_group_exit+0x48/0xb0) > [ 547.940000] [<c003132c>] (do_group_exit+0x48/0xb0) from [<c003b618>] > (get_signal_to_deliver+0x278/0x504) > [ 547.950000] [<c003b618>] (get_signal_to_deliver+0x278/0x504) from > [<c001c8e4>] (do_signal+0x74/0x460) > [ 547.960000] [<c001c8e4>] (do_signal+0x74/0x460) from [<c001d150>] > (do_work_pending+0x64/0xac) > [ 547.970000] [<c001d150>] (do_work_pending+0x64/0xac) from > [<c00199c0>] (work_pending+0xc/0x20) > [ 547.980000] Code: e1927003 0afffff0 e7e80658 e3a0c000 (e1cc20d0) > [ 547.980000] ---[ end trace 05d3020cd57fa289 ]--- > [ 547.990000] Fixing recursive fault but reboot is needed! It probably means we're having issues with the Stage-2 page refcounts. Can you share the whole dump (I think there's a few additional lines before what you quoted)? > 2. I applied kvm-arm-fixes branch from Christoffer's tree > (github.com/virtualopensystems/linux-kvm-arm > <http://github.com/virtualopensystems/linux-kvm-arm>) and then applied > the v4 series of "ARM: KVM: Revamping the HYP init code for fun and > profit". I ran into some merge conflicts. So I manually edited and > applied the patches. Should I be including any more dependant patches? You'd be better of using the following branch: git://github.com/columbia/linux-kvm-arm.git kvm-arm-for-next as it should contain all you need. I haven't tested it yet, though. > 3. Regarding putting the secondary processors in hyp mode during cpu > hotplug, you suggested this to be done in firmware. During kernel > startup, u-boot used to do this job. After kernel startup, we have no > u-boot to do the job. When cpu is offlined, ROM code is run and the cpu > waits for an interrupt. SInce I cannot change the ROM code now, any idea > where this functionality can be included ? You could always reserve a page (using the /memreserve/ directive in your DT), let u-boot put your trampoline code there, and just use it directly. No need to duplicate this code, it is tricky enough. Cheers, M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
