On 11.07.2013, at 14:54, Benjamin Herrenschmidt wrote: > On Thu, 2013-07-11 at 14:47 +0200, Alexander Graf wrote: >>> Yes of course, that's what we call "soft disabled" :-) It's even the >>> whole point of doing lazy disable... >> >> Meh. Of course it's soft_enabled = 1; hard_enabled = 0. > > That doesn't happen in "normal" C code. It happens under very specific > circumstances, such as in the guts of entry_64.S, in areas where we just > want to temporarily mask HW interrupts without changing the SW state > (and thus without having to deal with replays etc...). > > We typically also do that right before going to idle on some processors > where we come back from idle with interrupts hard enabled, possibly > right in an interrupt vector. > > Typically that's a state that makes some sense on KVM entry. From a > Linux perspective, you enter KVM with interrupts enabled. But you > temporarily hard disable on the way down while doing the low level > context switch. > > This works well as long as you know you have no pending replay event. > That should be fine if you do a direct transition from soft+hard enabled > to hard disabled (without soft disabling). In that case there should be > nothing in irq_happened. > > It's equivalent to returning to userspace from the kernel. We are > soft-enabled, but the code in ret_from_except hard disables while > mucking around with TIF_FLAGS etc... until the final rfid Ok, let me quickly explain the problem. We are leaving host context, switching slowly into guest context. During that transition we call get_paca() indirectly (apparently by another call to hard_disable() which sounds bogus, but that's another story). get_paca() warns when we're preemptible. We're only not preemptible when either preempt is disabled or irqs are disabled. Irqs are disabled, but arch_irqs_disabled() doesn't know, because it only checks for soft disabled IRQs. So we can fix this either by setting IRQs as soft disabled as well or by disabling preemption until we enter the guest for real. Any preferences? 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
