From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kumar Gala Subject: Re: [PATCH 12/38] powerpc/booke: Provide exception macros with interrupt name Date: Wed, 21 Mar 2012 15:20:59 -0500 Message-ID: References: <1330474206-14794-1-git-send-email-agraf@suse.de> <1330474206-14794-13-git-send-email-agraf@suse.de> <29EC69C4-816F-4B9E-9834-71176D2DECB9@kernel.crashing.org> <4F6A1B99.9030105@freescale.com> Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Alexander Graf , , , To: Scott Wood Return-path: In-Reply-To: <4F6A1B99.9030105@freescale.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Mar 21, 2012, at 1:19 PM, Scott Wood wrote: > On 03/21/2012 01:04 PM, Kumar Gala wrote: >> >> On Feb 28, 2012, at 6:09 PM, Alexander Graf wrote: >> >>> From: Scott Wood >>> >>> DO_KVM will need to identify the particular exception type. >>> >>> There is an existing set of arbitrary numbers that Linux passes, >>> but it's an undocumented mess that sort of corresponds to server/classic >>> exception vectors but not really. >> >> So what do the new names correspond to? > > The names are Linux-defined. The values are IVOR numbers. > >> What header is defining MACHINE_CHECK, BOOKE_INTERRUPT_EXTERNAL, etc >> (asm/kvm_asm.h)? > > Yes, it's asm/kvm_asm.h at the moment. > > It's actually BOOKE_INTERRUPT_MACHINE_CHECK, etc. The exception macros > paste on BOOKE_INTERRUPT_ when they use it, to keep the macro users from > having to wrap lines even more often. > >> If so we really should move these out of >> asm/kvm_asm.h and into something a bit more appropriate. > > Yes, that was one of the things I had been planning to fix post-RFC. > Any preference what header it should be in? asm/reg_booke.h seems to be > the least bad option of the existing headers -- or perhaps move > head_booke.h to arch/powerpc/include/asm. asm/reg_booke.h seems the least painful right now. head_booke.h is only used on 32-bit so that's not the best choice at this point. We could create an in addition to the one in arch/powerpc/kernel/ > Long-term it would also be nice for this to replace, rather than > supplement, the current numbers, though as Ben pointed out there are a > number of places throughout the code that will have to be fixed for that > to happen. Yeah, not too worried about that. More just wanting it to be clear what one has to 'update' if adding support for a new exception. - k