Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel
From: Vitaly Kuznetsov
Date: Thu Dec 15 2016 - 08:28:23 EST
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:
> 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).