On Mon, 2009-06-29 at 04:25 -0700, Gleb Natapov wrote: > I left interrupt masking in enable_IR_x2apic() because interrupt should > be masked during transition to x2apic mode, so it can't be moved to > enable_IR(). I moved io-apic into enable_IR() because the state of > io-apic depend on whether IR was enabled or not, so I left it close to > IR enabling logic. This can be based on the outcome of enable_IR(). > Also io-apic masking can fail, but we still want to > enable x2apic on KVM if possible, and moving io-apic masking to > enable_IR_x2apic() will complicate the logic. io-apic masking can fail because of memory allocation failures, right? If we want a simple solution, we can skip both x2apic and IR. This is not going to be common scenario anyhow. If we really hit this, we will worry about more things than x2apic :) > > > Can we keep it together so that it will be easy to read and understand > > that we first do the interrupt subsystem mask, try enabling IR and > > x2apic and unmask the interrupt subsystem. > > > For io-apic this is not 100% symmetric. We mask io-apic, enable IR and > if this succeeds we do not unmask io-apic. Correct. Can we do the same, otherwise we might have a situation (under kvm atleast) where io-apic will be active while we will be changing the cpu mode. Just trying to be defensive as these might lead to hard to debug corner case conditions. thanks, suresh -- 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
