Did some more tracing, after the guest returns from disable_irq() it's guaranteed of no concurrent IRQ executing. All handled without any exits by disable_irq() and gneric_handle_irq(). Thanks. - Mario On 5/7/2013 7:14 PM, Marc Zyngier wrote: > On 07/05/13 17:47, Mario Smarduch wrote: >> I'm wondering if this race condition is possible, >> where guest may receive some interrupt after disable_irq() >> for that interrupt has completed. Considering couple >> vCPUs on different cores - >> >> 1.vCPU0 has the pending bit set for some IRQ while holding >> dist->lock - injected from QEMU (kvm_vgic_irq_line()) >> 2. KVM while holding dist->lock for vCPU0 programs the LR and is >> ready to resume Guest - after __kvm_vgic_flush_hwstate() >> 3. Before vCPU0 enters Guest mode, Guest on vCPU1 disables that IRQ, >> with dist->lock held - handle_mmio_clear_enable_reg() >> 4. It appears possible for vCPU1 to re-enter Guest mode before >> vCPU0. > > This looks indeed like a possibility, but I don't see how this is any > different from what you could observe on a physical system without any > additional synchronization between your CPUs. > > The GIC Spec also says: > "Writing a 1 to an GICD_ICENABLERn bit only disables the forwarding of > the corresponding interrupt from the Distributor to any CPU interface. > It does not prevent the interrupt from changing state, for example > becoming pending, or active and pending if it is already active." > > Here, the interrupt has already been forwarded to the logical CPU > interface. The fact that we're not running the vCPU just yet looks to me > like an implementation detail. > > M. > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
