On Mon, Feb 20, 2012 at 12:49:46PM +0100, Alexander Graf wrote: > > On 17.02.2012, at 22:55, Scott Wood wrote: > > > On 02/17/2012 11:13 AM, Alexander Graf wrote: > >> case BOOKE_IRQPRIO_EXTERNAL: > >> +#ifdef CONFIG_KVM_E500MC > >> + case BOOKE_IRQPRIO_DBELL: > >> +#endif > > > > This isn't e500mc specific -- it's in the ISA as "Embedded.Processor > > Control". > > > > Any harm in just removing the ifdef (similar to tlbilx)? > > Well, to me this is more of an indication "this should become a runtime > check one day" in case we want to combine the two targets. On e500v2, > we don't know what a doorbell interrupt is, so we really shouldn't be > delivering one either. Should at least have a comment saying that eventually the decision should be based on ISA category support rather than e500mc. > > Should this be a kvm_make_request instead (with a separate > > pending_doorbell bool in vcpu that msgclr can act on), considering > > earlier discussion of phasing out atomics on pending_exceptions, in > > favor of requests? > > Yeah, I was thinking about that too, but right now we already have some > direct use of pending_exceptions in different places around the code. > So today, that is our public interface. > > I'd rather go in and clean up the whole thing to make > pending_exceptions private in a separate cleanup round, rather than > having it part of e500mc support. We already use requests for timers, and it seems simple enough to add one for doorbells now rather than come back and clean it up later (it's not tied to what we'd have to do for external IRQs), but if you'd rather do it later that's fine with me. -Scott -- 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
