On 27.04.2012, at 01:37, Benjamin Herrenschmidt wrote: > On Fri, 2012-04-27 at 01:30 +0200, Alexander Graf wrote: >> On 27.04.2012, at 01:12, Benjamin Herrenschmidt wrote: >> >>> On Fri, 2012-04-27 at 00:24 +0200, Alexander Graf wrote: >>>> >>>> This is to actually enable interrupts for real, regardless of ppc64 >>>> and ppc32. In fact, the previous code was pretty buggy - it was >>>> running the handlers with interrupts disabled ;). >>> >>> They should be run with interrupts disabled.. tho both soft & hard. >> >> The kvm_resched()? No, that one should be run with interrupts enabled - hard and soft :). > > Ok, when you said "the handler" I thought you mean do_IRQ & co... those > must be run with IRQs off (and never enabled since taking the actual > exception). Ah, yeah, "the handler" in this context meant the kvm intercept handlers. Those were running with irq hard disabled. Pretty bad, eh? :) > >>> You probably do want to call local_irq_disable() unconditionally anyway, >>> because on ppc32, that will give you the proper accounting vs. lockdep. >> >> We already do __hard_irq_disable (which maps to local_irq_disable on ppc32) >> when entering the guest context and when leaving the intercept handler :). >> So that should be fine, no? > > Well, __hard_irq_disable() isn't defined on ppc32 in hw_irq.h so if you > redefine it locally that's really gross :-) Also that means that from a > lockdep perspective you are running the entire guest with IRQs off ? > that doesn't sound right... Yup. We're running the entire guest with IRQs off. Do you have any better idea how to make sure that we're atomic wrt signal delivery? Alex -- 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
