On 12/10/12 07:26, haibin wang wrote: > Question: When I configure guestos with CONFIG_ARM_ARCH_TIMER,and use > rtsm_ve-cortex_a15x2.dtb(two cpus) to boot guestos, it can't boot success! > > Which resource I used as follows: > kvm-arm: git://github.com/virtualopensystems/linux-kvm-arm.git > <http://github.com/virtualopensystems/linux-kvm-arm.git> branch > :kvm-arm-v12-vgic-timers > qemu: git://github.com/virtualopensystems/qemu.git > <http://github.com/virtualopensystems/qemu.git> branch > :kvm-arm > guide: http://www.virtualopensystems.com/media/pdf/kvm-arm-guide.pdf > <https://imailcn.huawei.com/owa/redir.aspx?C=940b46dde25148cb9c52642502462226&URL=http%3a%2f%2fwww.virtualopensystems.com%2fmedia%2fpdf%2fkvm-arm-guide.pdf> > It is worth mentioning that i use the guest kernel which is same to host > kernel,just like the guide said. > According to the guide,step by step,Qemu boot the guest with follow > command line,that will be sucess! > ./qemu-system-arm \ > -enable-kvm \ > -kernel zImage \ > -sd guest.cramfs \ > -dtb ./rtsm_ve-cortex_a15x1.dtb \ > -m 512 -M vexpress-a15 -cpu cortex-a15 -nographic \ > -append "console=ttyAMA0 mem=512M root=/dev/mmcblk0 rw" > > But,I attempt to change the dtb file to rtsm_ve-cortex_a15x2.dtb which > has two cpus ,there is > something wrong happened! There is not any print info to help me find > the problem. > > I find that there is an end-less loop. depict as follow: > > in the process of booting host : > init_hyp_mode ==> kvm_timer_hyp_init , this function enable > physical virtual timer ppi, and > register the irq handler: kvm_arch_timer_handler > > in the process of booting guest, some reasons make guest exit : > ||===> VM_EXIT > || || > || || save content module: > || > |--------------------------------------------------------------------------------------------------------------| > > || | save_timer_state (save hardware virtual > timer,CNTV_CTL, | > || | || CNTV_CVAL regiests to vcpu > and disenable | > || | || virtual timer) > | > || | > || > | > || | kvm_timer_sync_from_cpu (software judge and decide to > | > || | || send virtual > virtual timer ppi to guest or not) | > || > |-------------||------------------------------------------------------------------------------------------------| > || || > || || > || ioctl(KVM_RUN) > || || > || || restore content module: > || > |-----------------------------------------------------------------------------------------------------------------------| > > || | restore_timer_state (restore hardware virtual > timer,CNTV_CTL, | > || | || CNTV_CVAL regiests from > vcpu) | > || | > || > | > || | GICD_ISPENDING (because hardware virtual > timer has been enabled, and | > || | || hostos has enabled the > physical virtual timer ppi | > || | || so there will be a physical > virtual timer ppi pending | > || | || for > host) > | > || | || (host deal with the physical virtual > timer ppi using | > || | || handler kvm_arch_timer_handler, the > handler do nothing, so that | > || | || run here next time, GICD_ISPENDING > must have the physical | > || | || virtual timer ppi > pending) | > || | > || > | > || | HCR register > setting > | > || | > || > | > || | > || > | > || | ERET (want to exectue guest > instructions,deal with virtual virtual | > || | || timer ppi and read/write virtual > timer registers to set next | > || | || event timer,and only guest use and > change virtual timer | > || | || registers to set next event,but > GICD_ISPENDING has pending irq , | > || | || so next will trap to hyp_irq,that > is VM_EXIT) | > || > |-------------||------------------------------------------------------------------ > -------------------------------------| > || || > ||<========|| > > Reasons are listed as follows: > (1) When storing the context, it will send(or not send) the virtual > interrupt of virtual timer ppi to Guest > according to kvm_timer_sync_from_cpu. > (2) The physical virtual timer ppi is enabled by hostos, however, when > restoring content , there must be > a physical virtual timer ppi pending, so that "eret" will trap to > hyp_irq again immediately! this is the end-less loop. > > The solution of the problem: > I think it is not necessary to enable the physical interrupt of virtual > timer ppi in the function of > kvm_timer_hyp_init when hostos initializing the hyp . > > Signed-off-by: Wanghaibin<wanghaibin202@xxxxxxxxx > <mailto:wanghaibin202@xxxxxxxxx>> [snip] That's an interesting patch. Except that it's the completely wrong fix. The problem you're seeing is due to a bug in the model, due to a lack of CNTVOFF handling. The physical interrupts is only used to force an exit from the guest. By the time we reach the host kernel, the interrupt is not pending anymore (we're disabled it at the virtual timer level). For the record, this code works fine on fixed models and real HW. Two solutions for you: getting an updated model, or applying this patch locally: @@ -196,7 +199,7 @@ void kvm_timer_vcpu_terminate(struct kvm_vcpu *vcpu) int kvm_timer_init(struct kvm *kvm) { if (timecounter && wqueue) { - kvm->arch.timer.cntvoff = kvm_phys_timer_read(); +// kvm->arch.timer.cntvoff = kvm_phys_timer_read(); kvm->arch.timer.enabled = 1; } M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
