Olaf Hering <olaf@xxxxxxxxx> writes: > On Thu, Dec 15, Vitaly Kuznetsov wrote: > >> We actually need to read the reply and empty the message slot to make >> unload happen. And reading on a different CPU may not work, see: >> >> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2016-December/097330.html > > Does the following sentences mean the vmbus_signal_eom in > vmbus_wait_for_unload is a noop because the wrmsrl() is expected to > happen on the other cpu instead of the current cpu? > > ... > - When we read the message we need to clear the slot and signal the fact > to the hypervisor. In case there are more messages to this CPU pending > the hypervisor will deliver the next message. The signaling is done by > writing to an MSR so this can only be done on the appropriate CPU. > ... > -> K. Y., but these words were written before I implemented vmbus_wait_for_unload(), to me they just explain how we read messages. 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). -- Vitaly _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
