On 2017/6/5 21:56, Marc Zyngier wrote: > On 05/06/17 11:30, wanghaibin wrote: >> At present, take GICv3 as as an example, our implementation is that, the operation >> of the recovery ICH_HCR register is prior to the recovery of ICH_LRn registers in vgic >> state restore. Thus, the ICH_LRn registers are 0, and if ICH_HCR.UIE is configured to 1, >> a large number of unnecessary maintenance interrupts will be triggered. > > Is that a theoretical problem? Or something you've actually observed? I observed this problem with that boot a android vm (with 4 vcpus) on my hisilicon D03 board (4 LRs support). Boot the android vm will failed because of any virtual interrupts can't deliver to the vm timely. I watched the maintenance interrupt (/proc/interrupts, GICv3 hwirq:25), and the number can up to 200000+ per second. (sorry for my express fault, the large number of unnecessary maintenance interrupts means this). > > At the point where we restore the vgic state, interrupts are disabled. > And by the time we enter the guest, we fully expect the HW to be in a > stable state, and no spurious interrupt would be delivered. At that point where restore the vgic state, it's true that interrupts are disabled (local_irq_disable), but in my opinion, here maybe a maintenance interrupt pending at physical redist (at that point it can be delivered). and it will be delivered at the moment that current vcpu's ctxt restore and entry (eret, here, PSTATE.I maybe unmask). Thus, the vcpu will be kicked out immediately. At the next vgic state restore point, go round and begin again. Thanks. > > I also dispute the "large number of unnecessary maintenance interrupts". > This large number is at most *one*. > > Or am I missing something obvious? > > Thanks, > > M. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
