From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Thu, 26 Apr 2012 23:37:50 +0000 Subject: Re: [PATCH 2/2] KVM: PPC: Book3S: Call into C interrupt handlers Message-Id: <1335483470.21961.89.camel@pasglop> List-Id: References: <1335435543-19690-1-git-send-email-agraf@suse.de> <1335435543-19690-2-git-send-email-agraf@suse.de> <1335476747.21961.82.camel@pasglop> <4054E139-FF68-471B-B69C-9F76D75CA451@suse.de> <1335481976.21961.87.camel@pasglop> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexander Graf Cc: kvm list , kvm-ppc 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). > > 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... Cheers, Ben.