Hi Will, On 9/28/20 6:57 PM, Will Deacon wrote: > On Thu, Sep 24, 2020 at 12:07:04PM +0100, Alexandru Elisei wrote: >> From: Julien Thierry <julien.thierry@xxxxxxx> >> >> kvm_vcpu_kick() is not NMI safe. When the overflow handler is called from >> NMI context, defer waking the vcpu to an irq_work queue. >> >> A vcpu can be freed while it's not running by kvm_destroy_vm(). Prevent >> running the irq_work for a non-existent vcpu by calling irq_work_sync() on >> the PMU destroy path. >> >> Cc: Julien Thierry <julien.thierry.kdev@xxxxxxxxx> >> Cc: Marc Zyngier <marc.zyngier@xxxxxxx> >> Cc: Will Deacon <will.deacon@xxxxxxx> >> Cc: Mark Rutland <mark.rutland@xxxxxxx> >> Cc: Catalin Marinas <catalin.marinas@xxxxxxx> >> Cc: James Morse <james.morse@xxxxxxx> >> Cc: Suzuki K Pouloze <suzuki.poulose@xxxxxxx> >> Cc: kvm@xxxxxxxxxxxxxxx >> Cc: kvmarm@xxxxxxxxxxxxxxxxxxxxx >> Signed-off-by: Julien Thierry <julien.thierry@xxxxxxx> >> Tested-by: Sumit Garg <sumit.garg@xxxxxxxxxx> (Developerbox) >> [Alexandru E.: Added irq_work_sync()] >> Signed-off-by: Alexandru Elisei <alexandru.elisei@xxxxxxx> >> --- >> I suggested in v6 that I will add an irq_work_sync() to >> kvm_pmu_vcpu_reset(). It turns out it's not necessary: a vcpu reset is done >> by the vcpu being reset with interrupts enabled, which means all the work >> has had a chance to run before the reset takes place. > I don't understand this ^^ Marc had the same comment, I replied in his email. I thought about it and you're right, it doesn't make much sense. > > But the patch itself looks good, so I'm going to queue this lot anyway! Thank you for picking up the series! Thanks, Alex _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm