On Wed, Jul 18, 2012 at 05:20:40PM -0600, Alex Williamson wrote: > On Thu, 2012-07-19 at 01:49 +0300, Michael S. Tsirkin wrote: > > On Wed, Jul 18, 2012 at 04:26:41PM -0600, Alex Williamson wrote: > > > On Thu, 2012-07-19 at 00:52 +0300, Michael S. Tsirkin wrote: > > > > When more than 1 source id is in use for the same GSI, we have the > > > > following race related to handling irq_states: > > > > > > > > CPU 0 clears bit in irq_states. CPU 0 reads irq_state as 0. > > > > CPU 1 sets bit in irq_states. CPU 1 calls kvm_ioapic_set_irq(1). CPU 0 > > > > calls kvm_ioapic_set_irq(0). > > > > > > > > Now ioapic thinks the level is 0 but irq_state is not 0. > > > > > > > > Note that above is valid behaviour if CPU0 and CPU1 are using different > > > > source ids. > > > > > > > > Fix by performing all irq_states bitmap handling under pic/ioapic lock. > > > > This also removes the need for atomics with irq_states handling. > > > > > > > > Reported-by: Gleb Natapov <gleb@xxxxxxxxxx> > > > > Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx> > > > > --- > > > > > > > > This survives stress testing for me (though I only tried virtio, not > > > > device assignment). > > > > Avi, Marcelo, though we have not observed this in the field, > > > > it's a bugfix so probably 3.5 material? > > > > I assume yes so the patch is against 3.5-rc7. > > > > Also stable? It's a very old bug. > > > > > > > > > > > > arch/x86/include/asm/kvm_host.h | 15 ++++++++++++++- > > > > arch/x86/kvm/i8259.c | 14 ++++++++++++-- > > > > virt/kvm/ioapic.c | 13 ++++++++++++- > > > > virt/kvm/ioapic.h | 4 +++- > > > > virt/kvm/irq_comm.c | 31 ++++--------------------------- > > > > 5 files changed, 45 insertions(+), 32 deletions(-) > > > > > > > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > > > > index db7c1f2..fe6e9f1 100644 > > > > --- a/arch/x86/include/asm/kvm_host.h > > > > +++ b/arch/x86/include/asm/kvm_host.h > > > > @@ -802,7 +802,20 @@ int kvm_read_guest_page_mmu(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, > > > > void kvm_propagate_fault(struct kvm_vcpu *vcpu, struct x86_exception *fault); > > > > bool kvm_require_cpl(struct kvm_vcpu *vcpu, int required_cpl); > > > > > > > > -int kvm_pic_set_irq(void *opaque, int irq, int level); > > > > +static inline int kvm_irq_line_state(unsigned long *irq_state, > > > > + int irq_source_id, int level) > > > > > > This should probably be __kvm_irq_line_state given the calling > > > restrictions. > > > > It's such a trivial helper, do we need to split hairs about this? > > > > Look it's not a good time for minor coding style nits. > > 3.5 is imminent, it's about 1am here and I really don't have time to retest > > today, so we'll release another kernel with a bug. > > > > Could you focus on reviewing the functionality and correctness, and > > leave ideas for better variable naming aside until 3.6? > > Please get off your high horse, this bug has existed for a long time and > nobody has noticed. __ indicates locking and makes people think twice > about arbitrarily calling it. Correct naming prevents future bugs, > which is something you've been riding me on in other areas... > Agree, this is not a recent regression and in fact the bug cannot be triggered without device assignment that uses level interrupt (is this works at all?). -- Gleb. -- 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
