On Wed, Nov 02, 2016 at 04:40:35PM +0100, Alexander Graf wrote: > On 11/01/2016 12:35 PM, Peter Maydell wrote: > >On 29 October 2016 at 22:10, Alexander Graf <agraf@xxxxxxx> wrote: [...] > > > >>+ cpu->timer_irq_level = run->s.regs.timer_irq_level; > >>+ } > >>+ > >> return MEMTXATTRS_UNSPECIFIED; > >> } > >Does this code do the right thing across a vcpu reset or > >a full-system reset? > > Good question. I'm not 100% sure - but I don't know for sure whether > it's guaranteed without user space irqchip even. > > In essence, the code above merely synchronizes kvm state to qemu > state and is fully unaffected from any reset sequence. This is good, > as the line status is transient. So from a QEMU pov, we really only > copy the state of the vcpu interrupt line into the QEMU interrupt > line. Pulling that line down would be responsibility of the > KVM_ARM_VCPU_INIT ioctl if it also clears the timer registers I > guess. > > However, I don't see any clearing of cntv_ctrl inside KVM or from > QEMU. How do we ensure that the irq active bit is off on reset? In kvm_timer_vcpu_reset we cset cntv_ctl = 0, and that function gets called from the PSCI handler or whenever userspace calls the set target ioctl thingy. > > The other part that could get in the way of working system reset is > the interrupt controller emulation itself which resets all internal > irq line state. So on reset we'd always end up with the irq line > down from a gic pov, but with the vtimer line pending or not pending > depending on previous state. I doubt it's really going to hurt > though. I suppose it should resample the line, but if the GIC clears everything and the arch timer line goes down, you're in the right starting state again. Right? -Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
