Olaf Hering <olaf@xxxxxxxxx> writes: > On Thu, Dec 15, Vitaly Kuznetsov wrote: > >> vmbus_wait_for_unload() may be receiving a message (not necessarily the >> CHANNELMSG_UNLOAD_RESPONSE, we may see some other message) on the same >> CPU it runs and in this case wrmsrl() makes sense. In other cases it >> does nothing (neither good nor bad). > > If that other cpu has interrupts disabled it may not process a pending > msg (the response may be stuck in the host queue?), and the loop can not > kick the other cpus queue if a wrmsrl is just valid for the current cpu. > If thats true, the response will not arrive in the loop. > In case interrupts get permanently disabled on the CPU which is supposed to receive the CHANNELMSG_UNLOAD_RESPONSE message *and* there is some other message pedning in the slot for that CPU we'll hang. We may try to overcome this by sending NMIs but this is getting more and more complicated... I'd like to see a simple fix from Hyper-V host team: always deliver CHANNELMSG_UNLOAD_RESPONSE reply to the cpu which sent CHANNELMSG_UNLOAD request. This would allow us to remove all the craziness. -- Vitaly _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
